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

[Barry Leiba <[e-mail]>]

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

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