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

[Pat Calhoun (pacalhou) (pcalhoun]

I think the problem is that it is unclear exactly what kind of requests
we can expect in the future. The text at least calls for a designated
expert, who understands the scarcity issues, and requires him to post
the request to the CAPWAP mailing list. This seems to me to provide the
proper set of checks and balances to only assign numbers when the
request is valid.

The problem with the term SDO is that there are many pseudo-SDOs out
there. For instance, EPCGlobal is not an SDO. They are a marketing
organization who just happen to dabble in the creation of protocols from
time to time. Same with WiFi Alliance. So using a hard term like SDO
would like who can/cannot allocate numbers, and IMHO, would stiffle
innovation.

So I do believe that the current guidance offers as good a
recommendation to IANA as any. It does not restrict anyone from asking,
but at the same time, it requires that some trusted entity that is well
versed in the protocol limitations and challenges is engaged in
allocation requests.

PatC 

-----Original Message-----
From: Pasi.Eronen [at] nokia.com [mailto:Pasi.Eronen [at] nokia.com] 
Sent: Tuesday, August 19, 2008 1:54 AM
To: Pat Calhoun (pacalhou); margaret [at] thingmagic.com
Cc: capwap [at] frascone.com
Subject: RE: [Capwap] Issue 158: Allocation of WBIDs


Looks good, but it still doesn't provide much guidance about what kinds
of requests should be approved. If a request comes from a group calling
itself an "SDO", and a reasonably well-written technical specification
is available, should it be granted?

RFC 5226 says that "presumption should be that a code point should be
granted, unless there is a compelling reason to the contrary", but then
continues to list scarcity of code points as one reason to change this.
At least some bit fields and WBIDs look like a very scarce resource to
me (and BTW, if there wasn't the concern about backward compatibility,
I'd recommend changing WBIDs to 16 bits, and enlarging some other
fields, too).

Best regards,
Pasi 

> -----Original Message-----
> From: ext Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com]
> Sent: 19 August, 2008 00:49
> To: Eronen Pasi (Nokia-NRC/Helsinki); margaret [at] thingmagic.com
> Cc: capwap [at] frascone.com
> Subject: RE: [Capwap] Issue 158: Allocation of WBIDs
> 
> 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
> > 
>