Skip to main content

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

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


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

(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

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