Document writeup for:
https://datatracker.ietf.org/doc/html/draft-ietf-intarea-provisioning-domains-07
based on the template here:
https://www.ietf.org/chairs/document-writeups/document-writeup-working-group-documents/
as of 2019.06.06.
---
(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?
[1a] The type of RFC being requested is Proposed Standard.
[1b] This document meets the spirit of RFC 2026 section 4.1.1
("Proposed Standard"); the specification "has resolved known
design choices, [and] is believed to be well-understood" though
"further experience might result in a change...".
[1c] The document's title page header states
"Intended Status: Standards Track."
(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.
A provisioning domain (PVD) is defined as the consistent set of
network configuration information allowing a node to make use of
a network (RFC 7556 Section 2).
This document defines a mechanism for explicitly identifying PVDs
through a Router Advertisement (RA) option. This RA option announces
a PVD identifier, which hosts can compare to differentiate between
PVDs. The option can directly carry some information about a PVD and
can optionally point to additional PVD information that can be
retrieved using HTTP over TLS.
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 were two key discussions about the PVD Option that informed the
design.
First: all necessary (non-optional) data for making consistent use of
a network (PVD information) must be transmitted atomically. Use of
existing RA header and options support this (i.e. PIO, RIO, RDNSS).
The atomicity of receiving the minimum required set of information
helped establish that there would be no dependency loop on the
(supposed to be) optional data.
Second: there should be support for PVD Option-aware and non-aware
clients on the same network. This is the origin of the RA option
encapsulating format.
Document Quality:
Are there existing implementations of the protocol? Have a significant
number of vendors indicated their plan to implement the specification?
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?
I am not aware of any non-hackathon implementations. The mobile
operating system vendors have indicated their intent to implement.
At least one network vendor is in the course of implementing, and
has funded some open source Linux kernel work as well.
I am not aware of any media type review that was requested; the
media type registration template has been completed in the IANA
Considerations section.
Personnel:
Who is the Document Shepherd? Who is the Responsible Area Director?
The Document Shepherd is Erik Kline <ek@loon.com>.
The Responsible Area Director is Suresh Krishnan <suresh@kaloom.com>.
(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.
[3] I have read this document many times during its evolution. For
this writeup I have reread it in detail. I have sent some comments
to the authors that I think will clarify several minor issues. I
would expect that a -08 version (incorporating the feedback as deemed
appropriate) would be publishable as a proposed standards track
document.
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
[4] The general intarea concerns seem to have been hammered out in
the discussion among those that spoke up. It's not clear if others
in the working group have grasped the potential new use cases and
architectures that this document enables. The authors and active
discussion participants do seem to understand this, of course.
Some of the comments from the SECDIR review of -04 are of interest,
and there may well be future work around signing PVD data with JOSE.
I expect operational experience will motivate and inform such work.
(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.
[5] Beyond the directorate reviews and reviews required for
IANA-related issues (questions 17 and 18), no additional review
seems to be required.
Operational experience will need to be gained with this proposed
standard and subsequent documents will likely address the
management of any complexity that arises.
As mentioned in the SECDIR review, the use of the .well-known URI
and "vendor-*" PVD JSON keys may need a rethink (I'm not sure, but
"vendor-*" might fall into the same category as "X-*" vis a vis
RFC 6648. I have no concerns about the use of either of these.
(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.
[6] None.
(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?
[7] All authors have confirmed that they know of no relevant IPR
and therefore no appropriate IPR disclosures seem necessary.
(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.
[8a] A search on the IETF datatracker IPR page for:
https://datatracker.ietf.org/ipr/search/?doctitle=provisioning+domains&submit=doctitle
turned up only 2 IPR claims, neither of which are filed against this
document.
However, this document does have an informative reference to a
document with an IPR claim (https://datatracker.ietf.org/ipr/2722/).
[8b] Not Applicable.
(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 document has the solid consensus of those most directly impacted
by the lack (and, if published, presence) of explicit PvD indicators,
namely the mobile operating system developers. The document also
has (at least one) vendor support.
Surveying the mailing list archives, there appears to be consensus
support and no one raising concerns (technical or otherwise) in the
past year or so. The number of voices in favor are not numerous,
but the number opposing appears to be zero.
(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.)
[10] No public indications of opposition, nor are any known privately
by me.
(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.
[11] An email has been sent to authors with review comments. The
[URN] reference appears to be incomplete.
The automated checks have not flagged any errors in -07 and the
document seems to not run afoul of anything listed in
https://www6.ietf.org/id-info/checklist.html .
(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.
[12] The IANA Considerations requests a media type and a .well-known
URI.
The media type request appears to conform to RFC 6838 Section 5.6.
The .well-known URI may or may not have been requested per
RFC 8615 Section 3.1 (see 17c). I am seeking confirmation from the
authors.
(13) Have all references within this document been identified as either
normative or informative?
[13] 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?
[14] No; all normative references are already 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.
[15] No; all normative references are one of Internet Standard,
Proposed Standard, or Draft Standard. Of note, RFCs 2119 and 8174
are listed as Informative, and I have sent a note to the others
asking if they should be moved to normative. If so reclassified,
RFC 8174 is a BCP.
(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.
[16] No RFCs are updated nor any any obsoleted by this document.
(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 8126).
[17a] The IANA section appears to be in order with the possible
exception of the .well-known URI request (see 17c).
[17b] The existing IPv6 ND Option value 21 is requested to be made
permanent (remove the reclaimable designation from the existing
temporary assignment).
[17c] The IANA Considerations section mentions the RFC 8615
"Well-Known URI" registry, but it's not clear if registration
according to RFC 8615 Section 3.1 has taken place or not.
[17d] The two newly created registries are both identified ("PVD
Option Flags" and "PVD Additional Information Keys"), define their
present contents, and document the procedure for updates
(former: standards action, latter: expert review).
(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.
[18] This document requests a new IANA registry for
"Additional Information PvD Keys" new assignments for which would
require Expert Review.
Suitable experts would include people familiar with host operating
system implementations, particularly PVD-aware operating systems,
since they are likely intended consumers of this data.
Additionally, review from operators of networks that provide Explicit
PVD information services could be sought, to confirm there are no
operational deployment concerns with any proposed new keys.
(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.
[19] None. Visual inspection of I-JSON text only.