Subject: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

From: Warren Kumari <[email-masked]>
Date: Fri, 16 Sep 2016 17:53:53 -0400

Hi all,

I know that everyone is sick to death of this whole topic -- we've
been talking about it for *years* with very little progress, and it is
filled with annoying policy and politics discussions....

However, if there is not sufficient review and feedback for the chairs
to be able to select between them (or some other clear outcome), we
will be stuck... and then we will continue to talk about this topic ad
nauseam[0].

So, just like ripping off a bandaid, let's choose a document, perhaps
make some minor edits, ship it and then perhaps we can get back to
some more interesting, technical work...

W
[0]: Personally I thing that time passed a while back, but...

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

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 20 Sep 2016 15:33:57 +0200

On Fri, Sep 16, 2016 at 05:53:53PM -0400,
 Warren Kumari <[email-masked]> wrote 
 a message of 31 lines which said:

> However, if there is not sufficient review and feedback for the
> chairs to be able to select between them (or some other clear
> outcome), we will be stuck... and then we will continue to talk
> about this topic ad nauseam[0].

Or we could decide that the problem is not solvable in the current
context and tell that to the IESG. Some things are simply not
possible. And I'm still not convinced there is a problem to solve
(unless the real issue is "how to prevent the registration of .gnu and
.bit?")

The rest of this email is about
draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no
and no.

Problems
********

Despite many remarks on this list and in IETF meetings, the draft
continues to use disparaging terms like (section 1) "squatting".

Several remarks in the draft are dishonest because they could be
applied as well to many IETF technologies. It really seems the authors
felt the draft was too short and decided to pile in anything they
could find against 6761. For instance, section 3 says:

> [RFC6761] does not mention if the protocol using the reserved name
> should be published as an RFC document.

So what? It was never a problem at IETF to rely on protocols which are
not in a RFC. (See for instance the "Specification Required" policy in
RFC 5226.)

Another instance of the same problem, section 4 says:

> c.  Reserving a string in [RFC6761] does not guarantee queries will
> not leak in the DNS.

Requiring this is outrageous: there is no way to prevent
implementations to do stupid things. RFC 1918 does not "guarantee
packets will not leak [in the public Internet]" and nobody is going to
criticize RFC 1918 for that. (Not to mention the DNS leaks of
rfc1918-domains.arpa.)

Section 5:

> This leads to concerns about liability risks incurred by adding a
> particular string to the [RFC6761] registry.

There is no way to guard against any issue that a US lawyer may
raise. Until now, no owner of the Local or Onion trademarks
complained, or threatened to sue.

Errors
******

Section 1 :

> the GNU Name System (GNS) system is using block chains to build a
> decentralized name system

GNS does not use any blockchain. (Confusion with Namecoin?)

Little details
**************

Abstract :

> RFC 6761 introduced a framework by which a particular domain name
> could be acknowledged as being special.

Actually, suffix, not domain name (RFC 6761, section 4).

Section 1 :

> An algorithmic solution frequently chosen by application developers
> consists simply in using a special tag padded at the end of a name

Why calling it "tag", instead of "label" (or "suffix" if there are
several labels)?

---

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Sep 2016 09:46:36 -0400

On Tue, Sep 20, 2016 at 9:33 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> context and tell that to the IESG.

We could -- it is entirely possible that this is not a solvable
problem -- however, before we can make that determination, and even
more importantly, before we can clearly communicate that to the rest
of the IETF / IESG / <etc> we need to agree on what the *problem*
actually is.

This is what draft-tldr-sutld-ps is trying to do -- clearly document
the problems with special use names, not just the problems with
RFC6761.

Once we've documented the problem we can then discuss *mitigations* (I
suspect not solutions), and if there is anything useful we can
actually do...

W

> Some things are simply not

---

From: Mark Andrews <[email-masked]>
Date: Wed, 21 Sep 2016 11:01:14 +1000

I tend to agree that it may be impossible to give precise rules
for special names handling.  Below is my overview of the sitution.
6 is my opinion.

1) Today domain names are resolved with a number of protocols (e.g.
DNS, MDNS, TOR, NIS).

2) Some names are meant to be globally visible (*.onion) and some are
ment to be only be locally visible (*.local, *.10.in-addr.arpa) and
for some only the delegated authority knows the desired visibility
level.

3) Sometimes the contents of the name signals which protocol should be
used to resolve the name.  e.g. *.local -> mdns, *.onion -> tor.

4) Rules are sometimes needed to inform the resolution software about
which protocol to use.

5) Rules are sometimes need to handle lookups occuring in the wrong
protocol or the wrong place. e.g. *.onion in the DNS, AS112 servers
to 10.in-addr.arpa and locally served local zones, deliberate
breaking of DNSSEC chains of trust.

6) Names should only be used to identify stuff when you have been
delegated them either explicitly or implicitly (e.g. RFC 1918
implicitly delegates 10.in-addr.arpa to anyone using RFC 1918 space).

7) The default resolution mechanism is the DNS.  There are standard
proceedures for delegating names in the DNS.

8) Sometimes it is necessary to perform non standard delegations that
don't follow the normal proceedures as the requirements of the
delegation don't match the normal state of affairs.  The delegation
of .onion for the use of TOR is a example of such a delegation as
well as the delegation of .local for MDNS.

9) Such delegations by their very nature need to be handled on a case-
by-case basis which needs to be co-ordinated with the delegating
authority that normally handles that part of the namespace.  They
are exceptions to the normal rules.

10) Undelegated use of a name complicates the decision to delegate a
name either using conventional mechanisms or using exception
mechanisms.  So to does concurrent requests for a name especially
a TLD. So to does trade mark issues.

In message <[email-masked]>, Warren Kumari writes:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Tue, 20 Sep 2016 22:32:22 -0400 (EDT)

On Wed, 21 Sep 2016, Mark Andrews wrote:

> Below is my overview of the sitution.

I like Mark's summary below. I would add:

11) Some software has taken unused delegations causing dilemmas and/or
technical issues (eg .bit or .gnu)

12) Some hardware has taken unused delegations causing  dilemmas and/or
technical issues (eg .box for Fritzbox, .belkin). [note not all vendors
squated on their own brand, see .box]

And my own personal 13) would be:

 	The IETF would like to avoid making any decisions based on
 	specific names or trademarks, unless these pose a risk to
 	the stability and security of the resolving protocols. For
 	DNS specifically, it refers all naming issues to ICANN.

Paul

---

From: hellekin <[email-masked]>
Date: Wed, 21 Sep 2016 23:15:42 +0000

On 09/20/2016 01:33 PM, Stephane Bortzmeyer wrote:
>
> And I'm still not convinced there is a problem to solve

Even if I supported the SUDN of P2P systems draft mentioning both .gnu
and .bit, I see a great deal of difference between them. .gnu (and
.zkey, .exit, .i2p, .onion) all require (and request) an unique NXDOMAIN
response from DNS, and use their respective protocols to resolve from
the "stub resolver" (as mentioned in draft-tldr-sutld-ps-04.) .bit is a
special case in our I-D because it proposes an alternate way of DNS
resolution, not using a delegated tree, but a blockchain.  With regard
to DNS, .bit is different from the other five, besides the political
effects of its specific approach (which I think should be able to exist
anyway, for the sake of Internet End-to-End principle if nothing else.)

None of the problem statement drafts took reference of the Special-Use
Domain Names of P2P Systems which initiated this years long discussion
that ended up with: should we revise or replace RFC6761.  In my position
of editor of this draft, I don't really care what happens to RFC6761,
but I'm very much interested in .gnu & .zkey, .i2p, .onion & .exit, and
.bit.  I don't think any of the proposed problem statement drafts
mention the perspective of actual P2P networks sharing their experience
and their existence, and coming to the table with the idea of abiding to
the IAB rule of a globally unique namespace.

We say: hey, look, we exist, and we want to say that these are not
transactional names: they bear cultural value.  They came from usage and
the history of the Internet.  The DNS should know about them, so that
people won't ever get into trouble trying to resolve non-existing names,
or trying to resolve eventually delegated names that will collide with
existing networks if they keep being ignored by DNS.

I had the time to appreciate the nuances that IETF members can find in
this seemingly simple approach, and try to generalize the issue: "what
if others come and do the same? Who's responsible? How to judge of the
legitimacy of those claims?" Etc.

But what's been going on, from my point of view of volunteer who only
has one life (that at least we share) and doesn't get paid for this
work, is choking-by-bureaucracy.  People whose profession is to sit on
IETF WGs can spend their time not solving issues, they still get food on
the table.  And so production of norms is an endless process, and if not
this one, another.

As I see it, the problem we're trying to address is whether these P2P
systems warrant some recognition from the Internet Community, is that
something we want to encourage, or is that something that belongs to
"the Deep Web", and we'd better leave that out of the picture?  I'm not
talking about .mail, .corp, and .home, that belong to another category
(I like "toxic waste"), or "people trying to circumvent IANA processes",
or "don't want to pay", or "don't want to follow process".  We did
follow process, once we realized there was one.  And suddenly, after a
decade, everybody realizes there's an RFC6761 that really shouldn't have
become an RFC in the first place, and this process is flawed, and we
don't know how to handle this.  But when the Browser Forum comes with a
deadline, consensus is easily achieved in no time, despite the draft is
flawed with idiotic requirements such as "Users are expected to...".

My take is that none of the proposed statement drafts took care of
situating the debate in its (recent) historical context.  The fear of
frictions between IANA and IETF have had more to do with how things
went, than actual ponder of the technical arguments put forth by the
various RFC6761-based drafts.  Case by case is not necessarily evil: not
everything can nor should be automated.

I believe that in the case of the 6 TLDs we asked for, there's little
doubt they make sense technically, historically, and culturally.  That
others may take it as 'a way in' and flood the IETF with stupid drafts
'just in case' seems to me the core of the problem, that was mentioned a
few times over the years, but didn't make it through the recent drafts.

> draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no

This is a great summary, thank you!

==
hk

---

From: George Michaelson <[email-masked]>
Date: Thu, 22 Sep 2016 09:30:11 +1000

None of these named spaces would "fail" to work as sub-spaces of .ALT
or .arpa or any other community-led IETF tech community managed label.

You haven't convinced me they innately need to exist as a TLD. The
sole entrypoint into that model, is a belief in what happens in the
browser bar and at the shell.

You are the designer of systems of world scale, I do not doubt. But
you are bringing an assumption to the table: all things of world scale
do not have to exist at the top of the worldwide name space.

I remain unconvinced. I remain of the belief, that shutting 6761 down
is wiser than racionation over the problem space, without recognizing
intractable elements to this problem because its not at root a
technology problem: its a name problem. We gave that role to somebody
else.

-G

On Thu, Sep 22, 2016 at 9:15 AM, hellekin <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> -----BEGIN PGP SIGNATURE-----
>
> iQJ8BAEBCgBmBQJX4xScXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
> ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg95ckP/0/Ub0IPt7VQWBbjH914gbAP
> v1fKjQhuMSUiuYa+KJ7AyYTvTjqH6+NgEx5T/1a5F+tcTlD7rEQ6C4UDYqUTqUBS
> fa+H0i3sGkJT7it6vV5sjB9LTLb2Dmxff6uZkeBVtUbrun2Xl9uzBq9+rBloBQN0
> 5WDr2ykEbnTIBIM2bbBlhJSpHO6jhLgXhYQkWiFK+7c1zI2X3qNp6dlCnwJ9Gy7d
> KNQNUMmBllAepF6kF0kXv07I8cEPjx9bRc6LY5wIW08Sa3j3R0UEtzBoUODFr/oJ
> RbIq0bJgK8COZfEzEv6oJ1iDT64JXi2FxlPflBdqgFHiPQSX1Ermm1UtJU1Wrrcb
> S/Y6890dyJOa+014KUBdroGeH/MfZLHwKJELi6bs2wENkGp8ye6LwIOeJBOfJ47/
> 6Tt7ow+j9y05Xjh9lM1pOlQdlsusLmOHiBQ7cfWb1uo3XYCr5e86cUQ6S/3iBg17
> y0WfX1mFjWTvBnrLqMQrXTThiItMT+WN5JzkEcwfMv00oF62DQYh89WPzQ1SVSqQ
> vCQbCi5a25JfLtbS/LgJo4diXlnayMhJ5RtQIdBEbej2kO971eoYLxwma8jDB3gv
> mV8cJcjg4juj8Rpp0+eYsSNnOSlHcuZoaJBrpgd7XQNejuLZdR5/E3NmY1T+0Kif
> vVimJR3aa0C5SQQVFDxM
> =1b0u
> -----END PGP SIGNATURE-----
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Sep 2016 19:57:06 -0400

The problem with this kind of certainty is that it's not conducive to
reaching consensus.   The reality is that there are a broad set of people
with interest in this question, and they have different beliefs and
different motivations.

That's why it's important to go through the exercise of having those people
say "this is what I see myself losing if (for example) RFC 6761 is
deprecated with no replacement."   And then we see who those people are,
what they will do if they don't get what they want, and so on.

The problem with the way you are coming at it is that you are just one of
those people, and what you lose with your proposed way forward is nothing
you care about, and what you gain is something you care about a great deal.
  There are many people in the exact same situation in this discussion, but
with different things that they lose and gain.   So we have to all try to
understand each others' perspectives in order to come up with a way forward
that can gain consensus.   We can't just start arguing over which way
forward to choose without doing that groundwork first.

---

From: George Michaelson <[email-masked]>
Date: Thu, 22 Sep 2016 10:31:07 +1000

This is true. I am being overtly indulgent, to assert my view, and
assert my view hasn't changed. This is thomist logic. It's not very
conducive to consensus because it doesn't converge, it just rebuts.

I do this, because I find the views I am seeing appear to imply a
consensus around other views, which make huge inferential leaps (for
me at least) about loss/damage from being excluded from existing as a
TLD. Why do we necessarily reify these beliefs? Whats the technical
merit in the argument as it stands?

You are a consensus seeker, and I value that. I sense the emerging
consensus, and you will note I allowed my draft to expire and have not
re-submitted.

To address the primary question from the WG chairs, I find very hard.
One document is briefer than the other, and despite my own writing
style (!) I value brevity immensely.

On the other hand, the longer documents goes further in recognizing
name processes are really inherently tied to ICANN process more than
technical merit arguments. This pleases me, because I feel drawn to
the view the problems are best expressed as "this is done by somebody
else, in another equity process"

I invite other people to consider technical-needs statements from
parallel WG and standards authors skeptically. Ask yourself what
burden developers would take, if they had to code to a 2LD, and ask
yourself what community burden is taken in the wide, if a new TLD is
allocated in 6761 to break out of the DNS. The primary problem is how
labels express in tools. The omnibox, browser-bar and shell
command-level arguments point to gethostbyname() very very early.
Maybe, thats the underlying fundamental problem here more than
inclusion or exclusion from the DNS? (I have said this before btw,
both here and at the microphone)

The uber-conversation, what kind of name-to-record mapping we want, is
progressing quite nicely. I like Brian Trammell's work. I like Ed's
work recording history (although I could diverge from it) and I don't
think the problem-space overall is not being thought about.

-G

---

From: Alain Durand <[email-masked]>
Date: Thu, 22 Sep 2016 03:02:55 +0000

> On Sep 21, 2016, at 8:31 PM, George Michaelson <[email-masked]> wrote:
> 

This is an interesting observation, as one of the comments we have received many times about the first revisions of draft-adpkja was that the references to ICANN were not helping. We even took heat for mentioning 2860...

I guess this reflects on the multitude of diverging opinions on the subject.

Alain.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Sep 2016 23:25:42 -0400

I am not sure at this point, but I suspect the objection had to do with
section 6.3 of the -02 document that was published before Buenos Aires:
https://tools.ietf.org/html/draft-adpkja-dnsop-special-names-problem-02

Both documents mention 2860, and I don't see anything in particular to
disagree with about how the adpkja document references it, or, indeed, how
it referenced it in the -02 version.   However, the old section 6.3 does
remind me of some things I heard people objecting to in BA.

On Wed, Sep 21, 2016 at 11:02 PM, Alain Durand <[email-masked]>
wrote:

> This is an interesting observation, as one of the comments we have
> received many times about the first revisions of draft-adpkja was that the
> references to ICANN were not helping. We even took heat for mentioning
> 2860...
>

---

From: hellekin <[email-masked]>
Date: Thu, 22 Sep 2016 11:40:01 +0000

On 09/22/2016 12:31 AM, George Michaelson wrote:
>
> what community burden is taken in the wide, if a new TLD is
> allocated in 6761 to break out of the DNS.
>

I'm sorry but, what do you mean 'to break out of the DNS'?

==
hk

---

From: hellekin <[email-masked]>
Date: Thu, 22 Sep 2016 11:32:06 +0000

> or .arpa or any other community-led IETF tech community managed label.

All of them with a requirement for global uniqueness will fail with
.ALT, per .ALT draft.  Etc.

> do not have to exist at the top of the worldwide name space.

I don't understand what you mean.  We come to the table saying: the
globally unique namespace of the Internet needs to recognize non-DNS
ways to resolve names, that are by technical design incompatible with
the delegation model of the DNS.  The way to do that, according to
RFC6761, is to put these non-DNS TLDs into a registry that tells DNS to
always send NXDOMAIN to tell the systems: no, that does not resolve with
the DNS.

> because its not at root a technology problem: its a name problem.
>

I think we have both.  The technical aspect I just formulated.  The
naming aspect so far boiled down to "Why X and not Y?", which indeed, is
not entirely technical (and the answer is: because it occurred like
that, and there's no name collision.)

Regards,

==
hk

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 25 Sep 2016 11:02:04 +0000

On Tue, Sep 20, 2016 at 09:46:36AM -0400,
 Warren Kumari <[email-masked]> wrote 

> of the IETF / IESG / <etc> we need to agree on what the *problem*

But some people (like me) are not convinced there is a problem. RFC
6761 is imperfect (like every RFC) and can be improved, but it works
(two TLD were registered through it).

---

From: Ted Lemon <[email-masked]>
Date: Sun, 25 Sep 2016 12:23:15 -0400

Stephane, have you read draft-tldr-sutld-ps?   I would be curious to know
if you disagree with the specific set of problems enumerated there; I
realize that you don't believe that there is a problem that motivates a
change; my question is, do you agree or disagree that the things described
in the document are problems?

---

From: Paul Wouters <[email-masked]>
Date: Sun, 25 Sep 2016 12:35:00 -0400 (EDT)

> (two TLD were registered through it).

Are you referring to the two registrations as successes or failures,
because I don't think you will find agreement even on that part.

Paul

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 28 Sep 2016 21:24:06 +0000

On Sun, Sep 25, 2016 at 12:35:00PM -0400,
 Paul Wouters <[email-masked]> wrote 
 a message of 16 lines which said:

> > it works (two TLD were registered through it).
> 

In the absence of criteria for defining success or failure of a
special-use TLD, it will be hard to tell. But the _process_ was a
success: applications were written, examined, and the registry was
updated.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 28 Sep 2016 21:21:52 +0000

On Sun, Sep 25, 2016 at 12:23:15PM -0400,
 Ted Lemon <[email-masked]> wrote 
 a message of 72 lines which said:

> Stephane, have you read draft-tldr-sutld-ps?

Yes, but did not had time to post a sensible review, sorry.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 Sep 2016 09:59:33 -0400

> On Sep 28, 2016, at 17:24, Stephane Bortzmeyer <[email-masked]> wrote:
> 

If the process was a success, we would have had the other candidates go through as well. The process was a failure because it has been rather arbitrary - which is why it needed to close down as it did.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Sep 2016 10:21:04 -0400

To be clear, while the IESG may have said something about their
willingness to entertain further uses of the 6761 process, the 6761
process represents current IETF consensus.   If we don't update it, it
stands.   The IESG does not have the authority to overrule IETF
consensus. There's some sense that 6761 is inadequate, and that
perhaps were the IETF to be asked for a consensus now, 6761 would not
be what that consensus would be.   That's why we decided to write a
problem statement: to try to figure out if indeed there is a consensus
can be reached, and if so, what it is.

(Bear in mind that consensus does not mean "everyone agrees.")

---

From: Paul Wouters <[email-masked]>
Date: Thu, 29 Sep 2016 10:27:04 -0400

On Sep 29, 2016, at 10:21, Ted Lemon <[email-masked]> wrote:
> stands.  

That does contract earlier statements  from dnsop that stated no new 6761 based special names would be considered until we had a new solution.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Sep 2016 10:50:54 -0400

Carrot and stick. The current IESG can certainly abstain new proposals to
death, and individual ADs can refuse to publish. But in doing so they are
trying to lead the consensus on a new direction. They cannot unilaterally
change it.

On Sep 29, 2016 10:27, "Paul Wouters" <[email-masked]> wrote:

> That does contract earlier statements  from dnsop that stated no new 6761
> based special names would be considered until we had a new solution.
>
> Paul
>