Shepherd writeup
draft-ietf-dhc-sedhcpv6-21

Document Writeup, template from IESG area on ietf.org, dated 24 February
2012.

draft-ietf-dhc-sedhcpv6-05

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

  Proposed standard. This document defines new DHCPv6 options, an
  action which requires standards track. The indended type is
  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:

  This document analyzes the security issues of DHCPv6 and specifies a
  Secure DHCPv6 mechanism for communications between DHCPv6 clients and
  DHCPv6 servers. Client certificates and server private/public keys
  are defined. Server can verify client's identity by using PKI
  infrastucture. Clients couldn't do the same as during the
  configuration process they lack communication capabilities and
  thus can't access PKI. Therefore clients use server's public keys
  to verify the servers identity. Those mechanisms offer
  authentication and integrity. Also, an optional timestamp mechanism
  is defined as a protection against replay attacks.

Working Group Summary:

  This document has a long history in DHC. Its predecessor, draft-
  ietf-dhc-secure-dhcp-07, finished WG phase and was submitted to
  IESG in March 2013. It was rejected with the recommendation to
  rewrite it without using CGAs. draft-ietf-dhc-sedhcpv6 is
  realization of that request. Its initial version was published
  in June 2013 and was quickly adopted. This draft and its predecessor
  were presented several times during the DHC meetings. There was no
  opposition to this draft and WG was supportive. One member initially
  had some issues with the draft, but they were resolved and he
  is now a co-author. It went through WGLC in May 2014. The draft
  received sufficient support to pass, but there were significant
  changes introduced, therefore a second WGLC was held in Sep/Nov.
  2014. This time it passed with only small corrections addressed
  in -05.

Document Quality:

  This document went through multiple reviews by multiple WG
  participants. The options, client's and server's behaviors are
  clearly defined. The document was written by non-native speakers,
  which is visible in the text sometimes, but this does not impact
  its clarity. The document is idnits clean. (The only complaint
  is about the date not matching current year - it was published in
  Dec. 2014, so it is ok.)

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

  Tomek Mrugalski is the document shepherd. Ted Lemon 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 a thorough review of this draft twice for -02 and -04:

-02: http://www.ietf.org/mail-archive/web/dhcwg/current/msg15562.html
-04: http://www.ietf.org/mail-archive/web/dhcwg/current/msg16041.html

  I also checked that my (small) issues raised in -04 were addressed
  in -05. I also participated in on- and off-list discussions about
  this I-D, where I commented on several aspects. In my opinion, the
  current -05 revision is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  This draft received a very thorough review from the DHCP
  perspective. My inbox shows 181 messages related to this draft with
  about every active DHC member commenting on it at one time or
  another. I'm confident that the amount of reviews from DHCP
  perspective is more than sufficient. This draft could always get
  more reviews from the security point of view. I'm hoping that to
  happen as part of the IETF LC process.

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

  This draft received thorough DHC review. Two people involved, Sheng
  Jiang and Jinmei Tatuya (who initially served as a reviewer and
  later joined as co-author), are considered security experts. A third
  one, Francis Dupont, who is also a security expert, reviewed this
  draft and had commments which were addressed. If this review is
  insufficient from the security perspective, it may be useful to
  request additional review in the security directorate.

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

(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. All four authors confirmed in writing that the process has
  been followed. There are no IPR disclosures and they are not aware
  of any outstanding disclosures.

(8) Has an IPR disclosure been filed that references this document? If
so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

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

  The WG consensus is solid. There was never any opposition and the
  WG was supportive for this work. The WG participants involved
  discussed the issues at length. I counted 20 members involved
  in the sedhcpv6 discussion.

(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 2 nits, but they are about the year (2014) not matching
  current. That is ok, as the -05 was published in Dec. 2014.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No such review was necessary.

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

(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. There are no downard normative references.

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

  No. This draft defines new options and extends, but not updates the
  base (RFC3315) DHCPv6 spec. As such, lack of "updates 3315" is correct.

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

  IANA considerations section requests addition of four option codes
  to the existing DHCPv6 option codes list. It also requests creation
  of two new registries on the DHCPv6 parameters registry
  page. Initial contents, allocation procedures and reasonable names
  are clearly specified.

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

  There are no new IANA registries that require Expert Review.

(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 checks were necessary.
Back