Subject: [Capwap] CAPWAP IESG Review Comment T12

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

All,

The following is the IESG Comment Review:

   T12 - Section 4.6.1 - in the AC Descriptor protocol diagram delete =4
from the Type 
   filed (it can be 4 or 5 as I understand)

Actually, the reason why this is part of the diagram is because both 4
and 5 MUST be included (as described in the field description). So in
order to make this much clearer, we have included this in the diagram.

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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 16 Jun 2008 20:13:34 +0200

I won't fight this to death but I still find it confusing. Writhing 4 in
a field which can be either 4 or 5 may confuse other as well. What about
4/5? 

Dan

> -----Original Message-----
> From: Pat Calhoun (pacalhou) [mailto:[email-masked]] 
> Sent: Monday, June 16, 2008 6:40 PM
> To: [email-masked]
> Subject: [Capwap] CAPWAP IESG Review Comment T12
> 
> All,
> 
>    T12 - Section 4.6.1 - in the AC Descriptor protocol 
> diagram delete =4 from the Type 
> Actually, the reason why this is part of the diagram is 
> because both 4 and 5 MUST be included (as described in the 
> field description). So in order to make this much clearer, we 
> have included this in the diagram.
> 
> PatC

---

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

I think 4/5 is odd, personally. However, I think I have a better idea,
and one that I think will be MUCH clearer. In order to help express the
idea, I will include the whole text for the AC Descriptor section. If
this format works for you, I will replicate it in another two areas in
the spec that I had updated due to another IESG review comment.

<text>
4.6.1.  AC Descriptor

   The AC Descriptor message element is used by the AC to communicate
   its current state.  The value contains the following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |            Stations           |             Limit             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |          Active WTPs          |            Max WTPs           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    Security   |  R-MAC Field  |   Reserved1   |  DTLS Policy  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       AC Information...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   1 for AC Descriptor

   Length:   >= 12

   Stations:   The number of stations currently served by the AC

   Limit:   The maximum number of stations supported by the AC

   Active WTPs:   The number of WTPs currently attached to the AC

   Max WTPs:   The maximum number of WTPs supported by the AC

   Security:   A 8 bit mask specifying the authentication credential
      type supported by the AC.  The following values are supported (see
      Section 2.4.4):

      1 -  X.509 Certificate Based

      2 -  Pre-Shared Secret

   R-MAC Field:   The AC supports the optional Radio MAC Address field
      in the CAPWAP transport Header (see Section 4.3).

   Reserved:  A set of reserved bits for future use.  All
      implementations complying with this protocol MUST set to zero any
      bits that are reserved in the version of the protocol supported by
      that implementation.  Receivers MUST ignore all bits not defined
      for the version of the protocol they support.

   DTLS Policy:   The AC communicates its policy on the use of DTLS for
      the CAPWAP data channel.  The AC MAY communicate more than one
      supported option, represented by the bit field below.  The WTP
      MUST abide by one of the options communicated by AC.  The
      following bit field values are supported:

      1 -  Clear Text Data Channel Supported

      2 -  DTLS Enabled Data Channel Supported

   AC Information:   The AC Descriptor message element contains multiple
      AC Information sub-elements, and defines two sub-types, each of
      which MUST be present.  The AC Information sub-element has the
      following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                AC Information Vendor Identifier               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      AC Information Type      |     AC Information Length     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                     AC Information Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      AC Information Vendor Identifier:   A 32-bit value containing the
         IANA assigned "SMI Network Management Private Enterprise Codes"

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

         4 - Hardware Version:   The AC's hardware version number.

         5 - Software Version:   The AC's Software (firmware) version
            number.

      AC Information Length:   Length of vendor specific encoding of AC
         information, with a maximum size of 1024.

      AC Information Data:   Vendor specific encoding of AC information.
</text> 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, June 16, 2008 11:14 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: Re: [Capwap] CAPWAP IESG Review Comment T12

Dan

>    T12 - Section 4.6.1 - in the AC Descriptor protocol diagram delete 
> =4 from the Type

---

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

Given that Dan was comfortable with proposed change to the AC Descriptor
message element. I am proposing to make the same change to two other
similar message elements in the base protocol. This does not change the
packet format in any way, and therefore does not introduce any
compatibility issues. I think it simply provides more clarity on the
format and expected contents.

<text>
4.6.40.  WTP Board Data

   The WTP Board Data message element is sent by the WTP to the AC and
   contains information about the hardware present.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Board Data Sub-Element...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   40 for WTP Board Data

   Length:   >=14

   Vendor Identifier:   A 32-bit value containing the IANA assigned "SMI
      Network Management Private Enterprise Codes"

   Board Data Sub-Element:   The WTP Board Data message element contains
      multiple Board Data sub-elements, some of which are mandatory and
      some are optional, as described below.  The Board Data sub-element
      has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Vendor Identifier                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Board Data Type        |       Board Data Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                      Board Data Value...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Board Data Type:   The Board Data Type field identifies the data
         being encoded.  The CAPWAP protocol defines the following
         values, and each of these types identify whether their presence
         is mandatory or optional:

         0 - WTP Model Number:   The WTP Model Number MUST be included
            in the WTP Board Data message element.

         1 - WTP Serial Number:   The WTP Serial Number MUST be included
            in the WTP Board Data message element.

         2 - Board ID:   A hardware identifier, which MAY be included in
            the WTP Board Data message element.

         3 - Board Revision   A revision number of the board, which MAY
            be included in the WTP Board Data message element.

         4 - Base MAC Address   The WTP's Base MAC Address, which MAY be
            assigned to the primary Ethernet interface.

      Board Data Length:   The length of the data in the Board Data
         Value field, whose length MUST NOT exceed 1024 octets.

      Board Data Value:   The data associated with the Board Data Type
         field for this Board Data sub-element.
 
4.6.41.  WTP Descriptor

   The WTP Descriptor message element is used by a WTP to communicate
   its current hardware and software (firmware) configuration.  The
   value contains the following fields.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Max Radios  | Radios in use |    Encryption Capabilities    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                   Descriptor Sub-Element...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type:   41 for WTP Descriptor

   Length:   >= 31

   Max Radios:   An 8-bit value representing the number of radios (where
      each radio is identified via the Radio ID field) supported by the
      WTP.

   Radios in use:   An 8-bit value representing the number of radios in
      use in the WTP.

   Encryption Capabilities:   This 16-bit field is used by the WTP to
      communicate its capabilities to the AC.  A WTP that does not have
      any encryption capabilities sets this field to zero (0).  Refer to
      the specific wireless binding for further specification of the
      Encryption Capabilities field.

   Descriptor Sub-Element:   The WTP Descriptor message element contains
      multiple Descriptor sub-elements, some of which are mandatory and
      some are optional, as described below.  The Descriptor sub-element
      has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                  Descriptor Vendor Identifier                 |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |        Descriptor Type        |       Descriptor Length       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                       Descriptor Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Descriptor Vendor Identifier:   A 32-bit value containing the IANA
         assigned "SMI Network Management Private Enterprise Codes".

      Descriptor Type:   The Descriptor Type field identifies the data
         being encoded.  The CAPWAP protocol defines the following
         values, and each of these types identify whether their presence
         is mandatory or optional:

         0 - Hardware Version:   The WTP hardware version number MUST be
            present.

         1 - Active Software Version:   The WTP running software version
            number MUST be present.

         2 - Boot Version:   The WTP boot loader version number MUST be
            present.

         3 - Other Software Version:   The WTP non-running software
            (firmware) version number MAY be present.  This type is used
            to communicate alternate software versions that are
            available on the WTP's non-volatile storage.

      Descriptor Length:   Length of vendor specific encoding of
         Descriptor Data field, whose length MUST NOT exceed 1024
         octets.

      Descriptor Data:   Vendor specific data of WTP information encoded
         in the UTF-8 format.
</text>

PatC

-----Original Message-----
From: Pat Calhoun (pacalhou) 
Sent: Wednesday, June 18, 2008 10:06 PM
To: Romascanu, Dan (Dan); [email-masked]
Subject: Re: [Capwap] CAPWAP IESG Review Comment T12

<text>
4.6.1.  AC Descriptor

      0                   1                   2                   3

   Length:   >= 12

      2 -  Pre-Shared Secret

      0                   1                   2                   3

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]]
Sent: Monday, June 16, 2008 11:14 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: Re: [Capwap] CAPWAP IESG Review Comment T12

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 20 Jun 2008 09:06:33 +0200

OK with me. 

Dan

> Sent: Friday, June 20, 2008 3:07 AM
> To: Pat Calhoun (pacalhou); Romascanu, Dan (Dan); [email-masked]
> Subject: RE: [Capwap] CAPWAP IESG Review Comment T12
> 
> Given that Dan was comfortable with proposed change to the AC 
> Descriptor message element. I am proposing to make the same 
> change to two other similar message elements in the base 
> protocol. This does not change the packet format in any way, 
> and therefore does not introduce any compatibility issues. I 
> think it simply provides more clarity on the format and 
> expected contents.
> 
> <text>
> 4.6.40.  WTP Board Data
> 
> I think 4/5 is odd, personally. However, I think I have a 
> better idea, and one that I think will be MUCH clearer. In 
> order to help express the idea, I will include the whole text 
> for the AC Descriptor section. If this format works for you, 
> I will replicate it in another two areas in the spec that I 
> had updated due to another IESG review comment.
> 
> <text>
> 4.6.1.  AC Descriptor
> 
> I won't fight this to death but I still find it confusing. 
> Writhing 4 in a field which can be either 4 or 5 may confuse 
> other as well. What about 4/5? 
> 
> Dan
>  
> 
> because both 4

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Fri, 20 Jun 2008 10:21:33 -0700

OK, closing issue 53.

PatC 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Friday, June 20, 2008 12:07 AM
To: Pat Calhoun (pacalhou); [email-masked]
Subject: RE: [Capwap] CAPWAP IESG Review Comment T12

OK with me. 

Dan

> Descriptor message element. I am proposing to make the same change to 
> two other similar message elements in the base protocol. This does not

> change the packet format in any way, and therefore does not introduce 
> any compatibility issues. I think it simply provides more clarity on 
> the format and expected contents.
> 
> <text>
> 4.6.40.  WTP Board Data
> 

> and one that I think will be MUCH clearer. In order to help express 
> the idea, I will include the whole text for the AC Descriptor section.

> If this format works for you, I will replicate it in another two areas

> in the spec that I had updated due to another IESG review comment.
> 
> <text>
> 4.6.1.  AC Descriptor
> 
> Writhing 4 in a field which can be either 4 or 5 may confuse other as 
> well. What about 4/5?
> 
> Dan
>  
>