Thank you for the review.
> On 20.7.2015, at 4.21, Margaret Cullen <[email protected]> wrote:
> I support the publication of draft-ietf-homenet-dncp-07. However, I think
> there are a few issues with the document that need to be fixed before it is
> published as an RFC, including:
>
> (1) The document needs a reference for Merkel Trees that is sufficiently
> clear and well-specified to allow implementation.
The term was inexact and addressed in dncp-08; it is actually a hash tree, and
formally defined (in the original Merkle papers) the Merkle tree is a binary
hash tree. Therefore we simply renamed it (arbitrary width) hash tree, and as
there is a stand-alone section in dncp-08 already describing it's
characteristics and use, and some notes on it's usage also elsewhere in e.g.
overview, we hope it is sufficient without external reference as the data
structure itself appears in typical compsci textbooks I believe.
(Merkle tree and hash tree are used loosely synonymously even in some of the
literature though, so sigh..)
> (2) RFC 6234 (US Secure Hash Algorithms) should be a normative reference in
> this document, not an informative one, as the SHA-256 algorithm is needed to
> implement the Trust-Verdict TLV described in section 8.3.3. To reference RFC
> 6234 normatively, a routine down-ref will be required.
Added in dncp-08 and to be discussed in WG today if anyone has objections.
> (3) Section 6.3 on Node Data Fragmentation is a bit confusing. It states
> that a reason for needing fragmentation might be that a Node-Data TLV might
> be too large to fit in a single TLV or packet, however it then goes on to
> say, "Note that the maximum size of fragment also constrains the maximum size
> of a single TLV published by a node." I think I understand what this section
> is trying to say -- that a Node-Data TLV can be broken across multiple
> fragments, but that none of the TLVs _within_ a fragmented Node-Data TLV will
> be broken across fragments. The current text doesn't quite manage to say
> that, though.
Based on some other reviews we already removed the section altogether.
Later extensions to DNCP could define similar scheme as the one currently
defined, without even breaking backwards compatibility for most part, if it
seems useful. As currently there are no concrete DNCP using protocols that need
it, and no implementations, just removal seemed the sane choice for now.
> (4) In section 10 (Security Considerations), the document states that "A DNCP
> node should therefore rate-limit its reactions to multicast packets." I
> believe the "should" in this sentence should be replaced with "MUST", because
> if a node does not rate-limit its reactions to multicast packets, an attacker
> can repeatedly send a single packet that will be multiplied by the DNCP node.
Good catch, fixed in dncp-08.
Cheers,
-Markus
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
