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

"Barry Leiba" <barryleiba@computer.org> Thu, 19 November 2015 05:42 UTC

Return-Path: <barryleiba@computer.org>
X-Original-To: homenet@ietf.org
Delivered-To: homenet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 603321A8874; Wed, 18 Nov 2015 21:42:06 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Barry Leiba" <barryleiba@computer.org>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.10.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20151119054206.26381.90805.idtracker@ietfa.amsl.com>
Date: Wed, 18 Nov 2015 21:42:06 -0800
Archived-At: <http://mailarchive.ietf.org/arch/msg/homenet/_Y8Ik1l1FkB5cxhjqOCfgDRV7FU>
Cc: homenet-chairs@ietf.org, homenet@ietf.org, mark@townsley.net, draft-ietf-homenet-hncp@ietf.org
Subject: [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
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: Thu, 19 Nov 2015 05:42:06 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-homenet-hncp-09: 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-hncp/



----------------------------------------------------------------------
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.

-- 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?


----------------------------------------------------------------------
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?

-- 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?

   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.

      *  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.

-- Section 6.2 --

      In presence of any type 1 to 128 Prefix Policy TLV the prefix is
      specialized to reach destinations denoted by any such Prefix
      Policy TLV, i.e., in absence of a type 0 Prefix Policy TLV it is
      not usable for general internet connectivity.  An HNCP router MAY
      enforce this restriction with appropriate packet filter rules.

I have a similar question as above about the "MAY" here.  Are you
actually saying, "Packet filter rules are a good way for an HNCP router
to enforce this restriction." ?  Would that be better than using "MAY"
here?

-- 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)."

-- 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?

-- 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."

   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