Subject: Re: [Capwap] New issues: readability/ease of use/lack of specification

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Wed, 31 May 2006 15:24:22 -0700

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:[email-masked]] 
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) <[email-masked]> 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

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

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

---

From: "Dorothy Stanley" <[email-masked]>
Date: Wed, 31 May 2006 16:53:16 -0700

Bob,

Thanks very much for the comments. Replies below.

Dorothy

> > elements in section 11.10 may appear, since they are not listed in the
> > table in section 11.9.3.
>
>
> Section 11.7.1 includes the message elements which can be included in the
> 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.
>
>
> 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
> 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