Subject: Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 12 Feb 2014 17:13:49 +0100

On Mon, Feb 10, 2014 at 12:58:38PM -0800,
 [email-masked] <[email-masked]> wrote 
 a message of 36 lines which said:

>         Title           : The ALT Special Use Top Level Domain
>         Authors         : Warren Kumari
>                           Andrew Sullivan
> 	Filename        : draft-wkumari-dnsop-alt-tld-00.txt

The goal is laudable and I like the end of section 3, acknoweledging
that, existing TLDs like .onion won't move to the new .ALT

However, I disagree with the terminology.

> DNS context: The namespace administered by ICANN.

No. The DNS is a protocol. It exists whether or not it is rooted at
ICANN. When you use an "alternative root" (RFC 2826), you use the
DNS. When a big closed organization has its own infrastructure, with
root servers and so on, it is still the same DNS protocol.

> the DNS "standard" of a series of labels separated with dots

Many other systems work with this syntax (domain names can be resolved
by other protocols than the DNS, for instance /etc/hosts or LDAP) so
it should not be called "DNS standard".

---

From: Marc Blanchet <[email-masked]>
Date: Wed, 12 Feb 2014 11:28:31 -0500

- I like better that approach than the previous draft registering many tlds.
- I would prefer an IANA registry under .alt with "expert" review policy.  A namespace with possible collisions (past or future) have very low value to me. names are leaking in various contexts, so collisions would be bad for the protocols and deployment using that .alt tld.

Marc.

Le 2014-02-10 à 15:58, [email-masked] a écrit :

> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
> 	Pages           : 6
> 	Date            : 2014-02-10
> Abstract:
>   This document reserves a string to be used as a TLD label in non-DNS
>   contexts.  [Ed note: By now you should be wildly confused.  Go read
>   the intro / background :-P ]
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-alt-tld/
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00
> 
> 
> 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/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Joe Abley <[email-masked]>
Date: Wed, 12 Feb 2014 13:24:07 -0500

> - I like better that approach than the previous draft registering many tlds.

The previous draft (at least for some of the TLDs) was anchored in the reality that changing the name already in use was not practical, e.g. there's a sufficient deployed base that uses DNS-like names ending in ONION that proposals to use things like ONION.ARPA were non-starters.

I think therefore that the ALT draft addresses quite a different problem: the choice of DNS-like (but not DNS) name structure for new applications that we don't know about yet.

I suspect that there would be fewer roadblocks involved in choosing an anchor ALT.ARPA than ALT, since ARPA is under the control of an IETF family member while the root is controlled by distant cousins. If I'm right that this proposal is for future, as-yet-unknown applications, then the choice of anchor should be arbitrary; it feels in that case like the path of least resistance is the right one.

> - I would prefer an IANA registry under .alt with "expert" review policy.  A namespace with possible collisions (past or future) have very low value to me. names are leaking in various contexts, so…

I think that if we are talking about DNS names, we already have mechanisms to ensure uniqueness.

If we're not talking about DNS names, then the only consideration we really need is to avoid collisions with the DNS. We can do that by reserving ALT (or ALT.ARPA, or whatever), specifying that it's a reasonable domain to sink locally (RFC 6303) and perhaps providing some kind of AS112++ sink for leaks to the wider network (draft-ietf-dnsop-as112-dname).

(An AS112++ sink for a domain is probably easier to realise for ALT.ARPA than it is for ALT, since the root zone is maintained using specific registry machinery that would require changes to support DNAME, I think, and the track record suggests such changes might take a long time to action.)

I don't see an obvious reason to insist on IETF restrictions on an ALT-like namespace if the point of the namespace is to be available for use outside the IETF. If restrictions existed (no matter how simple we imagine they were to follow) the likely outcome is that ALT would either be abused (used without registration) or ignored.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Feb 2014 13:40:09 -0500

> I suspect that there would be fewer roadblocks involved in choosing an anchor ALT.ARPA than ALT, since ARPA is under the control of an IETF family member while the root is controlled by distant cou…

It really shouldn't be difficult to make this work, although if .ALT is already spoken for a different name might be needed.   If it is in fact difficult, then RFC 6761 is pretty pointless.

I agree with your other point, though—this may be useful for future efforts, but doesn't address the same problem as the other two documents we've talked about.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 12 Feb 2014 12:34:38 -0800

On 2/12/14, 10:40 AM, Ted Lemon wrote:
>> I suspect that there would be fewer roadblocks involved in choosing
>> an anchor ALT.ARPA than ALT, since ARPA is under the control of an
>> IETF family member while the root is controlled by distant cousins.
>> If I'm right that this proposal is for future, as-yet-unknown
>> applications, then the choice of anchor should be arbitrary; it
>> feels in that case like the path of least resistance is the right
>> one.
> 
> It really shouldn't be difficult to make this work, although if .ALT
> is already spoken for a different name might be needed.   If it is in
> fact difficult, then RFC 6761 is pretty pointless.

this discuss could dangerously veer into vanity territory and I'm
probably doing so by dorking with it but.

.IANA

seems kind of unambiguous as to where the registry for these things
would be.

> I agree with your other point, though—this may be useful for future
> efforts, but doesn't address the same problem as the other two
> documents we've talked about.
> 
> _______________________________________________ DNSOP  mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: George Michaelson <[email-masked]>
Date: Thu, 13 Feb 2014 09:38:50 +1000

On Thu, Feb 13, 2014 at 4:24 AM, Joe Abley <[email-masked]> wrote:

> The previous draft (at least for some of the TLDs) was anchored in the
> reality that changing the name already in use was not practical, e.g.
> there's a sufficient deployed base that uses DNS-like names ending in ONION
> that proposals to use things like ONION.ARPA were non-starters.
>

I dissent from this view. I strongly disagree with any characterisation of
the problem of code replacement in service being intractable, and I think
it is a false premise.

I realize I am probably a lone voice on this, but at *no* time have I felt
the "there are too many already" argument has merit, and it has materially
impeded several outcomes we now face, because of failure to accept the
necessary transition pain. The future is always bigger.

> I think therefore that the ALT draft addresses quite a different problem:
> the choice of DNS-like (but not DNS) name structure for new applications
> that we don't know about yet.
>

And as a consequence I disagree with this too. An orderly migration from
.ONION to another namespace is both feasible and capable of being planned
for.

-G

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Feb 2014 11:26:42 +1100

In message <CAKr6gn1fjJG=[email-masked]>,
> necessary transition pain. The future is always bigger.

You are not a lone voice.  I have already described how to do such
migrations.  They take time but they are do able.
 
> --001a1134519a2a68fd04f23e132e
> Content-Type: text/html; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
> 
> <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
> _quote">On Thu, Feb 13, 2014 at 4:24 AM, Joe Abley <span dir=3D"ltr">&lt;<a=
>  href=3D"mailto:[email-masked]" target=3D"_blank">[email-masked]</a=
> >&gt;</span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
> x #ccc solid;padding-left:1ex"><div class=3D""><br>
> On 2014-02-12, at 11:28, Marc Blanchet &lt;<a href=3D"mailto:marc.blanchet@=
> viagenie.ca">[email-masked]</a>&gt; wrote:<br>
> <br>
> &gt; - I like better that approach than the previous draft registering many=
>  tlds.<br>
> <br>
> </div>The previous draft (at least for some of the TLDs) was anchored in th=
> e reality that changing the name already in use was not practical, e.g. the=
> re&#39;s a sufficient deployed base that uses DNS-like names ending in ONIO=
> N that proposals to use things like ONION.ARPA were non-starters.<br>
> </blockquote><div><br></div><div>I dissent from this view. I strongly disag=
> ree with any characterisation of the problem of code replacement in service=
>  being intractable, and I think it is a false premise.</div><div><br></div>
> <div>I realize I am probably a lone voice on this, but at *no* time have I =
> felt the &quot;there are too many already&quot; argument has merit, and it =
> has materially impeded several outcomes we now face, because of failure to =
> accept the necessary transition pain. The future is always bigger.=A0</div>
> <div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
> ;border-left:1px #ccc solid;padding-left:1ex">
> <br>
> I think therefore that the ALT draft addresses quite a different problem: t=
> he choice of DNS-like (but not DNS) name structure for new applications tha=
> t we don&#39;t know about yet.<br></blockquote><div><br></div><div>And as a=
>  consequence I disagree with this too. An orderly migration from .ONION to =
> another namespace is both feasible and capable of being planned for.</div>
> <div><br></div><div>-G=A0</div></div></div></div>
> 
> --001a1134519a2a68fd04f23e132e--
> 
> 
> --===============0150303104473161178==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> --===============0150303104473161178==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: David Conrad <[email-masked]>
Date: Wed, 12 Feb 2014 20:48:01 -0500

On Feb 12, 2014, at 6:38 PM, George Michaelson <[email-masked]> wrote:
> I dissent from this view. I strongly disagree with any characterisation of the problem of code replacement in service being intractable, and I think it is a false premise.

+1 

> I realize I am probably a lone voice on this, but at *no* time have I felt the "there are too many already" argument has merit, and it has materially impeded several outcomes we now face, because of failure to accept the necessary transition pain. The future is always bigger. 

I once heard a story about the author of make(1) realizing that perhaps having the tab character be significant in makefiles might not have been the best choice, but deciding against fixing it because the installed base of systems using make(1) at the time -- all 200 of them -- was too large.

> And as a consequence I disagree with this too. An orderly migration from .ONION to another namespace is both feasible and capable of being planned for.

While I agree, pragmatically, I'm unsure there is incentive for the maintainers to move (which I think where Joe was going). As such, we're in the increasingly common quandary of figuring out how to document reality despite violation of policy or ignoring reality to ensure purity of policy.

Has anyone asked the folks coding .ONION (or others) if they're willing to migrate, pointing out the downsides if they choose not to? 

Regards,
-drc

---

From: Arturo Servin <[email-masked]>
Date: Thu, 13 Feb 2014 13:01:21 +0100

"4.  IANA Considerations"

I prefer option 2. A fully uncoordinated space, otherwise we will open
a policy can of worms.

-as

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 13 Feb 2014 09:59:32 -0500

> I think therefore that the ALT draft addresses quite a different problem: the choice of DNS-like (but not DNS) name structure for new applications that we don't know about yet.

I won't speak for Warren, but certainly this is _my_ view of our goal.
I do not want our current proposal (which doubtless needs improvements
in details) to get bound up with whether existing uses ought instead
to be subsumed.  But on another list we just heard about yet _another_
of these "pseudo-TLDs" crawling out of the woodwork.  When it was
observed to said pseudo-TLD pusher that the approach might run into
fewer problems if it were anchored somewhere else, he said that it was
a feature that it attacked the IANA root.  If we don't have an
ordinary and standard place where such uses can fit, then these sorts
of vandals will have a pragmatic argument open to them.  If we _do_
have a standard place for this stuff, then at least the pragmatic
argument will be closed, and we can have a discussion about the merits,
understanding that the goal really is in many cases to attack the
orderly operation of the public DNS.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Marc Blanchet <[email-masked]>
Date: Thu, 13 Feb 2014 10:23:52 -0500

ok, maybe this suggestion below is weird, but... 
- since they are not looking at a real delegated TLD.
- why not just register a URN namespace and use it as they see fit?

Marc.

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 13 Feb 2014 10:49:39 -0500

> - why not just register a URN namespace and use it as they see fit?

Because you only type in a string that "looks like a domain name" in
applications (for example browsers) without the URI scheme nowadays, and
people want that to work also with strings in other namespaces.

I.e. it all, from my perspective, have to do with where the signalling
is on what namespace to use. And if that signalling is inline, then we
do have something that can be viewed as the equivalent of a namespace
collision.

If people had entered the URI scheme all the time, including "http",
then we would have been in a different situation.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 13 Feb 2014 10:58:38 -0500

> - why not just register a URN namespace and use it as they see fit?

Why didn't they do that in the first place?

A

-- 
Andrew Sullivan
[email-masked]

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 13 Feb 2014 11:19:26 -0500

> then we would have been in a different situation.

I think that the draft is not radical enough it is trying to provide some belt and suspenders to a 
syntom rather than address the actual problem. 

The Meta problem is Multiple Namespaces with different resolution technologies. 
Addressing this via a SUFFIX in the domain name feels wrong, 
What I will propose is a Namespace layer solution that is a prefix to the name presented, 
thus names will be presented to the namespace layer as <namespace/name-encoding><space separator><name> 
Examples using ## as the separator
	DNS##www.example.com    This is normal DNS name, 
	GNU##eff 
	DUTF8##….. (DNS name in UTF8 format) 
	www.example.net    (by default the name is DNS) 
	
With a namespace layer we can have the host reject lookup locally if it does not know how to handle the namespace,
rather than dump it out as ".alt" query. 

I know this requires changes in lookup services and code, but it moves the effort to the people that want new namespaces. 

	Olafur
PS: IANA should maintain a registry of namespaces

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 13 Feb 2014 18:40:07 -0500

> PS: IANA should maintain a registry of namespaces

This is to me approximately like the URI scheme idea, but a different
syntax. Can fly, might not fly.

The whole question is what the application developers and marketing
people will print on bulletin boards and accept in input fields in
applications (and their configurations).

Which unfortunately means we do not know until some time after we have
tried to standardize it... :-P

   Patrik

---

From: Warren Kumari <[email-masked]>
Date: Thu, 13 Feb 2014 20:22:05 -0500

[ Replying to a bunch of comments in one mail (not just Patrik's). I'm
stuck in the storm in ATL (
http://www.cnn.com/2014/02/13/us/winter-weather/ ), and so am behind
on mail, etc. ]

Just so folk know, Olafur and I chatted about this before he submitted
his draft. I think that we are in agreement that the two drafts are
complementary, not conflicting.
Using a URI / Prefix / <something> to indicate another namespace (to
me at least) seems like an elegant, clean, sane, "better" solution --
unfortunately it seems that making pseudo-TLDs has suddenly become
popular, and so I think that reserving .ALT is an important *tactical*
solution. It creates a safe area for people who want to do this sort
of thing to do so, and lets the IETF push back on people trying to
reserve .foo in the future. I think we should work on Olafur's
proposal in parallel.

On Stephane's terminology comments...
Yes, the terminology section sucks -- unfortunately it was the best I
could come up with.
I'm really bad at terminology thingie whatzits. Andrew made it better,
but it is still bad. Much of the problem is that we are talking about
somewhat squishy things -- people using names in places where you
would usually put a "DNS name" (whatever that means).
1:  'the DNS "standard" of a series of labels separated with dots' --
An earlier version of the doc had some long and contrived text about
"names that are comprised of short strings (<=63) of LDH characters,
separated by dots" until Andrew hit me with a stick and reminded me
about 1: IDNs and 2: DNS being 8bit clean. I'd put the word "standard"
in quotes to try and make it clear that this isn't really the DNS
standard.
2: 'DNS context: The namespace administered by ICANN.'  -- Yup, it's
not clear / correct. But I couldn't figure out how to make it better.
It's not really the 'DNS protocol', because some of these solutions
use the DNS protocol, and then intercept it. What I was aiming for was
something like "The thingie that most people would think of if you
asked them to go resolve a name".
Suggestions / text more than welcome!

On the "should e.g .onion move under this?" discussion...
Personally I think that the Right Thing(tm) would be for .onion / .bit
/ etc to move under .alt -- unfortunately they are already deployed in
the wild, and there is running code, etc. If I had a wand I'd wave it,
magic would happen, everyone would have a pony and .onion would
suddenly be under .alt. Unfortunately I think that the reality is
that, whether or not the IETF approves the grothoff names, they will
continue to be used. I'd rather that that is documented. The .ALT
proposal is largely a solution so that we don't end up in the same
place in the future.  Olafur's namespace prefix solution is *better*,
but is (IMO) much more of a long term solution.

On the "Should there be an IANA registry?" bit.
I have no idea. I'm very conflicted on this. There are definite
advantages and disadvantages to both.
I want it to be easy for someone to start using a name here, so that
they have no excuse not to, but I'm also concerned about the chaos /
anarchy. An option (but an ugly one!) would be that we reserve
something like unmanaged.alt (or u.alt or swamp.alt, or...) as
unmanaged space within the ALT TLD. Other SLD would require expert
review or something.

Well, I'm off to go see if I can find any food -- when I went for
lunch earlier in the day the restaurant had already run out of
french-fries, tomatoes and a number of beers...
Wish me luck.
W

On Thu, Feb 13, 2014 at 6:40 PM, Patrik Fältström <[email-masked]> wrote:
>>       DUTF8##..... (DNS name in UTF8 format)

---

From: Warren Kumari <[email-masked]>
Date: Thu, 13 Feb 2014 20:33:27 -0500

On Wed, Feb 12, 2014 at 1:40 PM, Ted Lemon <[email-masked]> wrote:
> It really shouldn't be difficult to make this work, although if .ALT is already spoken for a different name might be needed.

Nope, checked, no-one has applied for .ALT....

> If it is in fact difficult, then RFC 6761 is pretty pointless.
>
> I agree with your other point, though--this may be useful for future efforts, but doesn't address the same problem as the other two documents we've talked about.

Yup. This is to primarily to prevent this sort of issue in the future...

W

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 14 Feb 2014 09:19:14 +0100

On Thu, Feb 13, 2014 at 10:58:38AM -0500,
 Andrew Sullivan <[email-masked]> wrote 

> Why didn't they do that in the first place?

Some did. For instance, the magnet people. (Although they apparently
did not register the URI scheme they are using...)

---

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 14 Feb 2014 16:54:22 -0500

I posted my draft on this this topic, 
I do not think it is a DNS topic thus I put the appsawg in my draft name: 

A new version of I-D, draft-ogud-appsawg-multiple-namespaces-00.txt
has been successfully submitted by Olafur Gudmundsson and posted to the
IETF repository.

Name:		draft-ogud-appsawg-multiple-namespaces
Revision:	00
Title:		Providing support for multiple namespaces to Internet protocols.
Document date:	2014-02-14
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-ogud-appsawg-multiple-namespaces-00.txt
Status:         https://datatracker.ietf.org/doc/draft-ogud-appsawg-multiple-namespaces/
Htmlized:       http://tools.ietf.org/html/draft-ogud-appsawg-multiple-namespaces-00

Abstract:
  Over the years there have been various proposals as to use namespaces
  other than the DNS/IN namespace that is under ICANN administration.
  Some of these were simple DNS competitors others use different lookup
  technologies.  In addition it is hard to supply different character
  encodings to DNS as each application needs to provide the translation
  between the encoding used and the format expected by DNS.

  This draft proposes a new service layer to provide multiplexing of
  different namespaces into appropriate function calls.

Olafur

---

From: John Bond <[email-masked]>
Date: Thu, 20 Feb 2014 22:18:09 +0100

-----Original Message-----
From: David Conrad <[email-masked]>
Date: Thursday 13 February 2014 02:48
To: George Michaelson <[email-masked]>
Cc: <[email-masked]>, dnsop <[email-masked]>
Subject: Re: [DNSOP] I-D Action: draft-wkumari-dnsop-alt-tld-00.txt

>
>Has anyone asked the folks coding .ONION (or others) if they're willing
>to migrate, pointing out the downsides if they choose not to?
Hopefully this response will help.

https://lists.torproject.org/pipermail/tor-dev/2014-February/006238.html

---

From: George Michaelson <[email-masked]>
Date: Fri, 21 Feb 2014 08:36:37 +1000

I suspect both sides of the argument about the tractability of change in
systems will be saying SEE I TOLD YOU SO.

It will be clear from my input, that I see this as a positive signal the
.onion community understand the problem, understand the migration and are
prepared in principle to discuss it.

HELL NO and WE CAN'T aren't words in that post.

-G