Subject: [homenet] RFC 7788 and the IANA registry conflict

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 09 Jun 2016 17:17:28 +0200

Suddenly shncpd stopped parsing name server information.  I asked Markus,
and he explained that the IANA registry[1] has different values for the
DHCPv4_DATA and DHCPv6_DATA TLVs than RFC 7788.  Hnetd was following the
former, while shncpd was following the former.

Grr.

I've just fixed shncpd so that it interoperates with hnetd again (by
following the IANA registry).  But what's to be done longer term?  Do we
change the IANA registry again, or should somebody publish an erratum to
RFC 7788.

Thanks,

-- Juliusz

---

From: Ray Bellis <[email-masked]>
Date: Thu, 9 Jun 2016 17:32:02 +0100

> change the IANA registry again, or should somebody publish an erratum to

To clarify for other readers, since it's hard to spot - the IANA
registry reflects what was specified in the IANA Considerations of the
document, but the diagrams in §10.2.2 and §10.2.3 have the option values
the wrong way around.

So yes, we should probably publish an erratum, but please leave it with
the Chairs and our AD for a short while.  Per the errata already raised
regarding the unintended de-facto reservation of ".home" for HNCP we're
expecting to need to put out a 7788-bis very soon anyway.

thanks,

Ray

---

From: Markus Stenberg <[email-masked]>
Date: Thu, 9 Jun 2016 20:35:19 +0300

> document, but the diagrams in §10.2.2 and §10.2.3 have the option values

I failed once today at spotting the difference too (although noticed it earlier at some point as well). Too much work I guess.

> expecting to need to put out a 7788-bis very soon anyway.

Is that RFC6something process for getting gTLDs still blocked by ICANN or whoever who is simultaneously celebrating their 1000th $$$ gTLD?

The specification (AFAIK) does not really require all implementations to agree on the same network-wide default (as it is not omitted from DDZ TLVs, the sub-zones are fully qualified), but I do not see any other sensible default than the one we use now. So I am not sure what this will change in practise.

Cheers,

-Markus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Thu, 09 Jun 2016 19:45:41 +0200

> The specification (AFAIK) does not really require all implementations to
> agree on the same network-wide default (as it is not omitted from DDZ
> TLVs, the sub-zones are fully qualified), but I do not see any other
> sensible default than the one we use now. So I am not sure what this
> will change in practise.

I can be convinced to change the default in shncpd.  Please let ICANN know
that I prefer slightly used, non-sequential banknotes.

-- Juliusz

---

From: Ray Bellis <[email-masked]>
Date: Thu, 9 Jun 2016 20:09:24 +0100

On 09/06/2016 18:35, Markus Stenberg wrote:

> Is that RFC6something process for getting gTLDs still blocked by
> ICANN or whoever who is simultaneously celebrating their 1000th $$$
> gTLD?

It's RFC 6761, and the process is suspended (AIUI) by the IESG.

The history and politics of that are unclear, but to the best of my
knowledge ICANN had nothing to do with it.

My recollection of events is that the suspension of the process was
related to the attempts to use it to register .gnu and a few others.

There was insufficient clarity about what might have made those names
"special" and therefore eligible for reservation as RFC 6761 "special
use domain names" (with a distinct technical purpose) instead of being
just like any other TLD in the global DNS name space that would have to
be applied for through the ICANN process.

That's also then tied up in the question of whether the trailing label
in something that otherwise looks like a domain name is suitable in the
general case for being a "protocol switch" signal (c.f. ".local")

Personally I still think that ".home" would make a fine choice for HNCP
(except for the language bias issue) but if is to be the choice we need
to follow due process.  Quite how we do that when that process is
suspended is the challenge currently facing your chairs and AD.

Ray

---

From: Ralph Droms <[email-masked]>
Date: Thu, 9 Jun 2016 15:35:16 -0400

> On Jun 9, 2016, at 1:35 PM 6/9/16, Markus Stenberg <[email-masked]> wrote:
> 

As Ray mentioned, the RFC 6761 process was suspended after the publication of RFC 7686 and the designation of .onion as a Special Use Domain Name, due to the length of the discussion in dnsop and the IETF as a whole about whether .  There is interest in clarifying or extending the RFC 6761 process to reduce the length of the discussions related to the designation of other names as Special Use Domain Names.
> 
> The specification (AFAIK) does not really require all implementations to agree on the same network-wide default (as it is not omitted from DDZ TLVs, the sub-zones are fully qualified), but I do not see any other sensible default than the one we use now. So I am not sure what this will change in practice.

What will change is the official standardization of .home as an implicit Special-Use Domain Name, which has not been put through the RFC 6761 process.

- Ralph

> 
> Cheers,
> 
> -Markus
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Ralph Droms <[email-masked]>
Date: Thu, 9 Jun 2016 15:44:40 -0400

> On Jun 9, 2016, at 1:45 PM 6/9/16, Juliusz Chroboczek <[email-masked]> wrote:
> 

Regrettably, your response is a little misleading, as ICANN has nothing to do with this process.  RFC 6761 outlines the process, which requires Standards Action or IESG Approval and an IANA Considerations section that provides the relevant information to be included in the Special-Use Names registry.

RFC 7788 seems to imply some special use characteristics for .home by making it the default zone to be "appended to all single labels or unqualified zones in order to qualify them.", as such generated names would not be unique nor appear in the global DNS.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 9 Jun 2016 15:47:22 -0400

> On Jun 9, 2016, at 3:09 PM 6/9/16, Ray Bellis <[email-masked]> wrote:
> 
> 
> 

I think a good first step would be to decide exactly the desired behavior for domain names that end in ".home" rather than a DNS zone.  I wasn't able to determine the expectations for ".home" from RFC 7788.

- Ralph

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 9 Jun 2016 15:57:11 -0400

> Regrettably, your response is a little misleading, as ICANN has nothing to do with this process.  RFC 6761 outlines the process, which requires Standards Action or IESG Approval and an IANA Conside…

This is true, and I further suggest reviewing https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/ and https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/ for two different attempts to describe the challenges arising from trying to apply RFC 6761.

DNSOP has been working for a very long time now on a problem statement for the ways this can go wrong. 

> RFC 7788 seems to imply some special use characteristics for .home by making it the default zone to be "appended to all single labels or unqualified zones in order to qualify them.", as such genera…

More specifically, it seems to assume those names will not resolve in the global public DNS, and will not already have a local resolution context, without providing any reason for that assumption-- such as an attempt to register such names in the special use names registry, or describing what the operator is expected to do to avoid possible collisions caused by existing local use of names ending in .home (there's widespread evidence of this, documented in the discussion of why ICANN isn't delegating it in the first place).

Suzanne

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Jun 2016 22:07:55 -0400

Hi,

Response to a couple messages at once:

> It's RFC 6761, and the process is suspended (AIUI) by the IESG.
[…]
> to follow due process.

On Thu, Jun 09, 2016 at 03:35:16PM -0400, Ralph Droms wrote:

> As Ray mentioned, the RFC 6761 process was suspended after the
>publication of RFC 7686 and the designation of .onion as a Special
>Use Domain Name, due to the length of the discussion in dnsop and the
>IETF as a whole
[…]
>  What will change is the official standardization of .home as an
> implicit Special-Use Domain Name, which has not been put through the
> RFC 6761 process.

I just want to make sure that the basic fact doesn't get lost here,
because I think some people may be noticing what I think are the wrong
things in the above and other messages in this thread.

RFC 6761 specifies what you have to do if you're going to carve out
part of the Internet's global name space for protocol-specific needs.
There are indeed some concerns about how that works, particularly at
the top of the global name space (i.e. to create a TLD-like-thing,
even if it's never supposed to appear in the DNS).

But the real problem here is that RFC 7788 doesn't do any of what is
in RFC 6761 _at all_, despite apparently attempting to reserve a name
in the namespace.  I am one of the people who failed to catch this
fault before publication of 7788, and for that I apologise.  But let
us not misunderstand that this is some sort of ICANN or IESG desire to
throw sand in gears.  The IANA considerations of RFC 7788 is wrong: it
doesn't include the necessary reservation request.  That's the bug.

I will note, also, that AFAICT the IESG has not issued a blanket
policy about 6761 requests.  It is worried about how to do duch
reservations in the root name space.

There is an already-functioning namespace that is fully capable of
handling these kinds of requests, and one that is under IAB control:
arpa.  There is ample evidence that it already works: ipv4only.arpa.
Rather than getting twisted 'round a TLD axle, it strikes me that
there is a quick and easy path forward, and one that appears
impervious to application fees.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]