Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification
draft-ietf-capwap-protocol-specification-15

The use of CN for MAC addresses was discussed on the IESG telechat on
Oct 9.  My understanding of the IESG rough consensus was that this wasn't
a good thing to do, and the IESG will attempt to get a URN scheme for MAC
addresses produced as a document.  If that URN scheme is completed, then
future specifications attempting to use CN for MAC address may be pushed
to support backwards-compatible migration to subjectAltName.  However, as
we've had trouble getting the URN scheme done this won't be a barrier to
advancement of this specification.  So as soon as the document is updated
with the agreed text to explain why "CN" is being used, I will clear my
discuss position.

I support the other discusses and will let them carry the block.

Section 4:

         0
         0 1 2 3 4 5 6 7
        +-+-+-+-+-+-+-+-+
        |Version| Type  |
        +-+-+-+-+-+-+-+-+

   Version:  ...

   Payload Type:  A 4 bit field ...

Here the names "Type" and "Payload Type" do not match.

Agree with the comments of the gen-art reviewer.

Section 3.3., paragraph 5:
>    WTP use of a limited IP broadcast, multicast or unicast IP address is
>    implementation dependent.

  Since no recommendation or requirement is made for the WTP to always
  use at least one of these option (the text basically says "MUST do one
  of the three"), does that mean that the AC needs to always listen for
  Discovery Requests by all three means? If not, discovery between
  components from different vendors may fail.


Section 4.5.2., paragraph 3:
>    DSCP:   The DSCP value of 46 SHOULD be used.

  It'd be good to somewhere in Section 4.5.2 mention that this DSCP
  designates the EF PHB and refer to RFC2598.


Section 4.6.9., paragraph 1:
>    When multiple CAPWAP Control IPV4 Address message
>    elements are returned, the WTP SHOULD perform load balancing across
>    the multiple interfaces.

  This is the first time load balancing is mentioned in this document,
  and there are only two other mentions, neither of which explains how
  load balancing is to be performed?


Section 4.6.11., paragraph 1:
>    The CAPWAP Local IPv4 Address message element is sent by either the
>    WTP, in the Join Request, or by the AC, in the Join Response.  The
>    CAPWAP Local IPv4 Address message element is used to communicate the
>    IP Address of the transmitter.  The receiver uses this to determine
>    whether a middlebox exists between the two peers, by comparing the
>    source IP address of the packet against the value of the message
>    element.

  This is not a reliable technique for NAT detection, because it fails
  when address spaces are overlapping. (Same for Section 4.6.12.)


Section 4.6.38., paragraph 0:
> 4.6.38.  Vendor Specific Payload

  I'd add a statement in this section along the lines of: "The exchange
  of vendor specific data between the MUST NOT modify the behavior of
  the base CAPWAP protocol and state machine." Otherwise we're creating
  a hole for incompatibilities.


Section 11., paragraph 2:
>    In the second case, two or more WTPs are deployed behind the same NAT
>    system.  Here, the AC would receive multiple connection requests from
>    the same IP address, and cannot differentiate the originating WTP of
>    the connection requests.

  The UDP source ports will be different for the two connection
  requests, which could be used to distinguish them.


Section 11., paragraph 4:
>    In the third configuration, the AC is deployed behind a NAT.

  Because all communication originates at the WTP and is addressed to
  the  AC, communication when the AC is behind a NAT will simply fail.
  (Unless the NAT has been specifically configured, in which case all
  issues can be assumed to disappear.)


Section 14., paragraph 4:
>    Because there is no congestion control mechanism specified for the
>    CAPWAP data channel, it is recommended that non-congestion-controlled
>    traffic not be tunneled over CAPWAP.

  s/recommended/RECOMMENDED/


Section 15.11., paragraph 0:
> 15.11.  CAPWAP Transport Protocol Types

  Why not simply reuse the Internet Protocol Numbers registry instead of
  creating a new one? http://www.iana.org/assignments/protocol-numbers/

(Updated comment on 2008-09-25)

In Section 4.5.3, both instances of "modulo 32" should be
"modulo 256".

In Section 4.6.36 (Session ID message element), the length
should be 16 octets instead of 32.

In Section 15.3, the range to be managed by IANA is not 32 bits, but 
only 8 (i.e. the unassigned values are 27-255, not 27-4294967295).

  Suresh Krishnan did a Gen-ART Review of -11 on 12 Aug 2008, and I
  have not seen a response to this review.  Please consider these
  comments.

I also support the naming aspects of Chris Newman's discuss position.  To elaborate:

The use of common name in section 2.4.4.3 is a rather non-standard use.  In retrospect, it 
would have been better to use the serial number attribute, which is conceptually a closer
match for the desired contents (the MAC address).   I understand that the wg determined
compatibility with current DOCSIS and PacketCable specs was needed, so they overloaded
the common name.  I can accept the wg consensus, but believe the decision should be
documented.  I wish the capwap spec had permitted use of the serial number attribute
as a transition strategy, since I believe that would be a better practice, but cannot really
claim that it is best practice.

Beyond the core of Chris' discuss, there are some interoperability concerns that should be
addressed.  The common name attribute is a directoryString, which can be encoded using
any of several different string types.  As described, the MAC address can always be encoded
using a PrintableString.  While I would suggest verifying this against the installed base, the
specification should indicate which string type is used with the common name attribute
to represent the MAC address.