Document Writeup, template from IESG area on ietf.org, dated 24 February
2012.
draft-ietf-dhc-dhcpv4-active-leasequery-04
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)? Why is
this the proper type of RFC? Is this type of RFC indicated in the title
page header?
Standards track. This I-D defines an extension to the DHCPv4 and
also updates existing standards track RFC, so it is a valid type.
The indended type is clearly indicated in the header.
(2) 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) has been
extended with a Leasequery capability that allows a client to request
information about DHCPv4 bindings. That mechanism is limited to
queries for individual bindings. In some situations individual
binding queries may not be efficient, or even possible. In addition,
continuous update of an external client with Leasequery data is
sometimes desired. This document expands on the DHCPv4 Leasequery
protocol, and allows for active transfer of near real-time DHCPv4
address binding information data via TCP.
Working Group Summary:
Active leasequery for DHCPv4 was initially proposed in 2010, but
after 2 revisions it was abandoned due to lack of interest in the
WG. In 2013 active leasequery was proposed for DHCPv6 and received
strong support in the WG. v6 version was presented in Vancouver
(IETF88, Nov 2013) and one of the questions was whether WG is
interested in its v4 equivalent. The strong consensus in the room
(later confirmed on ML) was to have active leasequery for both
DHCPv4 and DHCPv6 and thus the v4 draft was revived. As the
principles are the same, this ended up in a somewhat unusually fast
path. Cisco seems to have working implementation of this protocol,
which is reflected in high maturity of the draft. 00 WG item
passed WGLC in March 2014. The -01 (June 2014) addresses all raised
comments (all were minor). This work was somewhat stalled as its
v6 equivalent required several updates. The latest v6 draft was
approved in June 2015 and all the changes required to address IESG
comments were applied to v4 (in version -04).
Document Quality:
This document is of high quality. Personally, I think this is the
result of several factors: the imlementation primary author is
involved in has this mechanism implemented with actual deployments
for serveral years, significant experience of its primary author
and also the similarity to its DHCPv6 counter-part, which was
recently approved by IESG. Author made extra care to apply all
changes to both v4 and v6 drafts. I have reviewed -04 and
think it is ready for publication. It is idnits clean.
Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
Tomek Mrugalski is the document shepherd. Brian Haberman is the
responsible AD.
(3) Briefly describe the review of this document that was performed by
the Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.
I did read this document thoroughly and posted my comments to the
ML: http://www.ietf.org/mail-archive/web/dhcwg/current/msg15380.html
All my comments were addressed adequately. I also checked that all
comments raised during v6 active leasequery review in IESG were
also addressed in this v4 draft.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No. There was sufficient number of comments received, from both the
usual participants and also several people who typically do not
participate in DHC discussions.
(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.
No. There are no such sections needed. This draft is purely DHCP
extension, so DHC is the appropriate and sufficient WG to do the
review.
(6) Describe any specific concerns or issues that the Document Shepherd
has 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.
I do not have any concerns. One objection raised during the
discussion of the v6 version of this draft was that this mechanism
can be misused for pervasive monitoring. While technically it is
true, once the DHCP server cooperates (willingly or otherwise), he
may provide access to the DHCP server database and extract that
information anyway. Also, from my business experience I can see
valid use cases where an ISP could use active leasequery to notify
its inventory database about devices going up or down.
(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why?
Yes. Each author confirmed in writing that they are not aware of any
outstading IPR disclousures.
(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
Yes. There is one filed: http://datatracker.ietf.org/ipr/1278/
It was filed very promptly, couple days after the individual draft
was submitted. As the draft was individual at that time, the
announcement was not sent to the ML. This has been brought up to
the WG attention (http://www.ietf.org/mail-archive/web/dhcwg/current/
msg15452.html), but it didn't cause any reaction. That is
understandable, as the IPR disclousure is quite benign. Disclaimer:
I'm not a laywer and often find legal terms confusing.
(9) 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 strong consensus for this work. There was never any
opposition, although the interest was minor couple years ago.
Since the DHCPv6 equivalent is moving forward, WG decided to proceed
with DHCPv4 as well. That support was demonstrated during adoption
call (Dec 2013) and WGLC (Feb/March 2014).
(10) 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 publicly available.)
No.
(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
There are none. The I-D is idnits clean.
(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.
No such additional reviews are required.
(13) Have all references within this document been identified as either
normative or informative?
Yes.
(14) 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 plan for their completion?
No. All normative references are to published RFCs.
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
No.
(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed
in the Abstract and Introduction, explain why, and point to the part of
the document where the relationship of this document to the other RFCs
is discussed. If this information is not in the document, explain why
the WG considers it unnecessary.
Yes. It updates DHCPv4 Bulk Leasequery (RFC6926). That information
is clearly stated on the front page in the header and further
repeated in Abstract and later explained in the Introduction.
(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA
registries. Confirm that any referenced IANA registries have been
clearly identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).
The IANA considerations section is written correctly. It requests
IANA to assign 3 new DHCPv4 message types and 4 new status codes. All
registers and values are clearly identified, including direct links
to said registries.
(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.
No new IANA registries are defined.
(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
No such reviews were necessary.