Subject: [Capwap] Issue 158: Allocation of WBIDs

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 28 Jul 2008 13:31:51 -0700

Pasi's comment was:

   Section 4.3: it seems that allocation of WBIDs (and message element
numbers in 
   4.6) would be better done in the document specifying the binding.
Considering 
   that WBID allocations require Standards Action, especially allocating
WBIDs 
   for technologies for which not even an Internet-Draft exists yet
seems 
   premature.

The current text reads:

<current text>
4.3.  CAPWAP Header
[...]
   WBID:  A 5 bit field which is the wireless binding identifier.  The
      identifier will indicate the type of wireless packet associated
      with the radio.  The following values are defined:

      0 -  Reserved

      1 -  IEEE 802.11

      2 -  IEEE 802.16

      3 -  EPCGlobal [EPCGlobal]
</current text>

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?

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.

So if the change were to be made, the new text would read:

<new base text>
4.3.  CAPWAP Header
[...]
   WBID:  A 5 bit field which is the wireless binding identifier.  The
      identifier will indicate the type of wireless packet associated
      with the radio. 
</new base text>

<new IEEE 802.11 binding text>
2.1.  CAPWAP Wireless Binding Identifier

   The CAPWAP Header, defined in section 4.3 of
   [I-D.ietf-capwap-protocol-specification] requires that all CAPWAP
   binding specifications have a Wireless Binding Identifier (WBID)
   assigned.  This document, which defines the IEEE 802.11 binding, uses
   the the value one (1).

10.  IANA Considerations

10.1.  CAPWAP Wireless Binding Identifier

   This specification defines a new Wireless Binding Identifier, which
   is used in the CAPWAP header.  This value is defined in Section 2.1.
</new IEEE 802.11 binding text>

PatC
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 29 Jul 2008 09:55:14 +0100

> Margaret, you are closer to this than I am, so do you have any

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

> 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

---

From: <[email-masked]>
Date: Tue, 29 Jul 2008 12:58:39 +0300

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 30 Jul 2008 15:42:06 -0700

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

Best regards,
Pasi

> > IEEE 802.11 binding specification does not include the WBID value, 
> > so a change would be required for that specification. The bigger
> change, I
> > 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.
> 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.
>