DHCPv4 Bulk Leasequery
draft-ietf-dhc-dhcpv4-bulk-leasequery-07

[Ballot comment]
- Strike "DSLAM" from the box in the diagram in section 1, or simply replace it with "DHCP". DSLAM hasn't been defined yet, and it doesn't add anything to the diagram.

- Section 5:

  Only the DHCPBULKLEASEQUERY request is supported over the Bulk
  Leasequery connection. No other DHCPv4 requests are supported.  The
  Bulk Leasequery connection is not an alternative DHCPv4 communication
  option for clients seeking other DHCPv4 services.

I don't see how that's enforceable (given our lack of Internet Protocol Police), and I'm not sure what it adds. It might be sufficient to say, "The Bulk Leasequery connection was only designed to handle DHCPBULKLEASEQUERY. It is not intended as an alternative DHCPv4 communication option for clients seeking other DHCPv4 services." The above reads like you really wanted to say 'MUST NOT', but couldn't come up with a legitimate case to forbid it.

- Like Peter, I'd also like to understand what a "UTF-8 ASCII VPN identifier" is. So long it is a protocol-opaque user-readable identifier, it's no problem. But we Apps guys like to make sure. :-)

[Ballot discuss]
This is a Discuss because I want the opportunity to discuss with other members of the IESG on the call.

This document has seven front page authors, against a strong guideline of five. Other document teams have had to make very painful choices as a consequence of this policy. Unless there are exceptional reasons the number of authors  on the number of front page authors should be reduced to conform to the guideline.

[Ballot comment]
In Section 7.7 the requirement "MUST interleave replies" is not clear.  It could be read to mean an implementation has to wait to send additional replies to the first query until it has the information it needs to start answering a second (at the extreme, a strict round-robin of the responses).  Is the requirement you are really trying to capture "MUST NOT block sending replies on new queries until all replies for the existing query are complete."?

Is there a way for a server to say "the response to your query is too big, please ask again for a subset"? Consider adding a discussion to the document about what a client could do if a server is sending it more data
than it is prepared to deal with.

RFC5226 defines "IETF Review" as the well-known IANA policy name you are using in section 10. (That RFC notes that this was formerly called "IETF Consensus" in RFC2434.) The document should use that name.  RFC5226 is clear on what that policy name means - you invite argument by attempting to restate or clarify the policy in this document. Please consider removing the sentences that start "Basically, this means...".

[Ballot comment]
- The write up's technical and working group summaries are the
same. If that's a cut'n'paste accident, it might be worth putting
the right working group summary back there.

- Would it be worthwhile noting that this protocol is not
intended to be used to produce evidence (i.e. to be used in court)
as to who had what IP address when?  (And is that actually the
case? Would it be possibly bad/misleading evidence if so used?)

- Is it right, in section 4, to say that bindings are returned in
DHCPv4 "packets"? Maybe messages would be better?

- What are the consequences of having guessable "Relay
Identifier"  or "remote ID" or "vpn-id" values in queries? The
concern is whether such guessable values might allow for a lot of
probing.

- 6.2.8 "when 2 or more servers work together" I'm not sure if
there's an implied MUST or SHOULD for including this option in
this case. If not then a requestor can't really know for sure
they've got the full info on an IP address. That may well be ok,
but I think it'd be good to be clear about it.

- Do the query by MAC address or client-id options means that
personally identifying information about a user might be sent
further upstream that normal?  I don't think so but just wanna
check. If it did, that might be worth a note to the effect that
its another potential privacy issue that operators should worry
about.  (But with no change to the spec otherwise I'd guess.)

- server-identifier in only 1st response seems slightly fragile if
the overall session doesn't have data integrity (e.g. via TLS) but
I guess that's a fairly minor issue.

[Ballot discuss]
#1 How does the TCP framing interact with DHCP authentication
which only partly covers individual messages, was not designed for
this kind of bulk usage, and hence probably allows various bad
things to happen? E.g.  re-ordering or snipping out individual
messages seems to be possible or moving DHCPLEASEQUERYDONE earlier
in the sequence. I think that needs to be understood, and maybe it
is, but I don't get it from reading this nor from the referenced
RFCs, at least not without doing a lot more work that, presumably
the WG/coders already did and that could be documented here.  (If
you ended up saying "yes" to SSH or TLS in #3 below, this would be
moot.)

#2 Maybe replay is possible too if xid is predictable or always
starts at 1 or whatever. I'd suggest putting in a MUST for xid to
be hard to guess and very unlikely to collide over the life of a
DHCP authentication key at least.  (If you ended up saying "yes"
to SSH or TLS in #3 below, this would be moot.)

#3 If DHCP auth is actually mythical, in terms of real usage (is
it?) then wouldn't it be better to just run this over
mutually-authenticated SSH or TLS? (Possibly with a PSK
ciphersuite if you don't like private keys on the relay.) If not,
why not? If its likely that the boxes in the main use-case for
this (server, relay-agent) use SSH or TLS for something else (e.g.
netconf or whatever) then that might not be very hard to do at
all. Did the WG consider this?

#4 The secdir review raised the issue of a query like this coming
from a DHCP client (or elsewhere); the response [1] was that you
could firewall that, which should I guess be noted in the security
considerations, but I think the potential privacy consequences of
answering these queries, esp without authentication should also be
noted as in the reviewer's comment.

  [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03100.html

IANA understands that some of the IANA Actions in this document are
dependent on approval of another document ("Virtual Subnet Selection
Options for DHCPv4 and DHCPv6" draft-ietf-dhc-vpn-option).

IANA understands that, upon approval of this document, there five
actions which IANA needs to complete.

First, in the BOOTP Vendor Extensions and DHCP Options subregistry of
the Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol
(BOOTP) Parameters registry located at:

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

IANA is requested to add seven new option codes to the BOOTP Vendor
Extensions and DHCP Options subregistry.

QUESTION: Usually, registrations in this registry include a data length
and meaning in additon to the option code and name. Would the authors
like to supply those for the seven new option codes listed below?

Option code: [ tbd ]
Name: status-code
Data Length:
Meaning:
Reference [ RFC-to-be ]

Option code: [ tbd ]
Name: base-time
Data Length:
Meaning:
Reference [ RFC-to-be ]

Option code: [ tbd ]
Name: start-time-of-state
Data Length:
Meaning:
Reference [ RFC-to-be ]

Option code: [ tbd ]
Name: query-start-time
Data Length:
Meaning:
Reference [ RFC-to-be ]

Option code: [ tbd ]
Name: query-end-time
Data Length:
Meaning:
Reference [ RFC-to-be ]

Option code: [ tbd ]
Name: dhcp-state
Data Length:
Meaning:
Reference [ RFC-to-be ]

Option code: [ tbd ]
Name: data-source
Data Length:
Meaning:
Reference [ RFC-to-be ]


Second, in the DHCP Message Type 53 Values subregisty of the Dynamic
Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP)
Parameters registry located at:

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

two new Type 53 values are to be added as follows:

Value: [ tbd ]
Message Type:DHCPBULKLEASEQUERY
Reference: [ RFC-to-be ]

Value: [ tbd ]
Message Type:DHCPLEASEQUERYDONE
Reference: [ RFC-to-be ]


Third, in the Dynamic Host Configuration Protocol (DHCP) and Bootstrap
Protocol (BOOTP) Parameters registry located at:

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

a new registry will be created called "DHCP State TBD Values" (where TBD
corresponds to the assigned value of the dhcp-state option, from the
first IANA Action above). This registry will have the following initial
values:

Value State Reference
----- ------------- -------------------------
1 AVAILABLE [ RFC-to-be ]
2 ACTIVE [ RFC-to-be ]
3 EXPIRED [ RFC-to-be ]
4 RELEASED [ RFC-to-be ]
5 ABANDONED [ RFC-to-be ]
6 RESET [ RFC-to-be ]
7 REMOTE [ RFC-to-be ]
8 TRANSITIONING [ RFC-to-be ]

This registry will be maintained using IETF Review. (RFC 5226 replaced
"IETF Consensus" with "IETF Review.")


Fourth, in the Dynamic Host Configuration Protocol (DHCP) and Bootstrap
Protocol (BOOTP) Parameters registry located at:

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

a new registry will be created called "DHCP Status Code TBD Values"
(where TBD corresponds to the assigned value of the status-code option,
from the first IANA Action above). This registry will have the following
initial values:


Name status-code Reference
----------- ----------- ---------------
Success 000 [ RFC-to-be ]
UnspecFail 001 [ RFC-to-be ]
QueryTerminated 002 [ RFC-to-be ]
MalformedQuery 003 [ RFC-to-be ]
NotAllowed 004 [ RFC-to-be ]

This registry will be maintained using IETF Review. (RFC 5226 replaced
"IETF Consensus" with "IETF Review.")


Fifth, the the new registry created upon approval of the document
"Virtual Subnet Selection Options for DHCPv4 and DHCPv6"
draft-ietf-dhc-vpn-option, IANA will revise the registry that will be
created in the registry located at:

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

as a result of the IANA Actions in that document.

The newly created registry will be revised to contain the following
registrations:

Type VSS Information format:
0 UTF-8 ASCII VPN identifier
1 RFC2685 VPN-ID
2-253 Not Allowed
254 All VPNs. (wildcard; only allowed in DHCPBULKLEASEQUERY messages)
255 Global, default VPN.

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

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (Bulk DHCPv4 Lease Query) to Proposed Standard


The IESG has received a request from the Dynamic Host Configuration WG
(dhc) to consider the following document:
- 'Bulk DHCPv4 Lease Query'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery
  extension allows a requestor to request information about DHCPv4
  bindings. This mechanism is limited to queries for individual
  bindings. In some situations individual binding queries may not be
  efficient, or even possible. This document extends the DHCPv4
  Leasequery protocol to allow for bulk transfer of DHCPv4 address
  binding data via TCP.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-bulk-leasequery/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-bulk-leasequery/


No IPR declarations have been submitted directly on this I-D.

  (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?
       
I (Ted Lemon) am the document shepherd. I have reviewed the document, and believe 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

       
The document has had thorough review from several members of the working group, and is quite mature. The document has not been reviewed by other working groups--it is very specific to DHCP.

  (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?
       
I think the document is okay as it stands for the intended scope of use. It does not provide an authentication or authorization mechanism; this could be a problem if it were used out of its intended scope.

  (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.
       
The document is the result of two separate drafts from two different authors with clear need in the field for the functionality.  No IPR disclosures have been filed.

I have one minor concern about this document, which I've discussed with Kim.  The draft uses the term "global VPN" to mean "the Internet."  Kim says he did this for consistency with draft-ietf-dhc-vpn-option, which is currently being reviewed by the IESG.  I think this is confusing, and he's agreed to clarify it in the final AUTH48 edit if that's acceptable.  I would propose "global internet" instead of "global vpn," but I'm open to suggestions.

  (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? 
       
There is substantial consensus in the working group to publish the 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.)
       
There appears to be no rancor about this proposal.

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits? (See the Internet-Drafts Checklist
        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?
       
The document passes idnits except for one outdated reference to a draft that has since been updated.  This draft is a normative reference, so I expect this to be cleared up during publication.

  (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].
       
The doc has been split. Downward references exist for draft-ietf-dhc-relay-id-suboption-07.txt and draft-ietf-dhc-vpn-option-13.txt.

  (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 [RFC5226]. 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?
The IANA Considerations section has been updated to conform with these requirements. The IANA considerations section appears to be okay.  It's quite complicated, so it might be nice if another pair of eyes checked it.

  (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?
       
No such language exists in the text.

  (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 Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Leasequery
extension allows a requestor to request information about DHCPv4
bindings. This mechanism is limited to queries for individual
bindings. In some situations individual binding queries may not be
efficient, or even possible. This document extends the DHCPv4
Leasequery protocol to allow for bulk transfer of DHCPv4 address
binding data via TCP.
    Working Group Summary
This document received a thorough review by the WG. Many comments were made, and revisions done, but the process was amicable and seems to have satisfied all participants.
    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?
       
The authors are aware of three client implementations and one server implementation of the protocol. These implementations are of an earlier version of the document, but the authors believe they have gotten a good sense of the quality of the document from the exercise and do not anticipate that the changes that have been made during review will negatively impact interoperability.