On 20.11.2015, at 12.07, Steven Barth <[email protected]> wrote:
>> -- 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.

(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
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to