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

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Tue, 23 May 2006 11:46:56 -0700

Issue 124 has been created.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Bob O'Hara (boohara) 
> Sent: Tuesday, May 23, 2006 10:36 AM
> To: capwap
> Subject: [Capwap] New issues: readability/ease of use/lack of 
> specification
> 
> 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.
> 
> 2. Please include a table of message element type values for 
> the 802.11 binding-specific elements in section 11.10.
> 
> 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?
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
>  -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: "Bob O'Hara (boohara)" <[email-masked]>
Date: Wed, 31 May 2006 19:01:30 -0700

Thanks!

 -Bob

________________________________

From: Dorothy Stanley [mailto:[email-masked]] 
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