Subject: Re: [Capwap] Issue 158: Allocation of WBIDs

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 13 Aug 2008 14:42:56 -0700

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: [email-masked]; [email-masked]
Cc: [email-masked]
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: [email-masked] [mailto:[email-masked]]
Sent: Tuesday, July 29, 2008 2:59 AM
To: [email-masked]; Pat Calhoun (pacalhou)
Cc: [email-masked]
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:[email-masked]]
> Sent: 29 July, 2008 11:55
> To: Pat Calhoun
> Cc: [email-masked]; 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
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: <[email-masked]>
Date: Mon, 18 Aug 2008 22:09:41 +0300

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 

> From: ext Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: 14 August, 2008 00:43
> To: Pat Calhoun (pacalhou); Eronen Pasi (Nokia-NRC/Helsinki); 
> [email-masked]
> Cc: [email-masked]
> 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 
>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 18 Aug 2008 14:49:06 -0700

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: [email-masked] [mailto:[email-masked]] 
Sent: Monday, August 18, 2008 12:10 PM
To: Pat Calhoun (pacalhou); [email-masked]
Cc: [email-masked]
Subject: RE: [Capwap] Issue 158: Allocation of WBIDs

(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 

> 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
> 
> 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
> 
> 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
>

---

From: <[email-masked]>
Date: Tue, 19 Aug 2008 11:54:25 +0300

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 

> Sent: 19 August, 2008 00:49
> To: Eronen Pasi (Nokia-NRC/Helsinki); [email-masked]
> Cc: [email-masked]

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 19 Aug 2008 07:22:06 -0700

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: [email-masked] [mailto:[email-masked]] 
Sent: Tuesday, August 19, 2008 1:54 AM
To: Pat Calhoun (pacalhou); [email-masked]
Cc: [email-masked]
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 

> 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.
> free, but others are not. EPCGlobal and the WiFi Alliance does not 
> make their documents available to non-members.
> 
> <new text>
> 15.  IANA Considerations
> [...]