Subject: [homenet] Alia Atlas' Yes on draft-ietf-homenet-dncp-11: (with COMMENT)

From: "Alia Atlas" <[email-masked]>
Date: Wed, 21 Oct 2015 09:18:45 -0700

Alia Atlas has entered the following ballot position for
draft-ietf-homenet-dncp-11: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-homenet-dncp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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.

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 23 Oct 2015 07:22:37 +0300

Well, it will be actually -12 (we change the version # last thing), but we hope so too.  We will post a new version once we come up with good answer to Benoit’s DISCUSS.

> for a DNCP profile on how to make a decision about what hash function to

I staged this earlier to address this:

https://github.com/fingon/ietf-drafts/commit/0372f47bbc1866ecb3020bc31fb9cb4014ae8790

> 6) Please define H(...) in terminology, since Sec 4 uses it before it is

It refers to an explicit field name there, as it is “H(Node Data) field” in the two references there. So for now leaving the meaning of that H() to where it is described (which is section 7). If this notation is distracting, we can rename the field to e.g. Node Data Hash field and describe it’s contents as H(Node Data) instead within it’s own subsection.

I think having the encoding-related definitions in terminology seems excessive because then reading the TLV section would require fairly long jumps between terminology and TLV section.

Cheers,

-Markus