Capwap Mailing List: Re: comments on -08 base draft and .11binding-05 draft

[Puneet Agarwal (pagarwal]

Hi Pat,

Regarding # 3: I am OK with your resolution though it would not hurt to
state the padding requirements as an FYI in the -05 .11 spec.

Thanks.

-Puneet

-----Original Message-----
From: Pat Calhoun (pacalhou) [mailto:pcalhoun [at] cisco.com] 
Sent: Tuesday, December 18, 2007 4:44 PM
To: Puneet Agarwal
Cc: capwap
Subject: RE: [Capwap] comments on -08 base draft and .11binding-05 draft

> 1) In section 4.3 of -08 draft, the "Wireless Specific Information"
optional field has an 8-bit "Wireless ID" field. 
> There is a similar 5 bit WBID field in the main capwap header (in the
first 32 bits). Are the two same? If the two are > the same, then we
should delete the "Wireless ID" in the "Wireless Specific Information"
optional header.
Yes, I agree with this change.
 
> 2) The "Wireless Specific Information" field for .11 is described in
section 4 of the -05 .11 binding spec. Does the 
> text in section 4 "IEEE 802.11 Frame Info" describe the "data" part of
the "Wireless Specific Information" in the base 
> spec? If so, then we should clarify this in the -05 .11 spec.
Yes, I agree with this change.
 
> 3) The base spec requires that the optional elements be 4 byte
aligned. The "Wireless Specific Information" field has 2 
> bytes of "Wireless ID" + "Length which means that the "Data" part
should be 2, 6, 10 etc in length. However the .11 
> spec only defines a 4 byte "Data" part (see 2 above) which does not
meet the alignment requirements. We should change 
> the .11 binding spec and make the "Data" 6 bytes in length with the
last 2 bytes being reserved.
The CAPWAP spec already makes this very clear. Specifically, section 4.3
states:

"  Wireless Specific Information:  This optional field contains
      technology specific information that may be used to carry per
      packet wireless information.  This field is only present if the
      'W' bit is set.  The HLEN field assumes 4 byte alignment, and this
      field MUST be padded with zeroes (0x00) if it is not 4 byte
      aligned."

So I do not believe any additional changes are needed to address this.

Anyone disagree with the above?

PatC