Capwap Mailing List: Re: New issues: readability/ease of use/lack of specification

[Bob O'Hara (boohara) (boohara]

Dorothy,

 

Most of your suggestions for resolving the issues below work for me.  I will comment on each, individually, below.

 -Bob
 

 

---

From: Dorothy Stanley [mailto:dstanley1389 [at] gmail.com]
Sent: Thursday, May 25, 2006 10:33 AM
To: Bob O'Hara (boohara)
Cc: capwap
Subject: Re: [Capwap] New issues: readability/ease of use/lack of specification

Hi Bob,

Glad that you found the -01 draft a significant 
improvement. Proposed
resolutions to Issue 124 are inline below. 

Thanks,

Dorothy

On 5/23/06, Bob O'Hara (boohara) <boohara [at] cisco.com> wrote:

> The 
>   -01 draft is a significant improvement over the -00 
>   draft.  However,
> I find it very difficult to easily find some 
>   information in the
> document.  Following are some editorial and 
>   technical comments.
>
> 1. Please include a table of message element type 
>   values for the base 
> CAPWAP message elements in section 4.4.

Proposed Resolution: Insert a tablet at the end of Section 4.4, just prior to
4.4.1

The following CAPWAP protocol message elements are defined:
[Include the list - the 01 elements, plus changes due to issue resolution, with type values]

Bob>> Works for me. 

 

> 2. 
>   Please include a table of message element type values for the 
>   802.11
> binding-specific elements in section 11.10.

Proposed resolution:  Insert a table in Section 10.10, just
prior to 11.10.1

The follwoing IEEE 802.11 specific message elements are defined:
[Include the list - the -01 values, plus any changes per issue resolution, with type values]

 

Bob>> Works for me.

 

> 3. 
>   Please describe how the binding-specific message element type values
> are 
>   derived.  It appears that the 802.11 type values begin 
>   arbitrarily
> at 1024.  Are the values for this field to be IANA 
>   controlled, or are
> they able to be identified deterministically?

The resolution of Issue 91 (Duplicate message element values)
renumbered the CAPWAP message elements to begin with 1, and
The IEEE 802.11 message element values to begin with 1024.
The next wireless type would begin at 2048. The
definition of values is to be done in the CAPWAP document(s).

Proposed resolution: At the end of section 4.4, prior
to the table being added by comment #1 above, change from

   Where Type (16 bit) identifies the character of the information
   carried in the Value field and Length (16 bits) indicates the number
   of bytes in the Value field.

to

   Where Type (16 bit) identifies the character of the information
   carried in the Value field and Length (16 bits) indicates the number
   of bytes in the Value field. Type field values are allocated as follows:


                               Usage                                       Type Values

         CAPWAP Protocol Message Elements                1-1023
         IEEE 802.11 Message Elements                         1024-2047
         Reserved for Future Use                                      2048 - 65024

and delete text describing IANA allocation of message element values.
 

Bob>> Works for me.

 

> 4. 
>   Please identify in which messages the nine additional message
> elements in 
>   section 11.10 may appear, since they are not listed in the
> table in section 
>   11.9.3.

The table in 11.9.3 lists the message elements that may be included in
the various configuration related messages.

Section 11.7.1 includes the message elements which can be included in the
IEEE 802.11 WLAN Config Request message:
IEEE 802.11 Add WLAN
IEEE 802.11 Delete WLAN
IEEE 802.11 Update WLAN
IEEE 802.11 Information Element

Section 11.7.2 lists the message elements that may be included in
the IEEE 802.11 WLAN Config Response:
IEEE 802.11 Assigned WTP BSSID

Section 11.9.1 lists the message elements that may be included in the
Mobile Config Request message:
IEEE 802.11 Mobile
IEEE 802.11 Mobile Session Key
Station QOS Profile

Section 11.9.2 lists the message elements that may be included
in the WTP Event Request message:
IEEE 802.11 MIC Countermeasures
IEEE 802.11 Statistics
IEEE 802.11 Radio Fail Alarm Indication

Between all of these sections, each message element is included in
at least one message. There is  one message element listed in the
section 11.9.3 table that is not defined:
IEEE 802.11 WTP Mode and Type. This seems to be CAPWAP
level information rather than 802.11 specific.

Proposed change:
Delete the IEEE 802.11 WTP Mode and Type row in the 11.9.3 table

 

Bob>> Hmmm... I see that you are correct, but wonder why the format is so different from 11.7.1/2, 11.9.1/2 to 11.9.3.  If Config Request/Response, Mobile Config Request, and WTP Event Request all deserve their own little section, why are the configuration messages treated differently?  Also, why does Mobile Config Request appear in the table in 11.9.3 with two elements allowed and in 11.9.1 with three elements?  Why is Mobile Config Request in the table in 11.9.3, at all?

 

> 5. 
>   In 11.7, the Message Type Value for the two 802.11-specific messages
> is 
>   given.  However, I don't see anywhere that describes how these 
>   values 
> were determined.  Please add a description of the 
>   derivation of the
> message type values.

Please see the description in section 4.3.1.1 (extracted below). Is this sufficient, or
is additional description required?

The Message Type field is comprised of an IANA Enterprise
   Number and a message type value field.  The first two byte contain
   the IANA Enterprise Number (for example, the IEEE 802.11 IANA
   Enterprise number is 13277), and the second two bytes contain the
   Message Type value.  The message type field can be expressed as:

   Message Type = IANA Enterprise Number * 256 + Message Type Value
 

Bob>> Yes this is sufficient, with the reference in the first paragraph of 11.7 changed to "See Section 4.3.1.1 for the derivation of the Message Type Value from the IANA Enterprise number." 

> 6. 
>   11.8 says there are no 802.11-specific data message 
>   bindings.  I
> think that the data packet containing an 
>   802.11-encapsulated frame
> should go here, along with its complete 
>   description.

There is some descriptive text in Section 11.4, Transport
Specific Bindings, which describes the patload encapsulation.

Is this text sufficient? If not, what addtional information is needed?
Perhaps a figure should be added to this section? 

 

Bob>> Well, I wouldn't expect to see an 802.15 or 802.16 frame encapsulated in 802.11 in some future revision of CAPWAP.  so, I think that this encapsulation type is specific to the 802.11 binding.  That is why I think it should be defined and described in 11.8.  The native frame of the binding-specific protocol that is carried in a CAPWAP packet is not really "transport specific".  The transport is CAPWAP, not 802.11.  The encapsulation is 802.11.  I think that the entire content of 11.4 can be moved to 11.8.

> -Bob
>
> Bob 
>   O'Hara
> Cisco Systems - WNBU
>
> Phone:  +1 408 853 
>   5513
> Mobile: +1 408 218 
>   4025
>
> _________________________________________________________________
> To 
>   unsubscribe or modify your subscription options, please visit:
> http://lists.frascone.com/mailman/listinfo/capwap
>
> Archives: 
>   http://lists.frascone.com/pipermail/capwap