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

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

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.

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 <reasons>"?

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?

Thank you for resolving my DISCUSS point.

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.

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.

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.

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