[Capwap] AD review for draft-ietf-capwap-protocol-specification-10.txt

Here is the AD review of
draft-ietf-capwap-protocol-specification-10.txt. Although the document
is mature there are a number of places where it can be improved for
readability and clarity, and some inconsistencies that should be solved
before submitting it to IETF Last Call. I advice to clarify these issues
and issue a revised version. 

I have divided my comments in Technical and Editorial. 

Technical

T1 - a generic comment. In many protocol fields definitions the document
lacks max size or max length definitions. I tried but I may have not
caught them all. Is the assumption made that for all these fields always
the maximum capacity should be reserved? In this case I suggest that a
clarification is made in Section 1.2. I prefer however explicit
definition of max size and max length whenever needed, as it is not
always necessary and wise from a resources point of view to design for
max values. 

T2 - Section 1.1 - Layer 2 and radio technology independence and
extensibility seem to me to be major goals of CAPWAP to the same extent
as the three goals already mentioned. 

T3 - Section 2 - 'Protocol Overview' describes the process of discovery
and provisioning exchange between the AC and WTP. This seems to be
different than the pre-provisioning phase described in Section 12.5.
Please clarify and bring this two sections in synch. Also be more clear
what parameters are being provisioned in the provisioning exchanged
described here. 

T4 - Section 2.3.1, page 25, Configure to Reset - it is not clear what
'reset the connection' means, this state needs clarification, for
example what is the difference / relationship to DTLS teardown

T5 - Section 4.3, pag 47 - As I understand the 5 bit field encodes 32
possible wireless bindings (i.e. it's not a bit mask). If true it would
be good to make this explicit. My question is whether there is any
reason to start with value 1 and not with value 0? Assuming this is
already deployed, will 0 be a value to use, or does it have any special
significance? 

T6 - Section 4.3, page 48 - 'This is useful in packets sent from the WTP
to the AC, when the native wireless frame format is converted to 802.3
by the WTP.'. Please explain why (is Radio MAC address useful)? Also,
s/802.3/IEEE 802.3 format/

T7 - Section 4.3, pag 49 - what is the max size of this Data field in
the Wireless specific information. Is it 255 as the length is coded in 8
bit or something else? Please detail. 

T8 - Session 4.4.1, pag. 50 - what is the max size of the Message
Element field? Please detail

T9 - Section 4.4.2 - what is the max size of IEEE 802.3 frames that is
being supported? Is IEEE 802.3as supported. Please detail

T10 - Section 4.5.1.1 - it is not explicitly said whether the CAPWAP
control messages in the table at page 54 apply for any wireless
technology. If true, why is only a value for IEEE 802.11 mentioned in
this specification? In my opinion there is a need to clarify and to take
out the IEEE 802.11 value, which should be mentioned in the technology
binding document. 

T11 - Section 4.6 - Please define the CAPWAP Message elements Type
Values that are currently TBD

T12 - Section 4.6.1 - in the AC Descriptor protocol diagram delete =4
from the Type filed (it can be 4 or 5 as I understand)

T13 - Section 4.6.1 - please define the max length of the vendor
specific field information

T14 - Sections 4.6.2, 4.6.3 - what is the max number of IP addresses on
the two lists? 

T15 - Section 4.6.4, 4,6,5 - what is the max size of the AC names? 

T16 - the document is not consistent in defining which one of the
configuration objects is to be saved in non-volatile memory. For example
in 4.6.7 it is mentioned that this message element information is not
expected to be saved in non-volatile memory - if this is an exception
what is the rule?

T17 - Section 4.6.7, 4.6.9 - what is the max length of the MAC address
field? (i.e. how many addresses at most on the ACL MAC list?)

T18 - Section 4.6.8 - what is the max length of the VLAN Name? As
nothing is said I assume the max value currently supported but IEEE
802.1Q but it's better to be specific

T19 - Section 4.6.16 -  what is the max size of the Data field in the
Data transfer Data message? 

T20 - Section 4.6.16, 4.6.17, 4.6.33, 4.6.36, 4.6.42, 4.6.43  - why do
the encoded values start from 1 and not from 0? 

T21 - Section 4.6.18, 4.6.20 - what is the max number of entries in the
array (and thus the max length of the respective MAC Address fields)? 

T22 - Sections 4.2.24, 4.2.25 - why are the length field defined as >=
12, and >= 24 respectively. Is this triplicate addresses? Or more? And
if such cases exist, is this important to detect and report all in one
message? 

T23 - Section 4.6.26 - what is the unit for the Idle timeout 

T24 - Sections 4.6.27, 4.6.28 - should not these two messages include
length of the Value fields? 

T25 - Section 4.6.29 - what is the max length of the Value field?

T26 - Section 4.6.31 - what is the max length of the location field? 

T27 - Section 4.6.36 - what is the max length of the Message Element
field? 

T28 - Section 4.6.39 - I do not understand the semantics of the value
field - what does 'The value associated with the vendor specific
element' mean? Is this one byte as the diagram shows, or variable length
as indicated by the fact that the length of the message shows >=7? If
variable length what is the max length?

T29 - Section 4.6.40 - what is the max length of the Optional additional
vendor specific WTP board data TLVs? What kind of information is
expected to be carried there? The field is not described

T30 - Section 4.6.41 - what are the max values of the Value fields? What
is the semantics of Other Software version? I do not understand what
non-running (firmware) means

T31 - Section 4.6.46 - what is the max length of the WTP name field? 

T32 - Section 4.6.48 - are 16 bits enough to encode the wireless link
frame per second. Is an WTP never supposed to exceed 64k frames per
second over the air interface? 

T33 - Sections 4.6.49, 4.6.50 - Do the statistics counters defined here
initialize at zero and wrap-up and start counting from start when the
max value is reached? This may seem the obvious behavior, but there are
other, so clarifying would be useful. It also would be useful to
estimate the minimum wrap-up time for each of the counters

T34 - Section 4.7.2 - there is no unit specified for the
DataChannelKeepAlive timer

T35  - section 4.7.14 - this variable is not defined

T36 - Section 8.1 - 'The WTP retains the configuration of parameters
provided by the AC that are non-default values.' - does this mean that
any parameter that has a default value needs not be stored in
non-volatile memory, and the WTP will restore the defaults for these
parameters on all reset, power-up or bootstrap event?

T37 - Section 8.1 - If the WTP opts to save the configuration locally -
how is this option selected? Is this a local WTP configurations issue?
If so please specify

T38 - Section 9 should start with deployment considerations. It looks
like there are some assumptions made here about at least an AC being
present and configured at deployment, and other such. This should be
made clear.

T39. Section 13 is insufficient. The recommendation concerning
non-configurability of WTPs makes, sense, but what about the ACS? How
are ACs configured? It is OK to say that they are configured by
proprietary CLI and/or MIB interfaces that will be defined in other
CAPWAP document and/or by NETCONF in the future, but something needs to
be said. 

T40 - The same section should include information about impact on
network traffic. What is the extra level of traffic that is expected by
introducing and deploying CAPWAP? Is there any limit of AC load that
needs to be taken into consideration in order to avoid congestion on the
network or on the AC? Probably this section should be renamed to also
cover Operational considerations, 

Editorial

E1 - In the Abstract section, please eliminate the phrase 'The CAPWAP
protocol meets the IETF CAPWAP working group protocol requirements.' or
replace it with something that points to a reference less ephemeral than
the CAPWAP WG. 

E2 - A number of editorial problems have been detected when running
idnits. Please fix them:

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

  Checking nits according to
http://www.ietf.org/ietf/1id-guidelines.txt:

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

  == No 'Intended status' indicated for this document; assuming Proposed
     Standard

  Checking nits according to http://www.ietf.org/ID-Checklist.html:

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

     No issues found here.

  Miscellaneous warnings:

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

  == Using lowercase 'not' together with uppercase 'MUST' is not an
accepted
     usage according to RFC 2119.  Please use 'MUST NOT' (if that is
what you
     mean).

     Found 'MUST not' in this paragraph:

     Unless otherwise specified, a control message that lists a set of
     supported (or expected) message elements MUST not expect the
message
     elements to be in any specific order.  The sender MAY include the
message
     elements in any order.  Unless otherwise noted, one message element
of
     each type is present in a given control message.

  Checking references for intended status: Proposed Standard

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

     (See RFCs 3967 and 4897 for information about using normative
references
     to lower-maturity documents in RFCs)

  == Missing Reference: 'ChangeCipherSpec' is mentioned on line 1456,
but not
     defined
'[ChangeCipherSpec]...'

  == Unused Reference: 'RFC2132' is defined on line 6048, but no
explicit
     reference was found in the text
     '[RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP
Vendo...'

  ** Obsolete normative reference: RFC 3280 (Obsoleted by RFC 5280)

  ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)

  ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460)

  -- Unexpected draft version: The latest known version of 
     draft-calhoun-dhc-capwap-ac-option is -00, but you're referring to
-02.

  -- Possible downref: Normative reference to a draft: ref.
     'I-D.calhoun-dhc-capwap-ac-option'  (No intended status found in
state
     file of draft-calhoun-dhc-capwap-ac-option)

  == Outdated reference: draft-housley-aaa-key-mgmt has been published
as RFC
     4962
----------------------------

E3. Section 1.3 and Informative References 

The reference for LWAPP is
http://www.ietf.org/internet-drafts/draft-ohara-capwap-lwapp-04.txt.
Please define an Informative Reference and include a proper [LWAPP]
reference in the text

The reference for SLAPP is
http://www.ietf.org/internet-drafts/draft-narasimhan-ietf-slapp-01.txt.
Please define an Informative Reference and include a proper [SLAPP]
reference in the text

E4. Section 2.1:   'The CAPWAP protocol is independent of a specific WTP
radio technology.' My understanding is that CAPWAP is independent not
only of the radio technology but also of the layer 2 protocol. I suggest
to mention this. 

E5. First paragraph in Section 2.2 - what 'ideal case' means here? And
what 'idealized illustration' means in the last paragraph of the same
section? Maybe what is meant is simplified? 

E6. Please expand DTLS, PSK, EPCGlobal at first occurrence in the text. 

E7. Section 2.3, page 18, definition of threads - repetition 'figure
Figure 3' (three occurrences)

E8. Section 2.3, page 18 'Discovery Thread' - 'The state machine
transitions in figure 3 are represented by numerals.' - is this true?
Are not state transitions like Discovery to Discovery or Discovery to
Sulking, etc. represented by special signs, so this should be rather
'represented by discovery and special signs'? 

E9. Section 2.3, page 24 - the following phrase does not compile well:
'The WTP enters the Image Data state when it receives a successful Join
Response message and determines and the included Image Identifier
message element is not the same as its currently running image.'

E10. Section 2.4.4.3, page 38 - s/a device must have the id-kp-capwapWTP
or id-kp-anyExtendedKeyUsage keyPurposeID to act as a WTP/a device MUST
have the id-kp-capwapWTP or id-kp-anyExtendedKeyUsage keyPurposeID to
act as a WTP

E11. Section 3.4 - s/the CAPWAP protocol can be used in any network
configuration/the CAPWAP protocol can be used in any network topology
including firewall, NAT and middlebox devices/

E12. Section 4.1, page 45 - s/The reason for this header/The reason for
this preamble/

E13. Section 4.4.1 - title should be CAPWAP Data Channel Keepalive to be
consistent with the rest of the text

E14 Section 4.5.2 
s/802.1P/802.1Q/
s/precedence value/priority tag/
s/DSCP tag value/DSCP value/

E15. Section 4.7, page 83 - s/This section contains the CAPWAP
timers/This section contains the definition of the CAPWAP timers

E16 - Sections 4.7.10, 4.7.11, 4.7.12, 4.7.13, 4.7.14 (maybe, not clear
what this is, see technical comment), 4.7.15, 4.7.16 are not timers but
time-related configuration variables. The name of section 4.7 needs to
be changed

E17 - Some of the message diagrams are numbered as Figures, some are
not. For example the diagram at page 14-15 is not numbered, while the
one at page 119 is numbered as Figure 5. Please pick a consistent choice
(I prefer numbering)

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

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