Subject: [Capwap] CAPWAP IESG Issue T5

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Mon, 16 Jun 2008 08:35:54 -0700

Here is the IESG Issue:

   T5 - Section 4.3, pag 47 - As I understand the 5 bit field encodes 32
possible 
   wireless bindings (i.e. it's not a bit mask). If true it would be
good to make this 
   explicit. My question is whether there is any reason to start with
value 1 and not 
   with value 0? Assuming this is already deployed, will 0 be a value to
use, or does 
   it have any special significance?

No, this is not a bitmask. I'm not actually sure how to explicitely
state it isn't a bitmask, because in my mind any field is not a bitmask
unless it is explicitely stated, so I will use the term numerical.
Further, there is no reason why zero cannot be used, so I'll renumber
the fields to start at zero.

So I am proposing the following text:

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

      0 -  IEEE 802.11
      1 -  IEEE 802.16
      2 -  EPCGlobal
</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: "David B. Nelson" <[email-masked]>
Date: Mon, 16 Jun 2008 12:35:21 -0400

> unless it is explicitely stated, so I will use the term numerical.

Or maybe the term "enumerated value"?

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 16 Jun 2008 20:09:00 +0200

OK with me, with the terminology suggested by David Nelson - say clearly
these are enumerated values.  

Dan

> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Monday, June 16, 2008 6:36 PM
> To: [email-masked]
> Subject: [Capwap] CAPWAP IESG Issue T5
> 
> Here is the IESG Issue:
> 
>    T5 - Section 4.3, pag 47 - As I understand the 5 bit field 
> encodes 32 possible 
>    wireless bindings (i.e. it's not a bit mask). If true it 
> would be good to make this 
>    explicit. My question is whether there is any reason to 
> start with value 1 and not 
>    with value 0? Assuming this is already deployed, will 0 be 
> a value to use, or does 
> No, this is not a bitmask. I'm not actually sure how to 
> explicitely state it isn't a bitmask, because in my mind any 
> field is not a bitmask unless it is explicitely stated, so I 
> will use the term numerical.
> Further, there is no reason why zero cannot be used, so I'll 
> renumber the fields to start at zero.
>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 17 Jun 2008 11:49:38 -0400

Hi Pat,

I agree with your answer -- this is not a bitmask.

But, I'd personally prefer that we _not_ renumber the fields at this  
point.  If we do renumber them, this will make -11 incompatible with  
-10 in a way that I don't feel is justified by the benefit.  Instead,  
I'd personally prefer that you list 0 as "reserved for future use"  
and make it clear in the IANA considerations section that value 4-31  
are available for IANA allocation.

There are already implementations of CAPWAP, and EPCglobal is  
planning an interoperability event in July (for the base CAPWAP spec  
and the EPCglobal DCI specification), so I think it is too late to  
start renumbering fields without an important technical reason to do so.

Margaret

On Jun 16, 2008, at 11:35 AM, Pat Calhoun (pacalhou) wrote:

> encodes 32

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 18 Jun 2008 18:42:01 -0700

OK, again I need you and Dan to agree. I will make whatever change is
necessary.

Dan are you ok with zero being marked as reserved?

PatC 

-----Original Message-----
From: Margaret Wasserman [mailto:[email-masked]] 
Sent: Tuesday, June 17, 2008 8:50 AM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] CAPWAP IESG Issue T5

Hi Pat,

But, I'd personally prefer that we _not_ renumber the fields at this
point.  If we do renumber them, this will make -11 incompatible with -10
in a way that I don't feel is justified by the benefit.  Instead, I'd
personally prefer that you list 0 as "reserved for future use"  
and make it clear in the IANA considerations section that value 4-31 are
available for IANA allocation.

There are already implementations of CAPWAP, and EPCglobal is planning
an interoperability event in July (for the base CAPWAP spec and the
EPCglobal DCI specification), so I think it is too late to start
renumbering fields without an important technical reason to do so.

Margaret

On Jun 16, 2008, at 11:35 AM, Pat Calhoun (pacalhou) wrote:

> Here is the IESG Issue:
>
>    T5 - Section 4.3, pag 47 - As I understand the 5 bit field encodes 
> 32 possible
>    with value 0? Assuming this is already deployed, will 0 be a value 
> to use, or does
> state it isn't a bitmask, because in my mind any field is not a 
> bitmask unless it is explicitely stated, so I will use the term 
> numerical.

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 18 Jun 2008 22:20:15 -0700

Ok, that sounds good. I have made the necessary changes throughout the
spec.

<text>
4.6.1.  AC Descriptor
[...]
      AC Information Type:   Vendor specific encoding of AC information.
         The following enumerated values are supported.  Both the
         Hardware and Software Version sub-elements MUST be included in
         the AC Descriptor message element.

4.6.15.  CAPWAP Transport Protocol
[...]
   Transport:   The transport to use for the CAPWAP data channel.  The
      following enumerated values are supported:

4.6.16.  Data Transfer Data
[...]
   Data Type:   An 8-bit value the type of information being sent.  The
      following enumerated values are supported:

4.6.17.  Data Transfer Mode
[...]
   Data Type:   An 8-bit value the type of information being requested.
      The following enumerated values are supported:

4.6.23.  Discovery Type
[...]
   Discovery Type:   An 8-bit value indicating how the WTP discovered
      the AC.  The following enumerated values are supported:

4.6.27.  Image Data
[...]
   Opcode:   An 8-bit value representing the transfer opcode.  The
      following enumerated values are supported:

4.6.33.  Radio Administrative State
[...]
   Admin State:   An 8-bit value representing the administrative state
      of the radio.  The default value for the Admin State field is
      listed in Section 4.8.1.  The following enumerated values are
      supported:

4.6.34.  Radio Operational State
[...]
   Cause:   When a radio is inoperable, the cause field contains the
      reason the radio is out of service.  The following enumerated
      values are supported:

4.6.35.  Result Code
[...]
   Result Code:   The following enumerated values are defined:

4.6.36.  Returned Message Element
[...]
   Reason:   The reason why the configuration in the offending message
      element could not be applied by the WTP.  The following enumerated
      values are supported:

4.6.42.  WTP Fallback
[...]
   Mode:   The 8-bit value indicates the status of automatic CAPWAP
      fallback on the WTP.  When enabled, if the WTP detects that its
      primary AC is available, and that the WTP is not connected to the
      primary AC, the WTP SHOULD automatically disconnect from its
      current AC and reconnect to its primary AC.  If disabled, the WTP
      will only reconnect to its primary AC through manual intervention
      (e.g., through the Reset Request message).  The default value for
      this field is specified in Section 4.8.11.  The following
      enumerated values are supported:

4.6.46.  WTP MAC Type
[...]
   MAC Type:   The MAC mode of operation supported by the WTP.  The
      following enumerated values are supported:

4.6.49.  WTP Radio Statistics
[...]
   Last Failure Type:   The last WTP failure.  The following enumerated
      values are supported:

4.6.50.  WTP Reboot Statistics
[...]
   Last Failure Type:   The failure type of the most recent WTP failure.
      The following enumerated values are supported:

</text>

PatC
</text> 

-----Original Message-----
From: David B. Nelson [mailto:[email-masked]] 
Sent: Monday, June 16, 2008 9:35 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: Re: [Capwap] CAPWAP IESG Issue T5

numerical.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 19 Jun 2008 09:15:17 +0200

Yes, I can live with this. 

Dan

> Sent: Thursday, June 19, 2008 4:42 AM
> To: Margaret Wasserman
> Cc: [email-masked]
> OK, again I need you and Dan to agree. I will make whatever 
> change is necessary.
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 19 Jun 2008 09:15:38 +0200

OK with me. 

Dan

> Sent: Thursday, June 19, 2008 8:20 AM
> To: David B. Nelson; [email-masked]
> Ok, that sounds good. I have made the necessary changes 
> throughout the spec.
> 
> <text>
> 4.6.1.  AC Descriptor
> [...]

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 19 Jun 2008 09:19:52 -0700

Great, changed the terminology and marked the value zero as "reserved".

Closing issue 46.

PatC 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Thursday, June 19, 2008 12:16 AM
To: Pat Calhoun (pacalhou); David B. Nelson; [email-masked]
Subject: Re: [Capwap] CAPWAP IESG Issue T5

OK with me. 

Dan