Re: [homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)

Steven Barth <cyrus@openwrt.org> Fri, 20 November 2015 10:08 UTC

Return-Path: <cyrus@openwrt.org>
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 5E0701ACD21; Fri, 20 Nov 2015 02:08:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.549
X-Spam-Level:
X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_FAIL=0.001] autolearn=no
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 amtzL7C-qBsW; Fri, 20 Nov 2015 02:08:01 -0800 (PST)
Received: from mail.core-networks.de (mail.core-networks.de [IPv6:2001:1bc0:d::4:9]) (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 5D1A71ACD0C; Fri, 20 Nov 2015 02:08:01 -0800 (PST)
Received: from localhost ([127.0.0.1]) by mail.core-networks.de id 1Zzibl-0003pP-EZ with ESMTPSA (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) for ; Fri, 20 Nov 2015 11:07:57 +0100
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
References: <20151119054206.26381.90805.idtracker@ietfa.amsl.com>
From: Steven Barth <cyrus@openwrt.org>
Message-ID: <564EF0FC.3010107@openwrt.org>
Date: Fri, 20 Nov 2015 11:07:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Icedove/40.0
MIME-Version: 1.0
In-Reply-To: <20151119054206.26381.90805.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/CJXyQ27gG8VWhcSCEYZUsBKZx94>
Cc: homenet-chairs@ietf.org, homenet@ietf.org, mark@townsley.net, draft-ietf-homenet-hncp@ietf.org
Subject: Re: [homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (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: Fri, 20 Nov 2015 10:08:03 -0000

Hello Barry,

thanks for your review.

On 19.11.2015 06:42, Barry Leiba wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I have two points that I'd like to discuss, both of which should be very
> easy to resolve:
> 
> -- Section 10.1 --
> For all the capability values you say something like this:
> 
>       It MUST be set to some value between 1 and 7
>       included (4 is the default) if the router is capable of proxying
>       MDNS and 0 otherwise.
> 
> First, the word you want is "inclusive", not "included".
> 
> Second, "4 is the default" really means that you can set it to 0, and
> that's the same as setting it to 4.  But it seems that 0 means that the
> router does not have the specified capability.  Those seem to be in
> conflict.  I strongly suggest you do NOT have a default, and allow the
> use of 0 *only* to designate lack of that capability.
> 
> Please discuss this with me to make sure I'm not misunderstanding you
> here.

I have changed them all to:

  It MUST be set to 0 if the router is not capable of doing FOO,
  otherwise it SHOULD be set to 4 but MAY be set to any value from 1 to
  7 to indicate a non-default priority. The values 8-15 are reserved
  for future use.

I hope this clears it up.


> -- Section 13 --
> I have two concerns with how the HNCP TLV Types registry is specified:
> 
> 1. Because the DNCP TLV Types registry specifically allocates 32-511 for
> profiles, it'd be better to simply limit the range of values in this
> registry to those values, rather than making it broader and duplicating
> the other values from the other registry.
> 
> 2. I think it's a bad idea for HNCP to re-define DNCP's Private Use range
> in its registry.  I would rather see this be text in the document (here
> in the IANA Considerations is a fine place for it) that says that HNCP
> uses the Private Use range for per-implementation experimentation, and
> not have that be in the HNCP registry.
> 
> In other words, I'd make it more like this (and add a reference to RFC
> 5226):
> 
> NEW
>    IANA should set up a registry for the (decimal values within range
>    32-511, as allocated to profiles by DNCP) "HNCP TLV Types" under
>    "Distributed Node Consensus Protocol (DNCP)", with the following
>    initial contents:
> 
>       32: HNCP-Version
>       33: External-Connection
>       34: Delegated-Prefix
>       35: Assigned-Prefix
>       36: Node-Address
>       37: DHCPv4-Data
>       38: DHCPv6-Data
>       39: DNS-Delegated-Zone
>       40: Domain-Name
>       41: Node-Name
>       42: Managed-PSK
>       43: Prefix-Policy
>       44-511: Unassigned
>       
>    The policy "RFC Required" [RFC5226] should be used for future
>    assignments.
> 
>    The range reserved by DNCP for Private Use (768-1023) is used by
>    HNCP for per-implementation experimentation.  How collisions are
>    avoided is out of scope of this document.
> END
> 
> Does that make sense?

Yes, I will talk to Markus about it, but from my point of view your
suggestion looks good.



> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> -- Section 1.1 --
> 
>    As HNCP uses DNCP as the actual state synchronization protocol, the
>    applicability statement of DNCP can be used here as well; HNCP should
>    not be used for any data that changes rapidly and constantly, and
>    locators to find such services should be published using it instead.
> 
> I don't follow the second half of that (after the semicolon): I don't get
> the antecedents to "such services" (there are no services mentioned) and
> "it" (maybe understanding "such" will help sort this part out).  Can you
> re-word this to make it clearer?

Changed to:

  As HNCP uses DNCP as the actual state synchronization protocol,
  the applicability statement of DNCP applies here as well; HNCP
  should not be used for any data that changes rapidly and constantly.
  If such data needs to be published in an HNCP network, a more
  applicable protocol should be used for those portions and locators
  to a server of said protocol can be announced using HNCP instead.
  An example for this is <xref target="naming-sd">naming and service
  discovery</xref> for which HNCP only transports DNS server
  addresses, and no actual per-name or per-service data of hosts.


> 
> -- Section 3 --
> 
>    3.  DNCP Profile
>    The DNCP profile of HNCP is defined as follows:
> 
> That seems backwards to me; I'd say this is "the HNCP profile of DNCP",
> no?

changed to "DNCP profile *for* HNCP"

> 
>    o  HNCP operates on multicast-capable interfaces only.  HNCP nodes
>       MUST assign a locally unique non-zero 32-bit endpoint identifier
>       to each interface for which HNCP is enabled.  The value zero it is
>       not used in DNCP TLVs, but it has a special meaning in HNCP TLVs
>       (see Section 10.3 and Section 6.4).  Implementations MAY use a
>       value equivalent to the IPv6 link-local scope identifier for the
>       given interface.
> 
> I want to probe that "MAY" for a moment.  Of course, implementations can
> use anything they want to, right?  So what's the point of calling out the
> scope identifier specifically?  Is it because that's a particularly
> convenient ur useful value?  Is it something you're recommending (but not
> at the "RECOMMEND" level)?  If so, it might be better to say that, rather
> than saying "MAY"; the "MAY" seems rather useless here.

Clarified.

> 
>       *  Imax SHOULD be 7 doublings of Imin (i.e., 25.6 seconds) but
>          MUST NOT be lower.
> 
> The "i.e." is only correct here if the previous bullet's recommendation
> of 200ms is actually used.  I suggest avoiding the Latin abbreviation,
> and saying explicitly what you mean: "(25.6 seconds, if Imin is the
> recommended 200 milliseconds)".  It could also be unclear about whether
> "MUST NOT be lower" means "MUST NOT be lower than (Imin * 2**7)" or "MUST
> NOT be lower than 25.6 seconds".  I presume you mean the former, but I
> suggest making that explicit as well, either way.

Clarified.


> -- Section 6.3.1 --
> 
>    ADOPT_MAX_DELAY:   The default value is 0 seconds (i.e., prefix
>       adoption MAY be done instantly).
> 
> Here, I think the "MAY" is actually wrong.  I think what you mean is
> "(i.e., prefix adoption is done instantly unless it is delayed by a
> non-zero value here)."

Changed.

> 
> -- Section 6.4 --
> 
>    o  A node MUST NOT start advertising an address if it is already
>       advertised by another node.
> 
> ...
> 
>    o  Whenever the same address is advertised by more than one node, all
>       but the one advertised by the node with the highest node
>       identifier MUST be removed.
> 
> How can the second happen, given the first?

Mainly due to flooding delays, e.g. routers on different "ends" of the
network start to advertise the same address before they have received
the new announcement from the other one.


> 
> -- Section 8 --
> 
>    Each HNCP node SHOULD announce a node name for itself to be easily
>    reachable and MAY do so on behalf of other devices.
> 
> MAY announce a node name for itself on behalf of other devices?  That's
> what "do so" says to me.  Better to replace "do so" with something
> clearer: "...and MAY also announce node names for other devices."

Clarified.


> 
>    Announcements
>    are made using Node Name TLVs (Section 10.7) and MUST be unique in
>    the whole network.
> 
> The announcements are, I presume, not what MUST be unique.  You mean the
> node names MUST be uniques, yes?  So:
> 
> NEW
>    Announcements
>    are made using Node Name TLVs (Section 10.7) and the node names
>    MUST be unique within the whole network.
> END

Changed as well.



Cheers,

Steven