(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?
Yes.
(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
mechanism.
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
http://tools.ietf.org/html/draft-boucadair-pcp-nat64-experiments-00#section-2.9
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).
Personnel:
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
IESG.
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?
Yes.
(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.)
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 1 instance of lines with non-RFC2606-compliant FQDNs in the
document.
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
intentional?
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
draft-ietf-pcp-server-selection-01
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?
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?
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.
None.
(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.