Shepherd writeup
draft-ietf-roll-nsa-extension-10

(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 is the type indicated in the title page header.
This draft defines a new Objective Function for the RPL (RFC6550) routing protocol, as well as a new extension for the Node State and Attibute (NSA) object for the RPL routing metric (RFC6551).

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

Packet Replication and Elimination (PRE) is a general method for maximizing packet delivery rate and potentially minimizing latency and jitter.
PRE achieves controlled redundancy by laying multiple forwarding paths through a network and forwarding copies of a same packet in parallel over these paths.
PRE can follow the Destination-Oriented Directed Acyclic Graph (DODAG) formed, in a distributed fashion, by RPL.
RPL allows selecting multiple parents for each node in a network, a subset of these parents being used to forward packets.
What was missing so far to achieve PRE with RPL was
- an Objective Function (OF) that drives a node to locally select its parents based on their contributions to controlled redundant paths
- a metric that allows parent candidates to advertise their own parent set, allowing the Objective Function to achieve the aforementioned goal
This document specifies such metric and OF (actually even 3 different flavors of the OF).

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 no controversy, but a few reviews and discussions on a few technical aspects.
One topic carried over is about compressing the list of IPv6 addresses that are included in the Parent Set TLV of the metric.
The WG decided that this compression should be out of the scope of this draft, since a general compression technique for all RPL control messages (and in particular, those that carry IPv6 addresses) is needed anyway.
Until such compression is standardised, the applicability of this draft is likely to be limited to not-so-constrained networks.

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, YANG 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?]
There is one academic implementation known so far (by Tomas Lagos Jenscke, who is specifically recognized in the Acknowledgements section).
This work is awaited by the 6TiSCH and DetNet groups as the way to achieve Packet Replication and Elimination with RPL.
Therefore, other implementations are expected to emerge as part of the various 6TiSCH implementations.

Personnel:

[Who is the Document Shepherd? Who is the Responsible Area Director?]
The shepherd is Dominique Barthel.
The responsible AD is Alvaro Retana.

(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 Shepherd, who happens to be a co-author of RFC6551, had a special interest in this draft and performed several thorough reviews over the two years it was matured.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? 
No particular concern, for the reason mentionned in (3). The draft was reviewed by several competent contributors of the ROLL WG. However, more reviews from people with different backgrounds are always good.

(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. 
I don't believe any such particular perspective is needed, although Security Considerations reviews often bring back their load of surprises.

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

As mentionned in (2), a compression technique (beyond that of 6LoWPAN) is needed for this document to be applicable to constrained network. The WG intends to work on this, going forward.

(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, the 4 authors have confirmed that they are not aware of any IPR related to this draft, beyond disclosures # 3286 and 3269. 

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. 
Two IPR disclosures have been filed, which reference an earlier version of this document: # 3286 and 3269, Aug 2018.
This has been announced on the mailing list and displayed at several ROLL meetings. This has not prompted any discussion on the ML or at the WG meetings.

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

Packet Replication and Elimination is of interest for only a few people in the Working Group, who are mostly 6TiSCH and DetNet contributors.
They turn out to be among the most active and influencial contributors to the ROLL WG at the moment.
Other individuals in the WG seem to understand what is being done and have not expressed disagreement.

(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 significant discontent was expressed about this draft.

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

Idnit reports no issue on version -10 of the draft, except for one warning: one informative reference (draft-ietf-6tisch-architecture-29) has advanced to -30 since publication of -10 of this draft.
This will be corrected as part of the changes following IESG review.

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

The document has no such content requiring formal review.

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

Yes indeed.

(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 RFC's.

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

This document adds a new Objective Function (new code point) to RPL. RPL (RFC 6550) anticipated that objective functions would be added later as separate documents, so the status of RFC 6550 is not changed by this document.
This documents adds a TLV option (new code point) in the RPL Routing Metric/Constraint of RFC 6551. RFC 6551 anticipated that new options would be added later, so the status of RFC 6551 is not changed by this document.
In any case, RFC 6550 and 6551 are appropriately described and referenced 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 8126). 

This draft does not define any newly created IANA registries.
I have verified that the new requested codepoints (one for the Objective Function, one for the Parent Set option of the RPL Routing Metric/Constraint) accurately reference the appropriate IANA 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. 

This draft does not define any new IANA 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, YANG modules, etc.

There is no such section in this draft.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not Applicable.
Back