Distributed Node Consensus Protocol
draft-ietf-homenet-dncp-12

[Ballot comment]
publication in conjunction with an actual profile would I think have gone a long way towards ameliorating concerns associated with the nature of the document as it is it's incomplete. however it's time to move forward.

[Ballot comment]
I am abstaining, as this draft is not specifying a full protocol but just giving an abstract protocol (i.e., a hull only). I would ballot with no-objection if the designated status of this draft would be 'Informational', but given that it is 'Proposed Standard' I do not see that  RFC 2026, Section 3.1 and 3.2 are covered. It is neither a Technical Specification nor an Applicability Statement.

However, I will not stand in the way of the publication of the document.

[Ballot comment]
Thank you very much for addressing my previous Discuss points and comments. 
I understand that version -11 will handle the most recent concerns, as shown in
the github diff.

I've also read this draft too many times at this point to be certain that I've picked up all the points of
unclarity.

a) As pointed out by Lizhong, it would be very useful to have some text discussing
the issues around a network hash collision.  I suspect that this is related to guidance
for a DNCP profile on how to make a decision about what hash function to use and
how many bits to include

6) Please define H(...) in terminology, since Sec 4 uses it before it is defined in
Section 7.

[Ballot discuss]
Other ADs focused on the protocol specific points. So let me focus on something else.
The applicability section doesn't answer my questions: when to (re-)use this protocol?
Note that the write-up mentioned ANIMA.

I see the protocol description:

  DNCP is designed to provide a way for each participating node to
  publish a set of TLV (Type-Length-Value) tuples, and to provide a
  shared and common view about the data published by every currently or
  recently bidirectionally reachable DNCP node in a network.

However, this applicability section doesn't tell me when to re-use DNCP (or define a profile for it).
I see an effort to address my discuss in the appendix B of draft version 11. Thanks

What would solve my DISCUSS is an applicability section that would contain
a high level set of criteria that would briefly explain whether DNCP is applicable for
the specifications I have in mind. The first 2 paragraphs of section 1.1 is a good start,
then it goes considerations about Trickle, the interval A_NC_I, etc ... and you lose the
readers. 

Something like:

  DNCP is designed to provide a way for each participating node to
  publish a set of TLV (Type-Length-Value) tuples, and to provide a
  shared and common view about the data published by every currently or
  recently bidirectionally reachable DNCP node in a network.

  [As an example of what I'm expected, see below.
    Btw, I have no idea if this text is correct or complete, but that's besides the point]

  DNCP works with profiles in which you have the flexibility to specify:
  - the appropriate transport: the available options are TCP and UDP (see
  section appendix B for the tradeoffs)
  - the transport security: TLS or DTLS, see appendix B).
  - If service discovery is required, an optional multicast service can be defined. 
  - TO BE COMPLETED

  DNCP is applicable to LAN, WAN, or even the Internet.
  DNCP can exchange enterprise specific TLV or an IANA registry could be specified
  DNCP specific extensions are possible.
  TO BE COMPLETED

  DNCP limitations:
- Data published limited to 64kB
- Doesn't work for SCTP, DCCP
        - All devices in the network must be DNCP node?
        - TO BE COMPLETED

To summarize, I need the 2 min elevator pitch of when (not) to use DNCP.

[Ballot comment]
- I would agree with Alvaro, when he wrote: "In general, I found the text not straight forward or easy to understand." Potentially due to the structure.

- I hope that a document about manageability considerations (see https://tools.ietf.org/html/rfc5706#appendix-A) will follow.

[Ballot comment]
Thank you very much for addressing my previous Discuss points and comments. 
I understand that version -11 will handle the most recent concerns, as shown in
the github diff.

I've also read this draft too many times at this point to be certain that I've picked up all the points of
unclarity.  I've requested another Routing Directorate review, from a new reviewer, so I may be modifying
my ballot again before the telechat on Thursday.

6) Please define H(...) in terminology, since Sec 4 uses it before it is defined in
Section 7.

[Ballot comment]
Update:

The new version made some changes to appendix B, but at least for the transport security section, it's not clear to me if this means the _section_ is optional or that _transport_security_ is optional. If the former, then I'm concerned people may take that as a license not to think about transport security requirements. Would it make sense to make the section required, even if took the form of "This profile does not require transport security because of "?

Previous comment:

Thanks for the new appendix B. How should we interpret the "(optional)" tag on some of the sections of that appendix? For example, does for the Transport Security section, does (optional) mean the section is optional, that transport security is optional, or both?

[Ballot discuss]
Thank you very much for addressing my previous Discuss points and comments.  On a fresh read of the updated draft,
I have the following one minor point (but it matters for interoperability with DNCP profiles):

1) End of Sec 4.4, can you clarify what the behavior is for
unrecognized TLV that is included in the Node Data field of a Node
State TLV?  I assume that its meaning is not processed, but it is
included in the computation of the Node State Hash?

I've also read this draft too many times at this point to be certain that I've picked up all the points of
unclarity.  I've requested another Routing Directorate review, from a new reviewer, so I may be modifying
my ballot again before the telechat on Thursday.

[Ballot comment]
I also have a few more minor comments that affect readability.

2) On p. 6, Definition of Peer means that the same DNCP node using a
different local and remote endpoint pair would be a different Peer??
Is that intentional?

3) In Sec 4.1.1, I had no idea that the node's sequence number was
included before.  Thank you for the extra clarity!

4) In Sec 4.5, it seems unfortunate to have old network and
connectivity state stored.  It seems to me that it'd be fairly trivial
to describe a "polite neighbor" termination policy where a peer sends
an Node Data TLV for itself with no data in it - including Node
Endpoint TLVs.  I am a bit nervous about bad side effects, but I do
not have a specific example to mind and obviously, a neighbor can fail
as well as gracefully shut down connections.  Describing "polite neighbor"
behavior may be too much of a technical change at this point, but I'd be
happy if you think about it seriously.

5) In Sec 7.2.2, it says "This TLV contains the current locally calculated network state hash, see Section 4.1 for how it is calculated."  This describes the value when sent.  When received, it contains the Peer's network state hash.

6) Please define H(...) in terminology, since Sec 7 uses it.

[Ballot comment]
For -10, I just have a couple of nits from my comments related to -09.

In the Introduction  s/currently or recently bidirectionally reachable/currently bidirectionally reachable

In Section 2. (Terminology) the definition of bidirectionally reachable still uses “recent” in the definition.  Given the text in Section 4.5. (Adding and Removing Peers) I suggest simply to s/if a recent and consistent multicast/if consistent multicast

[Ballot comment]

Just to note version -10 took some of my comments below into
account. I didn't check in full detail, my comments being non
blocking.

- 8.3 generally: I think this could be the basis for something
quite good but that'll only become clear really (to me) when I
go over it in a real protocol and not in the abstract. I'd
also speculate that you might end up changing this if it gets
more security review, but again that's hard to get in the
abstract.  Basically: be prepared for changes as this is made
concrete and if that would be a problem please yell now.  If
you do yell, I'm fine with making this a DISCUSS so we're sure
to resolve it. (I nearly did make this a DISCUSS, as I'm not
sure this is all fully worked out, but I'm ok that we can fix
that later. And you have enough DISCUSS ballots;-)

- The write up notes various drafts were input to what became
this one. I assume that none of those had associated IPR that
hasn't trickled through to being noted as applying to this
one? If not, as I expect, that's fine, no response is needed,
I'm just noting this since I didn't see any "replaced by"
entries in the history and it's those that cause IPR to be
transitively visible.

- section 2 - it's not clear to me why all node identifiers
need to be the same length - some protocols using DNCP could I
guess have variable length identifiers. IPv4 and IPv6 and
Ethernet for example all have different lengths.

- 4.2: seems to contradict itself. 1st para says that MC is
not used for anything sensitive, but 2nd-last para of section
says that network state TLVs can be sent "now and then."
(Reason to ask is that (D)TLS won't work if sensitive data is
sent via MC.)

- 4.4, 2nd para: what is a "valid" address?

- 8.1: do you mean one PSK per network or per pair of nodes?
Better to say. I assume it's the former.

- 8.3: This is an example of (a fairly complex) use of
opportunistic security (RFC7435). Be good to note that.

- 8.3: Calling this "certificate based" is I think a misnomer.
I suspect all the same things could be done with raw public
keys (RFC 7250).

- 8.3: please do note that a concrete protocol might need
changes to this distributed algorithm and that this section is
guidance and not to be considered entirely fixed (when
coding).

[Ballot comment]
After spending a bunch of time reviewing the DISCUSS and COMMENT points made by all the IESG members and having several in-depth discussion with other IETF participants, I am abstaining on this document. I believe the concept of an "abstract protocol specification" does not align with the IETF's goal of generating clear and inter-operable protocol specifications. This approach requires an implementer to resolve differences between the abstract protocol specification and the profile rather than simply implementing a single protocol specification. Such an approach has a higher probability of error than the single specification approach. If the basic premise of a protocol is sound and applicable for other uses, a new protocol specification can be written that borrows the necessary part from the previous protocol and makes any requisite changes for the new use.

Given this, I will not support the publication of this draft, but I will not stand in its way given the perceived rough consensus for it.

[Ballot comment]
Thanks for the new appendix B. How should we interpret the "(optional)" tag on some of the sections of that appendix? For example, does for the Transport Security section, does (optional) mean the section is optional, that transport security is optional, or both?

[Ballot comment]
Thanks for your detailed work on this draft to provide all of the security related options in section 8.

Thanks for addressing my prior discuss with a note in section 8 on why TLS/DTLS should be used and the expanded guidance in the appendix for a profile.

[Ballot comment]
Thanks for talking through my Discuss, which was

This should be an easy Discuss to ... discuss ...

I'm looking at this text:

  If keep-alives specified in Section 6.1 are NOT sent by the peer
  (either the DNCP profile does not specify the use of keep-alives or
  the particular peer chooses not to send keep-alives), some other
  existing local transport-specific means (such as Ethernet carrier-
  detection or TCP keep-alive) MUST be used to ensure its presence.
 
and wondering if using TCP keep-alive for liveness detection is realistic in the use cases this specification is expecting to address.

Unless I missed something, the default TCP keep-alive interval is still two hours (that's been true since RFC 1122, and also true in the relatively recent version of Linux I'm using). If that's OK, I'll clear.

If you're assuming a keep-alive interval that's shorter, lots of implementations allow you to tune this, but it seems like the specification should say something about that.

Given that the other example of "transport-specific means" is Ethernet carrier-detection, which would be orders of magnitude faster, I thought I should ask.

[Ballot comment]

- 8.3 generally: I think this could be the basis for something
quite good but that'll only become clear really (to me) when I
go over it in a real protocol and not in the abstract. I'd
also speculate that you might end up changing this if it gets
more security review, but again that's hard to get in the
abstract.  Basically: be prepared for changes as this is made
concrete and if that would be a problem please yell now.  If
you do yell, I'm fine with making this a DISCUSS so we're sure
to resolve it. (I nearly did make this a DISCUSS, as I'm not
sure this is all fully worked out, but I'm ok that we can fix
that later. And you have enough DISCUSS ballots;-)

- The write up notes various drafts were input to what became
this one. I assume that none of those had associated IPR that
hasn't trickled through to being noted as applying to this
one? If not, as I expect, that's fine, no response is needed,
I'm just noting this since I didn't see any "replaced by"
entries in the history and it's those that cause IPR to be
transitively visible.

- section 2 - it's not clear to me why all node identifiers
need to be the same length - some protocols using DNCP could I
guess have variable length identifiers. IPv4 and IPv6 and
Ethernet for example all have different lengths.

- 4.2: seems to contradict itself. 1st para says that MC is
not used for anything sensitive, but 2nd-last para of section
says that network state TLVs can be sent "now and then."
(Reason to ask is that (D)TLS won't work if sensitive data is
sent via MC.)

- 4.4, 2nd para: what is a "valid" address?

- 8.1: do you mean one PSK per network or per pair of nodes?
Better to say. I assume it's the former.

- 8.3: This is an example of (a fairly complex) use of
opportunistic security (RFC7435). Be good to note that.

- 8.3: Calling this "certificate based" is I think a misnomer.
I suspect all the same things could be done with raw public
keys (RFC 7250).

- 8.3: please do note that a concrete protocol might need
changes to this distributed algorithm and that this section is
guidance and not to be considered entirely fixed (when
coding).

[Ballot discuss]
Other ADs focused on the protocol specific points. So let me focus on something else.
The applicability section doesn't answer my questions: when to (re-)use this protocol?
Note that the write-up mentioned ANIMA.

I see the protocol description:

  DNCP is designed to provide a way for each participating node to
  publish a set of TLV (Type-Length-Value) tuples, and to provide a
  shared and common view about the data published by every currently or
  recently bidirectionally reachable DNCP node in a network.

I see, under the applicability section, under which conditions to use it.
Basically, suitable to exchange any TLV tuples, infrequently.

However, this applicability section doesn't tell me when to re-use DNCP (or define a profile for it).
What about the environment: home network versus LAN versus WAN? How big can the network be?
Does the technology matter?
Regarding transport, it's basically any transport, unicast or multicast, right? (DNCP can be used in networks where only unicast transport is
available.  While DNCP uses the least amount of bandwidth when multicast is utilized)
All devices in a DNCP network must be DNCP node?
I have a DNCP network with profile 1, can I use the same DNCP network with profile 2?
IANA and enterprise specific TLVs?
UDP is fine as a transport?
What if I know my topology already (I see later: "may use multicast for Trickle-based shared state dissemination and topology discovery")
etc. 

Just reading the intro and the applicability, I scratched my head: it's so generic, should I even consider it for ANIMA?

A few paragraphs, somewhere in the document, would solve my DISCUSS:
- this protocol should be used to exchange the following type of data ...
- it's envisioned that this generic state synchronization protocol will be used in the following environments ...
- potential DNCP-based protocols include ...

[Ballot comment]
- I would agree with Alvaro, when he wrote: "In general, I found the text not straight forward or easy to understand." Potentially due to the structure.

- I hope that a document about manageability considerations (see https://tools.ietf.org/html/rfc5706#appendix-A) will follow.

- As reported by Victor, part of his OPS DIR review:
Found In Nits:

(https://tools.ietf.org/idnits?url=https://tools.ietf.org/id/draft-ietf-homenet-dncp-09.txt)

    - Use of lower case not with SHOULD statement (see Paragraph 2,
    Section 4.5)

    - Flagged spacing items (Lines 197, 252, 256 and 260)


Section 3: Overview
 
    paragraph 2: their addresses may be manually configured or they may

      be found by some other means defined in a later specification

    ** This text is not quite clear.  Is it the author’s intention that
    the reader assume the other means will be part of a specific DNCP
    profile specification, a revision of the DNCP document or a
    different type of document.? ***


Section 4.2: Data Transport

    Paragraph 4 / Part “Multicast+Unicast”

      It is used to send Network State TLVs every now and

          then, as specified in Section 4.3

    It is used to send Network State TLVs
    periodically, as specified in Section 4.3

      Avoids using an idiom to express sending frequency
    in text.


Section 8.1 Pre-Shared Kay Trust Method

    ** Would it be within the DNCP document to discuss how PSKs are
    stored (as to not be externally accessed) or would it be to the
    profile to defined that level? ***

[Ballot comment]
In general, I found the text not straight forward or easy to understand.  I support Alia’s DISCUSS on the basis that the document doesn’t seem to be well structured and some details are missing.  As I read, there were concepts/explanations that required me to read ahead to clarify; that is not a showstopper in itself, but maybe the fact that the TLVs were defined after the operation causes some of the confusion and makes the document harder to understand than what it has to be.

Comments:

1. Abstract.  "DNCP is an abstract protocol, and must be combined with a specific profile to make a complete implementable protocol.”  The shepherd’s writeup claims implementations.  The links show that the implementation is of HNCP.  It would have been better to progress both IDs together to better understand any dependencies, etc.

2. There are several places in the document where time-related actions or states are described using uncertain, maybe even sloppy language.  It would be ideal if that was cleaned up and the text was as specific as possible.  For instance:

2a. Recent.  The phrase "recently bidirectionally reachable” is used in a couple of places.  Note that the definition of “bidirectionally reachable” also uses “recent": “…if a recent and consistent multicast or any unicast DNCP message has been received…”  What does “recent” mean?  A naïve interpretation may be that the peer was (not long ago) reachable, but not anymore.  Knowing that the keep-alives are optional, what is the criteria  for “recent”?  Section 4.5. (Adding and Removing Peers) seems to provide some hints related to the ability to verify that the peer is present — that is a specific criteria, unlike the use of “recent”.  Please be specific.

2b. Now and then.  Section 4.2. (Data Transport): “…send Network State TLVs every now and then, as specified in Section 4.3”  Section 4.3 (Trickle-Driven Status Updates) explains: "Every time a particular Trickle instance indicates that an update should be sent, the node MUST send a Network State TLV…”  If I got this correctly, rfc6206 talks about updates being needed when the version numbers don’t match — that is a very specific case and not just “every now and then”.  Please clarify what those triggers may be, or include a reference — in both places to take away the uncertainty.

2c. Eventually.  Section 4.4 (Processing of Received TLVs) “…an implementation MUST eventually reply to similar repeated requests, as otherwise state synchronization breaks.”  It is clear that “eventually” is really time bound — what is that boundary?


3. Section 6.1.2. (Per-Endpoint Periodic Keep-Alives), 6.1.3. (Per-Peer Periodic Keep-Alives) and 6.1.5. (Peer Removal): "the endpoint-specific keep-alive interval” is used — initially I thought that you meant DNCP_KEEPALIVE_INTERVAL, but it isn’t until 6.1.5 when the term is defined.

4. Section 7.1.1. (Request Network State TLV)  If the Length is > 0, what can the Value be?  Nothing is specified.

5. Section 7.3. (Data TLVs within Node State TLV)  Just to clarify, the TLVs in this section would be carried in the Node Data field of the Node State TLV, right?  If so, then it would be clearer if it was explicitly mentioned.

6. References.  I think that both RFC6347 and RFC5246 should be Informational as the document doesn’t actually mandate their use — it just points at them as what the profiles may (or may not) specify.

Nits:
A. 4.2. (Data Transport)  s/to speeds up/to speed up
B. 4.4. (Processing of Received TLVs)  The notation ("H(Node Data)”, for example) for the hash function is used, but it is defined later in the draft.  Please add a reference.

[Ballot discuss]
First,  I have a number of specific comments.  Some of these are hazards to technical interoperability; I've tried
to include those in my discuss - but the general point is that it is very hard to tell a number of details because the
structure is assumed.  Having read this document, I do not think that I could properly implement DNCP from scratch.

Obviously, I can guess at the answers - but that doesn't let everyone interoperate well.  Examples include:

a) What is a topology graph?  When is it created, modified, or destroyed?  Is it a conceptual artifact constructed
from the various TLVs?  I think a quick paragraph describing it would help.

b) How are peer relationships discovered and established and destroyed?  I really can't tell from the draft and even a quick scan of
RFC 6206 doesn't give any hints.

c) It looks like the TLVs are sent one after another in a datagram or stream across a socket.  The closest I see to any detail
is "TLVs are sent across the transport as is". 

d) As far as I can tell, Trickle is used to decide basically how often to send information - but the details of this and the interactions
aren't clear to me.

I suspect that there are dependencies on the HNCP draft that would make this a lot easier to understand but since we want it to progress
separately, the document does need to stand alone.

Although not noted in the Shepherd's report, I did have a thorough Routing Directorate review done and the draft was improved from that.

8) In Sec 4.6 "  o  The origination time (in milliseconds) of R's node data is greater
      than current time in - 2^32 + 2^15."  Since origination time hasn't yet been introduced, I'm going
on an assumption that it means when R's node data was originated from R.  So - this requirement is
saying that R's node data must have been generated in the future (but already known by the local node)???

9) In Sec 4.6 "They MAY be removed immediately after the topology graph traversal"  The DNCP nodes can
be removed from what??  The topology graph?  From some type of received TLV??  How would they be
added back in later?

11) In sec 6.1: "Trickle-driven status updates (Section 4.3) provide a mechanism for
  handling of new peer detection on an endpoint, as well as state
  change notifications."  Nothing in Sec 4.3 talked about a mechanism for detecting
new peers on an endpoint.  It is entirely possible that Trickle does provide this (but what
about the modes where Trickle isn't used/needed??) but there needs to be a description of how
new peer detection is done - even if it's just a pointer to Trickle RFCs.

12) In Sec 6.1.4: "  On receipt of a Network State TLV (Section 7.2.2) which is consistent
  with the locally calculated network state hash, the Last contact
  timestamp for the peer MUST be updated."  Could you add some rationale for why this
is needed?  I suspect that part of my confusion is that the "locally calculated network state
hash" could mean two different things.  Is it the hash computed by the local node on the
data received in the Network State TLV to validate that the Network State TLV is not
corrupted?  Or is it the hash computed by the local node on its arbitrarily wide 1-hash tree
that represents the local node's network state?  Since the term is never defined, it's hard
to guess here.  The bottom of Sec 7.2.2 uses "current locally calculated network state hash"
to refer to, I believe, the latter.

13) In Sec 6.2: "normally form peer relationships with all peers."  Where is forming a peer
relationship defined?  Is this tied solely to Trickle instances?  What about with reliable unicast
where presumably Trickle isn't used between peers as the Overview states
"If used in pure unicast mode with unreliable transport, Trickle is also used between peers"?

14) In Sec 7: "  For example, type=123 (0x7b) TLV with value 'x' (120 = 0x78) is
  encoded as: 007B 0001 7800 0000.  If it were to have sub-TLV of
  type=124 (0x7c) with value 'y', it would be encoded as 007B 0009 7800
  0000 007C 0001 7900 0000."  In this case, the padding between the TLV's value
and the sub-TLV is included but the padding after the sub-TLV is not.  What would
happen if there were multiple sub-TLVs??  Would the padding between those sub-TLVs
be included?

Also related :"In this case the length field includes the length of the original TLV, the
length of the padding that are inserted before the embedded TLVs and the length of the
added TLVs."  Here, the phrase "length of the TLV" means different things.  In the first case,
"length of the original TLV" means the "length of the value in the encapsulating TLV".  In
the second case, "length of the added TLVs" appears to mean the length of the sub-TLVs
including the type/length header.  As I mentioned above, I can't tell what happens to the
padding in between sub-TLVs.

[Ballot comment]
1) In Sec 4.1, I think it would be clearer if you moved the sentence "These leaves are ordered in ascending
  order of the respective node identifiers. " to after the first sentence with appropriate text changes.  I was left
confused by why the leaf would be represented by a node's sequence number.  I think it's that a leaf represents
a node and is ordered based upon that node's identifier.  The value of a leaf is a tuple of the node's sequence
number and the hash value... 

2) In Sec 4.2, it says "As multicast is used only to identify potential new DNCP
  nodes and to send status messages which merely notify that a unicast
  exchange should be triggered, the multicast transport does not have
  to be secured."  There aren't attacks from processing fake potential new DNCP node
  or triggering lots of unneeded/unterminated unicast exchanges?

3) In Sec 4.3, it says "Imin, Imax and k.  Imin and Imax represent the minimum and maximum values for I"
I believe this isn't quite accurate.  Imax is a max multiplier of Imin for I and not a maximum value.
I've seen this error in another draft also; I think it's important to be correct & clear here.

4) There are multiple references to different unintroduced TLVs.  There is also the idea that
each DNCP protocol can have its own TLVs.  It'd be very useful in the Introduction to simply state
what TLVs are required by DNCP and conceptually what they are for.

5) In Sec 4.3, it says "The Trickle state for all Trickle instances is considered
  inconsistent and reset if and only if the locally calculated network
  state hash changes."  but I have no idea yet what a Trickle instance is, when
  a Trickle instance is created or associated with a node?  an interface? or something else?

6) I think it would be more useful to describe generally at least what is in a DNCP profile earlier in the
document.  This may be bringing Section 9 forward or it may be listing it earlier.  I'm seeing numerous
forward references.

7) Start of Sec 4.6 talks about the topology graph - but there's been absolutely no introduction of
what the topology graph is or how it was created, updated, etc.

10) In Sec 5:  This is a helpful section.  It tells me that a Trickle instance is per interface.  I don't see anything
like a topology graph in it.  It clarifies origination time slightly.  It talks about "For each remote (peer, endpoint)
pair detected on a local endpoint" but I still have no ideas how that detection is done.  It implies some policy
restrictions "Set of addresses: the DNCP nodes from which connections are accepted." but has no details on whether
that is created via multicast messaging or via local configuration or something else.






15) Also, in Sec. 4.6, the terminology for the fields of the Peer TLV is different than defined
in Sec 7.3.1 - just "Endpoint Identifier" instead of "Local Endpoint Identifier".

16) In Sec 7.3.2: "  Endpoint identifier is used to identify the particular endpoint for
  which the interval applies.  If 0, it applies for ALL endpoints for
  which no specific TLV exists."  Is this the Local Endpoint Identifier or the remote?
  The same question applies for Sec 7.2.1.

[Ballot discuss]
I just have one thing I'd like to discuss that should be easy enough to resolve.

Section 8 mentions that DTLS or TLS MAY be used and that it is up to the DNCP profile.  I'd be interested to see the security considerations that would lead to a recommendation of using session transport for the DNCP profiles.  If it is in another RFC, could you add a pointer?  If it is not, could this be added to the security considerations section since it could be an important consideration?

[Ballot comment]
In the IANA Considerations, we would normally use a normative reference to RFC 5226 to define the "Standards Action" and "Private Use" policies.  I suggest adding that.

[Ballot discuss]
This should be an easy Discuss to ... discuss ...

I'm looking at this text:

  If keep-alives specified in Section 6.1 are NOT sent by the peer
  (either the DNCP profile does not specify the use of keep-alives or
  the particular peer chooses not to send keep-alives), some other
  existing local transport-specific means (such as Ethernet carrier-
  detection or TCP keep-alive) MUST be used to ensure its presence.
 
and wondering if using TCP keep-alive for liveness detection is realistic in the use cases this specification is expecting to address.

Unless I missed something, the default TCP keep-alive interval is still two hours (that's been true since RFC 1122, and also true in the relatively recent version of Linux I'm using). If that's OK, I'll clear.

If you're assuming a keep-alive interval that's shorter, lots of implementations allow you to tune this, but it seems like the specification should say something about that.

Given that the other example of "transport-specific means" is Ethernet carrier-detection, which would be orders of magnitude faster, I thought I should ask.

[Ballot discuss]
I have no objections to the publication of this document, but I do have a couple of points that I want to discuss...

* The spec says that all TLVs are transmitted every time any value in the TLV set changes. Section 1 says that a delta synchronization scheme is not defined.  What is the justification for not using a delta synchronization approach?  The ordering of the TLVs needed to compute the hash can be done at the receiver and a delta approach would minimize bandwidth consumption.  I think it would be useful to provide some justification in the spec for the design decision made to not use a delta synchronization approach.

* Section 4.4 says that all responses are sent unicast, even for requests received via multicast over a multi-access medium. Was consideration given to use multicast responses and supporting message suppression on other nodes? Or, was the design decision made to ensure that all nodes responded with their TLV set to the requester?  Either approach may be reasonable, but there is no justification given.

* When responding to a multicast request over a multi-access medium, why is the randomization of the transmit time only a SHOULD?  I would think that needs to be a MUST.

[Ballot comment]
1. I think the mention of the trickle variable 'k' in section 1 is gratuitous and causes confusion.

2. Why does this document say (section 7) that the hash function is non-cryptographic?  Shouldn't that be determined by each profile?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-homenet-dncp-07.  Please report any inaccuracies and respond to the question below as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that upon approval of this document, there is a single action which IANA must complete.

A new registry called the Distributed Node Consensus Protocol TLV Types registry is to be created.

IANA QUESTION -> Where should this new registry be located? Is it a new heading on the IANA Matrix (see http://www.iana.org/protocols), or is it a sub-registry of an existing registry? If it is a sub-registry of an existing registry, in which registry will it be contained?

The registration rules for the new registry are Standards Action as defined in RFC 5226, with the exception of 32-191 and 192-255. See below.

There are initial registrations in the new registry as follows:

TLV Type Description Reference
-----------+-----------------------------------+---------------------
0 Reserved [ RFC-to-be ]
1 Request network state [ RFC-to-be ]
2 Request node state [ RFC-to-be ]
3 Node endpoint [ RFC-to-be ]
4 Network state [ RFC-to-be ]
5 Node state [ RFC-to-be ]
6 Reserved (was: Custom) [ RFC-to-be ]
7 Reserved (was: Fragment count) [ RFC-to-be ]
8 Peer [ RFC-to-be ]
9 Keep-alive interval [ RFC-to-be ]
10 Trust-Verdict [ RFC-to-be ]
11-31 Unassigned
32-191 Reserved for per-DNCP profile use
192-255 Reserved for per-implementation experimentation
256-65535 Unassigned

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Distributed Node Consensus Protocol) to Proposed Standard


The IESG has received a request from the Home Networking WG (homenet) to
consider the following document:
- 'Distributed Node Consensus Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2015-07-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document describes the Distributed Node Consensus Protocol
  (DNCP), a generic state synchronization protocol which uses Trickle
  and Merkle trees.  DNCP leaves some details unspecified or provides
  alternative options.  Therefore, only profiles which specify those
  missing parts define actual implementable DNCP-based protocols.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/ballot/


No IPR declarations have been submitted directly on this I-D.

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 https://github.com/sbyx/hnetd/ and project homepage at http://www.homewrt.org/doku.php.

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.

Personnel

Who is the Document Shepherd?

Mark Townsley

Who is the Responsible Area
  Director?

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

No.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Warnings:
  == 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.

N/A

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

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?

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.

None.

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

N/A

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 https://github.com/sbyx/hnetd/ and project homepage at http://www.homewrt.org/doku.php.

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.

Personnel

Who is the Document Shepherd?

Mark Townsley

Who is the Responsible Area
  Director?

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.

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

No.

(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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Warnings:
  == 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.

N/A

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

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?

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.

None.

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

N/A