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/
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
