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

From: "Alia Atlas" <[email-masked]>
Date: Mon, 19 Oct 2015 09:18:52 -0700

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.

---

From: Steven Barth <[email-masked]>
Date: Tue, 20 Oct 2015 13:31:00 +0200

Hi Alia,

thanks a lot for your continuous reviews. I have staged a few changes in
our Git to address your remaining issues. We will include it in a an
upcoming version with fixes for other remaining blockers left in -11.

See: https://github.com/fingon/ietf-drafts/commit/374a4a3
More replies inline below.

Thanks,

Steven

> included in the computation of the Node State Hash?

Clarified.

> my ballot again before the telechat on Thursday.

Thanks.

Changed to "at least one".

> happy if you think about it seriously.

I think there are legitimate cases where this graceful termination is
redundant, i.e., because the derived protocol employs a transport or
link-layer that provides such events already. Nevertheless I guess a
derived protocol could probably with some care add such a mechanism
where it makes sense. I'm a bit reluctant to add it as that stage really.

> Peer's network state hash.

Changed to "contains the current network state hash calculated by its
sender"

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

Hmm, it is currently defined at the beginning of Section 7 just before
the first sub-paragraph so I am not sure if it will add more clarity to
also add it to the terminology.

---

From: Alia Atlas <[email-masked]>
Date: Tue, 20 Oct 2015 09:49:59 -0400

Hi Steven,

The changes look good    Thank you.
I'd recommend putting H() in the terminology.  I agree that it's defined at
the start of Section 7 - but it is used earlier around Sec 4.2.  You can
also
refer to H() where how to calculate the network hash is defined.

I think the draft is a lot more readable and easier to understand now.

As I said in my discuss, I may have a few more comments from a
Routing Directorate review (since I'm no longer a new reader), but you've
nicely addressed all my concerns.

thanks,
Alia