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

Barry Leiba <> Fri, 20 November 2015 15:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E2FDE1B2B49; Fri, 20 Nov 2015 07:50:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iXg5IVqxpLBF; Fri, 20 Nov 2015 07:50:52 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6305F1B2B46; Fri, 20 Nov 2015 07:50:52 -0800 (PST)
Received: by vkay187 with SMTP id y187so49111vka.3; Fri, 20 Nov 2015 07:50:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=J6YTa5VUXuiiErrmPJ8kqZMjRdScTV1fHNqRhNcWqGc=; b=dTrHlqs5l0Txf2An3Aacyw0cB53qcCJy4rcBCQRnIYR+PjctJxHEDOLgIXpJYAwC3k IoSqVBQ/eVC8R0yMPfHZXkXEroQSSvAfP6vw/aSpoySkJTmlwxgPHowMZGDJFsQ3LHtb 204oDn6qioy2lK1ttTPaC3CMAate4PIuqzOEgytM/oMKLk/apFshwbj3BYRclzQAf5B3 4/INx9iiQRFftq5fSxQpw4oYNgU5DPeGkCZw5lVkJPRZFIwrGFlGsX+9sGv3D6VcPlRi l5VWgP72T7i06nZS4m9mLzF+ejt76LF8S6u5t4U0oRoKIcPobtGg3vxKwYrFyhq4K7mO MAzQ==
MIME-Version: 1.0
X-Received: by with SMTP id f75mr15195vke.40.1448034651420; Fri, 20 Nov 2015 07:50:51 -0800 (PST)
Received: by with HTTP; Fri, 20 Nov 2015 07:50:51 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 20 Nov 2015 10:50:51 -0500
X-Google-Sender-Auth: C-rMEv5WZCDioQLc9dmYP_Z3ar8
Message-ID: <>
From: Barry Leiba <>
To: Markus Stenberg <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc:, Mark Townsley <>,, Steven Barth <>, The IESG <>,
Subject: Re: [homenet] Barry Leiba's Discuss on draft-ietf-homenet-hncp-09: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 20 Nov 2015 15:50:54 -0000

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

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:

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

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