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

From: "Saravanan Govindan" <[email-masked]>
Date: Thu, 15 Dec 2005 15:08:23 +0800

Hi Philip,

You have clearly reviewed the draft in detail! I think the points you
raise are very important for the protocol. 

Perhaps some recommendations can be made based on the points raised. I
think it would be helpful for the WG to see how the recommendations can
fit in to the current LWAPP specifications. 

On a related note, I think the first WG version of the protocol can also
include those issues which were discussed during the last meeting. There
seemed to be some agreement in the issues such as information elements
field size, firmware operations and local-MAC mode operations. 

Cheers,

Saravanan

-----Original Message-----
From: Philip Rakity [mailto:[email-masked]] 
Sent: Tuesday, December 13, 2005 5:35 AM
To: [email-masked]
Subject: [Capwap] Comments on Draft 3 -- LWAPP

I am a newbie to the group and this the first time that I have read
the internet draft.  I have a number of comments on the draft that
are below.  Most a minor editorial things but some are areas I do not
understand

a) Use of "integer" is not consistent in the document --- most of the
time it means unsigned, sometimes signed (but marked as signed), but
sometimes the phrase "unsigned integer" is used and this then makes
me wonder if the fields marked integer are signed or not.

b) page 32 --  section 5.1 "Discovery requests MUST be sent by an ...
AND when no echo responses are received and the WTP"    I think it
should say that "Discovery requests MUST be sent by a WTP when the
WTP returns to the idle state.   This can occur for example when no
echo responses are received for NeibhborDeadInteval. "

c) Page 35 -- Radio Type --  no 802.11b (only) -- no 802.11n -- no
superG -- no superA

d) Page 37 -- Section 5.2.4  WTP manager control IPV4 address -- do
not understand the text --  is there only one ip address ?  if so --
then the ip address is used to return the interface of the AC.  If
only one address -- how is load balancing done ?

e) Page 41 -- Section 6.1  Join Request  -- 3rd paragraph -- Why the
1596 MTU limit -- how was this number chosen ? == (RIF routes if
vlan ?)  if I use 802.3 then I have seen h/w do 1522 (4 byte vlan
tag) -- some number a little bigger than 1522 and h/w do 16K bytes --
(intel ixp 4xx series) ---  The 16K number is bigger than the 4k SDU
for wireless medium...  Would it be better to base the discovery on
the MTU of the wireless media and work down ?

f) Page 52 -- Section 6.5 and Section 6.6 -- Change item that says
see Figure 2 -- to read see section 2.2

g) Page 60 -- REboot Statistics == this requires the WTP maintain
state to know if the last Failure Type was LWAPP initiated.   Same
comment for Crash count.  No value defined for state not maintained
by WTP.  Add cross reference to section where AC tells WTP to reboot.

h) Page 65 -- Blacklist Entry's  -- This whole area is not good from
my point of view.  When I configure a firewall I say what is allowed
(explicitly) and forbid everything else -- there is no way I can give
a list of trusted stations and forbid everything else.  This makes
live very difficult.  There is room for a blacklist -- but an allowed
list is also needed.

i) Page 70 -- Image Data -- do not understand how this can work --
only 2 fragments allowed -- no count of what is being sent etc -- no
way to detect packet loss ---  why not use data xfer mechanism of
tftp ?  -- the blocks are numbered == etc BUT define a md5 hash of
the whole image and give its length in the initial request.

j) Page 72 -- Section 8.5.1 Decryption Error Report   == add note
about only useful if split mac.

k) Page 72 -- Section 8.5.2   Duplicate IP address == what is a
host ?  Is this a mobile station ?  What about the case of a mobile
station having the SAME mac address as a already connected mobile
station to the WTP.  == only useful if NOT split mac

l) General comment -- there is no command to synchronize  time (set
the clocks) in the WTP to a common time base

j) General comment -- why not use the text in the 802.11 MIB
definitions and the name of the MIB entry where these are used to
configure the WTP

k) Page 94 -- Section 11.3.1 -- WLAN's field -- just do NOT
understand how setting a bit relates to the WLAN ID's used later in
the document -- can you give an example or two ?  Only 16 WLAN ID's
allowed ??/

l) Page 97 -- WLAN ID -- field is 8 bits -- other places in document
16 bits

m) Page 102 -- IEEE 802.11 stats -- Why not pad out Radio ID with 3
bytes of "reserved field" so all other fields are 32 bit aligned or
move it to the end of definition (after decryption errors).

n) Page 105 -- WLAN ID -- picture is 8 bits -- text is 16 bits

o) Page 109 WLAN Capability -- can you rename this and ALL other
fields to use the same terms as the 802.11 base standard or the MIB
(very confusing) -- or cross reference

p) Page 113 -- Country Code -- reference 802.11d since this is the
definition

q) Page 113 -- Rate Set -- is length wrong ?  should be >= 2
otherwise what is definition for rates NOT used

r) Page 115 -- RTS Threshold etc -- use wording from the MIB
definitions for all of these entries and reference mib object

s) Page 119 -- IEEE Antenna length -- length sound be >= 5

t) Page 120 -- Supported rates -- length >= 2 and <= 9

u) Page 122 - WTP Qos -- length is 2 if untagged or 802.1p  -- if
dscp it is 2 + (10)*dscp entries

v) Security -- any reason ssl could not be used even for level 2
encryption?  since the link is PT to PT -- the ip address/header is
not need -- then almost same code as layer 3 -- and the package is
public domain so easy to hack

regards,

Philip

Philip Rakity
[email-masked]

_________________________________________________________________
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