Thanks for your review Ole. Cheers Terry
On 8/07/2015 4:50 am, "Ole Troan" <[email protected]> wrote: >I have been selected as the Internet Directorate reviewer for this >draft. The purpose of the review is to provide assistance to the >Internet ADs. > >Although these comments are primarily for the use of the Internet ADs, >it would be helpful if you could consider them along with any other >IETF Last Call comments that you receive, and strive to resolve them >through discussion or by updating the draft. > >Document: draft-ietf-homenet-dncp-07.txt >Reviewer: Ole Troan >Review Date: July 7 16, 2015 > >The document now reads much better. I do get the impression that the text >is >reverse engineered from code in a few places though. > >Given that it is an "Abstract protocol" specification, that must be >combined with a profile specification to be a fully implementable, it >is somewhat difficult to predict if the specification is complete or >not. Juliusz Chroboczek is writing an independent implementation, and >I'd recommend incorporating the very informative replies the authors have >made to his >comments on the homenet list into the document. > >General comments: >================= >=> Replace no affiliation with "Independent". If that's the case. > >=> It is unclear to me how multiple instances of DNCP is run on a > link. Is that something that must be specified in the profile > document, and each profile must support multiple instances? > Given draft-stenberg-shsp, and the way it "hijacks" the HNCP > profile, it appears that more formal multiple instance support > would be needed. > >=> I can't help being left with the impression that fragmentation > (section 6.3) is underspecified. Can fragmentation be left out of > the protocol for now (and profiles requiring large TLVs can require > a transport layer supporting segmentation and reassembly?) > >=> I do find the text on transport modes somewhat confusing, U, M+U >and MulticastListen+U. I'd like to see more descriptive text > >Abstract: >========= > >OLD: > 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. > >NEW: > This document describes the Distributed Node Consensus Protocol > (DNCP), a generic state synchronization protocol that uses Trickle > and Merkle trees. DNCP is an abstract protocol, that must be > combined with a specific profile to make a complete implementable > protocol. > >=> The purpose of that change would be to make it clear what this >is. A framework? A component that protocols can be built out of? > >=> Add a reference to Merkle trees? > >Section 4.2: >============ > >=> This is confusing: >o If using a stream transport, the TLV MUST be sent at least once, > and it SHOULD be sent only once. > >OLD: >* If only unreliable unicast transport is employed, Trickle state > is kept per each peer and it is used to send Network State TLVs > every now and then, as specified in Section 4.3. > >NEW: >* If only unreliable unicast transport is used, Trickle state > is kept per peer and it is used to send Network State TLVs > intermittently, as specified in Section 4.3. > >s/every now and then/now and then/ > >s/employed/used/ > >Section 4.3: >============ >=> reference to rfc6206? > > > o the endpoint is in Multicast+Unicast transport mode, in which case > the TLV MUST be sent over multicast. > > o the endpoint is NOT in Multicast+Unicast transport mode, and the > unicast transport is unreliable, in which case the TLV MUST be > sent over unicast. > >=> What do an implementation do if the endpoint is not in M+U >transport mode, and the unicast transport is reliable? > >(I do find the transport modes confusing, and I'm not sure I >understand the MulticastListen mode). > >s/when using also secure unicast/when using secure unicast/ > >Section 4.4: >============ >=> What is meant by: "link with shared bandwidth"? > > > o Any other TLV: TLVs not recognized by the receiver MUST be > silently ignored. > >=> doesn't that mean it isn't stored in the Merkle tree? and the >hashes don't compute? > >Section 4.6: >============ >=> First mention of a topology graph. > >Section 5: >========== > >o Endpoint identifier: the 32-bit opaque value uniquely identifying > it within the local node. > >=> "it"? I think I'm still confused what is an endpoint, what is a >peer and what is a node. > >o Range of addresses: the DNCP nodes that are allowed to connect. > >=> How does a range of addresses look like and how is it used? > I find only one occurence in the document. > >Section 6.1: >============ > A DNCP profile MAY specify either per-endpoint or per-peer keep-alive > support. > >=> Again I'm confused over the usage of endpoint versus peer. >What's the difference between per-peer and per-endpoint keepalives? > >Section 6.2: >============ >s/actually uses/uses/ > >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
