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

From: "Barry Leiba" <[email-masked]>
Date: Wed, 18 Nov 2015 21:42:06 -0800

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

---

From: Steven Barth <[email-masked]>
Date: Fri, 20 Nov 2015 11:07:56 +0100

Hello Barry,

thanks for your review.

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.

>    avoided is out of scope of this document.

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

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.

> That seems backwards to me; I'd say this is "the HNCP profile of DNCP",

changed to "DNCP profile *for* HNCP"

> than saying "MAY"; the "MAY" seems rather useless here.

Clarified.

> suggest making that explicit as well, either way.

Clarified.

> "(i.e., prefix adoption is done instantly unless it is delayed by a

Changed.

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

> clearer: "...and MAY also announce node names for other devices."

Clarified.

>    MUST be unique within the whole network.

Changed as well.

Cheers,

Steven

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 20 Nov 2015 15:50:25 +0200

> Yes, I will talk to Markus about it, but from my point of view your

I am not so sure about it personally, mostly because this what lives on that port; if e.g. future DNCPv2 winds up redefining DNCP registry, or changes the behavior of the protocol in some drastic way _that is not desirable for HNCP_, I rather have HNCP stay the same. Therefore freezing the contents of the whole TLV space in one registry seems useful to me (for action that happens using same transport on same port(s) at any rate), but I do not care much the either way.

Whole DNCP registry in and of itself is bit questionable to me because it is not deployable in and of itself.

(e.g. Thomas C. argued that sticking in TLV definitions in DNCP was wrong move, and I agree with him but it was bit late in the game to change.)

Cheers,

-Markus

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Nov 2015 10:14:28 -0500

Hi, Steven, and thanks for the response.

> I hope this clears it up.

It does.  I'd prefer lowercase "may", rather than the 2119 key word --
the SHOULD has the 2119 language covered -- but, in any case, this
resolves the DISCUSS point nicely.  Thanks.

> Yes, I will talk to Markus about it, but from my point of view your

I'll respond to Markus's message on this point.

Your responses to my other comments are good, and thanks for addressing them.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Fri, 20 Nov 2015 10:50:51 -0500

> I am not so sure about it personally, mostly because this what lives
> on that port; if e.g. future DNCPv2 winds up redefining DNCP registry,
> or changes the behavior of the protocol in some drastic way _that is
> not desirable for HNCP_, I rather have HNCP stay the same. Therefore
> freezing the contents of the whole TLV space in one registry seems
> useful to me (for action that happens using same transport on same
> port(s) at any rate), but I do not care much the either way.
>

I can still be convinced that this is the way to go, but I haven't
been yet, so let's please talk about it a bit more.

I see your point about the possibility that future DNCP updates could
change the registry, though that's always a problem, and that issue
should be caught during IANA and IESG review in the future: changes
that conflict with how HNCP uses the registry should be noticed and
questioned.

It seems to me (not having participated in the discussion of DNCP)
that DNCP registered some common TLV types to be used by all profiles,
and then set aside overlapping space for each profile to define its
own TLV types.  So...

1. there's common space left in which profiles can register common TLV
types that can be used by other profiles and...

2. there's profile-specific space in which profiles can register their
own TLV types that other profiles won't use (and where other profiles
will, in fact, use the same type numbers for their own purposes).

That all seems sensible.  And, given that, what makes the most sense
to me is for this profile to *only* specify allocation for the range
that was allocated for profile-specific stuff (and to use the base
DNCP registry for any other ranges).  Repeating information from one
registry into another is a bad recipe, more prone to future conflicts,
I think, than what you're concerned about.

How about this?:
Add something like this to my suggested change above:

NEW+
In the DNCP TLV Types registry, IANA is asked to change the
descriptions of two value ranges, as follows:

32-511, new description "Reserved for per-DNCP profile use; this range
is in active use by DNCP profiles and must remain reserved."

768-1023, new description "Reserved for Private Use; this range is in
active private use and must remain reserved."
END

Markus, would that address your concern about possible future changes?

Barry

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 20 Nov 2015 18:02:06 +0200

> that conflict with how HNCP uses the registry should be noticed and

Yes, but not automatically rejected.

> own TLV types.  So…

Yeah, and I find that design more undesirable the more I think about it.

> Markus, would that address your concern about possible future changes?

Hmm. I am not quite sure about how this whole DNCP <> DNCP extensions <> DNCP#2 maps to the two registries in my head, so not quite sure how it _should_ be addressed. However, as Steven already staged the changes limiting the registry range to 32-511, I guess I can live with that :)

To expand on my concern, while HNCP refers to a particular DNCP version, what about DNCP extensions and/or DNCPv2 relation to HNCP (and the related registry content changes if any). It is not clear that an arbitrary DNCP extension needs to be supported by a HNCP implementation (unless HNCP 1.1 spec refers to it), but just looking at the main DNCP registry will not really work well to see what is ’the current state’ HNCP implementor needs to follow.

Anyway, I can live with even what’s currently staged, just general unease about the ‘future’ with dual registry model. Having _just_ HNCP registry would have made this much more understandable for an implementor, and less likely to break in the future too.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Sat, 21 Nov 2015 20:26:49 +0100

> 7 to indicate a non-default priority. The values 8-15 are reserved

Steven, shouldn't it say explicitly what a node does when it receives
a capability in the 8 to 15 range ?  Should it let the router announcing
the out-of-range capability win the election, or should such announcements
be ignored?  (Shncpd does the former, which I guess is the intent.)