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

[Alia Atlas <[e-mail]>]

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



On Tue, Oct 20, 2015 at 7:31 AM, Steven Barth <[e-mail]> wrote:

> 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
>
>
> > 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?
>
> Clarified.
>
> >
> > 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.
>
> Thanks.
>
> >
> >
> > ----------------------------------------------------------------------
> > 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?
>
> Changed to "at least one".
>
>
> > 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.
>
> 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.
>
>
> > 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.
>
> 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.
>