Distributed Node Consensus Protocol
RFC 7787

Note: This ballot was opened for revision 09 and is now closed.

(Alia Atlas) (was Discuss) Yes

Comment (2015-10-21 for -11)
No email
send info
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.

(Terry Manderson) Yes

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Ben Campbell) No Objection

Comment (2015-10-19 for -11)
No email
send info
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?

(Benoît Claise) (was Discuss) No Objection

Comment (2015-11-01)
No email
send info
Thank you for resolving my DISCUSS point.

Alissa Cooper No Objection

(Spencer Dawkins) (was Discuss) No Objection

Comment (2015-09-17 for -09)
No email
send info
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.

(Stephen Farrell) No Objection

Comment (2015-09-30 for -10)
No email
send info
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).

(Joel Jaeggli) No Objection

Comment (2015-10-21 for -11)
No email
send info
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.

Barry Leiba No Objection

Comment (2015-09-16 for -09)
No email
send info
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.

(Kathleen Moriarty) (was Discuss) No Objection

Comment (2015-09-29 for -10)
No email
send info
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.

Alvaro Retana No Objection

Comment (2015-09-30 for -10)
No email
send info
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

(Brian Haberman) (was Discuss) Abstain

Comment (2015-09-30 for -10)
No email
send info
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.

(Martin Stiemerling) Abstain

Comment (2015-10-21 for -11)
No email
send info
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.