Subject: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-05.txt

From: [email-masked]
Date: Mon, 12 Sep 2016 04:57:05 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations of the IETF.

        Title           : The ALT Special Use Top Level Domain
        Authors         : Warren Kumari
                          Andrew Sullivan
	Filename        : draft-ietf-dnsop-alt-tld-05.txt
	Pages           : 10
	Date            : 2016-09-12

Abstract:
   This document reserves a string (ALT) to be used as a TLD label in
   non-DNS contexts or for names that have no meaning in a global
   context.  It also provides advice and guidance to developers
   developing alternate namespaces.

   [ Ed note: This document lives in GitHub at:
   https://github.com/wkumari/draft-wkumari-dnsop-alt-tld . Issues and
   pull requests happily accepted. ]

   [ Question for Working Group.  It has been proposed that the string
   .ALT should be replaced with something else e.g. .NOT-DNS.  As naming
   discussions in the IETF are always short, simple, and not
   controversial, we figured we should open these for discussion now.
   We would appreciate clear feedback on preference and rationale. ]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: George Michaelson <[email-masked]>
Date: Tue, 13 Sep 2016 10:27:43 +1000

Alt being semantically overloaded in times past, contextually even in
domain names (Usenet, the great renaming)  It seems highly unwise to
ignore that historic understanding that people thought it meant the
same thing as "burning man"

The string >not-dns< has two useful properties: its not currently
semantically loaded, and its meaning is unambiguous.

It has a third useful property: Its ugly.

Personally, I favour use of the unicode U+FFFD � REPLACEMENT CHARACTER

-G

On Mon, Sep 12, 2016 at 9:57 PM,  <[email-masked]> wrote:
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Warren Kumari <[email-masked]>
Date: Mon, 12 Sep 2016 21:02:07 -0400

> Personally, I favour use of the unicode U+FFFD � REPLACEMENT CHARACTER

This (and your third property) is where we disagree -- there is
nothing that we can do to prevent people from simply squatting on
names. We are not the namespace police. This means that whatever we
select needs to be as attractive as possible if we want any hope of
people using it. Making it ugly, or impossible to type, or in any
other way implying that other resolution systems are second-class
citizens simply means that people won't use it, and will just squat on
whatever they choose.

I'm assuming you were actually meaning "not-dns" and not ">not-dns<"
-- if you were actually proposing the latter, we have a larger gulf --
the names need to be useable anywhere current domain type names are -
this includes things like browsers, but also includes other apps, like
SSH, FTP, etc.

foo.alt (and foo.not-dns) both are accepted by OpenSSH (as an example):
ssh: Could not resolve hostname foo.atl: Name or service not known
wkumari@ron:~/tmp$ ssh foo.not-dns
ssh: Could not resolve hostname foo.not-dns: Name or service not known

foo.>not-dns< (obviously enough) isn't:
wkumari@ron:~/tmp$ ssh foo.>not-dns<
-bash: syntax error near unexpected token `newline'
wkumari@ron:~/tmp$

If we don't provide people an (acceptable) alternative, and at least
try and meet their needs, we lose any sort of right to shake a finger
and say "Bad dog!" when they widdle on the namespace...

-W

-- 
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: George Michaelson <[email-masked]>
Date: Tue, 13 Sep 2016 11:38:03 +1000

If you wish to make it attractive, the meeting point is probably not-dns

because alt is .. too desireable by others with different intent, in
the real world.

(I didn't mean >not-dns<)

the advantage of the unicode choice, was purely that it avoided
semantic meaning and was unlikely to be chosen. But I did also hope,
that it would terminate in DNS of older code. A useful side-effect.

G

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 13 Sep 2016 08:05:58 -0700

> If you wish to make it attractive, the meeting point is probably 

Agree.

> because alt is .. too desireable by others with different intent, in

It is also too unclear even to people who think it means "alternative": 
this name is an alternative to what? That's the same problem that the 
label had in the Usenet days.

> (I didn't mean >not-dns<)

Good, I had the same concern that Warren did.

> that it would terminate in DNS of older code. A useful side-effect.

Not at all: it would just cause people who might get value from the new 
name not to use it. I agree with Warren: we want this name to feel like 
a first-class label.

--Paul Hoffman

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 25 Sep 2016 16:25:37 +0000

On Mon, Sep 12, 2016 at 04:57:05AM -0700,
 [email-masked] <[email-masked]> wrote

>       Filename        : draft-ietf-dnsop-alt-tld-05.txt

The previous versions were, and I think it was good, carefully
non-normative. .ALT was presented (as it should) as a MAY, not a MUST
or a SHOULD. Now, sentences like "This document provides a solution
that may, in many cases, be more appropriate than [RFC6761]." are,
IMHO, too much. I suggest "This document provides, in some cases, an
alternative solution to [RFC6761]"

Also, disparaging terms like "pseudo-TLD" should be avoided. "Non-DNS
TLD" is sufficient.

> This label is intended to be used as the final (rightmost) label

No. It is rightmost only in LTR scripts. "final" is correct,
"rightmost" isn't. Please delete it.

> For example, a group wishing to create a namespace for Friends Of
> Olaf might choose the string "foo"

If this namespace uses a non-DNS protocol for resolution, it may be
case-sensitive and therefore it should be "FoO". (Yes, this was a
troll.)

---

From: Jim Reid <[email-masked]>
Date: Sun, 25 Sep 2016 17:51:54 +0100

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

The original text is correct and doesn’t need fixing. Well, at least the quoted extract doesn’t.

Domain names are written left to right. So the final label (apart from the terminating NUL label for all the pedants on this list) is the rightmost component. Saying "final (rightmost) label” removes any uncertainty or scope for ambiguity. Saying “final label” would ADD that uncertainty for anyone out there who’s on really good drugs^W^W^W^W^Wusing a DNS-like name space that’s ordered from right to left. Mind you someone that misguided is unlikely to ever read this draft or RFC if it gets that far.

---

From: hellekin <[email-masked]>
Date: Sun, 25 Sep 2016 17:48:09 +0000

>    developing alternate namespaces.

Finally I read this draft after I realized the presence of this "or" in
"... in non-DNS contexts *or* for names that have no meaning in a global
context."

I must apologize for staying on
https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-04 and not
reading anymore of this draft, as it was explicitly stating the following:

"The ALT label MAY be used in any domain name as a pseudo-TLD to signify
that this is an alternate (non-DNS) namespace."

And:

"Currently deployed projects and protocols that are using pseudo-TLDs
(for example, the ".onion" pseudo-TLD (and other labels in
[I-D.grothoff-iesg-special-use-p2p-names]) are encouraged but not
required to move under the ALT TLD.  Rather, the ALT TLD is being
reserved so that future projects of a similar nature have a designated
place to create alternate resolution namespaces that will not conflict
with the regular DNS context."

Yet, this explicit recognition of existing name requests for P2P systems
was removed from the next draft on, and is obviously absent from the
current draft-ietf-dnsop-alt-tld-05.txt, which implicitly declares the
special-use names of P2P systems as falling under .ALT.  Since this
draft is reserving the .ALT TLD using RFC6761, and there's an ongoing
discussion about this RFC to figure out a proper way to use it, update
it, or dismiss it, I find the situation unacceptable.  Please correct me
if I'm wrong, but it really seems to me that this is the case, and that
the .ALT draft, which wasn't meant to threaten the history of the P2P
names, indeed became a way to easily dismiss any further discussion
about them.

Regards,

==
hk

---

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Sep 2016 16:18:32 -0400

> alternative solution to [RFC6761]"

I'm fine with that[0]. Please keep in mind that this document has been
around since early 2014, and has gone through many revisions (11, 6 as
an individual, and 5 as a WG doc). Since 2015-11-17 it has been a
"Parked WG Document" ("Waiting for the 6761 design team to sort out
the bigger issues before moving this forward.").
It was started before there had been much discussion on the Special
Use Names problems (draft-adpkja-dnsop-special-names-problem and
draft-tldr-sutld-ps were not even twinkles in the author's eyes), and
so it contains much background and discussions which may no longer be
needed - I've been told that this will finally be unparked as soon as
a decision is made on the problem statement, and we'll be happy to
revise it then.

> Also, disparaging terms like "pseudo-TLD" should be avoided. "Non-DNS

"pseudo-TLD" was in no way intended to be disparaging -- we had
defined it as "A label that appears in a fully-qualified domain name
in the position of a TLD, but which is not registered in the global
DNS.". Again, this was started in 2014 - there hadn't been much
discussion at this point. I really don't like "Non-DNS TLD", but I
also don't really like "pseudo-TLD" -- once we are allowed to make
proper edits to it again we'll happily put in whatever the WG wants --
and, suggestions welcome....

> case-sensitive and therefore it should be "FoO". (Yes, this was a

... was it? It raises an interesting point - seeing as alternate
resolution contexts are likely to want to have their names be able to
be used anywhere where a "traditional" DNS names is used, they will
likely also be (ASCII) case insensitive, because some apps likely
flatten case before handing to a resolver system. But, this seems like
a decision that the resolution system designed could make - perhaps it
is worth mentioning (again, once unparked) in the doc.
foo.alt MAY be different to foO.alt... perhaps....

Anyway, I'm really trying to stay away from solution discussions until
a problem statement is adopted....

W
[0]: We had been asked to put in the original text, but we will (of
course) do whatever the WG wants.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Sep 2016 22:37:18 -0400

> names, indeed became a way to easily dismiss any further discussion

This document is not intending to stop discussion of the P2P names. In
my opinion, discussions on those is orthagonal to these. If .ALT is
created and any of them are able to AND would like to, they can move
under .ALT. One of the main things that we seem to have learned from
the Special Use Names discussion is that we are not the DNS police.
There is nothing that we can do to prevent somebody from "squatting"
on a string. The only thing we can do is provide a sandbox for those
who would like to use it, which will not collide with delegated TLDs.
The .ALT draft is still parked and so we are not making significant
changes to it at the moment. Once it is unparked, we are happy to
incorporate the working group's desires and text. In deference to the
chairs, let's not open these discussions at the moment. (We believe
this will be unparked soon.)

It's been a really long time, but IIRC, we removed the mention of the
P2P names because we thought you wanted that -- somewhere around this
whole discussion:
https://www.ietf.org/mail-archive/web/dnsop/current/msg13338.html

My opinion really doesn't matter, but I happen to think that, at this
point, we should evaluate the requested P2P names according to RFC
6761  -- you followed the process in effect *at the time*, and jumped
through many hoops. The process is far from perfect (see
draft-tldr-sutld-ps) but that *was* the process at that point, and so
your drafts should (IMO) be evaluated against that. If the IETF had
been able to quickly and clearly come to consensus that the process
was broken, and what to do to fix it, I might feel differently, but
changing the rules retroactively feels unfair.

Interestingly enough, just above that mail, Stephane also objected to
"pseudo-TLD", but we asked the WG for a better term and (IIRC), didn't
get any better suggestions:
"Can you suggest a better term (noting that this term is used in both
RFC6761 and draft-grothoff-iesg-special-use-p2p-names-04)?
They are things that look like TLDs when leaking into the DNS context,
but are not actually TLDs.

This seems to be a very common term, and was not intended to be
perjorative, see for example:
RFC6761 - Special-Use Domain Names
(https://tools.ietf.org/html/rfc6761)  Section 1:
"This is typically done by stating that any fully qualified domain
name ending in a certain suffix (i.e., falling within a specified
parent pseudo-domain) will receive the special behaviour. "

draft-grothoff-iesg-special-use-p2p-names-04, Section 3 (Terminology
and Conventions Used in This Document):
"The abbreviation "pTLD" is used in this document to mean a pseudo
Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761]
reserved to P2P Systems in this document."

RFC1429 - Listserv Distribute Protocol, Section 3.3:
"You can use the pseudo-domain ".BITNET" for BITNET recipients: it is
always supported within DISTRIBUTE requests."

RFC1849 -  "Son of 1036": News Article Format and Transmission (Historic):
"The pseudo-domain ".uucp" MAY be used for hosts registered in the
UUCP maps ...."

'Measuring the Leakage of Onion at the Root “A measurement of Tor’s
.onion pseudo-top-level domain in the global domain name system”' -
Matthew Thomas and Aziz Mohaisen.
https://www.petsymposium.org/2014/papers/Thomas.pdf
"

---

From: hellekin <[email-masked]>
Date: Tue, 27 Sep 2016 08:33:04 +0000

> changing the rules retroactively feels unfair.

Thank you for your clarification.  Indeed the discussion was long ago
and details slipped from memory.

> but are not actually TLDs.

I remember introducing the term 'pseudo-TLD' in the P2P Names draft and
doing a similar research as the one I cut from your message for brevity.
 At the time I thought the Canada Dry effect would work: it looks like
DNS, it tastes like DNS, but it's not DNS, hence 'pseudo'.  But indeed
that can as well bring confusion.

I have no alternate suggestion at this point, but I have one to avoid
talking about "squatting" names: "using names without ICANN sanction".
It may be longer, but it's more accurate, and doesn't conflate a
legitimate but often criminalized practice with a fact of usage that can
stem from many reasons, one of them being the need of humans to name
things. Using names without ICANN sanction also speaks to people who
don't know why it's a problem, and places it in the correct context
where the problem can then be solved.  Except, of course, if that
particular name represents a technical issue ;o)

==
hk

---

From: Ray Bellis <[email-masked]>
Date: Tue, 27 Sep 2016 09:45:11 +0100

> that can as well bring confusion.

Personally, I like the term.

Ray

---

From: Jim Reid <[email-masked]>
Date: Tue, 27 Sep 2016 15:25:24 +0100

> On 27 Sep 2016, at 09:45, Ray Bellis <[email-masked]> wrote:
> 

Meh. I wish the WG could stop the shed-painting on a frankly pointless detail and concentrate its efforts on producing a viable problem statement.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Sep 2016 13:52:59 -0400

> Meh. I wish the WG could stop the shed-painting on a frankly pointless detail and concentrate its efforts on producing a viable problem statement.

.... we have two of them --
http://tools.ietf.org/html/draft-adpkja-dnsop-special-names-problem
and https://tools.ietf.org/html/draft-tldr-sutld-ps-04 . Neither of
them is great, but both are IMO "viable" - I prefer the second, but
whichever the chairs decide to adopt will be a fine starting point.
Once there is an adopted problem statement we should be able to
actually make some progress on updating the document (I think that
both are actually fairly close, but we'll see), and should also be
able to unpark ALT.
ALT doesn't solve any of the major issues, but it *does* create a safe
place for those people who want to experiment and build alternate
resolution systems -- and takes some of the pressure off while we
discuss solutions....

W

---

From: Jim Reid <[email-masked]>
Date: Tue, 27 Sep 2016 19:38:52 +0100

> On 27 Sep 2016, at 18:52, Warren Kumari <[email-masked]> wrote:
> 

Indeed Warren. That’s one too many.

They both come up short as problem statements IMO. I’m struggling to find words to succinctly describe what problem the WG is expected to solve - sorry about that -- since it appears to be a layer 9+ matter. Both drafts seem to be concerned with treating (some of?) the symptoms rather than the root cause(s). Excuse the pun.

> resolution systems -- and takes some of the pressure off while we

True. But that seems to be putting the cart before the horse. Where’s the demand from experimenters and why do they need a dedicated TLD for their alterate resolution systems? That’s a rhetorical question BTW. Answering it may well distract the WG from its quest for that one true problem statement to rule them all. So please don’t do that. :-)

FWIW I’m sceptical about creating .alt as a playpen for experiments since it might undermine efforts to answer the question ICANN asked us, whatever that question might be, or be the start of a slippery slope. Maybe a TLD is needed for experiments. Maybe not. However that’s something to discuss once we’ve figured out what has to be done about special* TLDs in general. *For some as-yet-unclear definition of special.

I think the WG should step back from both drafts, take a deep breath and agree a problem statement. Once that’s done, we’ll be in a better place to decide what to do with both drafts.

Easier said than done I know...

---

From: william manning <[email-masked]>
Date: Tue, 27 Sep 2016 11:48:42 -0700

I think Jim is on to some thing here.   I suspect part of the problem is
that there is no crisp understanding of what the DNS actually is.  Without
that it is much harder to say what it is not.

/Wm

On Tue, Sep 27, 2016 at 11:38 AM, Jim Reid <[email-masked]> wrote:

> >> Meh. I wish the WG could stop the shed-painting on a frankly pointless
> detail and concentrate its efforts on producing a viable problem statement.
> >
> They both come up short as problem statements IMO. I’m struggling to find
> words to succinctly describe what problem the WG is expected to solve -
> sorry about that -- since it appears to be a layer 9+ matter. Both drafts
> seem to be concerned with treating (some of?) the symptoms rather than the
> root cause(s). Excuse the pun.
>
> True. But that seems to be putting the cart before the horse. Where’s the
> demand from experimenters and why do they need a dedicated TLD for their
> alterate resolution systems? That’s a rhetorical question BTW. Answering it
> may well distract the WG from its quest for that one true problem statement
> to rule them all. So please don’t do that. :-)
>
> FWIW I’m sceptical about creating .alt as a playpen for experiments since
> it might undermine efforts to answer the question ICANN asked us, whatever
> that question might be, or be the start of a slippery slope. Maybe a TLD is
> needed for experiments. Maybe not. However that’s something to discuss once
> we’ve figured out what has to be done about special* TLDs in general. *For
> some as-yet-unclear definition of special.
>
> I think the WG should step back from both drafts, take a deep breath and
> agree a problem statement. Once that’s done, we’ll be in a better place to
> decide what to do with both drafts.
>

---

From: Warren Kumari <[email-masked]>
Date: Tue, 27 Sep 2016 16:11:34 -0400

> Indeed Warren. That’s one too many.

Yup. Some would say that that is two too many :-). I think that the
CfA ended last Friday, so hopefully there will only be one RSN.

>
> They both come up short as problem statements IMO.

Yup. They are not perfect - but hopefully whichever is selected will
be good enough starting point.

>  I’m struggling to find words to succinctly describe what problem the WG is expected to solve - sorry about that -- since it appears to be a layer 9+ matter.
> Both drafts seem to be concerned with treating (some of?) the symptoms rather than the root cause(s). Excuse the pun.

Yup, much of this *is* policy / layer-9 issues -- unfortunately this
doesn't make it not a problem, it just makes it all more annoying (as
someone who spends much of his time doing ICANN stuff, I can attest to
this :-))

We listed the symptoms, but I think also the root issue -- IMO the
root of the root issue is that there is a *single* namespace and
multiple organizations can reserve / allocate from it, or simply use
strings without allocation if the process is too onerous. Oh, and
because one use became dominant, it is the (assumed) default, and
there is no clear switch. This is a wild simplification, and leaves
out much subtlety, but IMO boils the issue down to the bones...

> FWIW I’m sceptical about creating .alt as a playpen for experiments since it might undermine efforts to answer the question ICANN asked us, whatever that question might be, or be the start of a slippery slope.

Um, which question ICANN asked us?

>Maybe a TLD is needed for experiments. Maybe not. However that’s something to discuss once we’ve figured out what has to be done about special* TLDs in general. *For some as-yet-unclear definition of special.
>

Well, the CfA has finally concluded, so now we are just waiting on a decision.

W

---

From: Alain Durand <[email-masked]>
Date: Tue, 27 Sep 2016 20:13:29 +0000

> On Sep 27, 2016, at 2:38 PM, Jim Reid <[email-masked]> wrote:
> 

Jim,

When we tried to frame this as L9 issues, the overwhelming wg feedback was: keep it technical. So we did, and now people realize there is an elephant in the room.
We don’t appear to converge here, and maybe we can’t. See the email Ed Lewis sent a few days ago...

Alain.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 27 Sep 2016 17:14:49 -0400

Jim, I asked you this privately, but your mail server bounced my mail for
no obvious reason with:

550 5.7.1 <mail-lf0-f41.google.com[209.85.215.41]>: Client host rejected:
No thanks.

So, what do you think "the root cause" is?

---

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

On Sun, Sep 25, 2016 at 05:51:54PM +0100,
 Jim Reid <[email-masked]> wrote 

> the quoted extract doesn’t.

As you can imagine, I disagree.

> Domain names are written left to right.

In english, yes, not in general. They are always written from the
beginning to the end (obviously) and the final label can be at the
left in a RTL script.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Thu, 29 Sep 2016 09:50:13 +0200

> beginning to the end (obviously) and the final label can be at the

There is no such thing as a language attribute to doamain names.
They are just strings.

	jaap

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 29 Sep 2016 14:24:18 +0200

On Tue, Sep 27, 2016 at 07:38:52PM +0100,
 Jim Reid <[email-masked]> wrote 
 a message of 35 lines which said:

> Where’s the demand from experimenters

The demand? You see it in the use of non-ICANN TLDs like .onion or
.bit.

> and why do they need a dedicated TLD for their alterate resolution
> systems?

You may think they don't NEED it but how will you convince them? (The
IETF has no police force, so our only course of action would be to
convince people.)

> FWIW I’m sceptical about creating .alt as a playpen for experiments
> since it might undermine efforts to answer the question ICANN asked
> us,

ICANN asked us what? When and where (URL, please)?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 29 Sep 2016 14:29:40 +0200

On Thu, Sep 29, 2016 at 09:50:13AM +0200,
 Jaap Akkerhuis <[email-masked]> wrote 

> There is no such thing as a language attribute to doamain names.

Tell that to ICANN, which continues to use "languages" when they mean
"scripts" :-(

But if you want precision, let's go:

A domain name is written from left to right if it is composed entirely
of characters from LTR scripts (for instance the latin script, used to
write english). If the domain name is composed of characters from RTL
scripts, it is written from right to left (the TLD will be the
leftmost label).

[Of course, this is only the text representation, the wire one is
unaffected.]

The case of Bidi FQDN (RTL and LTR characters) is left as an
exercice...

---

From: Jim Reid <[email-masked]>
Date: Thu, 29 Sep 2016 14:00:41 +0100

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

Stephane, please stop this rat-holing and whatabootery. [Raising non-sequiturs: what about...] It is not helping the production of a problem statement. I hope you can focus your efforts on that.

---

From: "Patrik Fältström" <[email-masked]>
Date: Thu, 29 Sep 2016 15:18:23 +0200

> Tell that to ICANN, which continues to use "languages" when they mean

If it was that easy... :-P

   paf