[homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-11: (with DISCUSS and COMMENT)

["Alia Atlas" <[e-mail]>]

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

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you very much for addressing my previous Discuss points and
comments.  On a fresh read of the updated draft,
I have the following one minor point (but it matters for interoperability
with DNCP profiles):

1) End of Sec 4.4, can you clarify what the behavior is for
unrecognized TLV that is included in the Node Data field of a Node
State TLV?  I assume that its meaning is not processed, but it is
included in the computation of the Node State Hash?

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.  I've requested another Routing Directorate review, from a new
reviewer, so I may be modifying
my ballot again before the telechat on Thursday.


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

I also have a few more minor comments that affect readability.

2) On p. 6, Definition of Peer means that the same DNCP node using a
different local and remote endpoint pair would be a different Peer??
Is that intentional?

3) In Sec 4.1.1, I had no idea that the node's sequence number was
included before.  Thank you for the extra clarity!

4) In Sec 4.5, it seems unfortunate to have old network and
connectivity state stored.  It seems to me that it'd be fairly trivial
to describe a "polite neighbor" termination policy where a peer sends
an Node Data TLV for itself with no data in it - including Node
Endpoint TLVs.  I am a bit nervous about bad side effects, but I do
not have a specific example to mind and obviously, a neighbor can fail
as well as gracefully shut down connections.  Describing "polite
neighbor"
behavior may be too much of a technical change at this point, but I'd be
happy if you think about it seriously.

5) In Sec 7.2.2, it says "This TLV contains the current locally
calculated network state hash, see Section 4.1 for how it is calculated."
 This describes the value when sent.  When received, it contains the
Peer's network state hash.

6) Please define H(...) in terminology, since Sec 7 uses it.