Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option
draft-ietf-capwap-dhc-ac-option-02

[Ballot discuss]
John Brzozowski (one of the DHC WG chairs) said this:

---

In short a DHCPv6 server should ONLY send options requested by the client.
There was some debate about this a while back and the end result, if I
recall correctly, is what I stated above.  The thinking here is/was why
would a server transmit an option(s) if the client has not requested it.
Further, what value might there be sending an option to a client that it did
not explicitly request and subsequently might not know how to parse or
process.

However, also note the following excerpt from RFC3315 section 17.2.2.
Creation and Transmission of Advertise Messages.  This text appear in
several area of RFC3315:


  The server includes options the server will return to the client in a
  subsequent Reply message.  The information in these options may be
  used by the client in the selection of a server if the client
  receives more than one Advertise message.  If the client has included
  an Option Request option in the Solicit message, the server includes
  options in the Advertise message containing configuration parameters
  for all of the options identified in the Option Request option that
  the server has been configured to return to the client.  The server
  MAY return additional options to the client if it has been configured
  to do so.  The server must be aware of the recommendations on packet
  sizes and the use of fragmentation in section 5 of RFC 2460.


The above seems to clearly suggest that the server MAY legally transmit
options to client(s) that were not specifically requested in the ORO.

My advice is to require the DHCPv6 clients in this case to add the requested
option to the DHCPv6 ORO.

----

I realize the Ralph Droms has reviewed the specification earlier, and
I suppose he would have raised an issue if there was one. Perhaps me or
John are missing something. In any case, can we talk about why ORO
is not used in this case? It would seem logical that a CAPWAP client
ask for the CAPWAP server information.

[Ballot comment]
FYI: I have question out to my DHCP experts on why on the IPv6 side we return options without the client asking for them -- other documents have done this differently.

IANA Last Call comments:

IANA understands that there are two actions required upon
approval of this document. First, a DHCPv4 option code for CAPWAP
Access Controller must be established. This should be added to the
DHCPv4 options codes located at:

http://www.iana.org/assignments/bootp-dhcp-parameters

in the registry named:

BOOTP Vendor Extensions and DHCP Options

Tag = TBD by IANA
Option name = OPTION_CAPWAP_AC_V4
Data Length = N
Meaning = CAPWAP Access Controller addresses

The second action required is to establish an entry for a DHCPv6
option code for CAPWAP Access Controller. We understand this
should be done in the registry located at:

http://www.iana.org/assignments/dhcpv6-parameters

in the registry named:

DHCP Option Codes

Value = TBD by IANA
Description = OPTION_CAPWAP_AC_V6

IANA understands that these are the only actions required upon
approval of the document.

AD Review from Dan Romascanu.

This is the AD review for draft-ietf-capwap-dhc-ac-option-01. The document is quite simple and in good shape. I have only a small number of comments (grouped in Technical and Editorial) which I suggest to treat as Last Call comments. If I do not hear any objections I will send this document to IETF Last Call.



T1. In the Security Considerations section the following text looks to me quite weak in describing the implication of the security vulnerabilities of the DHCP-based discovery option:

.  Therefore, the options defined in this
  document are not the only methods used to determine which AC a WTP
  should connect to.

It may be better to be more assertive here, on the lines of something like:

.  Therefore, in security sensitive environments the options defined in this
  document SHOULD NOT be the only methods used to determine which AC a WTP
  should connect to.


E1. The Intended Status is not mentioned in the document header. Needs to add Intended Status: Proposed Standard (if approved)

E2. It is not necessary to use capitalized MUST notation when describing the IANA actions in the IANA considerations section.

SUBMISSION QUESTIONNAIRE FOR:
draft-ietf-capwap-dhc-ac-option-01.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 properly reviewed.  In
addition to review in the CAPWAP WG, we sent the document to the
DHC WG chairs for their review.  This is a very simple document and
did not require extensive review by other areas.

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

I have no concerns about this document.

  (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?

Although there were few comments on this document, there is consensus in
the WG that there should be DHCP options for this purpose.

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

No appeals have been threatened, and there was no contention about this
document.

  (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 found
no problems.

  (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 is a
dependencies on the CAPWAP base document, which was just submitted
for publication.

  (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 and it is clear and complete.

  (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

  The Control And Provisioning of Wireless Access Points (CAPWAP)
  Protocol allows a Wireless Termination Point to use DHCP to
  discover the Access Controllers it is to connect to.  This document
  describes the DHCP options to be used by the CAPWAP protocol.

Working Group Summary

  This document is a work item of the CAPWAP WG and respresents
  the consensus of the group.
 
Document Quality
 
  This document was reviewed within the CAPWAP WG and no issues
  were raised in WG Last Call.