Subject: [Capwap] AD review of draft-ietf-capwap-protocol-binding-ieee80211-06

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 23 Jun 2008 15:23:51 +0200

Here is the AD review of
draft-ietf-capwap-protocol-binding-ieee80211-06. Although the document
looks stable and in pretty good shape, there are a number of issues that
need to be fixed or seem unclear, so a new I-D revision seems to be
necessary before sending the document to IETF Last Call. 

I have divided my comments into Technical and Editorial. 

Regards,

Dan

-------------------------------

T1. Section 2.1.1 and 2.1.2 - What version of IEEE 802.1X is this
document supporting? I believe that this needs to be clarified, as IEEE
802.1X is currently under revision, and the document needs to be
included as a Normative reference. 

T2. Section 4, definition of WLAN ID bitmap

         This field is to be set to zero for unicast packets and is
         unused if the WTP is not providing IEEE 802.11 encryption.

This being a bitmap, is the intention to say 'set to all zero'? 

T3. What is the encoding of the Capabilities or Capability field (see
also E6)? 

T4. Section 6.1 - what is the format and length of the SSID field?

T5. Section 6.3 - why length = 3? 

T6. Section 6.6 - should not length be >=3? (RadioID + WLANID + Flags at
minimum)

T7. Section 6.10 - the definition of how the field Band supported is
codified is confusing. First a three bit integer value is mentioned, but
then the explanation seems to indicate it's a bit mask

T8. Section 6.12 - the length should be 40

T9. Section 6.16 - for all statistics counters in this message - explain
1. do they start counting from 0 at initialization? What is the behavior
when the device loses power? What is the behavior when they reach
maximal value? Minimal interval between two rollover events

T10. Section 6.23 - Country Code

      Special
      attention is required with use of this field, as implementations
      which take action based on this field could violate regulatory
      requirements.  Some regulatory bodies do permit configuration of
      the country code under certain restrictions, such as the FCC, when
      WTPs are certified as Software Defined Radios.

I do not know what can be done with this text from a technical
(implementation or processing) point of view. What 'special attention'
means? What can an implementation know about regulatory restrictions?
And what 'certain restrictions' mean? I suggest to reconsider if this
text is needed and if it is clarify if there are any technical impacts
or move it to a separate note or subsection. 

E1. It is recommended to avoid mentioning references in Abstract
sections. The current Abstract section mentions [3], I suggest to remove
this. 

E2. Terminology - The definition of a Station (STA) differs from the one
in [3]. Is it there that it should extended to describe the presence of
a MAC and a PHY, or is it here it is unnecessarily verbose? 

E3. There are a lot of acronyms and terms mostly from the IEEE 802.11
realm that are neither expanded, not explained - RSN, WMM, EDCA, OFDM
are only part of them. I suggest to expand the terminology section to
add them  

E4. Section 4, page 19, Data rate - s/The data rate field is a 16 bit
unsigned value. The contents of the field is set to 10 times the data
rate in Mbps of the packet received by the WTP. /The data rate field is
a 16 bit unsigned value expressing the data rate of the packets received
by the WTP in units of 0.1 Mbps./

E5. Section 6 - for consistency it looks like the IEEE 802.11 Message
Element / Type Value table should be a numbered figure. 

E6. Section 6.1 - is the field named 'Capabilities' as in the diagram or
'Capability' as in the description? 

E7. Section 6.2 - Antenna Selection should be represented in the diagram
as N x 8 bit fields. Maybe the diagram is meant to say that padding is
applied to 32-bit multiple in this case, but this should be clearly
described, if this is the case. 

E8. Section 6.6 - the 6 Flags bits should rather be named Reserved Bits.

E9. Section 6.13 - more information should be included about the
supported rates syntax and length (even if the reference to the MIB
document in [2] is provided

E10. Section 6.14 - IEEE 802.1P tag is three bits - why is the 802.1P
Precedence Tag two octets? And why is it called Precedence Tag and not
Priority Tag (same comment for 6.20, 6.22)? 

E11. Section 6.23 - Document ISO/IEC 3166- 1 should be made a Normative
Reference

E12 - Section 6.25 - is radio type a bitmask? Say clearly so. No need to
say anything about the value for all four radio types

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

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

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Thu, 26 Jun 2008 05:33:34 -0700

Thanks Dan. I have loaded all of these issues in tracker, and will be
dealing with each of them in a separate e-mail thread.

PatC 

-----Original Message-----
From: Romascanu, Dan (Dan) [mailto:[email-masked]] 
Sent: Monday, June 23, 2008 6:24 AM
To: [email-masked]
Subject: [Capwap] AD review
ofdraft-ietf-capwap-protocol-binding-ieee80211-06

Here is the AD review of

Regards,

Dan

      Special