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

[Bob O'Hara (boohara) (boohara]

Thanks!

 -Bob
 

 

---

From: Dorothy Stanley [mailto:dstanley1389 [at] gmail.com]
Sent: Wednesday, May 31, 2006 4:53 PM
To: Bob O'Hara (boohara)
Cc: capwap
Subject: Re: [Capwap] New issues: readability/ease of use/lack of specification

Bob,

Thanks very much for the comments. Replies 
below.

Dorothy

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?

The Config section  format is the legacy format from the LWAPP draft. I have no problem with
establishing separate sections for each message, and cleaning up the Mobile config request.

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

Ok, will add the reference.

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.

Ok, will move the content of 11.4 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