Subject: [DNSOP] [[email-masked]: RFC 7788 on Home Networking Control Protocol]

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 23 Apr 2016 22:07:42 +0200

Interesting RFC, which introduces officially the TLD .home, without
using the RFC 6761 framework. So, apparently, you can reserve TLDs
without going through the Special-Use Domain registry.

I also note that some people complained that registering .onion was
squatting on ICANN's property. But .home was accepted while, unlike
.onion, there are actually people who are candidates to manage it.

Subject: RFC 7788 on Home Networking Control Protocol
From: [email-masked]
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 18 Apr 2016 17:23:57 -0700 (PDT)
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>

A new Request for Comments is now available in online RFC libraries.

        RFC 7788

        Title:      Home Networking Control Protocol 
        Author:     M. Stenberg, S. Barth, P. Pfister
        Status:     Standards Track
        Stream:     IETF
        Date:       April 2016
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked]
        Pages:      40
        Characters: 94146
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-homenet-hncp-10.txt

        URL:        https://www.rfc-editor.org/info/rfc7788

        DOI:        http://dx.doi.org/10.17487/RFC7788

This document describes the Home Networking Control Protocol (HNCP),
an extensible configuration protocol, and a set of requirements for
home network devices.  HNCP is described as a profile of and
extension to the Distributed Node Consensus Protocol (DNCP).  HNCP
enables discovery of network borders, automated configuration of
addresses, name resolution, service discovery, and the use of any
routing protocol that supports routing based on both the source and
destination address.

This document is a product of the Home Networking Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

The RFC Editor Team
Association Management Solutions, LLC

---

From: "John Levine" <[email-masked]>
Date: 23 Apr 2016 21:14:05 -0000

>without going through the Special-Use Domain registry.

In fairness, .home is just a default.  You can set your network to
squat on whatever name you want.

R's,
John

---

From: "Adrien de Croy" <[email-masked]>
Date: Sat, 23 Apr 2016 21:36:14 +0000

sounds like there could be trouble with that

https://icannwiki.com/.home

based on the applicants currently investing in acquiring that TLD.

on another note, TOR is proving its worth as a troll aggregator.  Since 
blocking TOR exit nodes from posting to our forums, our forum spam 
problem has disappeared.

------ Original Message ------
From: "Stephane Bortzmeyer" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sent: 24/04/2016 8:07:42 a.m.
Subject: [DNSOP] [[email-masked]: RFC 7788 on Home Networking 
Control Protocol]

---

From: David Conrad <[email-masked]>
Date: Sat, 23 Apr 2016 18:01:59 -0700

Stephane,

> without going through the Special-Use Domain registry.

I would agree that it is interesting.  Unsurprisingly, it is not in http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml. My gut feeling is that this is a process failure, but will admit that the whole question is quite unclear given the continuing uncertainty about the process described in 6761.

> squatting on ICANN's property.

If anyone did complain that .ONION was "squatting on ICANN's property", I think they were being silly.

FWIW, I do not believe unallocated names are anyone's "property".  There is a process that was developed in an open and transparent manner over a decade in which people can apply for parts of the DNS namespace, and that process went to great pains to try to walk a twisty maze of policy, legal, and economic interests. There is also a process developed within the IETF in which people can ask the IESG for parts of the domain [sic] namespace.  Given 7788, it would appear there is Yet Another process within the IETF by which parts of the domain [sic] namespace can be obtained, the rules of which are unclear (that is, it looks like "let's just pick a name").

> But .home was accepted while, unlike

Why does the fact that there are actual people to manage something matter? Who manages 10.in-addr.arpa?

Regards,
-drc
(speaking only for myself)

---

From: "John Levine" <[email-masked]>
Date: 24 Apr 2016 01:14:48 -0000

>based on the applicants currently investing in acquiring that TLD.

There's a bunch of applicants for .HOME, .CORP. and .MAIL.  I gather
that ICANN has decided not to delegate any of them due to collisions
with existing use in the wild.  (For .home, there's a lot of random
little routers using it, unrelated to new RFC 7788 uses.)

There was some discussion in the IETF of adding those three names to
the RFC 6761 registry, but it didn't go anywhere, largely (in my
opinion) due to lobbying by one of the .home applicants.

R's,
John

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Apr 2016 22:58:06 -0400

The Special-Use Top-Level Internet Names Problem Statement draft (
https://tools.ietf.org/html/draft-tldr-sutld-ps-00) references the ICANN
document that talks about .home (I don't know the URL off the top of my
head).   Like Suzanne, I'm pretty embarrassed that I didn't catch this.
The RFC only references ".home" once, and says nothing about how it is
handled, as would be needed for the RFC 6761 process, and of course there's
nothing about .home in the IANA considerations.   I will be adding this RFC
to the list of documents in the tldr draft, because what happened here is
definitely "a problem."

FWIW, I presented a homenet naming architecture document in the homenet
working group that talks about how this actually ought to be done (
https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-00).
I am fairly sure that the appearance of ".home" as a default setting in the
HNCP draft was an oversight on the part of the authors--the working group
had been using ".home" as a shorthand for "the special-use top-level
internet name that we'll use for name resolution in home networks that
don't have global names delegated to them," which as you can see is a bit
of a mouthful.

Bottom line: this is not actually the intended way things should work for
naming in homenets, and a lot of people missed it.   Sigh.

On Sat, Apr 23, 2016 at 9:14 PM, John Levine <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 24 Apr 2016 08:18:35 +0200

> I would agree that it is interesting.  Unsurprisingly, it is not in http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml. My gut feeling is that this is a process…

There is also nothing in the IANA Considerations Section about adding .HOME to the registry, which I think is a big mistake.

Either .HOME should not have been mentioned, or it should be added to the registry.

   Patrik

---

From: Ted Lemon <[email-masked]>
Date: Sun, 24 Apr 2016 09:22:46 -0400

Patrik, I think that it's fairly clear that the authors were assuming that
.home would be documented elsewhere when they wrote that text, so the
problem is simply that they never added a normative reference to the
document describing what .home does, and because of that nobody noticed
that it was being defined here for the first time.

On Sun, Apr 24, 2016 at 2:18 AM, Patrik Fältström <[email-masked]> wrote:

> > I would agree that it is interesting.  Unsurprisingly, it is not in
> http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml.
> My gut feeling is that this is a process failure, but will admit that the
> whole question is quite unclear given the continuing uncertainty about the
> process described in 6761.
>
> There is also nothing in the IANA Considerations Section about adding
> .HOME to the registry, which I think is a big mistake.
>

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 24 Apr 2016 16:05:20 +0200

Noted!

And I saw more email messages on this topic after I wrote this email of mine.

Happy to see not only I "miss" things when being AD :-)

All the best!

   Patrik

On 24 Apr 2016, at 15:22, Ted Lemon wrote:

> Patrik, I think that it's fairly clear that the authors were assuming that .home would be documented elsewhere when they wrote that text, so the problem is simply that they never added a normative reference to the document describing what .home does, and because of that nobody noticed that it was being defined here for the first time.
>

---

From: "Paul Hoffman" <[email-masked]>
Date: Sun, 24 Apr 2016 07:20:06 -0700

> naming in homenets, and a lot of people missed it.   Sigh.

...for well over a year. You see that exact phrase in the draft over 
many revisions. This is a sign that maybe the 6761 problem is going to 
be harder than some people think.

--Paul Hoffman

---

From: "Patrik Fältström" <[email-masked]>
Date: Sun, 24 Apr 2016 16:48:16 +0200

On 24 Apr 2016, at 16:20, Paul Hoffman wrote:

> ...for well over a year. You see that exact phrase in the draft over many revisions. This is a sign that maybe the 6761 problem is going to be harder than some people think.

Now it is at least possible to point to 6761, which I think is a step forward -- EVEN IF people think 6761 must be replaced, updated and what not.

;-)

   Patrik

---

From: Ted Lemon <[email-masked]>
Date: Sun, 24 Apr 2016 10:54:32 -0400

Paul. I think actually that we need to start maintaining a list of things
that ought to be explicitly looked for when reviewing documents for
publication, and this sort of thing would be one such.   This is not to say
that it's not a hard problem, though--such a list could easily become
unwieldy.   We tried to do something like that with RFC 7227 section 13.
The problem is that if there isn't a single resource to go to for this
stuff, and there's no step in the review process where this sort of check
happens.

On Sun, Apr 24, 2016 at 10:20 AM, Paul Hoffman <[email-masked]>
wrote:

> ...for well over a year. You see that exact phrase in the draft over many
> revisions. This is a sign that maybe the 6761 problem is going to be harder
> than some people think.
>
> --Paul Hoffman
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 24 Apr 2016 10:56:48 -0400

> Happy to see not only I "miss" things when being AD :-)

I think this is one of the hazards of being an AD--you just can't catch
everything, and when you miss something, in retrospect it often seems so
obvious.   This is definitely not a part of the job that I miss. :)

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 24 Apr 2016 18:20:36 -0400

Hi,

(no hats)

I had honestly expected the work on the homenet naming architecture to include a discussion of constraints on the syntax and other characteristics of the names to be used.

The default set for the homenet namespace in RFC 7788 strikes me as a risky recommendation from a purely operational perspective.  It's been surmised now for years that ".home" is widely used in local DNS configurations, based on the so-called "name collision" work commissioned by ICANN, and it's hard to see how collisions between overlapping local uses of the same names is preferable in any way to collisions between the global default namespace and local uses.

There's no reason to assume that homenet use of ".home" is compatible with pre-existing uses. Name collisions within one local scope, or multiple overlapping local scopes, seem to me to be dangerous in exactly the same ways as ambiguity between the "public namespace" and a local one would be.

Even a special use registry entry can't reasonably be expected to have a big impact on the other uses of ".home" that the name collision work surmised to be already occurring in the operational internet-- or the collisions that could occur if the homenet recommendation is widely used. 

Using ".home" for homenets is a bad idea, and would have been a bad idea even if there was a special use registry entry for it. 

Suzanne

On Apr 23, 2016, at 10:58 PM, Ted Lemon <[email-masked]> wrote:

> The Special-Use Top-Level Internet Names Problem Statement draft (https://tools.ietf.org/html/draft-tldr-sutld-ps-00) references the ICANN document that talks about .home (I don't know the URL off the top of my head).   Like Suzanne, I'm pretty embarrassed that I didn't catch this.   The RFC only references ".home" once, and says nothing about how it is handled, as would be needed for the RFC 6761 process, and of course there's nothing about .home in the IANA considerations.   I will be adding this RFC to the list of documents in the tldr draft, because what happened here is definitely "a problem."
> 
> FWIW, I presented a homenet naming architecture document in the homenet working group that talks about how this actually ought to be done (https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-00).   I am fairly sure that the appearance of ".home" as a default setting in the HNCP draft was an oversight on the part of the authors--the working group had been using ".home" as a shorthand for "the special-use top-level internet name that we'll use for name resolution in home networks that don't have global names delegated to them," which as you can see is a bit of a mouthful.
> 
> Bottom line: this is not actually the intended way things should work for naming in homenets, and a lot of people missed it.   Sigh.
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 24 Apr 2016 22:31:47 -0400

On Sun, Apr 24, 2016 at 6:20 PM, Suzanne Woolf <[email-masked]>
wrote:

> Using ".home" for homenets is a bad idea, and would have been a bad idea
> even if there was a special use registry entry for it.
>

Yup, no argument here.   That's why I used ".homenet" in the homenet naming
architecture... :)

---

From: joel jaeggli <[email-masked]>
Date: Sun, 24 Apr 2016 21:06:55 -0700

On 4/24/16 3:20 PM, Suzanne Woolf wrote:
> Hi,
> 
> (no hats)
> 
> I had honestly expected the work on the homenet naming architecture to
> include a discussion of constraints on the syntax and other
> characteristics of the names to be used.

Personally I see that as part of the design anti-pattern with the dns
that got us to this point in the first place. because their aren't
suitable alternatives to name resultion there is in fact no other way
around it until we do something less shambolic, or theres an emergent
alternative that actually makes sense to the market. I don't see 7788 as
providing any normative guidance on naming, which falls short of what I
would call specification certainly were a looking for a rational for the
selection of .home it's not in that document.

> The default set for the homenet namespace in RFC 7788 strikes me as a
> risky recommendation from a purely operational perspective.  It's been
> surmised now for years that ".home" is widely used in local DNS
> configurations, based on the so-called "name collision" work
> commissioned by ICANN, and it's hard to see how collisions between
> overlapping local uses of the same names is preferable in any way to
> collisions between the global default namespace and local uses.
> 
> There's no reason to assume that homenet use of ".home" is compatible
> with pre-existing uses. Name collisions within one local scope, or
> multiple overlapping local scopes, seem to me to be dangerous in exactly
> the same ways as ambiguity between the "public namespace" and a local
> one would be.
> 
> Even a special use registry entry can't reasonably be expected to have a
> big impact on the other uses of ".home" that the name collision work
> surmised to be already occurring in the operational internet-- or the
> collisions that could occur if the homenet recommendation is widely used. 
> 

> 
> Suzanne
> 
> 
> On Apr 23, 2016, at 10:58 PM, Ted Lemon <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>> The Special-Use Top-Level Internet Names Problem Statement draft
>> (https://tools.ietf.org/html/draft-tldr-sutld-ps-00) references the
>> ICANN document that talks about .home (I don't know the URL off the
>> top of my head).   Like Suzanne, I'm pretty embarrassed that I didn't
>> catch this.   The RFC only references ".home" once, and says nothing
>> about how it is handled, as would be needed for the RFC 6761 process,
>> and of course there's nothing about .home in the IANA considerations.
>>   I will be adding this RFC to the list of documents in the tldr
>> draft, because what happened here is definitely "a problem."
>>
>> FWIW, I presented a homenet naming architecture document in the
>> homenet working group that talks about how this actually ought to be
>> done
>> (https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-00).
>>   I am fairly sure that the appearance of ".home" as a default setting
>> in the HNCP draft was an oversight on the part of the authors--the
>> working group had been using ".home" as a shorthand for "the
>> special-use top-level internet name that we'll use for name resolution
>> in home networks that don't have global names delegated to them,"
>> which as you can see is a bit of a mouthful.
>>
>> Bottom line: this is not actually the intended way things should work
>> for naming in homenets, and a lot of people missed it.   Sigh.
>>
>>
>> On Sat, Apr 23, 2016 at 9:14 PM, John Levine <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 25 Apr 2016 09:04:00 +0200

On Sat, Apr 23, 2016 at 09:14:05PM -0000,
 John Levine <[email-masked]> wrote 

> squat on whatever name you want.

Yes, but the entire Homenet effort being made for unmanaged networks,
it is safe to assume that most homenets will use whatever default is
built in the software.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 25 Apr 2016 09:17:34 +0200

On Sun, Apr 24, 2016 at 01:14:48AM -0000,
 John Levine <[email-masked]> wrote 
 a message of 22 lines which said:

> the RFC 6761 registry,

https://datatracker.ietf.org/doc/draft-cheshire-homenet-dot-home/

> but it didn't go anywhere, largely (in my opinion) due to lobbying
> by one of the .home applicants.

Also because the IETF shot itself in the foot, by deciding to block,
de facto (last paragraph of
<https://www.ietf.org/blog/2015/09/onion/>), any new registration in
the Special-Use Domain registry (which would have been the obvious
home - no pun intended - for this TLD).

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 25 Apr 2016 09:25:17 +0200

On Sun, Apr 24, 2016 at 06:20:36PM -0400,
 Suzanne Woolf <[email-masked]> wrote 
 a message of 218 lines which said:

> It's been surmised now for years that ".home" is widely used in
> local DNS configurations, based on the so-called "name collision"
> work commissioned by ICANN, and it's hard to see how collisions
> between overlapping local uses of the same names is preferable in
> any way to collisions between the global default namespace and local
> uses.

It's not hard: privacy issues (leaks in the wild DNS) do not occur
when there are conflicts between local uses. Also, local conflicts are
easier to detect and debug.

> Name collisions within one local scope, or multiple overlapping
> local scopes, seem to me to be dangerous in exactly the same ways as
> ambiguity between the "public namespace" and a local one would be.

No.

> Using ".home" for homenets is a bad idea, and would have been a bad
> idea even if there was a special use registry entry for it.

And, anyway, I cannot blame the homenet people for having "registered"
.home surreptitiously because there is no other open way to do it
"properly".

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 25 Apr 2016 09:29:45 +0200

On Sat, Apr 23, 2016 at 06:01:59PM -0700,
 David Conrad <[email-masked]> wrote 
 a message of 70 lines which said:

> My gut feeling is that this is a process failure, but will admit
> that the whole question is quite unclear given the continuing
> uncertainty about the process described in 6761.

There is no uncertainty. We have a process (RFC 6761) with its
strenghths and weaknesses. Some people thought it would be a good idea
to reopen the debate, this was the mistake. We should have used RFC
6761, period. (Which does not prevent to work on a possible 6761-bis
but closing de facto the registry, pending this work, was a big error,
leading to things like slealth registration, as in RFC 7788.)

> matter? Who manages 10.in-addr.arpa?

% dig +short SOA 10.in-addr.arpa
prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800

It seems to be IANA :-)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 25 Apr 2016 09:31:20 +0200

On Sun, Apr 24, 2016 at 08:18:35AM +0200,
 Patrik Fältström <[email-masked]> wrote 

> Either .HOME should not have been mentioned, or it should be added

I fully agree it should have used the RFC 6761 framework. Unfortunately,
it is closed de facto <https://www.ietf.org/blog/2015/09/onion/> So,
the Homenet people really had no choice.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 25 Apr 2016 09:11:15 +0100

> .home surreptitiously because there is no other open way to do it

To the best of my knowledge there was no intent to get around 6761 here
surreptitiously or otherwise, just process failure.

It's one short sentence and I didn't spot the implications of it, my
co-chair didn't spot it and nor was it called out during WG LC, IETF LC,
nor IESG review.

Ray

---

From: David Conrad <[email-masked]>
Date: Mon, 25 Apr 2016 16:29:24 -0700

On Apr 24, 2016, at 7:54 AM, Ted Lemon <[email-masked]> wrote:
> Paul. I think actually that we need to start maintaining a list of things that ought to be explicitly looked for when reviewing documents for publication, and this sort of thing would be one such.

I'll admit some surprise that such a list doesn't already exist.

> This is not to say that it's not a hard problem, though--such a list could easily become unwieldy.   We tried to do something like that with RFC 7227 section 13.   The problem is that if there isn't a single resource to go to for this stuff, and there's no step in the review process where this sort of check happens.

That's also surprising.

The fact that problems like this haven't occurred before honestly increases my (already high) opinion of working group chairs and the IESG.

Regards,
-drc

---

From: Alain Durand <[email-masked]>
Date: Tue, 26 Apr 2016 12:50:11 +0000

> On Apr 25, 2016, at 3:31 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Of course they had choices. Now, I’m a bit concerned justifications like the one above could set a dangerous precedent.
I’m perfectly willing to accept there was no malice in that particular case, and it was a “process failure”.
We all make mistake, as individuals or as organizations. That’s human nature. The real question is, how do we deal with those mistakes?

Alain, speaking solely as myself, not on behalf of my employers, past, present or future.

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 26 Apr 2016 14:33:46 -0400

Hi

An Errata has been filed on this (by me of all people)

http://www.rfc-editor.org/errata_search.php?rfc=7788&eid=4677

tim