Subject: Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Jun 2015 11:59:36 -0400

On Thu, May 21, 2015 at 01:48:41PM -0400, Ted Lemon wrote:
> 
> This is a really good point.   I think there does need to be a .ALT registry in order for .ALT to be able to address anything other than experimental uses.
And I think this would actually be a good thing.

If we created a registry for alt, how would alt not be just another
TLD with exactly the same status as any other domain name registry?
You can already register a name in the DNS registries and not turn it
on in the DNS.

What you're suggesting is that the IETF run a parallel registry for
people who don't want to pay registrars and registries.  I think it
would be unwise for the IETF to get into that business.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bob Harold <[email-masked]>
Date: Thu, 4 Jun 2015 12:16:05 -0400

On Thu, Jun 4, 2015 at 11:59 AM, Andrew Sullivan <[email-masked]>
wrote:

> > This is a really good point.   I think there does need to be a .ALT
> registry in order for .ALT to be able to address anything other than
> experimental uses.

I think the difference is that ".alt" names should not be leaked into DNS,
but should be kept private.  I assume that DNS registrations have a cost
partly because of the infrastructure required if one chooses to publish
them in DNS.  Registrations under ".alt" would not have this overhead -
they should never reach DNS.  The whole purpose of a registry for ".alt"
sub-domains is simply to avoid name collisions.

-- 
Bob Harold

---

From: "John Levine" <[email-masked]>
Date: 4 Jun 2015 19:53:02 -0000

>> This is a really good point.   I think there does need to be a .ALT registry in order for .ALT to be able to
>address anything other than experimental uses.

I think the key difference would be that it would accept any number of
entries for the same string, and would have a pointer to the place
where you can download the code that implements it.  If you use
foo.alt and I use foo.alt, well, that's our problem.  There is also no
reason to have only one such registry, or why any organization with a
name starting with "I" would run any of them.

As I mentioned before, given that the whole point of .alt is that
people are implementing things that look like DNS names but are
resolved in some other way, the winner of any such conflict is the one
with widely used running code.

R's,
John

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Jun 2015 16:07:19 -0400

On Thu, Jun 04, 2015 at 07:53:02PM -0000, John Levine wrote:
> entries for the same string

I thought that Ted's idea was uniqueness.  (Otherwise there wouldn't
be a landrush.)

I agree that if you had a registry that had no unique entry, there'd
be no problem.  But if you have to be prepared for identifier
collisions anyway, what use is the registry?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 4 Jun 2015 16:08:58 -0400

On Thu, Jun 04, 2015 at 12:16:05PM -0400, Bob Harold wrote:
> but should be kept private.

But there will be such leaks, so that's no defence.  And for local
use, a DNS leak wouldn't be an issue either, some would argue, and
then alt turns into RFC 1918 for DNS.  (Although arguably we have that
with local anyway.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: "John Levine" <[email-masked]>
Date: 4 Jun 2015 20:15:03 -0000

>collisions anyway, what use is the registry?

It tells you where to find out about foo.alt if you want to use that
particular un-DNS hack.  Other than that, not much.  

Given the experience with usenet alt.*, it appears that in the absence
of a daddy to declare a winner when names collide, name collision
problems go away because it is much easier to avoid them than to
argue.  People used to the ICANN environment may find this a
conceptual challenge, but that's their problem.

R's,
John

---

From: Warren Kumari <[email-masked]>
Date: Fri, 5 Jun 2015 21:16:05 -0400

> name starting with "I" would run any of them.

I think that such a list / resource would be a fine idea, but I think that:
A: it would be good to avoid calling it a "registry" (that term has
specific meaning within the DNS world), and
B: it would also be good if someone (or someones) other than the IETF
ran them. This could be a person, like John for exmaple[0], or just
something like a wikipedia page.... Some of my reason for writing the
.alt draft was because I get more than enough ICANN politics at ICANN
meetings -- I *so* don't want special use names to become an
attractive niusence and have legal / trademark fights when someone
launches an alternate name resolution system for finding drugs and
calls it 'coke.alt'.

Having a place where I could go figure out what piece of software I
need to install to resolve http://0xdeadbeef.kitten.alt would be
really useful (even if the resource said that this could be any of 3
different alternate resolution methods - if it looks like a bunch of
hex is is probably KittenNet (install KittenRes0.23.tgz), if the
string is mainly badly spelt "words" it's likely LoLCat, try install
ICanHazNames from http://example.net :-)).

> with widely used running code.

Yah. If I'm launching a new namespace that resolves based upon
<something>, I have an incentive to choose a string that isn't already
being used by some other large, well known project, in the same way
that it would be silly for me to write a new UNIX program that does
something like cowsay (but with kittens) and call it 'cat'.

W

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

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

---

From: "John R Levine" <[email-masked]>
Date: 5 Jun 2015 21:36:27 -0400

> something like cowsay (but with kittens) and call it 'cat'.

Exactly.  The ICANN approach is what I might call the gold rush model -- 
people dash out to grab likely looking territory and squat on it before 
anyone else does.  This is more like homesteading -- there's a practically 
unlimited amount of territory, anyone can get some, but it you want to 
keep it, you have to live on it and improve it.

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 9 Jun 2015 10:41:19 +0000

>specific meaning within the DNS world), and

Not just in the DNS world.

To research this response, I looked up the definition or registry (place
that keeps a register) and register.  There are other meanings - including
a vocal register - but the central theme is a public record or an official
list, etc.  In many uses it is the official/public relationship of what
I've mentioned before.

>ran them.

If for no other reason that the IETF isn't prone to operating services.

>This could be a person, like John for exmaple[0], or just

Sounds like you are trying to solve legal issues with engineering.

>ICanHazNames from http://example.net :-)).

The fact that the current Special-Use Domain Names doesn't do this
specifically is what makes me wonder what the benefit that registry offers.

>something like cowsay (but with kittens) and call it 'cat'.

After reading this I'm less sure I understand what the solvable problem
is.  Collisions in identifiers have existed before the Internet and
continue external to the Internet.  Prevention of external events is
impossible, you can only hope to deal with them.

In a side conversation about "preventing" badness it was suggested to turn
the conversation towards "accommodating correct behavior."  What would it
take for someone to pick an identifier space and get it acknowledged?
Answering that may be more beneficial than figuring where in the DNS to
stick all these ad hoc naming schemes.  (After all, [in my opinion] the
DNS is not the root of all identifiers.)

---

From: "John Levine" <[email-masked]>
Date: 9 Jun 2015 10:51:49 -0000

>take for someone to pick an identifier space and get it acknowledged?

Write the software and get people to use it.  Once again, this is
homesteading, not gold rush.

R's,
John

---

From: Edward Lewis <[email-masked]>
Date: Tue, 9 Jun 2015 11:49:59 +0000

>homesteading, not gold rush.

I've seen that run into the rocky shoals.

The note above is not to prevent innovation like this but to accommodate
it.

Many recall the MARID WG and SPF record.  The way I tell the tale, there
was a desire to have a DNS resource record hold a policy expression for
sending email.  To get a type code, an onerous process was in place, which
included proof of substantial work/deployment.

The innovators used the TXT record, became successful.  The IETF "core"
told them to not use the TXT record for standardization, rather propose a
new type.  This was a breaking point because of the installed base.

One of the outcomes from that was a revamping of the policy to get a new
resource record registered in the IANA registry for such things.  The
other outcome is the saga of the SPF record which is not central to my
point here, other than, it hasn't "gone well."

Back to the comment that this is homesteading.  There are two forks from
this.  One is homesteading that keeps to it's own and the other is
homesteading that becomes a part of the neighborhood's life.  Only the
latter needs to have some sort of identifier clash protection - because of
they way I've divided this - and that is for the mutual benefit of the
"it" and "the neighborhood."  That is certainly not a gold rush, just a
natural development of a culture.

Like most systems that evolve over time, there's a point where things
don't work so well.  When there's a lot of reserve capacity, carving out
chunks of space ad hoc works.  As the reserve dwindles, there's a need to
build coordination.  In this case (ALT), and I admit to extremely
stretching this - there could be a competition between those that see ALT
as a short for alternative/alternate or trailing debris from USENET days
and those (a fictional group for illustration only) who see ALT as the
German word for "old" and see a commercial opportunity to use that
(perhaps has a counter to those that use translations of "new", such as NU
in Sweden).  I'm just throwing this as an example that every thing has a
trade off, I've sometimes been surprised where conflict arises in cases.

Relying on homesteading to prove the quality of innovation has a good
track record when there's plenty of space to go around.  But the same
strategy doesn't work so well when resources are depleting and nearing
scarcity.  One might argue that the name space is so large that is
laughable, until one steps on a landmine.

PS - Once Warren said that this isn't about "ALT" - it could be
"FLUGABFARB0129".  Keep in mind my example is simply picking on ALT which
happens to be something I recognize in non-English.  It's just a
coincidence and I'm using this just to push the point that there might be
trade offs to consider external to the DNS world.

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 09 Jun 2015 12:11:07 -0400

Hi Ed,

> I've seen that run into the rocky shoals.

I feel like we're succumbing to the temptation to solve vague human problems with robust, definitive engineering solutions which is going to lead us on a campaign of preemptive bridge-crossing, every one with its own set of trolls.

John's homesteading approach sounds like exactly the right one to me. Some deployment risks are better addressed by the people doing the deployment, not by spectators.

Let's make the conscious, informed decision to recommend against any authoritative registry for DNS-like namespaces that end in ".ALT". It should be clear that this is a goal, not an oversight.

Joe

---

From: Tom Ritter <[email-masked]>
Date: Mon, 15 Jun 2015 18:57:34 -0500

On 23 May 2015 at 09:35, Richard Barnes <[email-masked]> wrote:
> tl;dr: Ship it.

++

Nits:
 - Noted for the first time that the IETF boilerplate uses the oxford
comma. (I like the Oxford comma, but it seems most don't.)
 - "visually or apparently semantically similar to the desired
service" - not sure what "or apparently semantically" adds to this,
seems to be a repeat of "visually"

-tom