Re: Issue 158: Allocation of WBIDs
From: Pat Calhoun (pacalhou) (pcalhouncisco.com)
Date: Mon, 18 Aug 2008 14:49:14 -0700 (PDT)
Yes, I agree we need to provide some guidance.

I would recommend the following text added to the end of section 15.
Note that I have crafted the wording very carefully because unlike other
standards, the CAPWAP protocol will be used by other SDOs, who have
policies that do not allow for the public sharing of their documents.
The IEEE is one such example where some standards are available for
free, but others are not. EPCGlobal and the WiFi Alliance does not make
their documents available to non-members.

<new text>
15.  IANA Considerations
[...]
   For registration requests where an Expert Review is required, a
   Designated Expert should be consulted, which is appointed by the
   responsible IESG area director.  The intention is that any allocation
   will be accompanied by a published RFC, but given that other SDOs may
   want to create standards built on top of CAPWAP, a document the
   Designated Expert can review is also acceptable.  IANA should allow
   for allocation of values prior to documents being approved for
   publication, so the Designated Expert can approve allocations once it
   seems clear that publication will occur.  The Designated expert will
   post a request to the CAPWAP WG mailing list (or a successor
   designated by the Area Director) for comment and review.  Before a
   period of 30 days has passed, the Designated Expert will either
   approve or deny the registration request and publish a notice of the
   decision to the CAPWAP WG mailing list or its successor, as well as
   informing IANA.  A denial notice must be justified by an explanation,
   and in the cases where it is possible, concrete suggestions on how
   the request can be modified so as to become acceptable should be
   provided.
</new text> 

PatC
-----Original Message-----
From: Pasi.Eronen [at] nokia.com [mailto:Pasi.Eronen [at] nokia.com] 
Sent: Monday, August 18, 2008 12:10 PM
To: Pat Calhoun (pacalhou); margaret [at] thingmagic.com
Cc: capwap [at] frascone.com
Subject: RE: [Capwap] Issue 158: Allocation of WBIDs

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
> 

Results generated by Tiger Technologies using MHonArc.