Subject: [DNSOP] followup and proposed actions: RFC 6761 interim and next steps

From: Suzanne Woolf <[email-masked]>
Date: Tue, 19 May 2015 18:18:24 -0400

Dear Colleagues,

First, thanks for extensive and thoughtful discussion on the list and in our interim meeting last week on the way forward for the internet-drafts requesting special use names registry entries under RFC 6761.

This message is fairly long, and contains some impressions of where we are, a couple of actions we expect to take in the next few days, and some questions we’d like to pursue going forward. Please read all of it if you’re interested in the overall topic; we have significant challenges of both process and substance to navigate.

It's clear that applying RFC 6761 is challenging, and one of the outcomes we'd like to see from the current discussion is serious consideration of whether we need to update it with a new document suggesting additional guidelines or considerations.

First, some initial impressions:

.ONION (draft-appelbaum-dnsop-onion-tld-01):

* There’s significant support for the .onion request, in terms of the draft itself and what the TOR project is trying to accomplish by supporting the protocol and making the request.

* There are some reservations about .onion. We heard concerns that we might be setting a precedent for arbitrary appropriation of namespace; that the protocol may not be thoroughly documented, and that we’re not clear on how high the bar should be for a special use name.

.ALT (draft-wkumari-dnsop-alt-tld-06):

* There’s significant support for .alt as a possible alternative namespace for implementers who want namespace they’re certain won’t resolve in the global DNS, but are willing to be flexible on what namespace they use.

* There are operational questions about .alt that would have to be resolved in further development of the draft, such as whether to assume “leaked” queries would be sunk to AS112.

* There was some concern that implementers who want single-label or “TLD” namespaces would not accept .alt as a possible alternative

* There was some question as to what would be gained by .alt that we don’t already have in .invalid, which is also already reserved

HOME/CORP/MAIL (draft-chapin-additional-reserved-tlds-02):

* This is the most controversial of the RFC 6761 drafts and the one most driven by policy concerns

* The draft assumes that these names are commonly being used in local DNS contexts and often “leak” into the public internet. Specific uses are not documented.

* The most commonly used justification for this reservation was the risk of name collision if ICANN delegates these names in the production root zone.

* Since ICANN has said that they’re not currently planning to delegate these names, the justification further seems to assume that ICANN’s assurance of this is not a sound basis for believing that risk is contained

* There were questions about how to quantify name collision risk, or otherwise set a threshold for what operational characteristics of the appearance of a given name in the public internet would justify a conclusion that it should be “protected” by the IETF from delegation in the production root zone

ADDITIONAL NOTES:

There was some discussion of other drafts as well. In particular, there was some willingness to review the requests currently contained in draft-grothoff-iesg-special-use-p2p-names-04 if presented in separate drafts, as that would make it easier for the WG to properly consider those requests.

MOVING FORWARD:

We expect to take the following steps:

1. A call for adoption on the WG list of draft-appelbaum-dnsop-onion-tld-01. Given that there's clear support for it and a timeliness concern, we'd like to see if we can get to a consensus to move forward with it.

2. A call for adoption on the WG list of draft-wkumari-dnsop-alt-tld-06, and further discussion on the list to the operational questions mentioned above. We're all aware this isn't a complete solution to the perceived demand for special use names; can it be used to make the situation notably better?

3. Further discussion on the WG list of draft-chapin-additional-reserved-tlds-02. Given that we don't currently see consensus to move forward with it, and the support for it seems widely fragmented among technical and policy-based reasoning, we'd particularly like to see any NEW input on:

	* What is the specific operational impact being sought by adding these names to the special use names registry? Is the goal to have an impact on anyone besides ICANN?
	* Some of our discussion so far has suggested that there's a difference between basing a decision about a special use names delegation on intended use in a new protocol, such as .onion, and basing such a decision on unknown and unspecified use, perhaps particularly within the DNS. In the interests of evaluating future such requests that might also not be based on a specific protocol use, is there a bar we can set besides the discussion in the current draft of inferred name collision risk?

4. It's been pointed out that the maintenance of the special use names registry is complicated by the fact that people used to be able to assume the root zone was relatively stable, and this assumption has become less defensible. (ICANN is not currently accepting new applications for TLDs, and has no announced schedule for opening an application window again, but has said they plan a future application round.) Is there something that the IETF should be doing to help DNS implementers and operators handle this change in the environment?

thanks,
Suzanne and Tim

---

From: Tom Ritter <[email-masked]>
Date: Wed, 20 May 2015 07:06:11 -0500

On 5/19/15 5:18 PM, Suzanne Woolf wrote:
> 4. It's been pointed out that the maintenance of the special use names
> registry is complicated by the fact that people used to be able to
> assume the root zone was relatively stable, and this assumption has
> become less defensible. (ICANN is not currently accepting new
> applications for TLDs, and has no announced schedule for opening an
> application window again, but has said they plan a future application
> round.) Is there something that the IETF should be doing to help DNS
> implementers and operators handle this change in the environment?

Yes - and I've not been following the effort closely, but I believe it's
being done over in DBOUND in their work to replace the Public Suffix List.

Because (AIUI) DBOUND is intended to specify security-relevant zone cuts
*in DNS* using it to specify names that are reserved in DNS but not _in_
DNS might come out a little weird... but it seems like the most relevant
place to at least take the idea and discuss it.

-tom

---

From: Warren Kumari <[email-masked]>
Date: Wed, 20 May 2015 09:48:26 -0400

On Tue, May 19, 2015 at 6:18 PM, Suzanne Woolf <[email-masked]> wrote:
> Dear Colleagues,
>
>
> First, thanks for extensive and thoughtful discussion on the list and in our
> interim meeting last week on the way forward for the internet-drafts
> requesting special use names registry entries under RFC 6761.
>
>
> This message is fairly long, and contains some impressions of where we are,
> a couple of actions we expect to take in the next few days, and some
> questions we’d like to pursue going forward. Please read all of it if you’re
> interested in the overall topic; we have significant challenges of both
> process and substance to navigate.
>
> It's clear that applying RFC 6761 is challenging, and one of the outcomes
> we'd like to see from the current discussion is serious consideration of
> whether we need to update it with a new document suggesting additional
> guidelines or considerations.
>
>
> * There’s significant support for the .onion request, in terms of the draft
> itself and what the TOR project is trying to accomplish by supporting the
> protocol and making the request.
>
>
> * There are some reservations about .onion. We heard concerns that we might
> be setting a precedent for arbitrary appropriation of namespace; that the
> protocol may not be thoroughly documented, and that we’re not clear on how
> high the bar should be for a special use name.
>
>
>
> * There’s significant support for .alt as a possible alternative namespace
> for implementers who want namespace they’re certain won’t resolve in the
> global DNS, but are willing to be flexible on what namespace they use.
>
>
> * There are operational questions about .alt that would have to be resolved
> in further development of the draft, such as whether to assume “leaked”
> queries would be sunk to AS112.

We updated the draft yesterday, it currently says:
"The ALT TLD is delegated to "new style" AS112 servers, and so
recursive and stub resolvers
   will get NXDOMAIN for all queries.

   1.  Iterative resolvers SHOULD follow the advice in [RFC6303],
       Section 3.

   2.  The ALT TLD is delegated to "new style" AS112 nameservers
       ([I-D.ietf-dnsop-as112-dname] ), which will return NXDOMAIN for
       all queries.

   These rules are intended to limit how far unintentional queries (i.e.
   those not intended for the global DNS) flow."

(this text is actually out of date, I-D.ietf-dnsop-as112-dname is now
RFC 7535 (fixed in edit buffer / github ))

It also goes on to say (in the IANA Considerations section):
"In addition, the "Locally Served DNS Zones" ([RFC6303]) registry
should be updated to reference this document."

The plan is that queries that leak into the DNS should be dropped as
soon as possible, and should not add significantly to the root junk
queries[0].
Once added to Locally Served DNS Zones (and recursives have been
updated) they should be dropped there, any which happen to still slip
through should be punted to AS112, and dropped there (and, if qname
minimization / resimprove happens, .alt itself would be cached by
recursives that ignore locally served zones).

>
>
> * There was some concern that implementers who want single-label or “TLD”
> namespaces would not accept .alt as a possible alternative

Yup. That's entirely possible / likely. But, after .alt exists, people
who want to be a: responsible or b: experiment actually have a good
alternative. Some implementors will no doubt simply choose a single
label (.foo) and use that -- but, when they later come ask for it to
be added to SUN, we / the IESG can push back and say that there was an
alternative...

>
> * There was some question as to what would be gained by .alt that we don’t
> already have in .invalid, which is also already reserved

.invalid is reserved, but doesn't get the special handling that we
would be requesting for .alt (perhaps it should though; I smell
another draft in the making :-)). Strings also have human meaning - if
I want to create a resolution system using distributed hash tables  /
prefix tree that uses a concatenation of the entered name with a
"selector" to create multiple parallel namespaces I *may* be willing
to use names for the form <something>.decentralized.alt... but I'd be
much less likely to be willing to use
<something>.decentralized.invalid.
For better or worse, labels *do* have meaning (as demonstrated by
ICANN auction proceeds topping $61,000,000USD)

> * The draft assumes that these names are commonly being used in local DNS
> contexts and often “leak” into the public internet. Specific uses are not
> documented.
>
>
> * The most commonly used justification for this reservation was the risk of
> name collision if ICANN delegates these names in the production root zone.
>
>
> * Since ICANN has said that they’re not currently planning to delegate these
> names, the justification further seems to assume that ICANN’s assurance of
> this is not a sound basis for believing that risk is contained
>
>
> * There were questions about how to quantify name collision risk, or
> otherwise set a threshold for what operational characteristics of the
> appearance of a given name in the public internet would justify a conclusion
> that it should be “protected” by the IETF from delegation in the production
> root zone
>
>
>
> ADDITIONAL NOTES:
>
> There was some discussion of other drafts as well. In particular, there was
> some willingness to review the requests currently contained in
> draft-grothoff-iesg-special-use-p2p-names-04 if presented in separate
> drafts, as that would make it easier for the WG to properly consider those
> requests.
>
>
> MOVING FORWARD:
>
> 1. A call for adoption on the WG list of draft-appelbaum-dnsop-onion-tld-01.
> Given that there's clear support for it and a timeliness concern, we'd like
> to see if we can get to a consensus to move forward with it.
>
> 2. A call for adoption on the WG list of draft-wkumari-dnsop-alt-tld-06, and
> further discussion on the list to the operational questions mentioned above.
> We're all aware this isn't a complete solution to the perceived demand for
> special use names; can it be used to make the situation notably better?

I believe it can -- it provides people who want to create alternate
namespaces a legitimate way to do so.

This document was initiated in Feb 2014, and is now at revision -06.
During its life it has received a fair bit of discussion, including
being presented / discussed at:

IETF-89  - Berlin -
http://www.ietf.org/proceedings/89/slides/slides-89-dnsop-15.pdf
IETF-91 - Dallas -
http://www.ietf.org/proceedings/92/slides/slides-92-dnsop-5.pdf
The "special use names" interim: (no slides)
https://www.ietf.org/mail-archive/web/dnsop/current/msg14238.html
and around 75 or 80 emails.

I have attempted to capture and incorporate all of the comments
received. The most recent set of changes was:
a: make it clearer that this is for *new* pseudo-TLDs. Existing ones
may choose to move under .alt if they wish (it's open, there is
nothing we could do to stop them if we wanted!), but are not expected
to.

b: to remove the request that IANA create and run a registry where
people can (optionally) register their use of the string. Various
people (myself included) were concerned that this looks too much like
a "real" TLD then, with the IETF as the registry and registrar. This
would open the whole can of worms, with trademark and similar issues.

As always, if this is adopted by the WG (and the chairs select us to
continue editing), we will incorporate whatever WG consensus is.

Thank you,
W

Condensed change log below:

 From -05 to -06
   o  Incorporated comments from a number of people, including a number
      of suggestion heard at the IETF meeting in Dallas, and the DNSOP
      Interim meeting in May, 2015.
   o  Removed the "Let's have an (optional) IANA registry for people to
      (opportinistically) register their string, if they want that
      option" stuff.  It was, um, optional....

   From -04 to -05
   o  Went through and made sure that I'd captured the feedback
      received.
   o  Comments from Ed Lewis.
   o  Filled in the "Domain Name Reservation Considerations" section of
      RFC6761.
   o  Removed examples from .Onion.

   From -03 to -04
   o  Incorporated some comments from Paul Hoffman

   From -02 to -03
   o  After discussions with chairs, made this much more generic (not
      purely non-DNS), and some cleanup.

   From -01 to -02
   o  Removed some fluffy wording, tightened up the language some.

   From -00 to -01.
   o  Fixed the abstract.
   o  Recommended that folk root their non-DNS namespace under a DNS
      namespace that they control (Joe Abley)

>
> 3. Further discussion on the WG list of
> draft-chapin-additional-reserved-tlds-02. Given that we don't currently see
> consensus to move forward with it, and the support for it seems widely
> fragmented among technical and policy-based reasoning, we'd particularly
> like to see any NEW input on:
>
> * What is the specific operational impact being sought by adding these names
> to the special use names registry? Is the goal to have an impact on anyone
> besides ICANN?
> * Some of our discussion so far has suggested that there's a difference
> between basing a decision about a special use names delegation on intended
> use in a new protocol, such as .onion, and basing such a decision on unknown
> and unspecified use, perhaps particularly within the DNS. In the interests
> of evaluating future such requests that might also not be based on a
> specific protocol use, is there a bar we can set besides the discussion in
> the current draft of inferred name collision risk?
>
> registry is complicated by the fact that people used to be able to assume
> the root zone was relatively stable, and this assumption has become less
> defensible. (ICANN is not currently accepting new applications for TLDs, and
> has no announced schedule for opening an application window again, but has
> said they plan a future application round.) Is there something that the IETF
> should be doing to help DNS implementers and operators handle this change in
> the environment?
>
>
> thanks,
> Suzanne and Tim
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 20 May 2015 10:47:00 -0400

[ not subscribed to dnsop, so this might not post to the list; please cc
  me on replies ]
  
> place to at least take the idea and discuss it.

The above is a little hard to parse, but i think Tom is suggesting that
dbound will not result in a "security-relevant zone cut" mechanism that
is implemented in the DNS itself.

i don't think that constraint is a given for DBOUND work at all (though
i might be confused -- hopefully other dbounders can comment).

I think the most likely way for DBOUND to be implemented is to introduce
some sort of "organizational boundary goes here" DNS record, and the
wrangling is going to be around what that record looks like and what its
semantics will be.

Regards,

      --dkg

---

From: "John Levine" <[email-masked]>
Date: 20 May 2015 15:54:43 -0000

>> round.)

The current round is far from over. There are nearly 700 gTLDs
currently in the root, and about 600 more names with applications
still in process.  There are still 8 names with pending auctions among
multiple applicants, and 21 that are "on hold" for various reasons.
This last group includes .corp, .home, and .mail.

>> Is there something that the IETF should be doing to help DNS

DBOUND is indeed trying to come up with something less bad than the current
PSL, but ...

>place to at least take the idea and discuss it.

Sorry, that's just wrong.  DBOUND has nothing whatsoever to do with
zone cuts or reserved names.  There's plenty of ambiguity about what
we're trying to do, but neither of those are on or even near the table.

R's,
John

---

From: Tom Ritter <[email-masked]>
Date: Wed, 20 May 2015 11:24:01 -0500

> we're trying to do, but neither of those are on or even near the table.

I think I used zone cuts to mean something it's not, I meant
"establish separation lines in DNS that parties (like browsers, or
anyone using PSL) can use to make security decisions about what is an
'open' domain hierarchy with mutually distrusting participants versus
what is a 'shared' domain where all the subdomains are
administratively joined."  I (hope) that's closer to what DBOUND is
after.

I didn't think you'd have worked with reserved names, but what I'm
curious about is if there could be an easy way to put in a DBOUND
record for (say) onion. with a with flag meaning "This name is
reserved and should not be resolved unless you know how to
specifically handle it."  Then if .foo gets the same treatment in N
years, no client software changes are needed.

-tom

---

From: "John Levine" <[email-masked]>
Date: 20 May 2015 17:42:52 -0000

>administratively joined."  I (hope) that's closer to what DBOUND is

Well, that's one usage scenario.  DBOUND is very difficult because
people use the PSL for radically different things, and people who want
it for one application have a surprising amount of trouble dealing
with the fact that an approach that works for one application may be
hopeless for another.

>specifically handle it." 

I can't think of any application that plans to use DBOUND to ask
whether to try to resove a name at all.  After all, the DNS already
has a perfectly good way to ask whether a name exists -- you look
it up and see if you get an answer or an NXDOMAIN.  

As I understand it, our goal here is to deal with a situation in which
an application uses a name that is intended to be handled in a special
way (say blah.onion) but due to misconfiguation is instead sent to a
normal DNS resolver.  No matter how we implement DBOUND, this would
require an extra lookup before every single DNS query, which seems
like a really bad idea.

If we're going to fix this, it has to be fixed if not at the roots as
close to them as possible.

R's,
John

---

From: Lyman Chapin <[email-masked]>
Date: Tue, 26 May 2015 14:50:37 -0400

Hi Suzanne -

> * This is the most controversial of the RFC 6761 drafts and the one most driven by policy concerns

It is not driven by policy concerns; it is driven by operational concerns, and I have heard almost no one in the WG discussion argue that these three names should *not* be withdrawn/reserved (and I say "almost" just to be safe, as I haven't checked thoroughly enough to omit it).

> * The draft assumes that these names are commonly being used in local DNS contexts and often “leak” into the public internet. Specific uses are not documented.

The draft does not "assume" this, it "recognizes" or "observes" it. "Assumes" suggests that the authors of the draft weren't really sure about the local-context usage of these names, and so just "assumed" that it was was a problem. Specific uses are of course documented in great detail in the name collision study report (https://www.icann.org/en/system/files/files/name-collision-02aug13-en.pdf), which is 197 pages long and presumably would not be welcome as a cut-and-paste addition to a document intended only to follow the rules established by RFC 6761 for adding names to the special-use names register.

> * The most commonly used justification for this reservation was the risk of name collision if ICANN delegates these names in the production root zone.

More specifically, with respect to why this matters to the IETF, the justification was the risk of operational instability when names that were chosen to anchor local domain name trees precisely because they "will never resolve in the global DNS" are actually resolved by the global DNS.

> * Since ICANN has said that they’re not currently planning to delegate these names, the justification further seems to assume that ICANN’s assurance of this is not a sound basis for believing that…

ICANN's decision is in the realm of policy. It is in no way disrespectful of ICANN to say that a policy decision to withhold "for now" the delegation of specific names is not the same as an operational stability decision to permanently reserve those names for local ("special") use.

> * There were questions about how to quantify name collision risk, or otherwise set a threshold for what operational characteristics of the appearance of a given name in the public internet would ju…

That's not what our draft was about. Our draft was about following the rules duly established by RFC 6761 to add 3 specific strings to the special-use names registry. Full stop.

- Lyman

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 26 May 2015 12:48:49 -0700

> 
> On May 26, 2015, at 11:50 AM, Lyman Chapin <[email-masked]> wrote:
> 
> Hi Suzanne -
> 

I’m against withdrawing/reserving these names.

> The draft does not "assume" this, it "recognizes" or "observes" it. "Assumes" suggests that the authors of the draft weren't really sure about the local-context usage of these names, and so just "a…

It makes a lot of assumptions. As a TLD operator, I have not seen any operational problems with the names that were under names collision. This does not mean there there aren’t any.

Taking an excerpt fromR RFC6761:

   Now, suppose a
   developer were to use this special "guaranteed nonexistent" name,
   "knowing" that it's guaranteed to return NXDOMAIN, and suppose also
   that the user's DNS server fails to return NXDOMAIN for this name.
   The developer's software then fails.  Who do the user and/or
   developer complain to?  ICANN?  The IETF?  The DNS server operator?
   If the developer can't depend on the special "guaranteed nonexistent"
   name to always return NXDOMAIN, then the special name is worthless,
   because it can't be relied on to do what it is supposed to.

How is the IETF supposed to “guarantee nonexistence” ? how is ICANN going to do it?

In my opinion, defining it in “Protocol” won’t fix it, because we’re talking about “private” networks not “intended” to be connected to the Internet leaking traffic to the outside world, this is going to happen regardless of what the IETF does or does not do.

I believe there is a bigger security risk when I can’t register the name and not have a full top-down DNSSEC validation chain for my users. What is the message that we want to send?,

“… sure use .HOME for local networks because it’s guaranteed that you’ll never receive an address there, so you can trust that the IP that you are receiving comes from your intranet.."

> More specifically, with respect to why this matters to the IETF, the justification was the risk of operational instability when names that were chosen to anchor local domain name trees precisely be…

Those names were resolving (in some cases) before the new GTLD program started, NX Redirection is not new within ISPs.

How do we measure the real Risk? how do we balance risk vs. benefits? I have not seen any hard data on the risk just speculations.

I have seen people implement Intranet names under COM they don’t own, but they used them for their own local network, is there a risk here? is it the same risk?, I personally think there isn’t any, people are free to shoot themselves in the foot at any time, having them wear steel toe shoes won’t solve the problem.

> ICANN's decision is in the realm of policy. It is in no way disrespectful of ICANN to say that a policy decision to withhold "for now" the delegation of specific names is not the same as an operati…

If they want to be “reserved” for local use, I’m ok with it in the sense that it can be done, lets not waste time then on the assumptions and draft a document that describes those three TLDs as reserved for local use and turn the page.

> That's not what our draft was about. Our draft was about following the rules duly established by RFC 6761 to add 3 specific strings to the special-use names registry. Full stop.

If we want to make assumptions, I’ll make one:

I believe the delegation of HOME/CORP/MAIL provides with more benefit than risks, there will be more companies/homes and mail users happy because their names resolve from everywhere, they can validate with DNSSEC, they can opt who can connect to their networks and no longer require domain hacks to get their users to go to the right places.

If the problem is really about the “intent” that those TLDs where meant to be used “locally”, reserving them “forever” seems for a really long time, I would leave enough room to revisit this in the future because the TLD will outlive the systems that were misconfigured, and also the people who are in this forum (including me).

I much rather like to see us work on a transition plan on how to delegate them and not withdraw them in stone “forever”.

Best regards,

> - Lyman

Francisco Obispo
CTO - Registry Operations
____________________________

 <http://www.uniregistry.com/>
2161 San Joaquin Hills Road
Newport Beach, CA 92660

Office +1 949 706 2300 x4202
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 26 May 2015 20:07:03 -0000

>I believe the delegation of HOME/CORP/MAIL provides with more benefit than risks, there
>will be more companies/homes and mail users happy because their names resolve from
>everywhere, they can validate with DNSSEC, they can opt who can connect to their
>networks and no longer require domain hacks to get their users to go to the right
>places.

There are probably tens of thousands of people who have a device with
the local name PRINTER.HOME.  I must be dim, because I cannnot imagine
any way that any possible set of DNS records in the root or a TLD
would allow that name to "resolve from everywhere" in a way other than
perhaps one that sent an enormous amount of people's printouts to one
printer somewhere.

Could you clarify how it's supposed to work?

R's,
John

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 26 May 2015 17:31:43 -0300

> Em 26/05/2015, à(s) 15:50:000, Lyman Chapin <[email-masked]> escreveu:
> 
> Hi Suzanne -
> 

I'm curious about one of those TLDs: MAIL. Besides dotless "mail", which seems to hit the root at very high rate (lack of negative caching) and shouldn't be ever allowed to exist, and a few meaningful labels like local.mail*, I can't recall the reasoning for being concerned with <something-here>.mail.  

No matter whether one thinks the responsibility to deal with .MAIL lies with, what are the issues that people see with it ? 

Rubens

* From the first JAS namespace collision analysis still published at http://forum.icann.org/lists/comments-name-collision-05aug13/pdf3WmZlrH3fo.pdf although not anymore published at original point of publication

---

From: "John Levine" <[email-masked]>
Date: 26 May 2015 21:18:13 -0000

>I'm curious about one of those TLDs: MAIL. Besides dotless "mail", which seems to hit
>the root at very high rate (lack of negative caching) and shouldn't be ever allowed to
>exist, and a few meaningful labels like local.mail*, I can't recall the reasoning for
>being concerned with <something-here>.mail.  
>

Queries for dotless mail already provide plenty of issues.  See RFC
7085.

R's,
John

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 26 May 2015 14:19:33 -0700

> On May 26, 2015, at 1:07 PM, John Levine <[email-masked]> wrote:
> 

I would certainly like to have: obispo.home, be a real FQDN, so I can name my home devices, printer.obispo.home, etc.

If I go to a hotel around the world and I need to print in my printer at home, I should be able to do it, I shouldn’t be “hacking” my way around that. In a v6 world, this is going to be common practice, the fact that we have limitations on how we use our home networks today does not mean that those same restrictions will exist in the future.

Perhaps the approach is (if identified as a problem), to have printer.home be on a controlled interruption list for a while, so people can identify and fix their setups.  I don’t know, but the approach where we ban the whole TLD from ever existing because of few that misconfigured their naming, doesn’t seem reasonable to me. (few compared to the rest of the world who will be connected in the future).

Should we also add a .BELKIN TLD?, there are tons of devices that use it (to name a few), what if in 10 years someone decides to create .FOOBARBAZ are we going to add it to the list later?,

We need a better view/picture of the whole DNS ecosystem, we should not be making assertions based on a 24 hour sample of 1 day of root server traffic, let put more effort into strategy for the long term and not be so tactical about these specific use cases.

Regards,

Francisco Obispo

---

From: Rubens Kuhl <[email-masked]>
Date: Tue, 26 May 2015 18:22:31 -0300

> Em 26/05/2015, à(s) 18:18:000, John Levine <[email-masked]> escreveu:
> 

RFC 7085 mentions MX queries to other existing TLDs, not MAIL. And I would be equally concerned with MX requests for dotless MAIL than with A/AAAA/SRV requests for dotless MAIL. 

Saying there is a concern with dotless MAIL is an easy sell, my question was on issues with not-dotless MAIL. 

Rubens

---

From: "John R Levine" <[email-masked]>
Date: 26 May 2015 17:33:04 -0400

> I would certainly like to have: obispo.home, be a real FQDN, so I can name my home devices, printer.obispo.home, etc.

Ah, you expect the thousands of people with printer.home all to change the 
domain names they use.  Could you explain, preferably in detail, how you 
plan to do that?

R's,
John

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 26 May 2015 14:38:06 -0700

Where are you getting the ‘thousands’ from?

> On May 26, 2015, at 2:33 PM, John R Levine <[email-masked]> wrote:
> 
> Ah, you expect the thousands of people with printer.home all to change the domain names they use.  Could you explain, preferably in detail, how you plan to do that?

If thousands need to fix their setups, then yes.

Do you expect to write a technical document and expect the problem to be fully resolved?

Francisco Obispo

---

From: "John R Levine" <[email-masked]>
Date: 26 May 2015 17:53:16 -0400

PS:

> Should we also add a .BELKIN TLD?, there are tons of devices that use it 
> (to name a few), what if in 10 years someone decides to create 
> .FOOBARBAZ are we going to add it to the list later?,

If those names were leaking as badly as the three we're talking about, 
sure.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: "John R Levine" <[email-masked]>
Date: 26 May 2015 17:53:47 -0400

> Where are you getting the ‘thousands’ from?

Interisle's report.  There's a link to it about three messages back.

Regards,

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 26 May 2015 14:59:54 -0700

> On May 26, 2015, at 2:53 PM, John R Levine <[email-masked]> wrote:
> 

Which is my point.

We are making tons of assertions from 1 DITL window, making assumptions about how the Internet works with just a slice of the puzzle.

We now know that the major “risks” identified did not occur in practice (at least for other TLDs), if something stops working, most likely someone (tech) will realize they made a mistake, fix it and move on.

Francisco Obispo

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 May 2015 15:24:17 -0700

> RFC 7085 mentions MX queries to other existing TLDs, not MAIL. And I would be equally concerned with MX requests for dotless MAIL than with A/AAAA/SRV requests for dotless MAIL. 

dotless names were never contemplated as endpoints, even in the
HOSTS.TXT era (see for example DECWRL.ARPA). so while i'm happy to have
dotlessness shot down as often and as variously as possible, and to see
those shoot-downs well documented, diverse, and unassailable, the raw
fact of the matter is that a dotless name should _never_ be accidentally
presentation-reachable.

what i mean by presentation reachable is, you can't ping it, you can't
send mail to it, you can't point an MX or NS or PTR at it, you can't
look up its AAAA or A by typing it into a web browser, and so on.

anybody who wants more background, see
<http://www.circleid.com/posts/20110620_domain_names_without_dots/>.

anybody still not convinced and who thinks this is a castle worth
storming, see <http://queue.acm.org/detail.cfm?id=1242499>.

> Saying there is a concern with dotless MAIL is an easy sell, my question was on issues with not-dotless MAIL. 

i agree with ruben. i know of a lot of local uses of HOME, CORP, and
LOCAL, where non-dotless names inside some network perimeter have local
meaning. i know of no instance of MAIL being used that way.

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 May 2015 15:33:48 -0700

Francisco Obispo wrote:
>
>> On May 26, 2015, at 2:53 PM, John R Levine <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
> We are making tons of assertions from 1 DITL window, making
> assumptions about how the Internet works with just a slice of the puzzle.
>
> We now know that the major “risks” identified did not occur in
> practice (at least for other TLDs), if something stops working, most
> likely someone (tech) will realize they made a mistake, fix it and
> move on.

francisco, i object, and i also disagree.

i object, because as a tld registry, you are making a self-interested
argument here. i'd prefer you to find someone who makes no money when a
new TLD is allocated and get them to carry this torch. as a senior
member of the uniregistry technical staff, you have a conflict of
interest. as my friend, you have extremely high standards of personal
behaviour.

i also disagree. people don't know when something stops working, it just
makes their experience worse and they don't know why. the most likely
outcome is they'll just live in digital squalor.
DITL happens to be representative. (you've operated f-root; you know
what the root servers see.) my take on the data is, .HOME, .CORP, and
.LOCAL are poisoned for all time, no further discussion needed.

to the extent that the new gTLD programme has any public benefit
purpose, that purpose must be balanced with digital public safety. if
there's a risk, then the risk is too high, because if there's a benefit,
the benefit is too low.

-- 
Paul Vixie

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 May 2015 19:00:07 -0400 (EDT)

> meaning. i know of no instance of MAIL being used that way.

How do 15 year old OSes and applications implement and interact for "search domains".

The answer is "very differently and often very wrongly".

Are we sure that an application querying "mail" will still end up receiving
an A record for mail.corp.com. when mail. is delegated. Or will it get
NXDOMAIN and fail the mail. And when the application sending mail is not
an enduser MUA, what will happen with these failed emails and when will
people notice the problem?

I've been inside a bank network where they could not get rid of "unused"
zones for > 10 years because of unqualified lookups and applications of
which they only had the binary and no replacement product ready, running
on very old Microsoft Windows versions. (although perhaps now they could
DNAME it)

While this applies to all unqualified names, the most used ones that I
expect this would hit, based on my personal biased experience, is
"linux", "server", "mail", "oracle" and "exchange".

The last two can be handled by those starting the problem TLDs (vendor and
their customers). The first three will cause outages and problems.

Paul

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 May 2015 16:07:31 -0700

Paul Wouters wrote:
>>> Saying there is a concern with dotless MAIL is an easy sell, my
>>> question was on issues with not-dotless MAIL.
>>
> an A record for mail.corp.com. when mail. is delegated.

yes. i wrote a lot of the 15-year-old code in question. (actually some
of it is 25 years old.) NOERROR vs. NXDOMAIN doesn't matter. all that
matters is that there is no AAAA or A RR at "MAIL.", and that's already
a rule, so what we're discussing here (your mail.corp.com example) will
not be impacted.

your example is spot-on when it comes to CORP, HOME, or LOCAL, or to
dotless domains, but not to *.MAIL.

-- 
Paul Vixie

---

From: Francisco Obispo <[email-masked]>
Date: Tue, 26 May 2015 16:43:22 -0700

> On May 26, 2015, at 3:33 PM, Paul Vixie <[email-masked]> wrote:
> 

You are correct. I do have a conflict of interest in terms of my affiliation which is why I’ve not authored any proposals myself. But I think that having different points of view on the table helps build a solution that could be better than any single one, but please don’t disqualify me because of it.

> outcome is they'll just live in digital squalor.

This is what I would like to quantify. Those people are probable already in a digital squalor and they don’t know it. How can we improve that situation?

> .LOCAL are poisoned for all time, no further discussion needed.

I’m not discarding the DITL, it’s one good slice, but there is more that we don’t see, perhaps you have access to more information and have a more complete picture of it via DNSDB and other systems?

Perhaps there is a more room for additional studies / data and analysis ?

> there's a risk, then the risk is too high, because if there's a benefit,

There is risk in not doing anything as well, how do balance it?

I trust your judgement and respect your contributions, that’s not in question, I'm not against reserving some TLDs for local use (said it in my first email), my main concern is creating the illusion that by reserving those TLDs, we’ve solved the problem and create a false sense of safety. This is a multi-variable/multi-dimensional complex system, where there are pieces that neither IETF and ICANN have control of.

Best regards,

Francisco Obispo

---

From: Mark Andrews <[email-masked]>
Date: Wed, 27 May 2015 09:55:35 +1000

In message <[email-masked]>, Francisco O
bispo writes:
> I would certainly like to have: obispo.home, be a real FQDN, so I can
> name my home devices, printer.obispo.home, etc.

In reality it would be printer.obispo72.home or something like that
99.999% of registrants after a year or so.  Only those that jump
at the very begining would get their family name.  .home wouldn't
be like .com where you are choosing a name for a business and part
of that process is finding something that is unique and that you
like in the DNS.  You already have a name.

And Australia actually has a model for how to link individuals /
families / homes into the dns.

name.<othername>.id.au

id is for individual.
<othername> is a meaningless label designed to deal with human name
collisions.

andrews.wattle.id.au (the master is currently broken) is just as
easy for me to remember as andrews.home and has the advantage that
lots of other andrewses can get a andrews.something.id.au name and
be on a equal footing.

wattle.id.au is also a free registry run on a volunteer basis.

Basically .home is too high in the heirarchy for this sort of
individual / family use.  There are too many collisions of names.

.home.ctld is also too high which is why a third level was added.

Mark

> If I go to a hotel around the world and I need to print in my printer at
> home, I should be able to do it, I shouldn’t be “hacking” my way around
> that. In a v6 world, this is going to be common practice, the fact that
> we have limitations on how we use our home networks today does not mean
> that those same restrictions will exist in the future.
>
> Perhaps the approach is (if identified as a problem), to have
> printer.home be on a controlled interruption list for a while, so people
> can identify and fix their setups.  I don’t know, but the approach where
> we ban the whole TLD from ever existing because of few that misconfigured
> their naming, doesn’t seem reasonable to me. (few compared to the rest of
> the world who will be connected in the future).
>
> (to name a few), what if in 10 years someone decides to create .FOOBARBAZ
> are we going to add it to the list later?,
>
> We need a better view/picture of the whole DNS ecosystem, we should not
> be making assertions based on a 24 hour sample of 1 day of root server
> traffic, let put more effort into strategy for the long term and not be
> so tactical about these specific use cases.
>
> Regards,
>
>
> Francisco Obispo

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 26 May 2015 22:32:50 -0400 (EDT)

> dotless domains, but not to *.MAIL.

OLD:
1) some stupid application asks for "mail"
2) some resolver library interprets this as unqualified (maybe because
    it did not resolve from the root), adds its own search domain ".example.com"
    and re-queries.
3) resolver finds IP for mail.example.com and returns it
3) stupid application happy

NEW:
1) some stupid application asks for "mail"
2) same resolver library, now finding mail exists, does not add
    search domain ".example.com" and returns NXDOMAIN. 
3) stupid application fails

No, i do not know how common or uncommon or important/unimportant this
is. We would only know once this fails.

Paul

---

From: David Conrad <[email-masked]>
Date: Wed, 27 May 2015 05:39:34 +0300

<digression>

> dotless names were never contemplated as endpoints, even in the HOSTS.TXT era

Err, what?

All names were dotless in the "HOSTS.TXT era" (well, depending on what you mean by the "HOSTS.TXT era" -- I'm assuming pre-RFC 881) and they were all endpoints.

> the raw

I'd be OK dotless names if there is a mutual understanding of the implications of those name for relevant parties. For example, I think it'd be fun to move the root servers out of root-servers.net and into the root, i.e.:

$ORIGIN .
...
a IN A 198.41.0.4
b IN A 192.228.79.201
...

> look up its AAAA or A by typing it into a web browser, and so on.

Maybe those features are actually desirable. The real issue is expectations. For the vast majority of uses dotless names are simply not an option as there are way too many built-in expectations in pretty much every piece of software that deals with domain names.  However, as mentioned above, there may be cases where there are no expectations (or, the expectations aren't actually necessary -- does any root server operator want someone to try to point their browser at their root server and get something useful back?).

</digression>

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 May 2015 23:10:32 -0700

Francisco Obispo wrote:
>
>> On May 26, 2015, at 3:33 PM, Paul Vixie <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
> This is what I would like to quantify. Those people are probable
> already in a digital squalor and they don’t know it. How can we
> improve that situation?

1. microsoft puts win/xp under f/oss; worldwide team launches bugfix jihad.
2. ITU treaty updated to require SAV; many undersea cables chopped.
3. CPE vendors learn about bufferbloat; FQ-Codel universally deployed.
4. social network industry announces IPv6-only as of December 2016;
worldwide V6 surge.
5. someone somewhere finally reads SAC064; wisdom ensues.

as you know, my list is actually much longer than that 5-item sample.

> I’m not discarding the DITL, it’s one good slice, but there is more
> that we don’t see, perhaps you have access to more information and
> have a more complete picture of it via DNSDB and other systems?
>

well, yes. and if you, as a hobbyist/adventurer, wanted to spend unpaid
time away from your job and family, i'd be very happy to give you access
to the SIE DNS Errors and DNS Changes channels so that you can see what
i see and publish your findings if any.

> There is risk in not doing anything as well, how do balance it?

your question begs for a simplistic answer like "first, do no harm."
however, i think there's a more nuanced view available: most code that
hasn't been upgraded in the last 15 years is on the 50-to-100 year
upgrade cycle, a lot of it is source-code-lost and authors-now-dead.
let's build a new secure V6 network that isolates those older nodes as
harmlessly as possible.

>
> I trust your judgement and respect your contributions, that’s not in
> question, I'm not against reserving some TLDs for local use (said it
> in my first email), my main concern is creating the illusion that by
> reserving those TLDs, we’ve solved the problem and create a false
> sense of safety. This is a multi-variable/multi-dimensional complex
> system, where there are pieces that neither IETF and ICANN have
> control of.

on this, we agree.

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 May 2015 23:20:35 -0700

Paul Wouters wrote:
>    search domain ".example.com" and returns NXDOMAIN. 3) stupid
> application fails
>

i can only repeat what you quoted:

> a rule, so what we're discussing here (your mail.corp.com example) will
 
that is, NOERROR and NXDOMAIN have the same fallback path in the era
you're worried about.

-- 
Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 May 2015 23:49:33 -0700

> All names were dotless in the "HOSTS.TXT era" (well, depending on what you mean by the "HOSTS.TXT era" -- I'm assuming pre-RFC 881) and they were all endpoints.

By RFC 952, there were no dotless names in HOSTS.TXT, even though the
grammar allowed it.

> I'd be OK dotless names if there is a mutual understanding of the implications of those name for relevant parties. For example, I think it'd be fun to move the root servers out of root-servers.net…

i'd really like to see those as A.ROOT-SERVERS, B.ROOT-SERVERS, etc,
where ROOT-SERVERS. was an empty non-terminal (not a delegation point).
so, in-zone, but not dotless. because most of my daily-use tools won't
let me ping "A" or "A." since they are both treated as local names (to
be found in YP/NIS or /etc/hosts or the Windows "hosts" file), and i
like pinging root name servers.

-- 
Paul Vixie

---

From: "John Levine" <[email-masked]>
Date: 27 May 2015 18:56:21 -0000

>Maybe those features are actually desirable. The real issue is expectations. For the vast
>majority of uses dotless names are simply not an option as there are way too many built-in
>expectations in pretty much every piece of software that deals with domain names.

On the other hand, have the data point of about 15 ccTLDs that publish
A or MX records at the TLD.  Some of them have done so for a very long
time.  I'm not saying that it's a wonderful idea to have dotless
names, but they haven't led to disaster yet.

On the third hand, if we do think that no new TLDs should have dotless
names (a reasonal position in my book), last year's argument about
.SEARCH and the recent discussions about .HOME suggest that it's not a
great idea to depend on ICANN policies to be permanent.  In the
argument about changing the policy to allow dotless .SEARCH, from what
I saw, Google's dominance of the search market had at least as much to
do with the outcome as the technical issues. Another application from
an applicant that does not dominate its industry would not necessarily
be resolved the same way.

R's,
John

---

From: Lyman Chapin <[email-masked]>
Date: Wed, 27 May 2015 15:22:21 -0400

> I’m against withdrawing/reserving these names.

Hi Francisco -

We don't know each other, but if I may assume that you work for Uniregistry (apologies if I'm jumping to the wrong conclusion from the domain name in your email address), you have a clear conflict of interest as a gTLD applicant for "home". Your viewpoint and comments are still valuable, and I mean no disrespect when I suggest that you have a conflict; but I hope that when Tim and Suzanne refer to "consensus of the WG" they mean "except for WG participants who have a clear COI".

Your other comments have been taken up by others on the list. The one I find particularly troubling is "how do we balance risk vs. benefits?" I suspect that a lot of our disagreement about delegating these names comes from very different assessments of what the "benefits" might be. Built into the new gTLD program is the assumption that the benefits are enormous - large enough, at any rate, to convince ICANN to set the bar for name collision harm at "Is the issue causing clear and present danger to human life?" (https://forms.icann.org/en/help/name-collision/report-problems). That's in bold-face type, repeated twice on the NC report form. To be fair, ICANN is also willing to take NC seriously "[i]f your system is suffering demonstrably severe harm." But the clear message is that the benefits of a new gTLD outweigh the risk of all but the most grievous consequences to Internet users.

I have yet to hear a disinterested argument that the benefit of delegating corp, home, or mail outweighs the risk of operational instability. Maybe I'm just old school, but my instinct is to err on the side of operational stability unless the benefit of doing otherwise is clear and strong. I don't see that in this case.

Having heard no (disinterested) objection to putting corp, home, and mail in the special-use name registry defined by RFC 6761, perhaps the WG chairs would proceed with a call for adoption of draft-chapin-additional-reserved-tlds-02 -

- Lyman

---

From: Jim Reid <[email-masked]>
Date: Wed, 27 May 2015 20:53:41 +0100

> We don't know each other, but if I may assume that you work for Uniregistry (apologies if I'm jumping to the wrong conclusion from the domain name in your email address), you have a clear conflict…

Indeed. However IMO the question of what hats Francisco (or anyone else) might or might not be wearing does not matter to the consensus view/determination of the WG and its co-chairs.

The usual working definition of consensus is lack of sustained reasonable objection. Francisco has objected but AFAICT has not found support in the WG for his position. The WG should note his objection and proceed.

FWIW RFC7282 says "Rough consensus is achieved when all issues are addressed, but not
necessarily accommodated". I think in this case that rough consensus has been reached. All the issues seem to have been addressed even if the above objection has not been accommodated.

> Having heard no (disinterested) objection to putting corp, home, and mail in the special-use name registry defined by RFC 6761, perhaps the WG chairs would proceed with a call for adoption of draft-chapin-additional-reserved-tlds-02 

+1.

IMO there's a consensus for that view in the WG. So let's get this out the door and move on.

Lyman's instinct to favour operational stability is prudent. I support that PoV.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 May 2015 13:13:29 +1000

> names, but they haven't led to disaster yet.

We have plenty of evidence that when unexpected matches with search
lists happen problems occur.  We have even written RFC due to the
issues.

As for the 15 tlds people can work around the handful of collisions
the 15 ccTLD's caused by not using those labels.  They can't work
around a continually changing list of labels as new TLDs get added
if they put the wrong records there.

---

From: Suzanne Woolf <[email-masked]>
Date: Thu, 28 May 2015 11:17:14 -0400

(no hats, as I haven't discussed with my co-chair and AD.)

> We don't know each other, but if I may assume that you work for Uniregistry (apologies if I'm jumping to the wrong conclusion from the domain name in your email address), you have a clear conflict…

For the reasons pointed out by Jim Reid in the next message, I think this heads in the wrong direction.

Perhaps more to the point, my experience of the IETF suggests that since contending interests are a fact of life, and that WG discussion frequently engages vendors, their competitors, their customers, and their vendors all at once, claims about others' conflicts of interest are a poor substitute for addressing arguments on the merits (which you get full credit for attempting to do, and can stand on its own).

> Having heard no (disinterested) objection to putting corp, home, and mail in the special-use name registry defined by RFC 6761, perhaps the WG chairs would proceed with a call for adoption of draft…

It would be helpful to me in discerning consensus to separate two different concepts here.

1. Delegating home/corp/mail in the root zone would be bad.
2. Adding home/corp/mail to the special-use name registry would be good.

Again, trying my best to speak as a disinterested observer of the discussion, I've seen little support for such delegations(1). I've seen a couple of arguments that seem to have strong support against such delegations.

However, that's not the question in front of the WG. The IETF doesn't decide what goes into the root zone. ICANN does, and appears to have already decided (stipulating that not everyone believes them, which strikes me as a separate problem) not to add those names to the root zone.

The question in front of the WG is whether to propose adding those names to the IETF registry for special-use names(2). I've heard support for that, but I've also heard a number of objections to such additions, and I'm having trouble telling how much the support for (2) is really support for (1) or vice versa.

It remains less than obvious to me what outcome is being sought here. I first thought it was to influence the body that *does* decide what goes into the root zone against a possible future change in policy, but it's also been repeatedly asserted that no, the proposal is motivated by operational considerations.

I realize I may be dim, but what operational impact is sought here?  What change in server or resolver configuration are administrators expected to make? Is there some other possible source of name collisions besides a change in the root zone that we can or should be guarding against? Given that the problem people seem concerned about developed entirely outside of any action by the IETF, how does the IETF acting now help?

I understand the argument that the IETF can and should prevent such a misstep by ICANN, so reiterating it won't help me. 

thanks,
Suzanne

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 28 May 2015 11:34:24 -0400

On 28 May 2015, at 11:17, Suzanne Woolf wrote:

> The IETF doesn't decide what goes into the root zone. ICANN does

The IETF decide what does NOT go into the root zone, while ICANN do decide what goes into the zone.

ICANN can only "delay" their decision of adding things by "not yet" saying "yes".

That's the difference I see.

   Patrik

---

From: Bob Harold <[email-masked]>
Date: Thu, 28 May 2015 13:52:58 -0400

> 2. Adding home/corp/mail to the special-use name registry would be good.

I support "2".

> Again, trying my best to speak as a disinterested observer of the
> discussion, I've seen little support for such delegations(1). I've seen a
> couple of arguments that seem to have strong support against such
> delegations.
>
> However, that's not the question in front of the WG. The IETF doesn't
> decide what goes into the root zone. ICANN does, and appears to have
> already decided (stipulating that not everyone believes them, which strikes
> me as a separate problem) not to add those names to the root zone.
>
> The question in front of the WG is whether to propose adding those names
> to the IETF registry for special-use names(2). I've heard support for that,
> but I've also heard a number of objections to such additions, and I'm
> having trouble telling how much the support for (2) is really support for
> (1) or vice versa.
>
> It remains less than obvious to me what outcome is being sought here. I
> first thought it was to influence the body that *does* decide what goes
> into the root zone against a possible future change in policy, but it's
> also been repeatedly asserted that no, the proposal is motivated by
> operational considerations.
>
> I realize I may be dim, but what operational impact is sought here?  What
> change in server or resolver configuration are administrators expected to
> make? Is there some other possible source of name collisions besides a
> change in the root zone that we can or should be guarding against? Given
> that the problem people seem concerned about developed entirely outside of
> any action by the IETF, how does the IETF acting now help?
>

The operational impact sought here includes changes to software:   "name
resolution APIs and libraries" and "caching domain name server software"
and "authoritative domain name server software" all "SHOULD restrict these
names to local resolution and SHOULD NOT allow queries for strings that use
these Special-Use Domain Names to be forwarded to the public DNS for
resolution."
-- and change to policy: --
"Requests to register any names added to the Special-Use Domain Name
registry as part of the IANA Considerations section of this document MUST
be denied."

>
> I understand the argument that the IETF can and should prevent such a
> misstep by ICANN, so reiterating it won't help me.
>
> thanks,
> Suzanne
>
>
-- 
Bob Harold

---

From: "John Levine" <[email-masked]>
Date: 28 May 2015 19:16:47 -0000

>2. Adding home/corp/mail to the special-use name registry would be good.

I think we should do 2.

R's,
John

PS: I agree with comments that while 1 is true, it's not directly our
department.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 29 May 2015 09:48:01 +1000

In message <[email-masked]>, Suzanne Woolf writ
es:
> > We don't know each other, but if I may assume that you work for Uniregistry
>  (apologies if I'm jumping to the wrong conclusion from the domain name in yo
> ur email address), you have a clear conflict of interest as a gTLD applicant 
> for "home". Your viewpoint and comments are still valuable, and I mean no dis
> respect when I suggest that you have a conflict; but I hope that when Tim and
>  Suzanne refer to "consensus of the WG" they mean "except for WG participants
>  who have a clear COI".
> 
> Perhaps more to the point, my experience of the IETF suggests that since cont
> ending interests are a fact of life, and that WG discussion frequently engage
> s vendors, their competitors, their customers, and their vendors all at once,
>  claims about others' conflicts of interest are a poor substitute for address
> ing arguments on the merits (which you get full credit for attempting to do, 
> and can stand on its own).
> 
> > Having heard no (disinterested) objection to putting corp, home, and mail i
> n the special-use name registry defined by RFC 6761, perhaps the WG chairs wo
> uld proceed with a call for adoption of draft-chapin-additional-reserved-tlds
> -02 -
> 

Can we please stop lumping home/corp/mail as if they need / should
have the same solution.  There presence at the root is clearly the
result of different reasons.  How we deal with there presence at
the root should be different because of that.

The solution space is also much more nuanced that this.

> 1. Delegating home/corp/mail in the root zone would be bad.

Delegating to WHAT would be bad?

* A registry - yes.
* A unsigned empty zone - no.  This breaks the DNSSEC chain of trust
  which would be good for home users as they don't generally already
  have a namespace, not really needed for corporations as they
  should be using a part of their own namespace and does nothing
  for mail as those queries are usually just the label itself.

> Again, trying my best to speak as a disinterested observer of the discussion,
>  I've seen little support for such delegations(1). I've seen a couple of argu
> ments that seem to have strong support against such delegations.
> 
> However, that's not the question in front of the WG. The IETF doesn't decide 
> what goes into the root zone. ICANN does, and appears to have already decided
>  (stipulating that not everyone believes them, which strikes me as a separate
>  problem) not to add those names to the root zone.
> 
> The question in front of the WG is whether to propose adding those names to t
> he IETF registry for special-use names(2). I've heard support for that, but I
> 've also heard a number of objections to such additions, and I'm having troub
> le telling how much the support for (2) is really support for (1) or vice ver
> sa.
> 
> It remains less than obvious to me what outcome is being sought here. I first
>  thought it was to influence the body that *does* decide what goes into the r
> oot zone against a possible future change in policy, but it's also been repea
> tedly asserted that no, the proposal is motivated by operational consideratio
> ns.
> 
> I realize I may be dim, but what operational impact is sought here?  What cha
> nge in server or resolver configuration are administrators expected to make? 
> Is there some other possible source of name collisions besides a change in th
> e root zone that we can or should be guarding against? Given that the problem
>  people seem concerned about developed entirely outside of any action by the 
> IETF, how does the IETF acting now help?
> 
> I understand the argument that the IETF can and should prevent such a misstep
>  by ICANN, so reiterating it won't help me. 
> 
> 
> thanks,
> Suzanne
>

---

From: Lyman Chapin <[email-masked]>
Date: Thu, 28 May 2015 21:38:06 -0400

> For the reasons pointed out by Jim Reid in the next message, I think this heads in the wrong direction.

Yes, I agree; I reacted inappropriately when it appeared that the only "don't reserve these names" comment came from someone who works for Uniregistry. Apologies to the WG.

> 2. Adding home/corp/mail to the special-use name registry would be good.

I agree that these are different assertions, but they are not assertions about different concepts. (1) expresses the risk of instability associated with changing the way in which specific TLD names that have become deeply embedded in existing practices are resolved by the global DNS. (2) refers to the suitability, or optimality, of a specific mechanism for dealing with (1). If you are setting these up as if (1) is the purview of ICANN, and (2) is the purview of the IETF, then I think that you are creating a false dichotomy.

I'm of course aware that not everyone likes the mechanism created by 6761, and not everyone thinks that the 6761 mechanism is the best way to accomplish the goal of permanently preventing specific strings from being delegated as TLD names. (I also recognize Mark's "delegating to WHAT?" - there's a lot of detail lurking behind the language we've been using to discuss this, and yes, those details are different for corp, home, and mail, which have been bundled as if they were equivalent.) But this is the tool that we have, so it's the tool we've used.

> However, that's not the question in front of the WG. The IETF doesn't decide what goes into the root zone. ICANN does, and appears to have already decided (stipulating that not everyone believes th…

I believe that your effort to frame the question as "who decides what goes into the root zone?" is misguided. ICANN's decisions about which new gTLDs to allow into the root are policy decisions - the new gTLD program is an enormous policy machine designed and operated specifically for this purpose. The IETF's interest in operational stability is orthogonal to ICANN's policy machinery. As John says, the IETF can say "this specific string must not be a TLD name" because it would destabilize the operating Internet without infringing ICANN's privilege to operate its policy machinery with respect to gTLDs in general.

I'm bewildered by your repeated assertion that the problem with ICANN's decision "not to add those names to the root zone" is that "not everyone believes them" - as if it were simply a matter of trust. It's not. ICANN's decision, which I trust completely, is a *policy* decision. A 100% trustworthy policy decision can be changed, with no forfeiture of trust, if the policy on which it is based changes. ICANN's processes and criteria for policy development and change are different from those of the IETF. Not better, or worse, or more believable, or less believable - just different.

> The question in front of the WG is whether to propose adding those names to the IETF registry for special-use names(2). I've heard support for that, but I've also heard a number of objections to su…

I haven't heard objections to (2); but as I've already said, (2) concerns the use of an IETF Proposed Standard mechanism to deal with (1), so I don't understand the distinction implied by "(2) is really support for (1)" - ?

> It remains less than obvious to me what outcome is being sought here.

The addition of three names to the special-use name registry defined by RFC 6761 :-) Sorry, couldn't resist...

> I first thought it was to influence the body that *does* decide what goes into the root zone against a possible future change in policy, but it's also been repeatedly asserted that no, the proposal is motivated by operational considerations.

See below; I don't agree with the way in which you are framing the question.

> I realize I may be dim, but what operational impact is sought here?  What change in server or resolver configuration are administrators expected to make? Is there some other possible source of name…

None of those questions is relevant to the request to proceed with a call for adoption of draft-chapin-additional-reserved-tlds-02.

> I understand the argument that the IETF can and should prevent such a misstep by ICANN, so reiterating it won't help me. 

I don't think that the IETF can or should be in the business of trying to prevent an ICANN misstep. That's not what this is about. The point of an IETF decision to add corp, home, and mail to the special-use names registry would not be "to guarantee that no future ICANN policy change could lead to their delegation as TLD names." It would be to permanently reserve them for the special uses to which they have already been put (a fact on the ground, not a value judgement about whether they "should" or "should not" have been put to those uses), thereby preventing the unstable consequences of delegating them as gTLDs. It's not about ICANN - it's about the interest of the IETF in operational stability.

- Lyman

---

From: Rubens Kuhl <[email-masked]>
Date: Fri, 29 May 2015 09:34:40 -0300

> The question in front of the WG is whether to propose adding those names to the IETF registry for special-use names(2). I've heard support for that, but I've also heard a number of objections to su…

It's also of notice that the support level for doing $something (for some value of $something) with 2 of those strings (home and corp) are higher than the support level for one of those strings (mail). 

Rubens