Skip to main content

Shepherd writeup
draft-ietf-roll-nsa-extension

(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