Capwap Mailing List: Re: Issue 158: Allocation of WBIDs

[Pasi.Eronen (Pasi.Eronen]

Not an objection, but note the following text in RFC 5226:

   "The required documentation and review criteria for use by the
   Designated Expert should be provided when defining the registry.

(In particular, the WBID field is only 5 bits, so it's not an infinite
supply -- especially if new 802.11xx features may require new WBIDs,
as was suggested in discussion around issue 171.)

Best regards,
Pasi 

> -----Original Message-----
> From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] 
> Sent: 14 August, 2008 00:43
> To: Pat Calhoun (pacalhou); Eronen Pasi (Nokia-NRC/Helsinki); 
> margaret [at] thingmagic.com
> Cc: capwap [at] frascone.com
> Subject: RE: [Capwap] Issue 158: Allocation of WBIDs
> 
> Folks, in order to move this one along, I would recommend that we
> change the current IANA considerations from Standards Action to
> Expert Review.  This would alleviate many of the issues brought up
> for both the WBID, the message element and the EPCGlobal WBID
> allocation.
> 
> Objections?
> 
> PatC 
> 
> -----Original Message-----
> From: Pat Calhoun (pacalhou) 
> Sent: Wednesday, July 30, 2008 3:42 PM
> To: Pasi.Eronen [at] nokia.com; margaret [at] thingmagic.com
> Cc: capwap [at] frascone.com
> Subject: Re: [Capwap] Issue 158: Allocation of WBIDs
> 
> Correct, Pasi. The current IANA classification requires a Standards
> track RFC for assignment of WBIDs (and every other namespace in the
> document). I suspect that if EPCGlobal is using their own Enterprise
> Number for control message types, then it is less of an 
> issue. However,
> the message element types are still global, and therefore 
> unless you are
> using the vendor specific message element, you would need an RFC.
> 
> So what I'm hearing is remove 802.16, and keep 802.11 and 
> EPCGlobal. We
> just need to work out the details of the IANA classification.
> 
> PatC 
> 
> -----Original Message-----
> From: Pasi.Eronen [at] nokia.com [mailto:Pasi.Eronen [at] nokia.com]
> Sent: Tuesday, July 29, 2008 2:59 AM
> To: margaret [at] thingmagic.com; Pat Calhoun (pacalhou)
> Cc: capwap [at] frascone.com
> Subject: Re: [Capwap] Issue 158: Allocation of WBIDs
> 
> 
> Ok -- but if the intent is to allow CAPWAP bindings (and 
> possibly other
> types of CAPWAP specifications) to be developed outside IETF Standards
> Track, then the IANA instructions need to be something else than
> "Standards Action".
> 
> Best regards,
> Pasi
> 
> > -----Original Message-----
> > From: ext Margaret Wasserman [mailto:margaret [at] thingmagic.com]
> > Sent: 29 July, 2008 11:55
> > To: Pat Calhoun
> > Cc: capwap [at] frascone.com; Eronen Pasi (Nokia-NRC/Helsinki)
> > Subject: Re: [Capwap] Issue 158: Allocation of WBIDs
> > 
> > >
> > > Frankly, I don't care much whether we adopt this proposed
> > change. The
> > > IEEE 802.11 binding specification does not include the 
> WBID value, 
> > > so a change would be required for that specification. The bigger
> > change, I
> > > suspect, is on the EPCGlobal spec. Of particular note, the
> > CAPWAP spec
> > > currently requires a Standards Action to allocate one of these 
> > > numbers, and since the RFID CAPWAP specification is being 
> published 
> > > by EPCGlobal, and not the IETF, I'm not sure how they could get a 
> > > number assigned.
> > > Margaret, you are closer to this than I am, so do you have any 
> > > recommendations?
> > 
> > (Wearing my EPCglobal hat)
> > 
> > The EPCglobal Discovery Configuration and Initialization (DCI) 
> > specification defines a CAPWAP binding for RFID readers.  
> It is very 
> > nearly complete after ~1-1/2 years of work.  EPCglobal requires 
> > interoperability testing before they will ratify a 
> standard, and that 
> > testing was completed last week.  Final ratification of the 
> EPCglobal
> > standard is now blocked on getting an RFC number for CAPWAP.   
> > EPCglobal doesn't have any plans to publish DCI as an IETF 
> standards 
> > track document.
> > 
> > The work in EPCglobal was done based on the CAPWAP WG's 
> agreement to 
> > assign an binding ID for that purpose in the CAPWAP spec.  While I 
> > agree that further binding IDs need to be defined in their 
> bindings, I
> 
> > think it would be pretty late to change the agreement with 
> EPCglobal 
> > now.
> > 
> > > Finally, removing the IEEE 802.16 from the list is not a problem, 
> > > and I agree that if there is ever a specification that 
> defines the 
> > > use of CAPWAP for 802.16, then the number would be 
> assigned at that 
> > > time.
> > 
> > That would be fine with me, as the 802.16 binding doesn't exist, 
> > AFAIK.
> > 
> > Margaret
> > 
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
> _________________________________________________________________
> To unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
> 
> Archives: http://lists.frascone.com/pipermail/capwap
>