Shepherd writeup

As required by RFC 4858, this is the current template for the Document 
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(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. Homenet was chartered to produce standards track work, and this is a fundamental building block for HNCP. DNCP could be used for other work in the IETF, and is based upon other standards track building blocks (RFC 6206). One of the reasons for separating DNCP out of HNCP, was for possible integration in Anima. Related work to DNCP (RFC 7503 which was spun out of Homenet, and RFC 6206 on which DNCP is based) are both standards track RFCs.

(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

This document describes the Distributed Node Consensus Protocol (DNCP), a generic state synchronization protocol which uses Trickle and Merkle trees.  DNCP is transport agnostic and leaves some of the details to be specified in profiles, which define actual implementable DNCP based protocols.

Working Group Summary

The earliest roots of DNCP are in draft-acee-ospf-ospfv3-autoconfig-00 (Oct 2011) which led to draft-acee-ospf-ospfv3-autoconfig-00 and was published as Standards Track RFC 7503,  draft-arkko-homenet-prefix-assignment-00 (April 2012), “Trickle” as defined in Standards Track RFC 6206, and HNCP first defined in draft-stenberg-homenet-hncp-00. DNCP in its current form was split from HNCP for the sake of modularity and reuse. Thus the work that ultimately led to this document evolved roughly through three major iterations before reaching draft-ietf-homenet-dncp-00. Last call had mostly minor issues brought up, which were addressed. 

Document Quality

  Are there existing implementations of the protocol? 

Yes, one open source project at and project homepage at

Have a significant number of vendors indicated their plan to implement the specification?

The open source implementation (hnetd daemon) has been a part of routing feed of OpenWrt since Barrier Breaker (14.07) release in July, 2014.

Google Nest, Comcast Xfinity, D-Link, Freebox, Technicolor, and Cisco have all expressed interest in implementing and/or shipping HNCP, which relies upon DNCP. HNCP (and thereby DNCP) is referenced in version 1.0 of the Thread Specification (Nest, Samsung, etc.)

“Homenet” running either the early OSPF version and later HNCP (with DNCP) has been demonstrated publicly at:

8 IETF BnB events
1 CES Event in Las Vegas
3 IPv6 World Congress
1 Cablelabs Meeting

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?

No particular Dr. reviews. I believe there has been a special request for review by the newly formed Routing Area Design Team regarding homenet, but have not seen the result. Brian Carpenter reviewed on behalf of Anima. Mikael Abrahamsson and Juliusz Chroboczek provided substantive review and comments as well.


Who is the Document Shepherd? 

Mark Townsley

Who is the Responsible Area

Terry Manderson

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

Document Shepherd performed a review just after last call, provided comments (mostly editorial) which have been addressed in the latest revision. 

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

Considering the entire life of the technology and open source development, I am very comfortable with the technical aspects. I would welcome more review for readability and consistency with the HNCP and other Homenet specifications as they have been through quite a bit of shuffling to get the right modules lined up with the right documents.

(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 optional “certificate-based trust consensus” security scheme could use additional review by a security expert. 

(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 such specific concerns or issues.

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

Email sent to authors on Friday, June 5 asking them to confirm explicitly that there is no IPR they are aware of.
Steven Barth and Markus Stenberg affirmed - waiting on Pierre Pfister

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


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

When HNCP and DNCP were created, the whole of the WG understood their purpose and exhibited strong consensus. As time has passed and “Big Decisions” turned to “Hard Work”, reliance upon a few individuals writing open source code has emerged. 

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

Not with DNCP, no.

(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

  == Line 167 has weird spacing: '...ntifier   an o...'
  == Line 223 has weird spacing: '...e trust   the ...'
  == Line 227 has weird spacing: '...r graph    the...'

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


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


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

The document does not intend to change the status of any existing RFC.

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

Confirm all of the above.

Note for RFC Editor - under further review the text of the IANA section needs some improvement by copying and/or moving normative text regarding use of certain ranges of TLV types into section 7 (the TLV definition). 

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

IANA will have one registry to setup for DNCP TLV types as outlined in the IANA Considerations section.

While DNCP is designed to be generally useful, its first usage is within Homenet (specifically HNCP) so any Expert Reviewer should be familiar with the work in the Homenet WG. Either the chairs, or other active and willing participants. 

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