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

Alia Atlas <akatlas@gmail.com> Tue, 20 October 2015 13:50 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: homenet@ietfa.amsl.com
Delivered-To: homenet@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18A21A8AC8; Tue, 20 Oct 2015 06:50:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Level:
X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UDpWAl1-_zrJ; Tue, 20 Oct 2015 06:49:59 -0700 (PDT)
Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFC531A8AC0; Tue, 20 Oct 2015 06:49:59 -0700 (PDT)
Received: by oiev17 with SMTP id v17so10010686oie.2; Tue, 20 Oct 2015 06:49:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WJRu1AcbKUxhbgzes3/ATR1nTsYSO/Woc3vswDjmmVA=; b=Q99jX/uuxIG4QM/9LMc7AKEUJASypLPnxYFsu9hQOxqTvoZyytZ7s5fM3vpOB9OjMJ 6ntpktSg/X6EHfkq1rH1/n2ZEcuAlLgkH+tCKLJ7QweYLxjufiWxUIoLtjoLfstOlHkI t1+7jJIjPMRq5gLIpjbCqHvjeMbSrH4pa49nb7KOzN8S/BFzkYJsbTN0YO71obBvsFK0 lr7cejnQkilLwy+/nXNkSQsCbUf/i8OMdmlltNohaeemdtj1UFYmAw94LRjUi52m6+sd WNi5eYsxwegAohLwKJ6A5kiNDeaIaMi+5PKJRKzNZQK35i8QIqgP+uYbJ5PbQvBWgfUr LDjA==
MIME-Version: 1.0
X-Received: by 10.202.221.68 with SMTP id u65mr1885112oig.34.1445348999118; Tue, 20 Oct 2015 06:49:59 -0700 (PDT)
Received: by 10.60.121.74 with HTTP; Tue, 20 Oct 2015 06:49:59 -0700 (PDT)
In-Reply-To: <562625F4.1020009@openwrt.org>
References: <20151019161852.15251.13863.idtracker@ietfa.amsl.com> <562625F4.1020009@openwrt.org>
Date: Tue, 20 Oct 2015 09:49:59 -0400
Message-ID: <CAG4d1re2pZzTufoxq-cc5aOS88BjWVFwapkb6g2DM6RU4nZxUA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: Steven Barth <cyrus@openwrt.org>
Content-Type: multipart/alternative; boundary=001a113d57c6ab501d05228989a0
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/yPk6UKo8Eoo1dQHgzVowoEZ7wdE>
Cc: homenet-chairs@ietf.org, draft-ietf-homenet-dncp@ietf.org, HOMENET <homenet@ietf.org>, Mark Townsley <mark@townsley.net>, The IESG <iesg@ietf.org>
Subject: Re: [homenet] Alia Atlas' Discuss on draft-ietf-homenet-dncp-11: (with DISCUSS and COMMENT)
X-BeenThere: homenet@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <homenet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/homenet>, <mailto:homenet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/homenet/>
List-Post: <mailto:homenet@ietf.org>
List-Help: <mailto:homenet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/homenet>, <mailto:homenet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 20 Oct 2015 13:50:05 -0000

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 <cyrus@openwrt.org> 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.
>