Subject: RE: [Capwap] Comments on Draft 3 -- LWAPP

From: "Bob O'Hara (boohara)" <[email-masked]>
Date: Sat, 24 Dec 2005 12:41:29 -0800

It is not a good idea to include specific references to an amendment to
802.11, such as 802.11a/b/d/e/g/h/i/j.  The designations are ephemeral
and disappear when the base 802.11 standard is next "revised" by the
IEEE.  

IEEE procedure requires that when the number of amendments exceed a
threshold that they be merged with the base standard.  This is a
"revision" in IEEE terminology.  802.11 is long overdue for such a
merger.  

Such a revision is in process right now.  With high probability before
the end of 2006, all current amendment designations will be obsolete and
superseded by a new IEEE Standard 802.11-2006 that incorporates those
amendments.

We should determine some alternative wording, perhaps including
reference to a specific clause in 802.11, to replace references to
amendments.

 -Bob
 
-----Original Message-----
From: Philip Rakity [mailto:[email-masked]] 
Sent: Tuesday, December 20, 2005 3:27 PM
To: Pat Calhoun (pacalhou)
Cc: [email-masked]
Subject: Re: [Capwap] Comments on Draft 3 -- LWAPP

[much snipped]

>
>>
>> p) Page 113 -- Country Code -- reference 802.11d since this is the
>> definition
>
> If you insist, but 802.11d will point you to this exact reference  
> and we
> would therefore end up creating a double reference just for fun :(
>
> My personal preference is to keep this.

The words are fine ---
just wanted a note adding "802.11d" so I knew where this defintion  
came from.

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

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

---

From: [email-masked]
Date: Sat, 31 Dec 2005 05:03:26 -0000 (GMT)

I was re-reading the specification on the airplane and found the following
items that may need addressing.  I do not have access to my previous
e-mail so I may have duplicate comments from before.

regards,

Philip

Page 15 Join to Join Confirm
WTP -- the Join Response must include a valid <== valid is mis-spelled

Page 16:  Image Data to Image Data
WTP:  Response that indicates that the AC has more data to send

I did not see in the definition of the Image Data how the WTP knows there
is more data to come from the AC.

Page 18:  4th item -- This is the AC's normal state of operation, ...
delete the phrasethat says [, and there are many events that cause this to
occur.]

Page 26 last paragraph
In the event the WTP and AC are separated by a NAT,
delete the remark in between the comma's
with the WTP using private IP address space,

It is always the responsibility of NAT to manage the connection

Page 27:  LWAPP Packet Definitions

is the 802.11 FCS included in the LWAPP packets or not.  If so, how does
one know that this is occuring.

Page 59:  7.2.6 WTP Static IP Address Information

add note to say that IP Address/ Netmask/ Gateway are only valid if static
is 1 == or rearrange structure so that static is first element and other
elements follow if static is 1.

Page 90:  2nd sentence should read:  The probe request is then sent

Page 95:
WLAN ID bit mask -- define which bit maps to which BSSID
in reading the ieee spec the bits start of the left but I think here bit 0
is on the right.

Page 97:  Supported Rates
I think this IE is between 1 and 8 octets -- if the length of the IE is
not passed than the VLAN Name's starting position cannot be known.

Page 99:  VLAN Name --  do not understand "with local MAC WTPs"

Page 101:  VLAN Identifier:  PRC  ==  What is a PRC ?

Page 113:  Add note on Number of BSSID's :  range 1 to 16