Shepherd writeup
rfc7724-07

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