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

[Ballot discuss]
Based on my discuss on the IEEE-binding spec there seem that adding ECN language should be done to this base-specification rather than the binding spec itself.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot discuss]
I believe this document needs to acknowledge a lying endpoint problem, especially with
respect to firmware update.  Specifically:

The firmware update aspects of the CAPWAP protocol specification place a great deal of faith
in the WTP.  Specifically, the AC is trusting the WTP to assert the current firmware update,
and to indicate whether the update has been installed.  (This is consistent with efforts in
NEA where we specifically excluded the lying endpoint problem, but I recall that it was
somewhat controversial.)

However, there is nothing in the CAPWAP protocol specification to indicate this level of trust
in the WTP.  I believe that a discussion of the trust model, and its limitations, should appear
in this document.  I would suggest introducing this concept in section 9, and expanding it in
the security considerations.

This part is really a discuss-discuss:

Is there a conflict between the guidance given in NAT Considerations Case 2 (Section 11,
paragraph 2, last sentence) and the guidance in section 12.2 "Session ID Security"?

From section 11:

                                    The CAPWAP Data Check state, which
  establishes the data plane connection and communicates the CAPWAP
  Data Channel Keepalive, includes the Session Identifier message
  element, which is used to bind the control and data plane.  Use of
  the Session Identifier message element enables the AC to match the
  control and data plane flows from multiple WTPs behind the same NAT
  system (multiple WTPs sharing the same IP address).

From  section 12:

                  For example, an AC MUST NOT associate decrypted DTLS
  control packets with a particular WTP session based solely on the
  Session ID in the packet header.  Instead, identification should be
  done based on which DTLS session decrypted the packet.  Otherwise one
  authenticated WTP could spoof another authenticated WTP by altering
  the Session ID in the encrypted CAPWAP header.

[Ballot discuss]
I'm concerned about the decision to overload the "CN=" field of the
certificate subject with an EUI-48 or EUI-64 address.  I understand
this has pragmatic advantages.  But an EUI-48/EUI-64 address is not
a "Common Name".

I took the time to review the discussion of this document on the PKIX
WG mailing list (I did not review any secdir-only exchanges as that
archive is not public).  I agree that PKIX did not have sufficient
consensus to recommend a change from the DOCSIS current practice use
of "CN" for MAC address.

However, one of the suggestions from Steve Kent in that
discussion stands out as very good advice on this topic:

"I was not aware that DOCSIS and PacketCable had created cert
profiles using this convention. That provides a strong rationale
for CAPWAP specs to be compatible where the two overlap, i.e., in
terms to certs provisioned in WTPs and ACs. Since this is the
rationale for this questionable use of the CN field, the document
should include cites to the relevant DOCSIS and PacketCable specs,
and say that this convention has been employed here because these
specs have caused numerous devices to be provisioned with certs of
this form."

I will hold this discuss position until action has been taken on that
advice.  Further, I consider this a precedent that use of "CN" for
MAC address is effectively best current practice for devices identified
by MAC address.  While I am OK supporting such a precedent based on
the advice of this WG and lack of strong opinion from PKIX, I want to
verify the rest of the IESG agrees before I clear my discuss.  I
expect that to happen on the telechat in two weeks.

[Ballot comment]
(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).

[Ballot discuss]
I'm concerned about the decision to overload the "CN=" field of the
certificate subject with an EUI-48 or EUI-64 address.  I understand
this has pragmatic advantages.  But an EUI-48/EUI-64 address is not
a "Common Name".  Did the working group consider alternatives to
overloading this field?

For example, we could define a URN scheme for EUI-48/EUI-64 addresses
(I'm honestly surprised that hasn't been done yet) and then use a
SubjectAltName of type URI.

I wonder what PKIX folks would prefer here.  Was that WG consulted?

[Ballot comment]
Section 3.1:
  "If an AC permits the
  administrator to change the CAPWAP control port, the CAPWAP data port
  MUST be the next consecutive port number."
 
This requirements seem to lack explicit reasons. If one in the future
think the AC will reside in an environment where port translation of
destination ports for the AC exist then this can be highly problematic
as was found out with RTP. As I see the only reason to have consecutive
ports are to reduced the number of ports to keep track in configuration
protocols and the DNS.

Section 4.5.3:

  If an older Request message (with smaller
  Sequence Number modulo 32) is received, it MUST be ignored.
 
  Smaller is not super obvious here. I would interpret it as
(Last_nr-15)%32 to (Last_nr-1)%32. Saying something like that might be
clearer on which sequence numbers that are okay.
 
It is also possible to become out of sync with this if the sender of
requests do what is not recommend and aborts transmission 16 times. Then
the sender and receiver will have there sequence number windows out of
sync. I don't think there is a significant issue here. But a warning
about this might with the SHOULD NOT abort sentence may provide good
motivation.

Section 4.5.2.  Control Message Quality of Service

  DSCP:  The DSCP value of 46 SHOULD be used.
 
The actual DSCP values use for a particular Per hop behavior (PHB) are
suggested rather then required and are up to the adminstrative domain.
Therefore you should indicate which which PHB you recommend and a
reference to its definition.

Also I don't understand why aren't using on of the assured forwarding
classes instead of expedited forwarding class. Can you please provide
some motivation for that?


Section 4.6:

What about type values 0, 65025-65535? What are they and should one care
about them at all?

Secton 4.6.14:

"Note that this option is illegal is
        either the WTP or the AC uses IPv4."
       
In addition to the is/if misstake it isn't really illegal but not
defined?

Section 9.1.1:

I am a bit confused reading the description for how Image download is
going to work. First to determine which is the first data of the image
one needs to pay attention to the sequence or are there another
mechanism for that?

Secondly, there seem to be no way of indicating in the Image Data
Request (CA->WTP) message the offset in the file of the data. As the
download may take substantial time, is it thought that one can
interleave other type of control message while the download goes on? If
yes, then I think one need to clarify which messages that are possible
without corrupting the state necessary for the download to progress
without issues. If no, probably fine but should be clarified and may
lock up the WTP for substantial time while data transfer is ongoing.


I will take the freedom to extend on Lars' comment about the NAT
traversal when AC behind NAT:

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.)

Yes, the NAT one deployes a AC behind needs to have no incoming filters
for this port. Otherwise it will not work. Usage of STUN like mechanisms
appear to not work due to that the AC has no way of knowing when a WTP
tries to contact it and from where. It needs to do that to be able to
send filter rule establising packets.

Section 11 and 9:

Another issue with NATs that my read through don't think is covered in
enough detail is the importance of the source address for the CA->WTP
Image Data Request messages. They need to be sent from the CA control
channel destination port on which it received the Image Data Request
from the WTP. And it needs to send to the source address present in that
download initiating request.

For the CA behind NAT the same applies for the WTP data upload.

[Ballot discuss]
Section 2.4.4.3
There is formal syntax in this section without any reference to which
syntax this is. Please include such a one.


section 4.3: Fragment ID:

I think the text does not make it clear if the fragment ID space is per
direction and AC/WTP pair. I am also worried about the size of this
field. It seems that if a large quantity of the packets needs
fragmentation then this field will wrap within a segments lifetime
resulting in the same type of missassociation issues that has been
identified with the IP-ID field and fragmentation.

A simple example shows that if one sends predominately packets that just
gets fragmented and assume a IP uplink MTU of 1500 then wirless payloads
of 1450 bytes will be fragmented. If the source sends only this size
packets not uncommon for long lived TCP transfers then this field will
wrap every second at data rates below 1 Gbit. At 100 mbit you will wrap
in around 8 seconds.

[Ballot comment]
Section 3.1:
  "If an AC permits the
  administrator to change the CAPWAP control port, the CAPWAP data port
  MUST be the next consecutive port number."
 
This requirements seem to lack explicit reasons. If one in the future think the AC will reside in an environment where port translation of destination ports for the AC exist then this can be highly problematic as was found out with RTP. As I see the only reason to have consecutive ports are to reduced the number of ports to keep track in configuration protocols and the DNS.

Section 4.5.3:

  If an older Request message (with smaller
  Sequence Number modulo 32) is received, it MUST be ignored.
 
  Smaller is not super obvious here. I would interpret it as (Last_nr-15)%32 to (Last_nr-1)%32. Saying something like that might be clearer on which sequence numbers that are okay.
 
It is also possible to become out of sync with this if the sender of requests do what is not recommend and aborts transmission 16 times. Then the sender and receiver will have there sequence number windows out of sync. I don't think there is a significant issue here. But a warning about this might with the SHOULD NOT abort sentence may provide good motivation.

Section 4.5.2.  Control Message Quality of Service

  DSCP:  The DSCP value of 46 SHOULD be used.
 
The actual DSCP values use for a particular Per hop behavior (PHB) are suggested rather then required and are up to the adminstrative domain. Therefore you should indicate which which PHB you recommend and a reference to its definition.

Also I don't understand why aren't using on of the assured forwarding classes instead of expedited forwarding class. Can you please provide some motivation for that?


Section 4.6:

What about type values 0, 65025-65535? What are they and should one care about them at all?

Secton 4.6.14:

"Note that this option is illegal is
        either the WTP or the AC uses IPv4."
       
In addition to the is/if misstake it isn't really illegal but not defined?

Section 9.1.1:

I am a bit confused reading the description for how Image download is going to work. First to determine which is the first data of the image one needs to pay attention to the sequence or are there another mechanism for that?

Secondly, there seem to be no way of indicating in the Image Data Request (CA->WTP) message the offset in the file of the data. As the download may take substantial time, is it thought that one can interleave other type of control message while the download goes on? If yes, then I think one need to clarify which messages that are possible without corrupting the state necessary for the download to progress without issues. If no, probably fine but should be clarified and may lock up the WTP for substantial time while data transfer is ongoing.


I will take the freedom to extend on Lars' comment about the NAT traversal when AC behind NAT:

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.)

Yes, the NAT one deployes a AC behind needs to have no incoming filters for this port. Otherwise it will not work. Usage of STUN like mechanisms appear to not work due to that the AC has no way of knowing when a WTP tries to contact it and from where. It needs to do that to be able to send filter rule establising packets.

Section 11 and 9:

Another issue with NATs that my read through don't think is covered in enough detail is the importance of the source address for the CA->WTP Image Data Request messages. They need to be sent from the CA control channel destination port on which it received the Image Data Request from the WTP. And it needs to send to the source address present in that download initiating request.

For the CA behind NAT the same applies for the WTP data upload.

[Ballot discuss]
Discuss:

Section 2.4.4.3
There is formal syntax in this section without any reference to which syntax this is. Please include such a one.


section 4.3: Fragment ID:

I think the text does not make it clear if the fragment ID space is per direction and AC/WTP pair. I am also worried about the size of this field. It seems that if a large quantity of the packets needs fragmentation then this field will wrap within a segments lifetime resulting in the same type of missassociation issues that has been identified with the IP-ID field and fragmentation.

A simple example shows that if one sends predominately packets that just gets fragmented and assume a IP uplink MTU of 1500 then wirless payloads of 1450 bytes will be fragmented. If the source sends only this size packets not uncommon for long lived TCP transfers then this field will wrap every second at data rates below 1 Gbit. At 100 mbit you will wrap in around 8 seconds. Which still would be low enough that your reassembly buffer keeps the data around.

[Ballot discuss]
(Last Edited Date: 2008-09-23 in response to Margaret's email.)

Section 3.3., paragraph 3:
>  The WTP MUST send the Discovery Request
>    message to either the limited broadcast IP address (255.255.255.255),
>    a well known multicast address or to the unicast IP address of the
>    AC.

  DISCUSS: http://www.iana.org/assignments/multicast-addresses does not
  list a well-known IPv4 multicast address reserved for CAPWAP, and
  Section 15.1 only requests allocation of a new IPv6 multicast address.
  Which well-known multicast address should be used for CAPWAP with
  IPv4?

[Ballot comment]
(Updated comment on 2008-09-24)

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).

[Ballot comment]
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/

[Ballot discuss]
Section 3.3., paragraph 3:
>  The WTP MUST send the Discovery Request
>    message to either the limited broadcast IP address (255.255.255.255),
>    a well known multicast address or to the unicast IP address of the
>    AC.

  DISCUSS: http://www.iana.org/assignments/multicast-addresses does not
  list a well-known IPv4 multicast address reserved for CAPWAP, and
  Section 15.1 only requests allocation of a new IPv6 multicast address.
  Which well-known multicast address should be used for CAPWAP with
  IPv4?


Section 4.3., paragraph 20:
>    Fragment Offset:  A 13 bit field that indicates where in the payload
>      this fragment belongs during re-assembly.

  DISCUSS: IP packets can be up to 2^16 bits long, but a 13-bit fragment
  offset field only allows reassembly of payload packets < 8K. Could the
  three subsequent reserved bits be used to create a 16-bit fragment
  offset?

[Ballot comment]
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.

[Ballot discuss]
Suresh Krishnan did a Gen-ART Review of -11 on 12 Aug 2008, and he
  reported one major concern.  That major concern was not addressed
  in the recently posted -12.  The concern deals with Section 3.1,
  which says:
  >
  > The UDP checksum field in CAPWAP packets MUST be set to zero.
  >
  This does not work if the CAPWAP control protocol is run over IPv6
  since the UDP checksum is mandatory and cannot be set to zero.

IANA Last Call comments:

IANA understands that a complex series of actions needs to occur
upon approval of this document. IANA further understands that no
IANA CAPWAP registry exists and that the message flags, message
types, identifiers, and other data to be registered will be part of a
new CAPWAP registry.

IANA understands that it will take the following action outside the
context of the new CAPWAP registry upon the approval of this
document.

1] In the Internet Protocol Version 6 Multicast Address registry
located at:

http://www.iana.org/assignments/ipv6-multicast-addresses

IANA will assign an address called "All ACs multicast address" of
link-local scope.

IANA further understands that it must build a new registry for
CAPWAP (at a location to be determined after approval of this
document). In that new registry, multiple subregistries must be
created. Upon approval of this document, IANA understands that
the following new subregistries will be a part of the newly created
CAPWAP Parameters Registry:

1] CAPWAP Message Types
The Message Type field in the CAPWAP header is used to identify
the operation performed by the message. There are multiple
namespaces, which are identified via the first three octets of the
field containing the IANA Enterprise Number [RFC5226]. When the
Enterprise Number is set to zero, the message types are reserved
for use by the base CAPWAP specification. Future registrations in
this subregistry require standards action.

IANA understands that NO NEW MESSAGE TYPES are specified by the
document. The document only supplies the definition of the format
and the registration process.

2] CAPWAP Header Fields
The Flags field in the CAPWAP header is used to identify any special
treatment related to the message. There are three bits for the
CAPWAP header field. For this subregistry no initial values are
supplied. Future registrations in this subregistry require standards
action.

3] CAPWAP Control Message Flags
The Flags field in the CAPWAP Control Message header is used to
identify any special treatment related to the control message. For
this subregistry no initial values are supplied. Future registrations in
this subregistry require standards action.

4] CAPWAP Control Message Types
The Type field in the CAPWAP Control Message header is used to
identify the data being transported. This is a 32-bit field. For this
subregistry a set of 26 inital values is supplied. Future registrations
in this subregistryrequire standards action.

CAPWAP Control Message Message Type
Value
Discovery Request 1
Discovery Response 2
Join Request 3
Join Response 4
Configuration Status 5
Configuration Status Response 6
Configuration Update Request 7
Configuration Update Response 8
WTP Event Request 9
WTP Event Response 10
Change State Event Request 11
Change State Event Response 12
Echo Request 13
Echo Response 14
Image Data Request 15
Image Data Response 16
Reset Request 17
Reset Response 18
Primary Discovery Request 19
Primary Discovery Response 20
Data Transfer Request 21
Data Transfer Response 22
Clear Configuration Request 23
Clear Configuration Response 24
Station Configuration Request 25
Station Configuration Response 26

5] Wireless Binding Identifiers
The Wireless Binding Identifier in the CAPWAP message header is
used to identify the wireless technology associated with the packet.
These identifiers are five bits in length. For this subregistry a set of
4 initial values is supplied. Future registrations in this subregistry
require standards action.

Binding Wireless
Identifier Packet Type

0 Reserved
1 IEEE 802.11
2 IEEE 802.16
3 EPCGlobal [EPCGlobal]

6] AC Security Types
The Security field in the AC Descriptor message element is used to
identify the authentication type available on the AC. The security
type is an eight bit field. For this subregistry a set of 2 initial values
is supplied. Future registrations in this subregistry require
standards action.

Authentication
Credential Type Description

1 X.509 Certificate Based
2 Pre-Shared Secret

7] AC DTLS Policy
The DTLS Policy field in the AC Descriptor message element is used
to identify how (or if) the CAPWAP Data Channel is to be secured.
The AC DTLS Policy field is an eight bit field. For this subregistry a
set of 2 initial values is supplied. Future registrations in this
subregistry require standards action.

DTLS Policy Description
Type

1 Clear Text Data Channel Supported
2 DTLS Enabled Data Channel Supported

8] AC Information Type Field
The Information Type field in the AC Descriptor message element is
used to represent information about the AC. The AC Information
Type Field is a sixteen bit field. For this subregistry a set of 2 initial
values is supplied. Future registrations in this subregistry require
standards action.

AC Information
Type Description

4 Hardware Version: The AC's hardware version number.
5 Software Version: The AC's Software (firmware) version number.

9] CAPWAP Transport Protocol Types
The Transport field in the CAPWAP Transport Protocol message
element is used to identify the transport to use for the CAPWAP
Data Channel. This is an eight bit field. For this subregistry a set of
2 initial values is supplied. Future registrations in this subregistry
require standards action.

Transport Protocol
Type Description

1 UDP-Lite
2 UDP

10] Data Transfer Type
The Data Type field in the Data Transfer Data message element and
Image Data element is used to provide information about the data
being carried. This is an eight bit field. For this subregistry a set of
3 initial values is supplied. Future registrations in this subregistry
require standards action.

Data Transfer
Type Description

1 Transfer data is included
2 Last Transfer Data Block is included (EOF)
5 An error occurred. Transfer is aborted

11] Data Transfer Mode
The Data Mode field in the Data Transfer Data message element and
Data Tranfer Mode message element is used to provide information
about the data being carried. This is an eight bit field. For this
subregistry a set of 3 initial values is supplied. Future registrations
in this subregistry require standards action.

Data Mode Description

0 Reserved
1 WTP Crash Data
2 WTP Memory Dump

12] Discovery Types
The Discovery Type field in the Discovery Type message element is
used by the WTP to indicate to the AC how it was discovered. This is
an eight bit field. For this subregistry a set of 5 initial values is
supplied. Future registrations in this subregistry require standards
action.

Discovery
Type Description

0 Unknown
1 Static Configuration
2 DHCP
3 DNS
4 AC Referral (used when the AC was configured either through the
AC IPv4 List or AC IPv6 List message element)

13] Radio Admin State
The Radio Admin field in the Radio Administrative State message
element is used by the WTP to represent the state of its radios. This
is an eight bit field. For this subregistry a set of 3 initial values is
supplied. Future registrations in this subregistry require standards
action.

Radio Admin
State Description

0 Reserved
1 Enabled
2 Disabled

14] Radio Operational State
The State field in the Radio Operational State message element is
used by the WTP to represent the operational state of its radios.
This is an eight bit field. For this subregistry a set of 3 initial values
are supplied. Future registrations in this subregistry require
standards action.

Radio
Operational
State Description

0 Reserved
1 Enabled
2 Disabled

15] Radio Failure Causes
The Cause field in the Radio Operational State message element is
used by the WTP to represent the reason why a radio may have
failed. This is an eight bit field. For this subregistry a set of 4 initial
values are supplied. Future registrations in this subregistry require
standards action.

Radio Failure
Cause Description

0 Normal
1 Radio Failure
2 Software Failure
3 Administratively Set

16] CAPWAP Result Code
The Result Code field in the Result Code message element is used
to indicate the success, or failure, of a CAPWAP control message. This is a thirty-two bit field. For this subregistry a set of 23 initial
values are supplied. Future registrations in this subregistry require
standards action.

Result Code Description

0 Success
1 Failure (AC List message element MUST be present)
2 Success (NAT detected)
3 Join Failure (unspecified)
4 Join Failure (Resource Depletion)
5 Join Failure (Unknown Source)
6 Join Failure (Incorrect Data)
7 Join Failure (Session ID already in use)
8 Join Failure (WTP Hardware not supported)
9 Join Failure (Binding Not Supported)
10 Reset Failure (Unable to Reset)
11 Reset Failure (Firmware Write Error)
12 Configuration Failure (Unable to Apply Requested Configuration
- Service Provided Anyhow
13 Configuration Failure (Unable to Apply Requested Configuration
- Service Not Provided)
14 Image Data Error (Invalid Checksum)
15 Image Data Error (Invalid Data Length)
16 Image Data Error (Other Error)
17 Image Data Error (Image Already Present)
18 Message Unexpected (Invalid in current state)
19 Message Unexpected (Unrecognized Request)
20 Failure - Missing Mandatory Message Element
21 Failure - Unrecognized Message Element
22 Data Transfer Error (No Information to Transfer)

17] Returned Message Element Reason
The Reason field in the Returned Message Element message
element is used to indicate the reason why a message element was
not processed successfully. This is an eight bit field. For this
subregistry a set of 5 initial values are supplied. Future registrations
in this subregistry require standards action.

Reason
Field Description

0 Reserved
1 Unknown Message Element
2 Unsupported Message Element
3 Unknown Message Element Value
4 Unsupported Message Element Value

18] WTP Board Data Type
The Board Data Type field in the WTP Board Data message element
is used to represent information about the WTP hardware. This is a
sixteen bit field. For this subregistry a set of 5 initial values is
supplied. Future registrations in this subregistry require standards
action.

Board
Data Type Description

0 WTP Model Number
1 WTP Serial Number
2 Board ID
3 Board Revision
4 Base MAC Address

19] WTP Descriptor Type
The Descriptor Type field in the WTP Descriptor message element is
used to represent information about the WTP software. This is an
eight bit field. For this subregistry a set of 4 initial values is
supplied.

WTP Descriptor
Type Meaning

0 Hardware Version
1 Active Software Version
2 Boot Version
3 Other Software Version

20] WTP Fallback Mode
The Mode field in the WTP Fallback message element is used to
indicate to the WTP the type of AC fallback mechanism it should
employ. This is an eight bit field. For this subregistry a set of 3
initial values are supplied. Future registrations in this subregistry
require standards action.

WTP Fallback
Mode Description

0 Reserved
1 Enabled
2 Disabled

21] WTP Frame Tunnel Mode
The Tunnel Type field in the WTP Frame Tunnel Mode message
element is used to indicate the type of tunneling to use between the
WTP and the AC. This is an eight bit field. For this subregistry a set
of 4 initial values are supplied. Future registrations in this
subregistry require standards action.

WTP Frame Description
Tunnel Mode

1 Local Bridging
2 802.3 Frame Tunnel Mode
3 Native Frame Tunnel Mode
7 All

22] WTP MAC Type
The MAC Type field in the WTP MAC Type message element is used
to indicate the type of MAC to use in tunneled frames between the
WTP and the AC. This is an eight bit field. For this subregistry a set
of 3 initial values is supplied. Future registrations in this subregistry
require standards action.

WTP MAC
Type Description

0 Local-MAC
1 Split-MAC
2 Both Local-MAC and Split-MAC

23] WTP Radio Stats Failure Type
The Last Failure Type field in the WTP Radio Statistics message
element is used to indicate the last WTP failure. This is an eight bit
field. For this subregistry a set of 5 initial values is supplied. Future
registrations in this subregistry require standards action.

WTP Radio
Stats Failure
Type Description

0 Statistic Not Supported
1 Software Failure
2 Hardware Failure
3 Other Failure
255 Unknown

24] WTP Reboot Stats Failure Type
The Last Failure Type field in the WTP Reboot Statistics message
element is used to indicate the last reboot reason. This is an eight
bit field. For this subregistry a set of 7 initial values is supplied.
Future registrations in this subregistry require standards action.

WTP Reboot
Stats Failure
Type Description

0 Not supported
1 AC Initiated
2 Link Failure
3 Software Failure
4 Hardware Failure
5 Other Failure
255 Unknown

IANA understands that the assignment of the multicast address and
the creation of the registry for CAPWAP (with the 24 subregistries
enumerated above) are the only IANA actions required upon
approval of the document.

IETF Last Call Comments from Pasi Eronen:

I read capwap-protocol-specification-11 on my way to Dublin; here are some comments/observations.

Substantial topics first:

Section 3.5: The text about MTU discovery doesn't look right; Section
3.5 seems to assume that after the WTP has discovered the AC it wishes to communicate with, RFC 1191/1981/4821 would provide it with the MTU, and then the WTP would establish the CAPWAP session.  But those RFCs don't specify e.g. what packets would be used for probing for the MTU.

Section 4.6.29: Using MD5 in a new protocol, and not providing algorithm agility for moving to new algorithms, is probably not such a great idea.

The linking of control and data channels, and how DTLS session resumption is used here, seems unnecessarily complicated.  Normally session resumption is totally TLS internal optimization, and applications running over TLS don't know (and have no need to know) whether full or abbreviated TLS handshake was used. It seems this document wouldn't really need to say anything about session resumption; if the WTP provides the Session ID in data channel, and AC checks that both DTLS connections were established by the same authenticated client, that seems sufficient.  This would seem to remove much implementation complexity; e.g. the requirement in 4.4.3 that "The AC DTLS implementation MUST NOT accept a session resumption request for a DTLS session in which the control channel for the session has been torn down" doesn't follow the usual TLS/DTLS module boundaries.

Section 3.3: Should IPv4 use a well-known multicast address (instead of broadcast), too? Why not?

The protocol allows the AC to add and delete static MAC ACL entries, but it seems the AC can't check what the current ACL entries are.
This means the WTP and AC could get out-of-sync, right? (The AC can't delete the unneeded static MAC ACL entries if it doesn't know what they are.)

Section 3.3: there's a single sentence about DNS-based discovery; probably slightly more details would be useful.

Section 2.4.3: handling of cookies that fail to validate is really a DTLS detail, and shouldn't be in this specification. RFC 4347 doesn't say what the DTLS server should do, but I think the right approach is to treat an invalid cookie the same as no cookie (and not discard the whole message, as is suggested here -- I think that could lead to weird failure modes even in the absence of malicious attackers).  I'll raise this on the TLS mailing list, so it can be clarified in DTLS 1.2 update.

Section 4.3: it seems that allocation of WBIDs (and message element numbers in 4.6) would be better done in the document specifying the binding. Considering that WBID allocations require Standards Action, especially allocating WBIDs for technologies for which not even an Internet-Draft exists yet seems premature.

Section 4.5.3: Is CAPWAP control protocol strictly "lock-step" (once you send a Request, you must wait for Response until you send another Request), or are multiple outstanding requests allowed?  Can you "give up" a Request (stop retransmitting it even though you haven't received a Response), and move to the next Request?  What should you do if you receive a Request with a Sequence Number that's too old (less than previous Request you've seend) or too new (greater than previous
Request+1)?

Replay protection is an optional feature in RFC 4347. Should this document say something about it? (e.g. MUST use?)

There's some inconsistency about NAT detection: Sections 4.6.12, 4.6.13, and 4.6.15 say it's done using "CAPWAP Local IPv4/6 address"
message elements; Sections 4.6.44, 4.6.45, and 6.1 say it's using "WTP
IPv4/6 address" message elements.



Minor clarifications/editorial nits:

Section 2, 1st para: should reference RFC4347 instead of RFC4346

Section 2.3: should have a sentence saying what transitions represented by punctuation characters mean.

Section 2.4.1: "DTLS will never terminate the handshake due to non-responsiveness; instead, DTLS will continue to increase its back-off timer period" While RFC 4347 doesn't specify how long you should continue retransmitting, the intent certainly was not to continue indefinitely.

Section 2.4.3 text about DTLS retransmissions is slightly inaccurate; DTLS handshake isn't strictly request/response, and both parties (not just the DTLS client) retransmit based on timers (in some situations).

Section 2.4.4.1: should reference RFC4346 instead of RFC4279.
Section 2.4.4.2: TLS_DHE_PSK_WITH_AES_256_CBC_SHA is listed twice.

Section 4.4.1, "The 8 bit Length field" looks like 16 bits.

Section 4.4.2: is it unambiguous which 802.3 frame fields are included or omitted? (e.g. preamble, SOF delimeter, etc.)

Section 4.6, message element 29 is spelled "Image Information"
in the rest of the document, but "Image Info" here

Section 4.6.1, description of R-MAC Field needs some more text (current text would probably be fine if the field was only 1 bit, but it's 8 bits).

Section 4.6.6 (AC Timestamp): the timestamp format in RFC 1305 is
64 bits, but the field here is only 32 bits.

The description of bit fields needs clarification in several places:
at least Section 4.6.1 (Security field), 4.6.1 (DTLS Policy field),
4.6.43 (Frame Tunnel Mode field). For example, the "Security" field currently seems to say that bit 1 is X.509, bit 2 is PSK, and bits 0 and 3..7 are unused -- but the intention was probably to say that bit 0 is X.509 and so on. This gets especially confusing in Section 4.6.43 (and associated IANA text in 15.21), where it's not even clear whether this is an enumeration or bit field. Drawing bit diagrams would be a good idea, IMHO.

Section 4.6.50 (WTP Static IP Address Information): probably should have a sentence saying why this is for IPv4 only.

Section 4.6.50 (WTP Static IP Address Information): "Netmask" field is listed twice.

Section 4.6.28 (Image Identifier): length should be >= 5 (instead of 1)?

Section 4.6.30 (Initiate Download): there's no message element named "Image Download"

Section 6.1 (Join Request): WTP IPv4/6 IP Address are listed twice.

Section 4.6.28 (Image Identifier) says this message element is sent by the AC to the WTP; but according to Section 9.1, it can also be sent by the WTP?

Section 9.1.2: should say that "Image Information" and "Initiate Download" elements are included only when this message is sent by the AC.

Section 12.2 says Session ID is 64 bits, but in Section 4.6.37, it's 32 bits.

Section 12.5: This text probably needs to mention PSK Identity Hint as well.

Section 15: Even if the well-known port numbers have already been allocated, it would be good to say they've been allocated by IANA.

Section 15: needs to cite RFC 5226 for the "Standards Action" policy.

Section 15: RFC 5226 says that documents requesting creation of new registries MUST include certain instructions for IANA (RFC 5226 Section 4.2) -- many of the details are currently missing.

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)

SUBMISSION QUESTIONNAIRE FOR:
draft-ietf-capwap-protocol-specification-10.txt
======================================================================

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

Margaret Wasserman will be the shepherd for this document.  Yes, I
have fully reviewed the document and believe that it is ready for
publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

It is my opinion that this document has been very well-reviewed.  In
addition to a lot of review within the WG including our two security
advisors (Charles Clancy and Scott Kelly) and our transport advisor
(David Borman), we got an early secdir review and the document was
reviewed by the transport ADs.  All issues raised during the course of
these reviews were carefully tracked in an issue tracker and fully
addressed.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

No, I believe that the document has been adequately reviewed.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

It is possible that IANA may need somewhat more information than is
included in the IANA considerations section.  The current section
was reviewed by the WG, and there is consensus that it is adequate,
but I anticipate that some questions may be raised by IANA during
IETF LC.  It is my suggestion that we address them at that time.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

This document represents a very strong consensus of the WG.  Earlier
there was a lot of contention about different aspects of this
protocol, including (but not limited to) the security model, the basic
operational model, and what parts of the functionality should be
mandatory or optional.  However, I believe that consensus was reached
on all of those points and that consensus is properly reflected in the
current document.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarise the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

Noone has threatened an appeal.  Some people have indicated discontent
with the pace of the work and/or concerns about whether this will be
implemented.  However, some have indicated that they are implementing
this specification, and I am personally aware of implementations.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type and URI type reviews?

I personally checked this document for ID-Checklist issues and other
nits a few months ago and filed issues for those that I found. 
Everything I found at that time was fixed.

There are a few very minor issues with the document now (one unused
reference, two outdated references and a "MUST not"), and  I have sent
these issues to the CAPWAP list.  In my opinion, though, we should
proceed with publication and fix these issues if/when another update
is needed, as none of these nits could be hiding a substantive
issue.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

Yes, the references are split.  There are no downrefs.  There are some
dependencies on other CAPWAP document, specifically the IEEE 802.11
binding and the DHCP option, but those documents have also completed
IETF LC and will be submitted for publication in parallel.

  (1.i)  Has the Document Shepherd verified that the document IANA
          consideration section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process has Shepherd
          conferred with the Responsible Area Director so that the IESG
          can appoint the needed Expert during the IESG Evaluation?

There is an IANA considerations document that has WG consensus.  As I
indicated above, it may not be sufficient to allow IANA to set
up the registries, but I think that this would be best handled by
responding to IANA questions during IETF LC.

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

N/A

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up?  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

Technical Summary

  This specification defines the Control And Provisioning of Wireless
  Access Points (CAPWAP) Protocol.  This is a protocol to allow an
  Access Controller (AC) to securely manage the firmware and
  configuration of a set of Wireless Termination Points (WTPs).

  The CAPWAP protocol meets the IETF CAPWAP working group protocol
  requirements.  The CAPWAP protocol is designed to be flexible,
  allowing it to be used for a variety of wireless technologies.
  This document describes the base CAPWAP protocol.  The CAPWAP
  protocol binding which defines extensions for use with the IEEE
  802.11 wireless LAN protocol is available in
  [I-D.ietf-capwap-protocol-binding-ieee80211].  Extensions are
  expected to be defined to enable use of the CAPWAP protocol with
  additional wireless technologies.

Working Group Summary

  This document is a work item of the CAPWAP WG.  Although there were
  a number of contentious issues raised during the definition of this
  protocol, this document represents the consensus of the working
  group.  No issues were raised during our final WG Last Call.
 
Document Quality
 
  The CAPWAP protocol has been extensively reviewed and has been
  updated to address issues raised in those reviewes.  We'd like to
  offer special thanks to our technial advisors:  Charles Clancy,
  Scott Kelly, Bob O'Hara and David Borman.  Also to Joe Salowey
  for providing an early secdir review, and to Magnus Westerlund and
  Lars Eggert for performing an early transport area review.