Skip to main content

Shepherd writeup

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet 
    Standard, Informational, Experimental, or Historic)? 

Proposed Standard

    Why is this the proper type of RFC? 

This specifies an option for configuring a standards track protocol,
and the WG charter we have consensus on has a milestone for standards track
PCP server discovery.

    Is this type of RFC indicated in the title page 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:

    Relevant content can frequently be found in the abstract and/or 
    introduction of the document. If not, this may be an indication that 
    there are deficiencies in the abstract or introduction. 

This document specifies DHCP (IPv4 and IPv6) options to configure
hosts with Port Control Protocol (PCP) Server IP addresses.  The use
of DHCPv4 or DHCPv6 depends on the PCP deployment scenario.

    Working Group Summary:

    Was there anything in WG process that is worth noting? For example, was 
    there controversy about particular points or were there decisions where 
    the consensus was particularly rough? 

There was controversy around the use of IP address vs hostnames vs
strings passed to getaddrinfo (which could be hostname or IP literal).
The WG eventually achieved rough consensus on the IP address mechanism
recommended by Ted Lemon, referencing [I-D.ietf-dhc-topo-conf] informatively
for discussion on how various scenarios can still be solved using that

    Document Quality:

    Are there existing implementations of the protocol? Have a significant 
    number of vendors indicated their plan to implement the specification? 

One implementation is documented at

Other implementations are expected.

    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? 

Ted Lemon performed DHCP review and raised issues with the previous approach
(strings passed to getaddrinfo).  A significant discussion ensued which 
resulted in Ted authoring draft-ietf-dhc-topo-conf for WGs and documents
to reference.  That document was presented to the PCP WG, which then got
consensus on the final approach (IP addresses, and referencing that draft
for discussion of operational guidance).


    Who is the Document Shepherd? 

Dave Thaler

    Who is the Responsible Area Director? 

Ted Lemon

(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

The document shepherd checked ID-nits, reviewed the document for
clarity and completeness, verified all open issues were addressed,
and consensus exists on the document.

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

No concerns.

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

The review has gone through multiple DHCP expert reviews, first by Bernie Volz
and then more recently by Ted Lemon. The reason the document took so long
was in fact due to the multiple reviews that ended up changing the consensus
of the WG as a result, with corresponding doc updates.

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

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


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

No IPR disclosures filed.

(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 as a whole understands and generally agrees with it. There were
dissenting opinions, but the WG did achieve consensus.

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


(11) Identify any ID nits the Document Shepherd has found in this document. 
     (See and the Internet-Drafts 
     Checklist). Boilerplate checks are not enough; this check needs to be 

  == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the

This is a false warning, it complains about the "a1.a2.a3.a4" notation
being used to refer to the four bytes of an IPv4 address.

  == The copyright year in the IETF Trust and authors Copyright Line does not
     match the current year

  -- The document date (November 05, 2013) is 119 days in the past.  Is this

These are intentional.

  -- No information found for draft-ietf-dhc-topo-conf - is the name correct?

Seems to be a tools issue as the name and reference are correct.

  == Outdated reference: A later version (-02) exists of

This informative reference is normal based on the date, and will be 
automatically handled as part of the publication process.

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

No formal reviews beyond the DHCP expert review that occurred.

(13) Have all references within this document been identified as either 
     normative or informative? 


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

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. 

Normative references are to
RFC 2119 = BCP
RFC 2131 = Draft Standard
RFC 2132 = Draft Standard
RFC 3315 = Proposed Standard
RFC 4291 = Draft Standard
RFC 6887 = Proposed Standard

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

(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 document shepherd's earlier review resulted in the present IANA
considerations section. No new registries are creted, and existing registries
referenced are clearly identified.

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


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

There are no such formal language sections.