Subject: [DNSOP] Please review and provide feedback -- draft-stw-6761ext

From: Warren Kumari <[email-masked]>
Date: Tue, 6 Aug 2019 15:43:43 -0400

Hi there,

It's time again for everyone's favorite topic -- Special Use Domain Names!

Back in October 2015 the IETF approved RFC7686 - 'The ".onion"
Special-Use Domain Name' -- those who were involved no doubt remember
that it was a really long and frustrating set of discussions, and we
determined that there is much broken in this process.

To job people's memory, Jari penned a nice summary here -
https://www.ietf.org/blog/onion/ :
"Some contention arose during the processing of the document in the
working group. There also was some discussion about needing to clarify
or adjust RFC 6761 before making any additions.
...
However, subsequent to this action, the IESG believes RFC 6761 needs
action, and substantial community input. It needs to be open for
review and modification because the current process is unscalable.
Several other names had also been submitted for consideration as
special names, and the RFC may not give adequate guidance about how
when names should be identified as special names. Special names should
also be, as the name implies – special and rare. The DNSOP working
group is chartered to address this RFC 6761 review."

The IESG tasked DNSOP with providing better guidance on how to handle
future requests to reserve names under the RFC6761 process[0]. As part
of that we wrote RFC8244 - "Special-Use Domain Names Problem
Statement", which "should be considered required reading for IETF
participants who wish to express an informed opinion on the topic of
Special-Use Domain Names.".  RFC8244 "presents a list, intended to be
comprehensive, of the problems that have since been identified", but
we ran out of steam without actually *solving* the issues.

Later (April 2016) RFC7788 - "Home Networking Control Protocol" was
published which included "A network-wide  zone is appended to all
single labels or unqualified zones in order to qualify them. ".home"
is the default; ..." - this caused much excitement and was updated by
RFC8375 - "Special-Use Domain 'home.arpa.'" which says to use
home.arpa instead of .home.
This was helped by the IAB statement -
https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/

This helps, but still doesn't solve many of the issues with RFC6761
style reservations, and wouldn't have really solved the .onion case if
it came along now - the IETF, and the IESG would still be in the
sticky position of how to evaluate if .onion should be placed in the
SUDN registry.

Suzanne has a document which I'd appreciate review and discussion of
-- "Guidelines for Use of the Special Use Names Registry"
(https://tools.ietf.org/html/draft-stw-6761ext-01).
As Stephane pointed out, this doesn't solve for issues *outside* the
IETF, but it does (hopefully) "define guidelines for the IESG and the
IETF community on the interpretation of RFC 6761 and the use of the
special use names registry."

I know that people are tired of this whole topic, but I'd really
appreciate some more of your time reviewing and providing feedback on
this topic; this issue isn't going to go away...

As Suzanne is one chairs, she will not be participating in any of the
consensus calls, etc - Benno and Tim can handle that (this is obvious,
but Suzanne asked me to mention it for completeness).

W
[0]: There is lore that the IESG actually halted reservations under
the 6761 process, but that doesn't seem to be the case, or, if it is,
I cannot find a reference; if there is anything saying so, can someone
please send a link?

-- 
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: Paul Wouters <[email-masked]>
Date: Tue, 6 Aug 2019 16:31:40 -0400 (EDT)

> I cannot find a reference; if there is anything saying so, can someone

If this refers to my comments, which I've given a number of times in
response to this issue, it was DNSOP and not IESG that halted this as
far as I remember.

You can likely find it in some of the dnsop recordings of a year+
ago, but I doubt many have the energy to do listen to a year of dnsop
meetings. If we are resolving this issue now, then it is moot anyway. The
reason I brought this up various times, is because (IMHO) DNSOP made a
rather arbitrary decision to process .onion under the 6761 rules, but
stopped every other name from using the same privilege. There might be
messages in the list archive on this.

I know Suzanne Woolf does not think my view represent how she remembers
the events unfolding. Calling it "lore" though makes me feel like Data's
evil twin :P

Anyway, since we are addressing the problem now, even though it is
unpleasant, is a good thing and the history does not matter that much
to me. I will review the document later and respond in a separate message

Paul

---

From: Warren Kumari <[email-masked]>
Date: Fri, 9 Aug 2019 13:40:29 -0400

Thank you Paul.

As an incentive to everyone else  -- there is an Easter Egg hidden in
this document: if you judiciously choose letters from the text (and
reorder them) you can create a very rude word.

W

P.S: Hey, it's worth a try!

---

From: Bob Harold <[email-masked]>
Date: Fri, 9 Aug 2019 14:26:04 -0400

> I cannot find a reference; if there is anything saying so, can someone
I read it.  It seems like a reasonable summary of the issues.

-- 
Bob Harold

---

From: "John Levine" <[email-masked]>
Date: 10 Aug 2019 11:36:04 -0400

>reorder them) you can create a very rude word.

I think that like everyone else I've read it, but I'm not sure what to say.

R's,
John

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 12 Aug 2019 12:25:16 -0400

(Draft author hat here, not WG chair)

> On Aug 10, 2019, at 11:36 AM, John Levine <[email-masked]> wrote:
> 

Well, the document is intended as guidance to the IETF community and to the  current/future IESG on what it’s reasonable for people to do with reservations for special use domain names, particularly in IETF protocols. This is only a piece of the larger space around the general idea of the special use names registry, but it seemed like a useful place to start.

So it would be helpful to know if you think the recommendations are in fact reasonable. 

In particular, there’s a couple of distinctions the draft makes in order to carve out what looks (to me, anyway) like a manageable piece of the larger issue of administration of domain names as a superset of DNS names: between TLDs and names elsewhere in the namespace, and between IETF protocols and other possible uses for SUDNs.

First, special use “TLDs” (single label domain names) present a hard case for the IETF because of the nexus with another body (ICANN) that has actual authority over what DNS names are delegated as TLDs in the public DNS. A failure to coordinate in such cases could result in poor outcomes for anyone who assumes that the reservation of a special use name under RFC 6761 comes with any assurances about the public DNS.

IMO the IETF has three choices here: refuse to reserve single label names as special use; agree to reserve such names, at least as a possibility, and assume coordination is unnecessary; or ask ICANN, through the established liaison relationship, to discuss a process for coordination on reservation of special use single label names outside of the public DNS.

No matter which course is chosen, however, a special use name under a TLD that’s already in existence and already under the policy control of the IETF presents a simpler path to approval with fewer risks, so the draft encourages IETF WGs to use such names in their protocols where possible, and the IESG to approve them. (This is the “home.arpa” case.)

Second, the other line the draft tries to draw is between IETF protocols, and requests for special use name registrations for use in protocols or code bases not developed in the IETF. 

This isn’t about excluding anyone else from access to some magical potion, and in fact I’d be happy to propose a more detailed set of guidelines for non-IETF protocols that it might be reasonable to approve special use names for. (The draft suggests “stable specification required,” but I’m not attached to it.) The rationale here is that an IETF registry should have clear policy around its administration, and this one doesn’t: approval of the next .onion is likely to be just as ad hoc as the previous one, because “standards track” has a clear meaning inside the IETF, but there’s no equivalent set of guidelines for requests not based in IETF process. This doesn’t scale in, for example, the case that a sponsor of a closed, non-IETF protocol wants to reserve a set of names: is there any limit to how many names the IETF is willing to reserve? Should there be a stable reference to their use? Is there any presumption that if an existing codebase that uses a reserved name is forked, the new codebase should be able to get a new special use name? RFC 6761 is silent on these questions, which are implicitly resolved for a protocol that’s on the standards track in the IETF, but not for anything else.

If a new organization of the contents would be less baffling, I’m definitely open to that, too.

Suzanne

---

From: "John Levine" <[email-masked]>
Date: 18 Aug 2019 14:29:35 -0400

>So it would be helpful to know if you think the recommendations are in fact reasonable. 

I think they're reasonable but I would more clearly distinguish cases
by where the protocol switch is, where I think these are the
interesting ones:

1. Names handled totally unlike the DNS with nothing like an IP address (.onion)

2. Names handled through mutant DNS which can returns IP addresses (.local, .localhost, .homenet/.home.arpa)

3. Names that have other problems such as conflicting prior use (.test, .example, .invalid, also .home, .belkin)

For 1, we can reserve if if there's a compelling argument and evidence
of clear use.  This leads to a catch 22 where the only way to get the
evidence is to squat on it, but I don't see any way around it.  I
particularly do not want to reserve names just because someone claims
to have a great plan.  I think this probably includes Warren's great
plan for .alt.

For 2, we seem to agree that future reservations, if any, will go under .arpa.

For 3, we already did .test, .invalid, and .example which seem to have
solved that particular problem.  I think the question of what might be
too cruddy to delegate is ICANN's problem.  As you know better than I
do, ICANN has a big project to characterize "cruddy" and I don't see
the IETF having anything to contribute there.

R's,
JOhn

---

From: Warren Kumari <[email-masked]>
Date: Fri, 23 Aug 2019 17:18:16 -0400

[ No hats!]

> to have a great plan.  I think this probably includes Warren's great

... hey, that's my cue!

.alt was discussed at IETF 105, and it sounded to me like was good
support for progressing it / discussing it again.

A quick recap for those who've managed to swap out state on this...
"This document reserves a string (ALT) to be used as a TLD label in
non-DNS contexts.  It also provides advice and guidance to developers
developing alternative namespaces."

For all sorts of reasons (compatibility with existing apps being the
main one!) people building alternate naming systems (like .onion, the
GNUnet naming system, many of the blockchain-based / type systems)
want to use names which follow the DNS convention. This means that
they can and do leak into the DNS - for example, if I send you email
with a link to https://facebookcorewwwi.onion/ and you don't have a
TOR browser / shim you'll end up asking the DNS. This ruins much of
the privacy they should be providing (and also being annoying :-), and
also leads to the possibility of collisions.

As John says, there isn't much that people who want to do this
responsibly *can* do - there isn't a path for them.
Reserving .alt will give people designing and using systems like this
a responsible option -- they choose something under .alt (e.g:
foo.alt).

Below is a FAQ to answer to some of the previously discussed questions.

FAQ:
1: Why not just suggest people choose something + <non-DNS-character>
(like ASCII 168)?
A: We need this to be usable with existing apps. e.g 'telnet
www.example.bar<0xA8>' results sadness. It's also makes the solution
really user-unfriendly.

2: Does this also get added to the"Locally Served DNS Zones"  registry?
A: "Earlier versions of this document requested that .ALT be added to
the  "Locally Served Zones" registry, and that a DNSSEC insecure
delegation (a delegation with no DS record) be created at the root.
Significant discussion on the DNSOP list (and an interim meeting)
generated the consensus that these names are specifically not DNS
names, and that them leaking into the DNS is an error.  This means
that the current (non-delegated) response of NXDOMAIN is correct as
there is no DNS domain .alt, and so the document was updated to remove
these requests.

3: Will there be a registry under .alt.
A: Not one run by ICANN / the IETF, no. There is the expectation that
people using this space will self-organize. A number of people have
also offered to publish an informal list.

4: What is the current status / history?
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/history/

There was a WGLC started 2017-03-16:
https://mailarchive.ietf.org/arch/msg/dnsop/tdp-OH3cYf6B9M0Kj1i7d2n6_KE

This was then extended 2017-04-07:
https://mailarchive.ietf.org/arch/msg/dnsop/zMchuCtfZU4jYFR5AEkAF1RB9wg

I believe that we've addressed all open comments from the WGLC.

It was marked as "Held by WG" (2018-07-17) while we dealt with the
Special-Use Domain Names Problem Statement (which became RFC8244)

It was discussed / presented at:
DNSOP Interim meeting on Special Use Names, RFC6761 (May 12, 2015) -
http://www.owl-stretching-time.com/presentations/IETF_DNSOP_Interim_May_2015.pdf

IETF92 - https://www.ietf.org/proceedings/92/slides/slides-92-dnsop-5.pdf
IETF95,
IETF96 - https://datatracker.ietf.org/doc/slides-96-dnsop-14/ (missing)

The Special Use Names interim:
http://www.owl-stretching-time.com/presentations/ALT_TLD_2017_Interim.pdf

It was also mentioned on the joint IETF DNSOP / ICANN interim to
discuss SUDN PS document, and ICANN was invited to participate in the
LC.

I've just posted a new version (bumped the version / date,
aggressive-nsec is now RFC8198, ) to revive it. I'd appreciate review
and comments; I personally believe that this document solves a real
issue, and I'd like to see it progress...

W

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

---

From: Joe Abley <[email-masked]>
Date: Fri, 23 Aug 2019 17:39:03 -0400

On 18 Aug 2019, at 14:29, John Levine <[email-masked]> wrote:

[...]

> 2. Names handled through mutant DNS which can returns IP addresses (.local, .localhost, .homenet/.home.arpa)

[...]

> For 2, we seem to agree that future reservations, if any, will go under .arpa.

I think I know what you're getting out here, but I think what we're talking about are things that are not specifically DNS-like in their protocol, but rather correspond to uses where the IETF has some skin in the game.

I think it's clear that nobody has ever shown signs of wanting to anchor anything like this under .ARPA if it's a name that a user might ever have to see. The reason we might imagine we can persuade some people in the future to do so anyway is presumably because the IET has some authority to nudge them in that direction, not because there's some component of the situation that is DNS-protocol-like.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 23 Aug 2019 17:39:11 -0400

Hi Warren,

On 23 Aug 2019, at 17:18, Warren Kumari <[email-masked]> wrote:

> .... hey, that's my cue!

I have never been very excited about your ALT proposal. However, I don't think it will do any harm beyond thwarting any secret plans anybody might have to apply for a string in a future round of gTLD applications that is ALT or is confusingly similar to it.

I do have my doubts as to whether reservation of ALT as proposed will actually help with the problem it ostensibly seeks to solve.

People have always been able to anchor their non-DNS naming schemes to domain names they control in the DNS as a way to avoid collisions, and nobody has seemed to think that's a good idea. Is it more likely that someone would anchor their ARTICHOKE alternative naming scheme under ARTICHOKE.ALT than it was for them to use (say) ARTICHOKE.NZ or ARTICHOKE.GLOBAL or something? Even within the IETF we struggled slightly to convince people to use HOME.ARPA instead of HOME, right?

Q: has anybody ever indicated that they would use ALT to anchor a non-DNS but domain-like naming scheme?
A: not so far as we know.

However, I appreciate we can't tell whether it will solve any problem until we try it. I stand ready to eat some kind of at least passably-edible hat if called to do so five years from now.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Fri, 23 Aug 2019 18:05:40 -0400

I haven’t read the latest version in a few weeks, and I must have missed the part about the “alt” TLD.   (Actually, I just checked, and my memory was correct—it isn’t there.)  My problem with the “alt” TLD as originally proposed was that there was no registry.   I think this is nearly useless.   It’s fine for experiments, but once the experiment is done, you need an allocation.   And then you have a flag day, which sucks, so why not just have an allocation to begin with?

If we want to have a special TLD under which all new non-DNS protocols will publish their names, we need a registry for it.  This doesn’t need to be very heavyweight, but it needs to exist.   I think “specification exists” is probably the bar for entry.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 23 Aug 2019 15:07:28 -0700

On Fri, Aug 23, 2019 at 2:40 PM Joe Abley <[email-masked]> wrote:

>
> I have never been very excited about your ALT proposal. However, I don't
> think it will do any harm beyond thwarting any secret plans anybody might
> have...

What exactly do you mean?

thanks,
Rob

---

From: Joe Abley <[email-masked]>
Date: Fri, 23 Aug 2019 18:10:26 -0400

Hi Ted,

On 23 Aug 2019, at 18:05, Ted Lemon <[email-masked]> wrote:

> I haven’t read the latest version in a few weeks, and I must have missed the part about the “alt” TLD.   (Actually, I just checked, and my memory was correct—it isn’t there.)

Warren is talking about a different document.

> My problem with the “alt” TLD as originally proposed was that there was no registry.   I think this is nearly useless.   It’s fine for experiments, but once the experiment is done, you need an allocation.   And then you have a flag day, which sucks, so why not just have an allocation to begin with?

I don't mean to channel Warren (it's unnecessary because even when he's asleep he's still reading mail) but I think the whole point of the ALT proposal is not to have a registry. A registry attracts policy and dispute resolution; an informal, decentralised understanding that anything goes, please play nicely with each other is (it is proposed) less likely to lead to friction.

I find this aspect of the proposal quite appealing. I don't think the IETF wants to have any part in decision-making around who gets to go in an ALT registry, and I'm pretty sure ICANN already has their own scheme for this ("new gTLD programme") that they'd rather not complicate with something violently different. Solving the problem of who gets to make decisions with "nobody" seems elegant.

As I mentioned, I still have significant doubts that anybody will use this though.

Joe

---

From: Joe Abley <[email-masked]>
Date: Fri, 23 Aug 2019 18:20:08 -0400

On 23 Aug 2019, at 18:07, Rob Sayre <[email-masked]> wrote:

>> I have never been very excited about your ALT proposal. However, I don't think it will do any harm beyond thwarting any secret plans anybody might have...
> 

I mean that if ALT was reserved such that it was not available for delegation from the root zone, that would presumably exclude it from any future new gTLD round, just as LOCAL, LOCALHOST, EXAMPLE and INVALID are reserved.

Anybody who was currently harbouring plans to apply for ALT in some future round of new gTLD applications would therefore presumably feel harmed by a decision to make it impossible for those plans to be executed.

I can't think of anybody else that the proposal would harm.

Hopefully that is more clear.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Fri, 23 Aug 2019 18:35:11 -0400

> I have never been very excited about your ALT proposal. However, I don't think it will do any harm beyond thwarting any secret plans anybody might have to apply for a string in a future round of gT…

Thank you.

> I do have my doubts as to whether reservation of ALT as proposed will actually help with the problem it ostensibly seeks to solve.

Yup, you might be right.

> People have always been able to anchor their non-DNS naming schemes to domain names they control in the DNS as a way to avoid collisions, and nobody has seemed to think that's a good idea. Is it more likely that someone would anchor their ARTICHOKE alternative naming scheme under ARTICHOKE.ALT than it was for them to use (say) ARTICHOKE.NZ or ARTICHOKE.GLOBAL or something?

Yes. Having ONION.NZ means that my privacy sensitive query flows to
the root, and then .NZ before being discarded, and then probably some
nameservers for ARTICHOKE.NZ. A number of the alternate resolution
systems are specifically designed around privacy, and this makes them
twitch...

>Even within the IETF we struggled slightly to convince people to use HOME.ARPA instead of HOME, right?
>

Actually, I had an off-linst discussion with Christian Grothoff who
said that if this had existed the GNUnet Gnu Naming System might have
used it. Because there wasn't something that they could use, they have
decided to just sit at the top (and so conflict with everything)
There was presented at DINRG @ IETF104 -
Video: https://youtu.be/OMHOyoJ5-_4?t=3908
More: https://youtu.be/OMHOyoJ5-_4?t=4041
https://youtu.be/OMHOyoJ5-_4?t=4082

There was also some discussions with Jacob (or perhaps Alec) saying
that if this had existed when they started, they probably would have
used onion.alt instead of .onion.

Whether or not people would *actually* have used it is unknowable, but:
1: at least now they *do* have the option and
2: in the future we can point at this instead of just having to agree
that they didn't have an option other than squatting.

> However, I appreciate we can't tell whether it will solve any problem until we try it.

Yup.
> I stand ready to eat some kind of at least passably-edible hat if called to do so five years from now.
>
>
> Joe

---

From: Rob Sayre <[email-masked]>
Date: Fri, 23 Aug 2019 15:49:31 -0700

On Fri, Aug 23, 2019 at 3:20 PM Joe Abley <[email-masked]> wrote:

>
> Anybody who was currently harbouring plans to apply for ALT in some future
> round of new gTLD applications would therefore presumably feel harmed by a
> decision to make it impossible for those plans to be executed.
>

That is a very clear explanation. Thank you.

I think a more salient issue might be that URI schemes can imply default
ports and name resolution mechanisms. As applications (imho, rightly) begin
to hide URI schemes, inventing new name resolution mechanisms will become
easier to do.

I think having a global namespace is extremely valuable, but I can see ways
in which short-sighted DNS arguments could result in fragmentation at the
scheme level.

thanks,
Rob

---

From: Ted Lemon <[email-masked]>
Date: Fri, 23 Aug 2019 19:04:57 -0400

> used onion.alt instead of .onion.

This wouldn’t have solved the problem.  Remember that the driving concern behind the .onion standardization effort was that they needed a stable allocation from IANA so that they could continue to get PKI certs signed.

I know that nobody wants to be in the business of vetting proposed names for allocation, but there is no way around this.

---

From: "John R Levine" <[email-masked]>
Date: 23 Aug 2019 19:07:37 -0400

> I don't mean to channel Warren (it's unnecessary because even when he's asleep he's still reading mail) but I think the whole point of the ALT proposal is not to have a registry. A registry attract…

Right -- a .alt with a registry would be pointless and counterproductive.

It'd be pointless since the whole idea of .alt is to encourage people to 
squat their non-DNS names there, and people will do that no matter what a 
registry says.  It'd be counterproductive since even though the registry 
was pointless, the same nitwits that have been imagining they'll get rich 
by squatting on TLDs for the past 20 years will fill the registry with 
speculative garbage.

Per Warren's recent message that .onion et al say they might have used 
.alt, in that case it seems like a pretty cheap experiment.

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

---

From: "John R Levine" <[email-masked]>
Date: 23 Aug 2019 19:11:50 -0400

> I think it's clear that nobody has ever shown signs of wanting to anchor anything like this under .ARPA if it's a name that a user might ever have to see. The reason we might imagine we can persuad…

I agree about names a user might see, but at this point I'm scratching my 
head wondering if there will ever be another .onion.  If someone wants a 
new set of non-DNS names intended to be used in web browsers, make it a 
new URI scheme.

In retrospect, .onion would better have been an onion: scheme.  It is my 
impression that the reason it looks like a TLD is that it was easier to 
hack it into a SOCKS proxy than into a browser.

Regards,

---

From: Christian Huitema <[email-masked]>
Date: Fri, 23 Aug 2019 16:34:53 -0700

>> to have a great plan.  I think this probably includes Warren's great

Well, maybe. When looking at leakage at the root, i find a 4th pattern
in addition to the three listed in the draft. Basically, I find a lot of
configurations in which the local admin define a "super root", to use in
a search list. Something like a search list composed of
"corp.example.com; example.com; super-root". This is probably meant to
implement some variation of "split DNS". It leaks at the root when the
search list is composed with something like "no-such-name.example.net",
which does not actually exist. The device ends up searching for
"no-such-name.example.net.<local-root>", which in the right
circumstances leaks a query to the root. It is easy to recognize this
pattern: non existent TLD, preceded by a valid TLD name as 2LD. It
accounts for a fairly large fraction of root traffic.

The value of "local-root" vary. Some domains use an IP address. Many use
common names like "LOCALDOMAIN" or "LAN", some use the name of a local
server, some use the name of an access router. Arguably, they could use
a reserved 2LD under ALT, although I am not holding my breath...

-- Christian Huitema

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 26 Aug 2019 12:03:55 +0200 (CEST)

> Il 24 agosto 2019 00:35 Warren Kumari <[email-masked]> ha scritto:
> 

I am in favour of trying this: it is simple and it won't do much harm if it fails, but it addresses a few of the problem cases specified in RFC8244 section 3 (I'd say #7, #8, and parts of #5 and #9). Of course it doesn't address the problem of people who do not know or do not care, they will just continue making up TLDs and using them - though some kind of information and peer pressure effort whenever these cases arise could have some effect, as a practical alternative would now exist.

Perhaps, as a guideline either here or somewhere in a future revision of RFC6761 (i.e. here), application developers should be told that before asking for a special use TLD they SHOULD/MUST experiment with a name under .alt, and prove the existence of some running code, adoption and success before moving to a TLD (and plan their implementations since the beginning so that such a move can actually be done). This would act in two ways: it would avoid wasting energy on discussing abstract special use TLD proposals that seem a great idea to some while others claim that they'll never work, and it would encourage people with successful .alt subdomains to move to a special use TLD to get the benefit of guaranteed non-collision, if they see merit in it.

This is also why not having a registry under .alt makes sense. Having one would make .alt second-level domains almost a functional duplicate of special use TLDs, raising the bar to get them and making special use TLDs only better in vanity/shortness, which would lead the IETF to have to deal mostly with vanity TLD applications.

(Also, you have "handing" instead of "handling" once in 4.1.1 and twice in 4.1.2.)

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Ted Lemon <[email-masked]>
Date: Mon, 26 Aug 2019 08:44:15 -0400

> This is also why not having a registry under .alt makes sense. Having one would make .alt second-level domains almost a functional duplicate of special use TLDs, raising the bar to get them and mak…

This isn’t really true.   The main problem with special-use top-level names is that it’s not clear what the process is for assigning them.   The IETF can’t just unilaterally assign them, because we don’t own the namespace.   We sort of have a right to allocate them, but if we do, we have to liaise with ICANN, and we don’t have a process for that.  So every time we do it, it’s a special case.  This makes the IETF leadership understandably reluctant to do it, which means that anybody who wants one can expect it to be a long process with no guarantee of a positive outcome.   This is discussed at length in RFC 8244.

So a TLD that is especially intended for non-DNS special-use names and that is entirely owned by the IETF would in fact be quite a bit easier to use, and we could have an allocation process that did not discourage casual use.

If we want both types of special-use TLD, we could easily have .arc and .adhoc to cover both use cases.   .arc would have a registry; .adhoc would not.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 27 Aug 2019 09:34:45 +0100

On 23/08/2019 22:39, Joe Abley wrote:

> People have always been able to anchor their non-DNS naming schemes 
> to domain names they control in the DNS as a way to avoid collisions,
> and nobody has seemed to think that's a good idea. Is it more likely
> that someone would anchor their ARTICHOKE alternative naming scheme
> under ARTICHOKE.ALT than it was for them to use (say) ARTICHOKE.NZ or
> ARTICHOKE.GLOBAL or something? Even within the IETF we struggled
> slightly to convince people to use HOME.ARPA instead of HOME, right?

For Homenet it wasn't an alternative naming scheme, it was a "locally 
scoped only" name but still using DNS protocol.

You also wrote:

> I think it's clear that nobody has ever shown signs of wanting to
> anchor anything like this under .ARPA if it's a name that a user
> might ever have to see.

Homenet names are expected to be user visible, but we certainly did 
*not* want them to be under .ARPA.    It was unfortunately the only
available option when the various I* bodies declined to attempt to set 
up the necessary processes and liaisons with ICANN.

Ray