Subject: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

From: Alain Durand <[email-masked]>
Date: Tue, 8 Mar 2016 14:09:12 +0000

Dear wg,

draft-adpkja-dnsop-special-names-problem-01 has been posted today. It is
available at:

https://www.ietf.org/internet-drafts/draft-adpkja-dnsop-special-names-proble
m-01.txt

It is an individual submission, not a working group item. It reflects the
discussions the initial 3 authors have had so far. Also, Warren Kumari
provided lots of input and generously contributed significant amount of
text. In the tradition of IETF recognizing contributions, we have added
Warren to the author list.

The authors know that the subject addressed in this document is
controversial. We hope it will help clarify the discussion. In many places,
we know different opinion exits. We have tried to reflect the existence of
those opposition views to the best of our possibilities.

We would like to see discussion of those views in the mailing list to help
us prepare the next version of this draft with the goal to ask the working
group to adopt it.

Best,

Alain, on behalf of the document authors.

---

From: Bob Harold <[email-masked]>
Date: Wed, 9 Mar 2016 16:19:21 -0500

On Tue, Mar 8, 2016 at 9:09 AM, Alain Durand <[email-masked]> wrote:

> https://www.ietf.org/internet-drafts/draft-adpkja-dnsop-special-names-problem-01.txt
>
>

Minor nits:

2.  Introduction
first bullet point ends with:
"any application which takes exiting DNS names."
s / exiting / existing /

7.  Security Considerations
middle of second paragraph
"will garantee that such leakage will not happen."
s / garantee / guarantee /
But should it be "not guarantee" ?

-- 
Bob Harold

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 14 Mar 2016 15:09:13 +0100

On Tue, Mar 08, 2016 at 02:09:12PM +0000,
 Alain Durand <[email-masked]> wrote 
 a message of 207 lines which said:

> draft-adpkja-dnsop-special-names-problem-01 has been posted today.

[One warning: I think the entire idea is bad. There is no "problem" to
solve, we have RFC 6761 and it works (it worked for Apple, it can work
for free software like GNUnet). I do not object to an effort to create
a 6761-bis, addressing lacks like the absence of a mailing list
designated to review the proposals like it exists for URI schemes,
media types, etc.]

> controversial. We hope it will help clarify the discussion. In many
> places, we know different opinion exits. We have tried to reflect
> the existence of those opposition views to the best of our
> possibilities.

I cannot say it was successful... Quite the contrary, the draft tries
to do too much, by mentioning everything the authors can think about
against RFC 6761, sometimes without a serious evaluation. An example
is mentioning that Tor is a non-IETF protocol, as if it should make
any difference.

> This means that these names can be entered in any application which
> takes exiting DNS names.

The draft speaks sometimes of DNS names, sometimes of domain names,
and does not explain if there is a difference. Clearly, a DNS name
uses the DNS so 7j3ncmar4jm2r3e7.onion is *not* a DNS name (it is a
domain name). [I agree with Paul Hoffman that a section explaining the
difference, and the constraints on DNS names, would be useful.]

> More over, the answers to the seven questions are not available in a
> machine readable form to applications that want to follow [RFC6761].

It's funny, it is one of the few points where there is clearly
something lacking in RFC 6761 and it just deserves one sentence. I
would prefer to see dnsop working on addressing this issue, than on
trying very hard to close to door to new TLDs.

> The discussions in the DNSOP WG and the IETF Last Call processes
> about the .onion registration in the Special Use Domain Names
> registry (1,200 messages) have made it apparent that clarity about
> if and how to treat this "protocol switching" practice would help a
> lot

I don't think the number of messages is a good metric. The issue is
hot because names are sensitive and because of the heavy
politicization of the subject, this is why there have been so many
messages, not because RFC 6761 is not clear.

> What is missing in [RFC6761] is the consideration of the name
> itself.  If one were to contrast the procedures relating to the
> admission of a name to the IETF Special Use Name registry to the
> processes associated with the New gTLD Program operated by ICANN,
> then it is evident that the IETF process does not admit many
> considerations which appear to be areas of evaluation in the new
> gTLD program.

I would not mention the ICANN processes as an example, far from
it. "ICANN has a heavy and political and complicated process for this,
so we must not attempt to do it if we don't have such a process."

> They refer to bad precedents such as .uucp and .bitnet.

In what way were there "bad"? Instead of labelling software with such
terms, one should explain, and draw real lessons from
experience. .bitnet and .uucp were big successes, the software behind
it disappeared but they were not "bad".

> For example, is large scale prior deployment an acceptable criteria?
> A number of voices have clearly answered "no" to that question as it
> would only encourage "squatting" on names.

The draft carefully forgets to mention that many people objected to
.gnu, .zkey and .i2p on the basis of insufficient deployment. People
outside of the IETF who brings things to the IETF receive an extremely
unfriendly welcome, with strong requirments to do one thing and its
complete opposite.

> String similarity ICANN has an entire process for evaluating the
> string similarity / confusability between applied for (and current)
> strings

Which is a complete failure (such as Eurid being refused a name under
the pretext that it collides with a name... which is not even
delegated.) Good thing it does not exist at
IETF. https://centr.org/system/files/agenda/attachment/ga55-seppia_idn_delegation-20160217.pdf
https://centr.org/system/files/agenda/attachment/ga51-seppia-similarity_perception_at_icann-20140313.pdf
http://domainincite.com/17538-bulgaria-and-greece-win-idn-cctlds-on-appeal

> However, it should be noted that, if the IETF were to formalize the
> concept of protocol/name switch in the Internet architecture,
> coordination would be require between ICANN and IETF on such names.
> Using the analogy described above of a catalog/registry of such
> switches, care must be taken to make sure we do not end up with 2
> process streams allowed to create entries without any
> synchronization.

This is probably one of the weakest arguments. The processes of ICANN
and IETF are slow, very slow. And a good part of them is public. And
many people follow both (and we have a formal liaison to ICANN). The
risk of a collision (between an ICANN delegation and an IETF
reservation) is nil. 

These were remarks on the actual text. There is also something
completely missing: whatever we decide, people will deploy new TLD. We
will have to live with it, anyway. (Someone at the IESG during the
.onion decision said "we must make our processes work for the
Internet, not the other way around". Internet is permission-less and
this is a good thing.)

Now, the technical issues:

> The names can follow the common DNS syntax of LDH labels,

The DNS does not restrict labels to LDH.

And the editorial ones:

> the reserved names could be any label in any random string, not just
> the rightmost

Last, not rightmost (some scripts are right-to-left). I know, the RFC
are in english, that's why I put that under "Editorial", not
"Technical".

> would be require

Would require or would be required?

---

From: Ralph Droms <[email-masked]>
Date: Fri, 25 Mar 2016 11:33:57 -0400

I'm responding here with none of my various hats on...

Here's the tl;dr version.  This document has some useful information and raises, directly and indirectly, some important questions that the IETF should consider.  Unfortunately, those useful bits are buried in a polemic that is directed toward a specific outcome.  If this document is accepted as a WG document, I strongly suggest that it be heavily edited to extract and emphasize the useful text and discard the rest.

If you're still reading...

Let me start with the fundamental difference I have with one of the key pre-conclusions of this document.  In my opinion, RFC 6761 and the Special-Use Domain Names registry meet the requirement of a complete and useful way to record and make available information about domain names designated to be special use.  Section 4 of RFC 6761 explicitly leaves the identification of special use names to "Standards Action" or "IESG Approval".  I've made several comments below in which I think the distinction is important for the accuracy and authority of draft-adpkja-dnsop-special-names-problem.

The document does identify some key questions the IETF should
consider:
* does the IETF want to formally sanction protocol switching based on
  the last label?
* should the IETF coordinate the designation of special-use domain
  names with other bodies such as ICANN; if so, how?
* does the IETF want to specify a more formal review process for the
  designation of special-use domain names?

I think this document would be greatly strengthened and far more helpful to the dnsop WG and the IETF if it included a clear identification of a list of specific problems that have been encountered with the review and publication of documents that define special use names in the past, and that might be encountered in the future.  Citations of mailing list discussions that lead to the identification of the specific problems would be a real plus.

Finally, I think the document would be strengthened by editing out text on solutions and editing down the text to state and motivate the problems directly and succinctly.

Specific comments, more or less in the order of appearance in draft-adpkja-dnsop-special-names-problem-02:

Abstract

   The dominant protocol for name resolution on the Internet is the
   Domain Name System (DNS).  However, other protocols exist that are
   fundamentally different from the DNS, and may or may not share the
   same namespace.

RD>> I think the problem is actually broader than just other
protocols.  We have a namespace that is primarily used for names
intended for resolution through DNS, but, as recorded in RFC 6761,
there are parts of the namespace that are handled in special ways.

   When an end-user triggers resolution of a name on a system which
   supports multiple, different protocols (or resolution mechanisms) for
   name resolution, it is desirable that the protocol used is
   unambiguous, and that requests intended for one protocol are not
   inadvertently answered using another.

RD>> editorial: too much detail for an abstract?

   RFC 6761 introduced a framework by which, under certain
   circumstances, a particular domain name could be acknowledged as
   being special.  This framework has been used twice to reserve top-
   level domains (.local and .onion) that should not be used within the
   DNS, to avoid the possibility of namespace collisions in parallel use
   of non-DNS name resolution protocols.

RD>> I disagree with this characterization of RFC 6761, which provides
an explicit registry for behaviors that are specified in other
documents for special handling.  My view of the process defined in RFC
6761 is that an RFC is published that describes the special use for
part of the domain namespace.  The decision about whether to
standardize that use is implicitly part of the RFC publication
process.  Once the decision is made to publish the RFC, the effects of
the standardized use of the subset of the namespace is recorded in the
RFC 6761 registry.

   Various challenges have become apparent with this application of the
   guidance provided in RFC 6761.  This document aims to document those
   challenges in the form of a problem statement, to facilitate further
   discussion of potential solutions.

RD>> I would phrase the problem as challenges in the process of
reviewing documents that would standardize special uses of names from
the domain name space.

RD>> Editorial nit: the Introduction is usually the first section of
the body of the document.

RD>> In 2. Introduction, and I'm sorry to be repeating myself, in my
opinion RFC 6761 records the special uses of some domain names, as
approved for publication as an Internet Standard.  I'll also repeat
myself that RFC 6761 describes other alternative special handling
aside from protocol switches.  That alternative special handling must
be considered carefully at the time of publication of the defining
RFC, regardless of the nature of the special use.

RD>> Also in the Introduction:

   The framework in [RFC6761] has recently been used to reserve the
   .onion label, allowing it to be used as a switch to the Tor
   resolution process, as described in [RFC7686].  Because the .onion
   label in the IANA "Special-Use Domain Names" registry
   [IANA-SPECIAL-USE], the Tor Project can be assured that there will
   not be a .onion TLD created in the IANA rooted DNS, and thus the
   possibility of collisions in the namespace will be avoided.

RD>> I think it's more correct to write that RFC 7686 defines ".onion"
as a Special-Use Domain Name, which takes it out of the Domain Name
space.  This designation is then recorded in the Special-Use Domain
Names registry, according to RFC 6761.

RD>> I disagree with the premise of the paragraph in section 3 that begins:

   The intent of those seven questions was originally to serve as the
   justifications for why a proposed special-use registration should be
   granted [...]

RD>> The intent from the beginning was to provide guidance as to what
should be written in the registry.  The justification is to be written
as a separate part of whatever RFC defines the registry entries.  The remainder of this paragraph really needs explicit support for the conclusions drawn about the special-use name designation process, or the conclusions should be clearly labeled as the opinions of the authors.

RD>> In 4. Architectural Considerations:

   At the time of writing, two top-level domain names reserved by
   inclusion in the Registry went through the [RFC6761] process [...]

For completeness, there are actually several names that have been
recorded in the Special-Use Domain Names registry as defined in RFC
6761.  Other top-level domain names in the registry include:

.example
.invalid
.localhost
.test

In addition, there are a couple of names designated for special use
that remove them from the available DNS Names space:

.example.com
.example.net
.example.org

Another name, ipv4only.arpa, has been designated a special-use name in
RFC 7050 (although it doesn't yet appear in the Special Use Names
registry).

Finally, draft-chapin-additional-reserved-tlds proposed the
designation of .home, .corp and .mail as special-use domain names.
The dnsop WG reviewed the draft and chose not to proceed with
publication of an RFC to so designate those names.

RD>> Also in section 4:

   In particular, DNS imposes constraints on name syntax.  An example of
   such constraints is the 63 octet limit per label.  Strings used in
   the .onion domain do not have that constraint.

This statement could use some explanation about the impact of the
observation; otherwise, I don't understand the relevance.

RD>> Similarly, why are .uucp and .bitnet "bad precedents"?

RD>> Regarding "building a catalog of all top level domains and what
resolution protocol each one invokes [...]", this argument is, in my
opinion, specious.  I think the common assumption is that everything
not lised in the Special-Use Domain Names registry is in the DNS name
space, which would make the Registry a complete catalog.  If I'm
wrong, seems like a pretty simple issue to fix.

RD>> I have to say I simply don't understand the discussion about
"expectations" in section 5.  Section 2 of RFC 7686 describes how
namnes ending in .onion should be processed.  It is, of course,
possible that names ending in .onion may be sent over the Internet by
non-compliant implementations.  That sort of expectation comes along
with any protocol that may encounter non-compliant implementations.
If there is a special concern, about a particular type of name, that
concern can be expressed in the defining RFC.  I don't see how every
possible failure case can be anticipated in the Registry, nor do I see
such a requirement placed on any other IETF protocols.

RD>> From Section 5:

   "[...] the [RFC6761] registry does not include
   direct guidance for any of the seven audiences, relying instead upon
   a reference for each entry in the Registry to the document that
   requested its insertion."

RD>> This argument is specious, as well.  It is common practice to
point at an RFC for information about a particular registry entry, to
avoid confusion and transcription errors inherent in putting redundant
text in the registry.  In the case of the Special-Use Domain names
registry and RFC 6762, there is no expectation that all of RFC 6762
needs to be read to understand the details of the special-use
designation.  Section 22.1, "Domain Name Reservation Considerations,
gives concise answers to the relevant questions from RFC 6761.

RD>> In section 6.1:

   [RFC2860] draws a line between what is policy and what is technical.
   A variety of opinions have been expressed regarding whether [RFC6761]
   blurs this line.  In particular, [HUSTON] has one viewpoint on the
   topic.  As noted earlier, it is out of scope for this document to
   analyse this issue beyond noting that such a variety of views
   exist.

RD>> Any reason not to include some of those other views, here,
especially views different from the views epressed in [HUSTON]?  Seems
like pretty selective reporting to me.

RD>> In response to section 6.2.*: again, in my opinion, RFC
6761 did not attempt to put any approval or designation process in
place beyond the explicit "an IETF 'Standards Action' or 'IESG
Approval' document".  So, RFC 6761 does not expect that the questions
for the registry would be the way in which a request for designation
as a special-use name would be evaluated.  Rather, each request was
left to be evaluated on a case-by-case basis through the normal IETF
Standards Action publication process.  By design, RFC 6761 makes no
statement about a specific WG or evaluation body or process.  One of
the key questions the IETF needs to consider is whether more formal
process is needed; if so, the IETF can design and publish a
description of that process.

> On Mar 8, 2016, at 9:09 AM 3/8/16, Alain Durand <[email-masked]> wrote:
> 
> Dear wg,
> 
> draft-adpkja-dnsop-special-names-problem-01 has been posted today. It is available at:
> https://www.ietf.org/internet-drafts/draft-adpkja-dnsop-special-names-problem-01.txt <https://www.ietf.org/internet-drafts/draft-adpkja-dnsop-special-names-problem-01.txt>
> 
> It is an individual submission, not a working group item. It reflects the discussions the initial 3 authors have had so far. Also, Warren Kumari provided lots of input and generously contributed significant amount of text. In the tradition of IETF recognizing contributions, we have added Warren to the author list.
> 
> The authors know that the subject addressed in this document is controversial. We hope it will help clarify the discussion. In many places, we know different opinion exits. We have tried to reflect the existence of those opposition views to the best of our possibilities.
> 
> We would like to see discussion of those views in the mailing list to help us prepare the next version of this draft with the goal to ask the working group to adopt it.
> 
> Best,
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: David Conrad <[email-masked]>
Date: Fri, 25 Mar 2016 10:04:12 -0700

Ralph,

> I'm responding here with none of my various hats on...

Me too.

> space.

No.  It is still a domain name in the sense that it is within the universe of identifiers under a singly rooted namespace used on the public Internet (the "domain name namespace").  What it is not is a part of the subset of that namespace that is resolved using the DNS protocol/infrastructure.

> RD>> Similarly, why are .uucp and .bitnet "bad precedents"?

They are bad precedents because of the challenges they caused for network operations. Specifically, the fact that they were local policy considerations meant that references to a .bitnet or .uucp name within one administrative domain would work but would fail when that reference escaped that administrative domain (e.g., in a cc line of an email address). In my view, this is essentially the same problem that led to the IAB publishing 2826. One of my concerns with 6761 is that it can encourage recreating that operationally challenging world without explaining the inherent risks.

> I think the common assumption is that everything
> space, which would make the Registry a complete catalog.

I disagree. I believe the domain name namespace can be broken down into:

1. In the DNS (exists within the root zone)
2. Not in the DNS (exists within the special use registry)
3. Not defined (everything else)

The primary issue I have with 6761 is that while it is relatively clear who the authority is for (1) and (2), it does not provide a clear answer about the authority for (3) or how a name gets put into (1) or (2) when taken in the context of 2860, section 4.3.

> By design, RFC 6761 makes no
> statement about a specific WG or evaluation body or process.

Which is, of course, one of the key problems. It results in an undefined decision process dependent on the individual subjective evaluation of IESG members.  Given the economic, political, and social implications of the naming hairball, this seems like a really bad idea to me.

Regards,
-drc
(speaking only for myself)

---

From: Ralph Droms <[email-masked]>
Date: Fri, 25 Mar 2016 13:48:33 -0400

Thanks for the quick followup, David...

> On Mar 25, 2016, at 1:04 PM 3/25/16, David Conrad <[email-masked]> wrote:
> 
> Ralph,
> 

Yes, you're right.  I understand and actually meant to write what you wrote...

> They are bad precedents because of the challenges they caused for network operations. Specifically, the fact that they were local policy considerations meant that references to a .bitnet or .uucp n…

Thanks for that explanation.  I think it would be helpful to include it in any future revs of the problem statement.

> The primary issue I have with 6761 is that while it is relatively clear who the authority is for (1) and (2), it does not provide a clear answer about the authority for (3) or how a name gets put i…

OK, I agree with your 3 categories.  I think you elaborated on the observation about authority for (3) and process for moving a name to (1) or (2) below...

> Which is, of course, one of the key problems. It results in an undefined decision process dependent on the individual subjective evaluation of IESG members.  Given the economic, political, and soci…

It is certainly a key issue and I hope we can get a focused discussion going about whether there is consensus that a more well-defined decision process is needed and, if so, what are the specifics of that process.

- Ralph

---

From: Alain Durand <[email-masked]>
Date: Fri, 25 Mar 2016 20:32:02 +0000

> On Mar 25, 2016, at 1:48 PM, Ralph Droms <[email-masked]> wrote:
> 
>>> 

Let me speak here solely as a long time (20+ year) IETF participant that has been through successes and failures of this organization.
IMHO, a "more well-defined decision process" would not help, as I would argue that the IETF (and the IESG as well) is ill-equipped
to wade in the political/economic/social space tied to policies evaluating which names are OK to reserve and which ones are not.
My applies to any names, being “special" or not.

RFC2860 section 4.3 recognized this inadequacy very clearly:
"Two particular assigned spaces present policy issues in addition to the technical considerations specified by the IETF:
the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU.”

At the end of the day, this is the key issue in 6761.

Alain.

---

From: "Paul Hoffman" <[email-masked]>
Date: Fri, 25 Mar 2016 18:37:48 -0700

> I'm responding here with none of my various hats on...

As are we all. (Or, in some of our cases, wearing none of our 
organization's jaunty logos...)

> Here's the tl;dr version.  This document has some useful information 
> and raises, directly and indirectly, some important questions that the 
> IETF should consider.  Unfortunately, those useful bits are buried in 
> a polemic that is directed toward a specific outcome.  If this 
> document is accepted as a WG document, I strongly suggest that it be 
> heavily edited to extract and emphasize the useful text and discard 
> the rest.

Understood. However, you said one very significant thing to support that 
view that is factually incorrect, and goes to the heart of what I read 
as a motivator for the longer list of problems in 

> the standardized use of the subset of the namespace is recorded in the

But that's *not* what RFC 6761 says. Instead, it says:
    If it is determined that special handling of a name is required in
    order to implement some desired new functionality, then an IETF
    "Standards Action" or "IESG Approval" specification [RFC5226] MUST 
be
    published describing the new functionality.
Both an IETF "Standards Action" and an "IESG Approval" require IETF 
consensus; RFC publication does not. My reading of the extensive list of 
problems in draft-adpkja-dnsop-special-names-problem is that most of 
them stem from lack of IETF consensus. Both the WG Last Call and IETF 
Last Call on .onion were contentious and were possibly moved forward 
more due to exhaustion than actual consensus (see RFC 7282).

Personally, I don't find listing the problems that came out during those 
consensus calls a "polemic", but you might.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 25 Mar 2016 22:16:09 -0400

Hi,

Since we're making disclaimers, ObDisclaimerPersonalViews.

> My applies to any names, being “special" or not.

I don't think I understand why.  

I think it is plain that a name that is actually somehow implicated in
the existing root policies (in which I would include names that are
excluded under some ICANN policy) are just not candidates for 6761
reservation, and I would expect the necessary consensus involved to
ensure that happens.  (If we don't believe that the necessary IETF
consultations would prevent such a mistake, then we have much bigger
problems than 6761.  Our entire standards process is in trouble.)  It
would also obviously include any names that were part of an ICANN
application for a new TLD.  (This is why I didn't feel comfortable
using 6761 to reserve home and corp, without ICANN's explicit decision
to reject the applications in question and permanently set the names
aside.  I agree that we don't want the special-use registry to become
a stealth way to solve political problems in ICANN's world.)

So the question is whether we have to worry about cases outside those.
I don't know what the political/economic/social space is in that case.
For we're talking about names that people have had the opportunity to
try to claim, but have not done.  So what problem do you think you're
trying to avoid?

On the flip side, if there is some technical use that means a domain
needs to have special use, that is a positive reason for the IETF to
proceed with its own standards-setting procedures, so long as there is
no conflict with ICANN's root zone activities.

> the assignment of domain names, and the assignment of IP address blocks. These policy issues are outside the scope of this MOU.”

I think you will find that the _very next paragraph_ in that RFC says,

   Note that (a) assignments of domain names for technical uses (such as
   domain names for inverse DNS lookup), (b) assignments of specialised
   address blocks (such as multicast or anycast blocks), and (c)
   experimental assignments are not considered to be policy issues, and
   shall remain subject to the provisions of this Section 4.

The question is whether the 6761 cases fall under "assigment of domain
names for technical uses".  To me, the various questions in 6761
suggest that the answer is "yes", but you might disagree.

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Fri, 25 Mar 2016 22:54:48 -0400

> On Mar 25, 2016, at 9:37 PM 3/25/16, Paul Hoffman <[email-masked]> wrote:
> 
> As are we all. (Or, in some of our cases, wearing none of our organization's jaunty logos...)
> 
> Understood. However, you said one very significant thing to support that view that is factually incorrect, and goes to the heart of what I read as a motivator for the longer list of problems in draft-adpkja-dnsop-special-names-problem. You say:
> 
>   "Standards Action" or "IESG Approval" specification [RFC5226] MUST be

You are right.  I wrote imprecisely and reviewed what I wrote hastily.  I would have been more correct to simply quote that text from RFC 6761, and point out that RFC 6761 leaves the process for determining that a name is to be designated as a special-use name as implicitly out of scope.

> Both an IETF "Standards Action" and an "IESG Approval" require IETF consensus; RFC publication does not.

I agree and it's an important point that the process of designating a name for special use requires IETF consensus, which implies IETF review and discussion of any potential designation.  It was a point I was trying to make but made badly.  Thanks for the clarification.

> My reading of the extensive list of problems in draft-adpkja-dnsop-special-names-problem is that most of them stem from lack of IETF consensus. Both the WG Last Call and IETF Last Call on .onion were contentious and were possibly moved forward more due to exhaustion than actual consensus (see RFC 7282).
> 
> Personally, I don't find listing the problems that came out during those consensus calls a "polemic", but you might.

I'll agree to disagree with you on this point.

- Ralph

---

From: David Conrad <[email-masked]>
Date: Fri, 25 Mar 2016 20:29:24 -0700

Andrew,

On Mar 25, 2016, at 7:16 PM, Andrew Sullivan <[email-masked]> wrote:
> ensure that happens.

Sorry, how is it "plain"?

Is it plain that (say) GNU is/is not a candidate for 6761?  Given https://gnunet.org/gns and the purported interest of folks involved in that project to use 6761, what is supposed to happen if the folks at http://www.gnu.com decided to pursue a brand TLD in the next round?  If the folks at https://onion.coop or http://www.theonion.com had applied for a brand TLD in the last round, what would the TOR folks have done?

> try to claim, but have not done.

I don't think so: this appears to assume a one-time event.

At the highest level, perhaps what we're talking about is what characterizes "technical use" sufficient to justify application of 2860 4.3(a).

Thanks,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 26 Mar 2016 14:17:49 -0400

> Sorry, how is it "plain"?

If a name is already somehow implicated in those policies, I should
hope everyone agrees that the IETF and IESG are sane enough not to try
to reserve something in competition with it.  If we don't agree about
that, then I think we have big troubles in general.

> Is it plain that (say) GNU is/is not a candidate for 6761?

As far as I know, right now ICANN's policies have nothing to say about
the string "gnu" in the top level.  So for that reason, if it were
necessary for some other technical reason it doesn't seem it would be
a problem under 6761.  (If I'm wrong about ICANN's policies, then that
changes my view.  That's the sort of evaluation work I'd expect to
happen if we had such a proposal that seemed likely to proceed.  But
this is precisely, for instance, the argument I've made repeatedly in
dnssd and homenet about the proposal to use a "home" pseudo-tld in
parallel with "local".  We shouldn't do it because it's already
implicated elsewhere.)

> Given https://gnunet.org/gns and the purported interest of folks involved in that project to use 6761, what is supposed to happen if the folks at http://www.gnu.com decided to pursue a brand TLD in the next round?  If the folks at https://onion.coop or http://www.theonion.com had applied for a brand TLD in the last round, what would the TOR folks have done?
>

It sure sounds to me like the long-ago accession to trademark
interests in the DNS is coming back to bite us, dunnit?
 
> At the highest level, perhaps what we're talking about is what characterizes "technical use" sufficient to justify application of 2860 4.3(a).

Yes, I think that's right.  It seems obvious to me that both local and
onoin met that test, because they both have a function of triggering
software to do something.  I cannot say that I like this design
pattern, but it is well-established and it is clearly a technical
function.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Sat, 26 Mar 2016 16:12:42 -0700

Andrew,

> that, then I think we have big troubles in general.

Sorry, I'm confused. What policies are you talking about? AFAIK, the strings "GNU", "ZKEY", "BIT", etc., all fall within the ICANN policies defined within the current AGB and thus would have been allocatable should anyone have bothered. Similarly, ONION fell within those same policies.

> the string "gnu" in the top level.

AFAIK, ICANN's policies say it is allocatable in the next round if someone (one/all of the number of folks with the GNU trademark in particular) wants to apply for it.

> So for that reason, if it were
> a problem under 6761.

I may be wrong, but I believe the folks behind GNS would argue that pretty much the same reason ONION was put into the Special Use registry would be the reason it should be put into the Special Use registry.

> interests in the DNS is coming back to bite us, dunnit?

I recall back in the IAHC days circa 1996 or so David Mayer stating that "that ship had sailed" when a number of people argued that trademarks shouldn't be mixed with domain names. I don't believe that particular ship has unsailed in the 20 years since then. That spilt milk has long since spoiled, evaporated, and the milk solids have turned to dust and blown away so crying over it isn't going to help.

> software to do something.

If that's your criteria, then how do any of the others that were proposed earlier not fit?  Or are you saying they do fit and should be put into the Special Use registry before the next round?

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 26 Mar 2016 23:30:49 -0400

On Sat, Mar 26, 2016 at 04:12:42PM -0700, David Conrad wrote:

> Sorry, I'm confused. What policies are you talking about? AFAIK, the
> strings "GNU", "ZKEY", "BIT", etc., all fall within the ICANN
> policies defined within the current AGB and thus would have been
> allocatable should anyone have bothered. Similarly, ONION fell
> within those same policies.

Aha.  We're tripping over the term "policy".  I should have used
something else.  My point is that ICANN's responsibility extends to
those things that are implicated in root zone policy.  I think that
the implication obviously includes everyhing actually in the root
zone, anything ICANN has in fact developed specific policy about (such
as, say, everything in
https://www.icann.org/sites/default/files/packages/reserved-names/ReservedNames.xml,
which ain't hardly a short list), and so on.
 
> I may be wrong, but I believe the folks behind GNS would argue that
> pretty much the same reason ONION was put into the Special Use
> registry would be the reason it should be put into the Special Use
> registry.

I agree.  I have previously argued that the GNS case is less plausible
because it creates a parallel resolution context with no practical
difference except that it cuts the IANA-root tree out of the game.  In
other words, it is a technical solution only to a politico-economic
problem, without any additional technical consequences. For that
reason, IMO, the registration would be an attempt to abuse the
technical functions registry for what are in fact political ends.
Were I to be convinced that the GNS use had even a single technical
advantage to recommend it over the DNS, I would be pushing hard for
the additional registration in the special user registry.  Having read
the documents, I haven't seen that yet.  ate.  > I recall back in the
IAHC days circa 1996 or so David Mayer stating > that "that ship had
sailed" when a number of people argued that > trademarks shouldn't be
mixed with domain names. I don't believe > that particular ship has
unsailed in the 20 years since then. That > spilt milk has long since
spoiled, evaporated, and the milk solids > have turned to dust and
blown away so crying over it isn't going to > help.

I guess my point was merely that your examples seemed only to be
arguing from this or that trade or service mark to some conclusion
that the IETF had an obvious problem to contemplate.  But the
registrations in 6761 are, not going to be part of such disputes; or,
if they are, it is a problem the IETF will have confronted in its
evaluation.  Waving around possible trademark cases as things one
ought to worry about seems to me not to help the discussion.

>  If that's your criteria, then how do any of the others that were
> proposed earlier not fit?  Or are you saying they do fit and should
> be put into the Special Use registry before the next round?

I continue to believe that each application should be considered on
its merits.  As nearly as I can tell, the IESG (disclosure: I am an
_ex officio_ member with no decision-making power) previously said it
was uncomfortable with the situation and therefore wanted the WG to do
something about it.  I don't think the result was a foregone
conclusion.

I believe that some of the proposals I've seen ought indeed to be
added to the special names registry.  I think some of the others
shouldn't.

I hope that clarifies your understanding of what I've said.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Mar 2016 13:11:56 +0000

Andrew,

This is the crux of the issue. I have a hard time to believe the statement
you are making above
that future RFC6761 registrations will not be the object of trademark & co
disputes.
ICANN history has shown us that anything that has a name attached to it is
a potentially candidate for such a dispute.
It may or may not have been the case for Onion or Local, but we have no
guarantees it will not
be the case for the following ones.

Now, your second statement that the IETF will confront such potential
claims during evaluation
is where I personally express serious reservations. As I mentioned in a
previous email,
I do not believe the IETF is well equipped to deal with that. Wishing
those issues away
is, IMHO, the very thing that is not helping in this discussion. I trust
this community
to make good technical decisions, but I¹m not ready to sign a blank check
on its ability
to make good decisions in the trademark/name policy arena.

Alain, speaking for myself.

---

From: Ralph Droms <[email-masked]>
Date: Mon, 28 Mar 2016 09:43:31 -0400

> On Mar 28, 2016, at 9:11 AM 3/28/16, Alain Durand <[email-masked]> wrote:
> 

I understand Andrew's point to be that the decision process regarding trademark, etc., disputes will take place as part of the review process inherent in meeting the requirements for publishing 'an IETF "Standards Action" or "IESG Approval" specification', which is required in RFC 6761 for adding a name to the registry.

> to make good decisions in the trademark/name policy arena.

First, I'll emphasize that the process of designating a name as "special use" is separate from the mechanical process of actually adding a new name to the Special-Use Names registry.

RFC 6761 explicitly defines the latter process, and implicitly requires open IETF review for the former process.  In my opinion, we can focus on the former process, of deciding whether a name should be designated as having a special use.  This process may have, as you point out, issues regarding trademarks, association of names with organizations, and many others.

I'm not trying to wish those issues away, and I don't think Andrew is either.  Rather, speaking only for myself, I believe that our open process of community review and consensus is an appropriate starting point for discussion.

- Ralph

---

From: "John Levine" <[email-masked]>
Date: 28 Mar 2016 16:35:19 -0000

>I understand Andrew's point to be that the decision process regarding trademark, etc., disputes will
>take place as part of the review process inherent in meeting the requirements for publishing 'an IETF
>"Standards Action" or "IESG Approval" specification', which is required in RFC 6761 for adding a name
>to the registry.

I read it somewhat differently: trademark issues are not technical and
insofar as they're anyone's problem, they're ICANN's.  There's lots of
other non-technical arguments about who gets to put names where, such
as the endless argument about .AFRICA which is now taking a detour
through U.S. courts.

One of the things to consider in a 6761 evaluation is whether it's
really a technical proposal or whether someone's trying to make an end
around the ICANN process.  If it's really a trademark dispute or
something else that isn't technically different from the DNS, it's not
our problem.

R's,
John

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 28 Mar 2016 13:32:29 -0400

Dear colleagues,

Thanks to John for this input, and all who've commented so far; but I'd like to use John's comment to slightly re-focus this conversation.

It has seemed to me from the beginning of this discussion, and even the establishment of the special use names registry, that it's fairly easy to get caught up in this aspect of the discussion, which focuses on the implications of using specific strings in specific contexts. In particular, we tend to focus on possible collisions between the special use names registry and the registry representing the public DNS root zone, and on hand-wringing over the fact those registries are operated by different parties.

While it's true there's potential for such collisions, and easy to argue that the potential needs attention in forming any solutions, potential collision between those registries is not necessarily the only or the biggest issue we have to address.

So I think it would be good to consider the broader issues, which are not specific to which strings are used in which context. 

It seems to me that "the bigger picture" needs to consider that the use of domain names is diverging in certain ways from practices and procedures for allocating names for use in other contexts, including but not limited to the DNS protocol context. This is leading to various complications, including possible (and even actual) collisions among domain names as used in different contexts; uncertainty around whether a given name can or can't be instantiated in a given context; the interaction between IETF registries and what's essentially protocol development taking place outside of IETF process; and some other architectural and operational issues arising from the fact people find domain names useful outside of DNS protocol (and indeed, they always have). 

I'd like very much to see us separate issues that depend on *which* strings are used, such as whether anyone's process includes a provision for avoiding a specific type of collision, from issues we'd have even if we've set aside a subset of the namespace structured to avoid policy issues arising from the use of the domain name space in the DNS root.

As a practical focus: sometime ago, DNSOP adopted and then parked https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/. This draft proposes a special use names registry entry that would be expected to function as the rightmost label in names intended for resolution outside of the DNS protocol: something of a meta-protocol switch.

Assuming we understand the problems a bit better now than we did before, particularly given the experience of .onion, which of the problems we've seen would be solved by telling people "You can use any domain names you want, but the safe choice for avoiding operational and policy collisions with DNS protocol and namespace is to root your chosen domain name space under .alt"?

Which technical issues would persist? 

If, as some people have argued, the only problem we really have here is separating domain names that might be used in the DNS from domain names available for use in other resolution contexts, it may be that ".alt" is both necessary and sufficient to support future experiment and development in the use of domain names. 

Will that do it? If not, why not?

The question of how to think about name resolution context in the internet in general-- even separately from domain names-- is the departure point for the ARCING BoF.  But the concerns addressed in the special-names-problem draft, regarding how domain names are used by DNS and possibly other name resolution protocols, seem to be still within scope for DNSOP.

thanks,
Suzanne

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Mar 2016 13:57:05 -0400

> As a practical focus: sometime ago, DNSOP adopted and then parked https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/. This draft proposes a special use names registry entry that would be ex…

One of the possibly amusing things that struck me lately is that
marking out the string even more clearly for this purpose might take
some of the venom from the sting.  In that context, let me ask whether
_alt or even _ would be better labels for this purpose.  Part of the
goal has been to make these strings usable in applications (in "domain
name slots", as 5890 calls them).  Would "_" work?  Would "_alt"?  I
have doubts, but I thought I'd ask.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Mar 2016 18:15:23 +0000

Sent from my iPhone
> On Mar 28, 2016, at 1:31 PM, Suzanne Woolf <[email-masked]> wrote:
> 

Such a solution as the clear benefit to get the IETF out of the name evaluation quagmire. The more I look into it, the more I'm drawn to a solution that would look like this: apply 6761 one last time to create .alt (or ._ or whatever) and *then* close the registry.

Alain, speaking solely for myself.

---

From: "John Levine" <[email-masked]>
Date: 28 Mar 2016 18:31:57 -0000

>have doubts, but I thought I'd ask.

I don't think so.  The URI definition in RFC 3986 says the host is a
"reg-name" which refers to section 2.1 of RFC 1123 which says a
hostname is letters, digits, and hyphens.  So underscores won't work
in names in web browsers which are, as far as I can tell, the main
place people are likely to use these names-that-are-not-names.

Nice thought, though.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Mar 2016 14:33:06 -0400

Hi,

> a potentially candidate for such a dispute.

I am not sure I accept this premise.  It seems to me that ICANN's
history is bound up with names in the DNS.  I am pretty sure that
whatever could get registered under RFC 6761, it would not be an
ordinary name in the DNS.  It seems to me for your argument to work,
you need to show that registrations of names that cannot be resolved
as part of the normal DNS resolution mechanism would also be subject
to such a dispute.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Mar 2016 14:35:13 -0400

On Mon, Mar 28, 2016 at 06:31:57PM -0000, John Levine wrote:

> The URI definition in RFC 3986 says the host is a
> hostname is letters, digits, and hyphens

Duh.  Now that you mention this, I realise that I actually had this
idea once before and chased that set of references and drew the same
conclusion.  So much for relying on my memory, but thank you for
hitting me again with the clue-by-four.  Maybe 3d time will be a
charm.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 28 Mar 2016 18:53:12 -0000

>any domain names you want, but the safe choice for avoiding operational and policy collisions with
>DNS protocol and namespace is to root your chosen domain name space under .alt"?
>

I can think of two, plus one non-technical one.

The first technical one is whether there is a registry for .alt names
and if so how it'd operate.  From prior discussion, some people think
it should be FCFS to prevent ambiguity.  I think that would be utterly
counterproductive since it'd lead to a squatter rush, and anyway
there's no way to enforce that people use names they've registered.
FCFS with unlimited name collisions would be OK, to help people figure
out where to get the code to implement various name things they've
come across.

The other, which is a can of worms, is whether we want to define
protocol switches.  At this point, there's an implicit switch used for
.local at the DNS level, where you give it a name and it returns an IP
address that might have come from an A or AAAA record or might have
come from somewhere else.  And there's another higher level one at the
socket level used for .onion, where you give it a name and it gives
you back an open socket that might be a TCP or UDP connection to an
addresss found in an A or AAAA record, or it might be something else.
If there's to be any hope that people could use more than one of these
hacks at a time, a protocol switch would be a big help.

Finally, no matter what we do, at some point someone will come by with
.GARLIC which is like .ONION but stronger and they will say (with some
justification) that it's used by a zillion people around the world.
"You should have used GARLIC.ALT." "Yeah, I guess so, but we didn't,
sorry."  Then we'll have to deal with it one way or the other.  I hope
that .alt will push that day off farther into the future but it's
unlikely to push it to infinity.

R's,
John

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Mar 2016 11:55:23 -0700

Ralph,

> First, I'll emphasize that the process of designating a name as "special use" is separate from the mechanical process of actually adding a new name to the Special-Use Names registry.

Agreed.

> I'm not trying to wish those issues away, and I don't think Andrew is either.  Rather, speaking only for myself, I believe that our open process of community review and consensus is an appropriate…

In my limited experience, the IETF process is great for (a subset of) technical matters. It has perhaps been less than great in social/political/economic matters and I thought there was a general reluctance for the IETF to go that direction. I am a bit surprised there appears to be a desire, implicit or not, to apply the IETF process in these non-technical areas, particularly as many assume that part of the reason for 2860 was specifically because the IETF wasn't, at least historically, particularly well suited to or interested in dealing with these kinds of non-technical issues.

I am a bit curious as to the rationale behind the change of heart.

Regards,
-drc
(Speaking only for myself)

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Mar 2016 12:15:15 -0700

Andrew,

On Mar 28, 2016, at 11:33 AM, Andrew Sullivan <[email-masked]> wrote:
> I am pretty sure that
> ordinary name in the DNS.

What do you mean by "ordinary"?
In what way is ONION not "ordinary"?
In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not "ordinary"
Are HOME, CORP, and MAIL "ordinary"?

Thanks,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Mar 2016 15:22:33 -0400

Hi,

I think I've answered these questions before, but in case not, here's
what I think:

> In what way is ONION not "ordinary"?

The label "onion" indicates that an alternative resolution path is
intended.  Moreover, an additional underlying networking protocol is
expected to be in use.

> In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not "ordinary"

An alternative (to DNS) resolution protocol is similarly expected.  In
some cases, additional underlying network protocols are expected.  In
other cases, it is merely an indication of alternative resolution,
with no alternative underlying network technology.  (Part of the
reason I wanted the different cases separated is because I think it's
an open question whether a different naming protocol with _no_
difference in the underlying technology is a legitimate use of 6761.)

> Are HOME, CORP, and MAIL "ordinary"?

Yes.  They're expected to resolve in ordinary DNS contexts, though not
necessarily the global one.  My own view is that these ought to be
outside the 6761 registry unless some ICANN-based PDP were to
determine that they should be permanently reserved and that the
reservation ought to be sought in the 6761 registry.

Best regards,

A (as usual, for myself)

-- 
Andrew Sullivan
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Mar 2016 21:41:53 +0000

Andrew,

This is the very registration in 6761 that makes (or would make) those names special, i.e. not ordinary. Those name could as well have been reserved in the previous ICANN gTLD round or in the next one for regular DNS purpose. The is nothing "non-ordinary" about the strings themselves...

> On Mar 28, 2016, at 3:23 PM, Andrew Sullivan <[email-masked]> wrote:
> 
> Hi,
>

---

From: Ralph Droms <[email-masked]>
Date: Mon, 28 Mar 2016 17:53:46 -0400

> On Mar 28, 2016, at 5:41 PM 3/28/16, Alain Durand <[email-masked]> wrote:
> 
> Andrew,
> 

Let me make the point again that the document that records the Standards Action or IESG approval is what designates a name as a special-use name.  Therefore, any designation as a special-use name will have IETF consensus.  RFC 6761 only documents the process for recording that designation in the Special-Use Names registry.

What do you mean by "reserved in the previous ICANN gTLD round"?  Do you mean "assigned to some entity", in which case it's highly unlikely the IETF would come to consensus about designating such a name as a special-use name.  Once a name has been designated as a special-use name, it is no longer part of the DNS namespace available for assignment by ICANN.

But, I may be misunderstanding your point...

- Ralph

---

From: Alain Durand <[email-masked]>
Date: Mon, 28 Mar 2016 22:32:41 +0000

I'm sorry if my point was not clear. My perspective is that, at the end of the day, a name is a name is a name. Being on the 6761 registry or in the DNS root zone is fundamentally irrelevant when it comes to IPR and other related socio-political issues. The same concerns apply.

> On Mar 28, 2016, at 5:54 PM, Ralph Droms <[email-masked]> wrote:
> 
>

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2016 00:36:30 -0000

>What do you mean by "reserved in the previous ICANN gTLD round"?

ICANN has its own list of reserved names that you can't apply for.
In the recent round it was all of these:

AFRINIC IANA-SERVERS NRO ALAC ICANN RFC-EDITOR APNIC IESG RIPE ARIN
IETF ROOT-SERVERS ASO INTERNIC RSSAC CCNSO INVALID SSAC EXAMPLE IRTF
TEST GAC ISTF TLD NSO LACNIC WHOIS GTLD-SERVERS LOCAL WWW IAB
LOCALHOST IANA NIC

plus "test" or "example" translated into other languages.  They also
reserved OLYMPIC and REDCROSS in about a dozen languages but said
those might change.

Presumably if there's another round, there will be a similar list.

R's,
John

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Mar 2016 21:30:26 -0400 (EDT)

> reserved OLYMPIC and REDCROSS in about a dozen languages but said

Wasn't MAIL added to that list a little later on?

Paul

---

From: George Michaelson <[email-masked]>
Date: Tue, 29 Mar 2016 11:58:11 +1000

Whats the process to understand how, and why a name gets added to the
list? Thats not an IETF question, understandably, but it would be nice
to understand it, even only in outline.

-George

---

From: "John R Levine" <[email-masked]>
Date: 28 Mar 2016 21:59:35 -0400

> Wasn't MAIL added to that list a little later on?

Nope, look at the ICANN new gTLD web site.

There were six applications for MAIL.  Two, from 1&1 and Afilias, have 
been withdrawn.  The other four, from Amazon, Google, Donuts, and 
whitepages.com, are all on hold.

https://www.icann.org/resources/pages/name-collision-ro-faqs-2014-08-01-en

FAQ #22 says CORP, HOME, and MAIL have been deferred indefinitely, but 
along with the four remaining applications for MAIL, there are 5 for CORP 
and 10 for HOME, and they haven't given back the $3.5 million in 
application fees, either.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Mar 2016 22:05:11 -0400

On Mon, Mar 28, 2016 at 10:32:41PM +0000, Alain Durand wrote:

> My perspective is that, at the end of the day, a name is a name is a
> name.

Your argument is now circular.  You cannot use a premise that no names
are special as a premise to draw your conclusion that no names are
special.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Tue, 29 Mar 2016 02:14:43 +0000

> On Mar 28, 2016, at 10:05 PM, Andrew Sullivan <[email-masked]> wrote:
> 

I’m sorry my point remains unclear. Let me try again:

All strings, regardless of the intend to be placed on the 6761 registry or in the DNS root zone, are potentially subjects to IPR & socio-economic issues.

There is nothing circular here. Do you agree or not with that statement?

Alain.

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2016 02:16:06 -0000

>to understand it, even only in outline.

The reserved names are in the ICANN application guidebook.  There was
a multi-year process of breathtaking complexity to come up with the
rules in the guidebook.

The de-facto reservation of COMP, HOME, and MAIL was later when it
became apparent that despite the complex process they'd neglected to
consider collisions with existing informal name uses.  The collision
mitigation framework is described here:

https://www.icann.org/en/system/files/files/name-collision-framework-30jul14-en.pdf

R's,
John

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 28 Mar 2016 22:25:33 -0400

> a multi-year process of breathtaking complexity to come up with the

It's also worth noting that since the recent new gTLD round is closed, with no new applications being accepted, it's not clear that there's a current process.

The assorted committees and working groups and advisory committees are gearing up to provide their input to policy and process for the presumed next round of new gTLDs. I won't venture to predict the contents of that future Applicant Guidebook.

Suzanne

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 Mar 2016 23:36:29 -0400

> There is nothing circular here. Do you agree or not with that statement?

If I knew what "potentially subject to IPR & socio-economic issues", I
might.  But I think you're smuggling into your argument a claim that
they're potentially subject to the IPR and socio-economic issues that
have been a problem in the DNS root and TLD zones.  That's in effect
an argument that the special-names registrations are not special.  I
do not agree with that claim.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Mar 2016 20:47:06 -0700

> FAQ #22 says CORP, HOME, and MAIL have been deferred indefinitely,

Yep.  The report on name collisions that ICANN commissioned had the following recommendation (recommendation #1 as a matter of fact, see https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf, top of page 5):

"The TLDs .corp, .home, and .mail be referred to the Internet Engineering Task Force (IETF) for potential RFC 1918-like protection/treatment."

Unfortunately, the IETF decided agains this treatment, so those strings remain "deferred indefinitely."

> but along with the four remaining applications for MAIL, there are 5 for CORP and 10 for HOME, and they haven't given back the $3.5 million in application fees, either.

I might be wrong, but I believe that is because the applicants have, to date, refused to terminate their applications for those strings. Hard to give back money if people refuse to accept it, no?

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Mar 2016 20:49:01 -0700

Andrew,

On Mar 28, 2016, at 8:36 PM, Andrew Sullivan <[email-masked]> wrote:
> But I think you're smuggling into your argument a claim that

Just to be clear, you believe that the IESG putting a name onto the special names registry means that it will then be immune from IPR and socio-economic issues?

Thanks,
-drc

---

From: joel jaeggli <[email-masked]>
Date: Mon, 28 Mar 2016 20:56:47 -0700

On 3/28/16 8:49 PM, David Conrad wrote:
>> they're potentially subject to the IPR and socio-economic issues
>> that have been a problem in the DNS root and TLD zones.  That's in
>> effect an argument that the special-names registrations are not
>> special.  I do not agree with that claim.
> 
> Just to be clear, you believe that the IESG putting a name onto the
> special names registry means that it will then be immune from IPR and
> socio-economic issues?

What IETF activity is immune to IPR or sociology-econmic issues?

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

---

From: David Conrad <[email-masked]>
Date: Mon, 28 Mar 2016 20:57:46 -0700

George,

> to understand it, even only in outline.

As Suzanne mentioned, there is no process as the new gTLD program (for the last round) has been shut down.  If/when a new round is created, there will be a new process (one undoubtedly based on the previous process but with enough changes to keep things interesting).  As that process does not yet exist, it is difficult to outline it.

One might view this as an encouragement for folks within the technical community (and the IETF in particular) to be less reticent to participate in ICANN processes than in the past, despite how excruciatingly painful that might be, but that's just crazy talk.

Regards,
-drc

---

From: George Michaelson <[email-masked]>
Date: Tue, 29 Mar 2016 14:08:00 +1000

On Tue, Mar 29, 2016 at 1:36 PM, Andrew Sullivan <[email-masked]> wrote:
> That's in effect an argument that the special-names registrations are not special.  I

>From an extreme point of view (which clearly, contextually, I hold)
thats exactly what I think I fundamentally agree with, in what Alain
is saying: The special-names are claiming technological override on
process which ignores the central unity of all name-strings: for
ICANN, for the namespace, these are labels like all the others.

They're asking for a joker-card permit, which I have major issues
with. That aside, they're just like all the others. The qualities they
have in the zone, the records which do or do not exist are in another
plane, orthoginal.

-G

---

From: joel jaeggli <[email-masked]>
Date: Mon, 28 Mar 2016 21:22:57 -0700

On 3/28/16 9:08 PM, George Michaelson wrote:
> process which ignores the central unity of all name-strings:

It doesn't ignore it, it assumes the unity of namespace. otherwise what
would be the point? you'd just go off and do your own thing...

>  for

indeed.

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 29 Mar 2016 07:46:38 -0700

On 28 Mar 2016, at 10:32, Suzanne Woolf wrote:

> As a practical focus: sometime ago, DNSOP adopted and then parked 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/. This draft 
> proposes a special use names registry entry that would be expected to 
> function as the rightmost label in names intended for resolution 
> outside of the DNS protocol: something of a meta-protocol switch.
>
> Assuming we understand the problems a bit better now than we did 
> before, particularly given the experience of .onion, which of the 
> problems we've seen would be solved by telling people "You can use any 
> domain names you want, but the safe choice for avoiding operational 
> and policy collisions with DNS protocol and namespace is to root your 
> chosen domain name space under .alt"?

Some. For a truly well-intentioned protocol developer who wants a 
"switch" name and is willing to trade likely long-term 
exclusivity-of-use for slightly-clunky-naming, ".alt" works very well.

> Which technical issues would persist?

If the 6761 registry is still open after putting .alt in it, all the 
technical issues that there are today would remain. Different people 
will feel that different technical issues are the most important ones. 
For me, the biggest is "Anyone can propose to reserve a name with no 
more than a technical protocol proposal, and those are easily cloned 
with very minor revisions", but there are certainly other significant 
technical issues as well.

If the 6761 registry is closed after adding .alt, I think there are no 
more technical issues.

> If, as some people have argued, the only problem we really have here 
> is separating domain names that might be used in the DNS from domain 
> names available for use in other resolution contexts, it may be that 
> ".alt" is both necessary and sufficient to support future experiment 
> and development in the use of domain names.
>

It could do it, but only if the 6761 registry is closed. If the registry 
is still open, and the only bar is an Internet-Draft that could gain 
"consensus" after wearing down opponents, the 6761 route will remain 
attractive to those who are willing to spend their time (and the time of 
everyone in the IETF consensus process) to "get" a name.

> out where to get the code to implement various name things they've

That's not really a technical issue with the draft because the draft 
says:

    There is no IANA controlled
    registry for names under the ALT TLD - it is an unmanaged namespace,
    and developers are responsible for dealing with any collisions that
    may occur under .alt.  Informal lists of namespaces under .alt may
    appear to assist the developer community.

> hacks at a time, a protocol switch would be a big help.

Again, that's not really a technical issue with the draft because the 
draft is completely silent on that.

> unlikely to push it to infinity.

Fully agree. That's why, when thinking about .alt, we need to consider 
two different cases:
   - Add .alt to the 6761 registry
   - Add .alt to the 6761 registry and close the registry
To me, the second gives a much clearer picture to both the IETF 
community about what they will be expected to do in the future, and to 
the developers who want new outside-the-DNS name switches.

--Paul Hoffman

---

From: "John R Levine" <[email-masked]>
Date: 29 Mar 2016 10:47:17 -0400

> Unfortunately, the IETF decided agains this treatment, so those strings remain "deferred indefinitely."

I think it would be fairer to say we didn't decide to do anything.  It 
didn't help that one of the louder voices in the discussion was am 
applicant for .HOME lobbying to keep his application alive, and lobbying 
and consensus work poorly together.

If we're thinking about closing the 6761 registry, it could make sense to 
revisit the question.  It's somewhat complicated because (as far as I can 
see) .home and .mail are likely to collide forever, but now that CAs have 
stopped signing .corp certificates, its usage might decline.

> I might be wrong, but I believe that is because the applicants have, to date, refused to terminate their applications for those strings. Hard to give back money if people refuse to accept it, no?

If I were an applicant, I would note that if I withdraw voluntarily at 
this point, I get 20% of my money back and ICANN keeps 80%.  Since we now 
know none of the applications for those three names could have been 
successful, I'd want 100% back.  Or I might figure that at this point, the 
incremental cost of waiting to see what happens to .corp is pretty low.

R's,
John

---

From: Jim Reid <[email-masked]>
Date: Tue, 29 Mar 2016 16:04:28 +0100

> On 29 Mar 2016, at 15:46, Paul Hoffman <[email-masked]> wrote:
> 
> Fully agree. That's why, when thinking about .alt, we need to consider two different cases:
> To me, the second gives a much clearer picture to both the IETF community about what they will be expected to do in the future, and to the developers who want new outside-the-DNS name switches.

I agree.

Though I’m struggling to understand how reserving .alt (or some other string) will actually help. Naive or less-than-well-intentioned protocol developers will just pluck TLD strings out of the ether and that’ll bring us right back to where we started when this .onion thing erupted.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 29 Mar 2016 17:25:41 +0200

> > To me, the second gives a much clearer picture to both the IETF community a
> bout what they will be expected to do in the future, and to the developers wh
> o want new outside-the-DNS name switches.
> 
> I agree.
> 
> Though Im struggling to understand how reserving .alt (or some
> other string) will actually help. Naive or less-than-well-intentioned
> protocol developers will just pluck TLD strings out of the ether
> and thatll bring us right back to where we started when this .onion
> thing erupted.  

One option would be to have a process that essentially says:
- The IETF decides whether the proposal is technically sound or not
- There is a .alt domain with a registry. Protocols can go there first come,
  first served, as long as there is consensus that the proposal is technically
  sound.
- Any another name, requires approval from ICANN, however the IETF will inform
  ICANN about consensus on the technical quality of the proposal.

This way ICANN can create policy on the name part of special names and the
IETF can focus on the technical part of those proposals.

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 29 Mar 2016 12:13:32 -0700

> IETF can focus on the technical part of those proposals.

This process would possibly work for the IETF, but how would it work for 
the developer of the technical protocol? They would not know what name 
to use in practice until after the IETF consensus call was finished. 
However, it is clear that many people in the community consider part of 
the technical review process the question of are there any/many users 
for the name. In order to get some, they need to start using a TLD (not 
.alt) name knowing that, if they get rejected, they have to change the 
name in all deployed instances. Technically, that's feasible; 
operationally, it is not.

--Paul Hoffman

---

From: Alain Durand <[email-masked]>
Date: Tue, 29 Mar 2016 20:19:20 +0000

> On Mar 29, 2016, at 3:50 PM, Paul Hoffman <[email-masked]> wrote:
> 
> This process would possibly work for the IETF, but how would it work for the developer of the technical protocol? They would not know what name to use in practice until after the IETF consensus call was finished. However, it is clear that many people in the community consider part of the technical review process the question of are there any/many users for the name. In order to get some, they need to start using a TLD (not .alt) name knowing that, if they get rejected, they have to change the name in all deployed instances. Technically, that's feasible; operationally, it is not.

This should be the opposite: start with a name with little perceived value, under .ALT or anything already existing, and then if you are successful apply for something of higher perceived value and change name in deployed code.
Seems like regular business model to me.

Alain

---

From: "John Levine" <[email-masked]>
Date: 29 Mar 2016 20:38:04 -0000

>  first served, as long as there is consensus that the proposal is technically

Developers will say to heck with that, and just pick a name and use
it, like they've been doing all along.  If we want people to use .alt
we need to make the friction as low as possible.  If there are a lot
of technically lame .alt hacks in the registry with overlapping names,
so be it.

Remember that we are not the Protocol Police, and neither is anyone else.

R's,
John

---

From: Philip Homburg <[email-masked]>
Date: Tue, 29 Mar 2016 23:34:19 +0200

>Remember that we are not the Protocol Police, and neither is anyone else.

If people want names without going through the IETF they should talk to
ICANN. ICANN can just as well set up a .free-for-all registery. 

IETF is about protocols, not names. So I can see room for a special 
purpose domain like .alt, but why would you open that for people
who can't be bothered to create a sensible protocol.

I see .alt more as a way for the IETF to have some reserved space for
future protcols and have all regular proposals deal with ICANN to get
their name. Though it may make sense for the ICANN community to require a
standards track protocol before they assign any top level name.

---

From: "John R Levine" <[email-masked]>
Date: 29 Mar 2016 17:51:54 -0400

> who can't be bothered to create a sensible protocol.

So they don't pollute the rest of the DNS namespace with their silly 
designs, of course.  Once again, we are not the Network Police, and we 
cannot keep people from doing whatever they want, even if we think it's 
dumb.  The best we can do here is try to channel the damage, and tell 
people that if they use .alt, we promise they'll never collide with a 
domain allocated by ICANN.

> standards track protocol before they assign any top level name.

You might want to re-read the .alt draft.  That is not at all what it's 
about.  Also, it seems utterly implausible to ask ICANN to do protocol 
management.  In 100% of the domains they've delegated so far, it's plain 
old RFC 1034/1035 DNS.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 29 Mar 2016 17:57:23 -0400

> Just to be clear, you believe that the IESG putting a name onto the special names registry means that it will then be immune from IPR and socio-economic issues?

I don't see how that is implied by what I wrote.  Apologies that this
is so long, but given your question it's plain I haven't made myself
clear when keeping the message short.

The IPR and socio-economic issues with respect to the DNS root and
TLDs arise within a context. Part of that context involves the fact
that, in many cases, DNS names appear in URIs and on the sides of
busses as approximately-Internet-wide identifiers and so on. This
makes DNS label string similarity with trademark-law word marks a hot
issue for trademark lawyers. (Early in ICANN's history, several
policies were adopted that implicitly accepted such IPR claims. But it
is irrelevant that ICANN currently has such policies or when or how
they arose, because they are in all cases founded in the use-in-public
nature of DNS names given the way certain pieces of user-accessible
identifiers, including email addresses and the host portion of URIs,
work on the Internet.)

The special-use names registry contains, so far, three kinds of names.
Some names are for special use within a DNS context. Examples include
example.com., invalid., and tld. These are all expected to appear in DNS
contexts, and are generally expected not to resolve in a global DNS
sense. There are also special names that do resolve in a global
context, but that have only local meaning.  The reverse trees for
RFC 1918 addresses and localhost. are of this sort.

The third kind is different, however, because it presents a mechanism
which is, in effect, instructions to the agent attempting the
resolution to use a different technology.  So, for instance, names
terminating in local. are not properly speaking candidates for lookup
in the global DNS _at all_.  They're intended to be used in other
contexts (mDNS names, for instance, are more likely to be encountered
in pick lists).  It is not at all clear that these names are really
approximately-Internet-wide identifiers.  The only worked example we
have of this recently is onion, which betokens that a name is for
lookup and use in the context of onion routing and otherwise probably
shouldn't be.

This technical difference _makes_ a difference for what sorts of IPR
claims could be introduced against such names.  Naturally, there could
be IPR or socio-economic issues associated, but they're not the same
ones as are raised in the DNS and in keeping with prevailing ICANN
policies.  (By way of analogy, certain large Internet Exchanges in
the US and extremely remote parts of the developing world both have "a
bandwidth problem", but trying to tackle them as though they were the
same thing would be to make a gross category mistake.)  It will do us
no good at all to attempt to collapse these different kinds of
problems into a single category, which is why I don't accept Alain's
claim that a name is a name.

Now, some appear to be arguing that we _could_ get an application for
a case that would test the distinctions I make above. To that claim I
respond that we'd need evidence that we have such a problem. So far,
all I've heard is "what if?". If we want to attend to things the IETF
is bad at, solving logically possible problems we don't actually have
instantiated is higher on my list than dealing with social and
economic pressure.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 29 Mar 2016 19:23:03 -0400

David,

> On Mar 28, 2016, at 11:47 PM, David Conrad <[email-masked]> wrote:
> 

I suspect it would be helpful to the draft authors and the WG to provide a public reference for the implied statement here, because it could be important to mapping the current relationship among different uses of the namespace.

You seem to be saying that the fact the IETF hasn’t added those strings to the special use names registry, per the recommendation of a third party consultant hired by ICANN, is somehow part of why they’re “deferred indefinitely” instead of having some other status, but it’s not completely clear to me what relationship there is among those things.

I’ve never been able to find any reference to the IETF special use names registry, or any discussion of its impact on ICANN policy, in the Applicant Guidebook for the previous gTLD round, or indeed anywhere else. I also haven’t seen a liaison or other open communication from ICANN containing an opinion about having the IETF reserve the names you mentioned.

I’ve always seen people assume that an entry in the special use names registry means that ICANN won’t delegate the same string in the DNS root. But given other discussion in this thread, where the claim is being made that any IETF action regarding strings for “special use” is subject to socio-economic pressures just as ICANN actions would be, I don’t see the basis of the assumption.

Doubtless I’m missing something though….is there a citation we can ask the draft authors to incorporate in the future?

thanks,
Suzanne

---

From: George Michaelson <[email-masked]>
Date: Wed, 30 Mar 2016 10:19:49 +1000

Make the application for .alt actually ask for xn--59g and I'd be there.

or even xn--3ve9dwb1a

The application demands .alt? It has the same problems as any other.
Its sole purpose should be uniqueness, and choosing a string which has
semantic meaning for a large community is confronting the issue up
front:  It should a symbol-string which has less chance of being asked
for as a name in social contexts, has more chance of being
justifyable.

-G

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 30 Mar 2016 01:16:09 +0000

Sorry if this is just a reprise of a previous discussion, I'm new to 
this list.
I think the concept of an extensible registry for special use domain 
names is complete madness, and the registry should document only 
existing special cases, and not permit any more registrations.  .onion 
should be rescinded.

IMO It is insane to allow the addition of a name to the special use 
names registry to make every DNS agent on the planet no longer 
compliant.

RFC6761 doesn't seem to really contemplate the logistics of modifying 
all DNS resolvers and servers on the planet.  It's a sisyphean task.

Our product includes a DNS resolver.  Even if we did add support for 
.onion, we can't (and wouldn't even if we could) _force_ our customers 
to upgrade.  So the only thing you can count on is that there will 
remain for considerable time a considerable deployment of resolvers who 
ignore any new special use names.  I'm sure you all know that, but it 
seems foolhardy to negotiate sensitive information over .onion 
resolution when that is highly likely to leak.

Surely .onion could have been handled in the application, without 
pushing it down to the resolution layer.
Adrien de Croy

------ Original Message ------
From: "George Michaelson" <[email-masked]>
To: "Suzanne Woolf" <[email-masked]>
Cc: "dnsop WG" <[email-masked]>; "David Conrad" <[email-masked]>
Sent: 30/03/2016 1:19:49 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

>>>  Yep.  The report on name collisions that ICANN commissioned had the 
>>>following recommendation (recommendation #1 as a matter of fact, see 
>>>https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf, 
>>>top of page 5):
>>>
>>>  "The TLDs .corp, .home, and .mail be referred to the Internet 
>>>Engineering Task Force (IETF) for potential RFC 1918-like 
>>>protection/treatment."
>>>
>>  I suspect it would be helpful to the draft authors and the WG to 
>>provide a public reference for the implied statement here, because it 
>>could be important to mapping the current relationship among different 
>>uses of the namespace.
>>
>>  You seem to be saying that the fact the IETF hasn’t added those 
>>strings to the special use names registry, per the recommendation of a 
>>third party consultant hired by ICANN, is somehow part of why they’re 
>>“deferred indefinitely” instead of having some other status, but it’s 
>>not completely clear to me what relationship there is among those 
>>things.
>>
>>  I’ve never been able to find any reference to the IETF special use 
>>names registry, or any discussion of its impact on ICANN policy, in 
>>the Applicant Guidebook for the previous gTLD round, or indeed 
>>anywhere else. I also haven’t seen a liaison or other open 
>>communication from ICANN containing an opinion about having the IETF 
>>reserve the names you mentioned.
>>
>>  I’ve always seen people assume that an entry in the special use names 
>>registry means that ICANN won’t delegate the same string in the DNS 
>>root. But given other discussion in this thread, where the claim is 
>>being made that any IETF action regarding strings for “special use” is 
>>subject to socio-economic pressures just as ICANN actions would be, I 
>>don’t see the basis of the assumption.
>>
>>  Doubtless I’m missing something though….is there a citation we can 
>>ask the draft authors to incorporate in the future?
>>
>>
>>  thanks,
>>  Suzanne
>>

---

From: "John Levine" <[email-masked]>
Date: 30 Mar 2016 01:55:22 -0000

>pushing it down to the resolution layer.

I have to say I'm startled to see that people here aren't aware that
.onion is entirely handled in applications.  The usual implementation
is a modified SOCKS proxy that treats .onion names specially.

The point of reserving .onion in the DNS is first to ensure that
nobody allocates it as an actual DNS domain, and secondly to encourage
developers to stub it out in DNS resolvers so that .onion requests
don't leak into the DNS.  The only thing that anyone's asking DNS
developers to do is to fail .onion requests rather than forwarding
them along.

R's,
John

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 30 Mar 2016 02:08:02 +0000

------ Original Message ------
From: "John Levine" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 30/03/2016 2:55:22 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

>.onion is entirely handled in applications.

a google search for "DNS .onion leaks" comes up with many links, many 
relating to reported bugs in browsers.

I think maybe browser vendors would have had a thing to say or two about 
the prospect of having a new list of things to monitor / maintain.  the 
Verisign study of .onion requests hitting their root servers is also 
interesting, noting that .onion was the 461st most popular TLD.

https://www.verisign.com/assets/onionleakage.pdf?inc=www.verisigninc.com

So I don't know if we can truly claim that resolvers are being shielded 
from .onion by the applications.  Maybe it's better now, it would be 
interesting if Symantec were to update this.

>The usual implementation
>nobody allocates it as an actual DNS domain,
ok

>and secondly to encourage
That's the problem.  Creating new requirements for DNS developers to do 
anything at all is a huge problem.

People who implement RFCs are used to being able to do the 
implementation, achieve compliance, and then do nothing - safe in the 
knowledge that future changes would be optional or backward compatible.  
This fundamental principle was broken in 6761

Having said that, I wish there was a way with a single DNS lookup one 
could resolve both/either IPv4 and/or IPv6 addresses from a name with a 
single query (e.g. the "give me any version address" query), rather than 
having to make 2 lookups and fail over etc.  Would basically halve the 
amount of DNS traffic on the network and resolve a lot of pathological 
cases.

Cheers

Adrien

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 30 Mar 2016 02:15:29 +0000

>anything at all is a huge problem.
Actually making the code change is not the problem. We could easily stub 
out .onion in about 5 minutes.

Reliably deploying the change however is physically impossible.

We still have people running versions of WinGate from last century, and 
we don't have a time machine to go back and change those.

Adrien

---

From: "John R Levine" <[email-masked]>
Date: 29 Mar 2016 22:17:07 -0400

> relating to reported bugs in browsers.

Yeah, that's why it'd be nice if the DNS resolver rejected them rather 
than telling the world what you were trying to look for in .onion land.

> So I don't know if we can truly claim that resolvers are being shielded from 
> .onion by the applications.  Maybe it's better now, it would be interesting 
> if Symantec were to update this.

They aren't.  That's why it'd be nice to make that bug less leaky.

> anything at all is a huge problem.

It's not a requirement.  It's a request.  I expect it's a lot easier than 
whatever you have to do to deal with .local.  If we adopt .alt, you can 
stub that out too and with any luck you're done.

> Having said that, I wish there was a way with a single DNS lookup one could 
> resolve both/either IPv4 and/or IPv6 addresses from a name with a single 
> query (e.g. the "give me any version address" query), rather than having to 
> make 2 lookups and fail over etc.  Would basically halve the amount of DNS 
> traffic on the network and resolve a lot of pathological cases.

Surely you've been reading the draft-vavrusa-dnsop-aaaa-for-free thread.

R's,
John

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 30 Mar 2016 02:31:00 +0000

>>That's the problem.  Creating new requirements for DNS developers to 
>>do anything at all is a huge problem.
>
>It's not a requirement.  It's a request.  I expect it's a lot easier 
>than whatever you have to do to deal with .local.  If we adopt .alt, 
>you can stub that out too and with any luck you're done.
we ignore .local also otherwise we'd break Active Directory resolution 
which also ignores .local, and happily gives us records for .local 
queries over DNS.  So maybe Microsoft is ignoring it too?

I also don't feel a commercial compulsion to implement a multicast DNS 
resolver and server just to deal with that.

In fact we ignore all special use names except localhost.  Stubbing out 
the private IP range reverse zones would break a lot of stuff.  
Example.com etc are seemingly ignored by the internet at large, since I 
can still resolve it.  That leaves .test?

>>could resolve both/either IPv4 and/or IPv6 addresses from a name with 
>>a single query (e.g. the "give me any version address" query), rather 
>>than having to make 2 lookups and fail over etc.  Would basically 
>>halve the amount of DNS traffic on the network and resolve a lot of 
>>pathological cases.
>
Thanks for the pointer, I'll check it out.

Cheers

Adrien

---

From: "Patrik Fältström" <[email-masked]>
Date: Wed, 30 Mar 2016 06:12:21 +0200

> Doubtless I’m missing something though….is there a citation we can ask the draft authors to incorporate in the future?

The formal references we in SSAC have found are the following:

For .corp and .home:

<https://www.icann.org/resources/board-material/resolutions-new-gtld-2013-10-07-en>

For .mail:

<https://www.icann.org/resources/board-material/resolutions-new-gtld-2014-07-30-en#1.a>

Note that the rationale include:

> Requirements for ICANN:
>
> Work within the IETF and with other relevant technical communities to identify a notification mechanism for IPv6 that provides similar functionality to that available in IPv4's "Loopback" reserved prefix.
>
> Defer delegating .MAIL indefinitely, and collaborate with the technical and security community to identify the best way to handle .MAIL (e.g. permanent reservation through the IETF process).

   Patrik

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 30 Mar 2016 04:38:03 +0000

Just looking at the justification for all of this

from that draft which quotes RFC2826

"To remain a global network, the Internet requires the existence of a 
globally unique public name space. The DNS name space is a hierarchical 
name space derived from a single, globally unique root."

"Maintaining a globally-unique public namespace that supports different 
name resolution protocols is hence an architectural requirement, and 
some facility for reservation of top-level requirement, and some 
facility for reservation of top-level
domains in the DNS is necessary."

I couldn't even find the second para in RFC2826 (search didn't yield 
it), neither does it follow logically from the first paragraph in any 
case.  Google finds the second para only in the problem statement which 
quotes it from RFC2826.  Maybe it was in an earlier draft of 2826, but 
I'd still expect it to be in google somewhere.

Is this the justification for having an extensible registry of special 
names?

Cheers

Adrien

------ Original Message ------
From: "John R Levine" <[email-masked]>
To: "Adrien de Croy" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 30/03/2016 3:17:07 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

>>So I don't know if we can truly claim that resolvers are being 
>>shielded from .onion by the applications.  Maybe it's better now, it 
>>would be interesting if Symantec were to update this.
>

---

From: Philip Homburg <[email-masked]>
Date: Wed, 30 Mar 2016 12:26:33 +0200

>domain allocated by ICANN.

I disagree that this a problem worth solving. 

The internet at large was not bothered by .onion. It was the tor project that
found the need to have their use ratified.

>You might want to re-read the .alt draft.  

What's even worse, this draft would not have helped the .onion case at all.

>Also, it seems utterly implausible to ask ICANN to do protocol 

So, why can't they learn new tricks?

ICANN is doing names, let them do names. They can always create a procedure
that consults the IETF on protocol issues.

You should not have two organisations trying to manage a single name space.

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 30 Mar 2016 09:33:10 -0300

On 29 Mar 2016, at 18:57, Andrew Sullivan wrote:

> To that claim I
> respond that we'd need evidence that we have such a problem.

draft-grothoff-iesg-special-use-p2p-names claimed BIT and ZKEY, both of 
which are trademarked. The fact that we pretty much told developers to 
not bother us with name applications while with consider 6761bis should 
not be used as a tool to suggest non-existence of problems.

But I also fundamentally disagree that "trademarks" are the only naming 
problem we have. Even untrademarked names can have control issues. 
During the run-up to the current work, this WG heard claims that there 
were different digital cash systems that would want names. Does the 
first of them to get an RFC get "CASH"? During the technical 
considerations for that first application, if a second system also uses 
"CASH" as a switch and rapidly becomes bigger than the first, does the 
IETF consensus process need to take that into account? It is implausible 
that a IETF consensus review of a name application could *not* consider 
topics such as term squatting.

Maybe 6761bis will have prohibitions on any consideration of term 
squatting and trademarks during the technical review, but we have not 
seen any evidence of such wording.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 Mar 2016 13:38:55 -0400

On Wed, Mar 30, 2016 at 02:15:29AM +0000, Adrien de Croy wrote:
> Actually making the code change is not the problem. We could easily stub out
> .onion in about 5 minutes.

It seems it would be better if you included a mechanism by which the
registry could from time to time be consulted to see whether there are
more things not to include.  (There is an argument to be made here
that the registry is insufficiently usable by machines, of course.
But we could fix that, too.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: David Conrad <[email-masked]>
Date: Wed, 30 Mar 2016 12:32:04 -0600

Suzanne,

On Mar 29, 2016, at 5:23 PM, Suzanne Woolf <[email-masked]> wrote:
> I’ve always seen people assume that an entry in the special use names registry means that ICANN won’t delegate the same string in the DNS root.

I thought putting a name onto the special use names registries was an exercise in informing ICANN (and the rest of the world) that the IETF was invoking clause 4.3(a) of RFC 2860. The last paragraph of 4.3 states:

"In the event ICANN adopts a policy that prevents it from complying with the provisions of this Section 4 with respect to the assignments described in (a) - (c) above, ICANN will notify the IETF, which may then exercise its ability to cancel this MOU under Section 2 above."

Are you suggesting you believe ICANN would want to trigger that exercise or that using the special use registry is not invoking clause 4.3(a) (or something else)?

Regards,
-drc

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 30 Mar 2016 20:25:04 +0000

sure, we could even call home for a machine-readable list.  That would 
help with future additions to the registry.

that's not the point though, the difficulty is in replacing all existing 
deployed implementations.

And I don't think .onion meets the threshold set in terms of having a 
clear need and lack of alternative solution to the problem.

Regards

Adrien

---

From: "John Levine" <[email-masked]>
Date: 30 Mar 2016 21:49:52 -0000

>clear need and lack of alternative solution to the problem.

Isn't it a little late to be refighting this argument?

RFC 7686 was published in October.

R's,
John

---

From: "Adrien de Croy" <[email-masked]>
Date: Wed, 30 Mar 2016 22:38:05 +0000

I don't know the answer to that.  If the leakage is still a significant 
problem, maybe they should be looking at alternatives anyway.

Adrien

---

From: Ralph Droms <[email-masked]>
Date: Wed, 30 Mar 2016 17:40:36 -0400

> On Mar 30, 2016, at 2:32 PM 3/30/16, David Conrad <[email-masked]> wrote:
> 
> Suzanne,
> 
> 

David - I've reviewed 4.3(a) and the paragraph you quoted, and I honestly don't see the connection between invoking 4.3(a), the last paragraph of 4.3 and any suggestion on Suzanne's part that ICANN would want to cause the IETF to exercise that option?

Would you please explain in a little more detail?

- Ralph

---

From: David Conrad <[email-masked]>
Date: Wed, 30 Mar 2016 17:32:03 -0600

Ralph,

> Would you please explain in a little more detail?

I believe Suzanne was asking for a reference as to why ICANN would not just go ahead and delegate a domain name, regardless of whether it was in the special use registry since the AGB does not make any reference to the AGB (not surprising since I believe that registry did not exist when the AGB was written).

4.3(a) states:

   4.3. Two particular assigned spaces present policy issues in addition
   to the technical considerations specified by the IETF: the assignment
   of domain names, and the assignment of IP address blocks. These
   policy issues are outside the scope of this MOU.

My reading: policy issues associated with (normal) domain names DO NOT fall under the MOU describing the technical work of IANA.

   Note that (a) assignments of domain names for technical uses (such as
   domain names for inverse DNS lookup) [...] are not considered to be
   policy issues, and shall remain subject to the provisions of this
   Section 4.

My reading: if a domain name is being assigned for "technical uses" then it DOES fall under the MOU.

   In the event ICANN adopts a policy that prevents it from complying
   with the provisions of this Section 4 with respect to the assignments
   described in (a) - (c) above, ICANN will notify the IETF, which may
   then exercise its ability to cancel this MOU under Section 2 above.

My reading: if ICANN chooses to come up with a policy that treats a domain name assigned for "technical uses" as a "normal" domain, that would be in violation of 4.3, which means it could trigger cancellation of the MOU.

My reading of Suzanne's statement was suggesting that ICANN would knowingly make the choice of treating a "technical use" domain as a "normal" domain, which strikes me as crazy particularly given the efforts ICANN has been taking in relation to the transition. Alternatively, Suzanne might have been suggesting that the special use registry was unrelated to "technical uses" of domain names as defined in RFC 2860. If so, I'd be interested in understanding that viewpoint.

Or I could simply be confused.

Regards,
-drc

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 31 Mar 2016 08:31:53 -0300

> Isn't it a little late to be refighting this argument?

+1.

Folks: this thread is about a specific document, not every other thing 
we have discussed before now. If you want to rediscuss (as I sometimes 
do), please at least reference in the document where your argument fits. 
That way, the document authors can maybe amend the document if there is 
consensus to do so.

--Paul Hoffman

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 31 Mar 2016 20:25:07 +0000

------ Original Message ------
From: "Paul Hoffman" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: 1/04/2016 12:31:53 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

>>Isn't it a little late to be refighting this argument?

I guess now we have some hindsight maybe we could learn from the 
experiences with .onion and maybe look differently at a proposal for 
.alt.

>do), please at least reference in the document where your argument 
>fits. That way, the document authors can maybe amend the document if 
>there is consensus to do so.
Well I would start with what is presented as a quote from RFC 2826 which 
isn't actually in RFC 2686 and which seems to be the basis for a claim 
of even doing a special use names registry at all.

In Section 4. Architectural considerations

"Maintaining a globally-unique public namespace that supports different 
name resolution protocols is hence an architectural requirement..."

Adrien

---

From: "Adrien de Croy" <[email-masked]>
Date: Thu, 31 Mar 2016 20:28:28 +0000

sorry, that second reference should have also been RFC 2826

neither the word "Maintaining" nor "architectural" are present in 2826 
according to the search function in Chrome.

Adrien

------ Original Message ------
From: "Adrien de Croy" <[email-masked]>
To: "Paul Hoffman" <[email-masked]>; "[email-masked]" 
<[email-masked]>
Sent: 1/04/2016 9:25:07 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

>Well I would start with what is presented as a quote from RFC 2826 
>which isn't actually in RFC 2686 and which seems to be the basis for a 
>claim of even doing a special use names registry at all.
>