Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Mark Andrews]

In message , "Adrien de Croy" 
writes:
>
> that's correct.  It looks in that document like a quote from the IAB,
> but if you're saying it's not, I then would have to challenge the
> logical conclusion asserted in that second paragraph.
>
> I don't see why it necessarily follows that having a single tree with a
> single root creates a requirement for support for multiple resolution
> protocols.

Because the only other way to be able to distingish between a onion
address and a DNS name would be to have onion use labels with a
wire representaion that are longer that 63 octets or with overall
lengths greater that 255 wire octets or you have to prefix all names
with DNS and ONION to identify the resolution namespace.  Almost
any string of characters will form a valid DNS name.

This was my signature back in 1995.  Note you had to NAME the NAMESPACES.

Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE:  +61 2 325 3148   INTERNET: 
ma...@syd.dms.csiro.au
UUCP: !uunet!syd.dms.csiro.au!marka

None of us grey beards want to go back to those days.

We could have added "*.onion 604800 IN NULL" to the root zone and
fixed all the resolvers to stop searching on NOERROR but that does
not stop the fact that you want to use TOR alone with who you want
to talk to leaking unintentionally.

> The thousands of authors of other protocols and systems don't seem to
> have had too much trouble so far just using DNS where required, and
> putting resolution into their own protocols outside the tree.  Why break
> the whole tree for some nebulous result which surely in all cases can be
> worked around with a smaller consequence than having to deploy new DNS
> to the entire world.
>
> Even a DSL/NAT box does DNS forwarding, do we expect all those cheap
> router box vendors to patch out the firmware for this any time soon?

No.  The expectation is that future boxes that they ship will
implement the protocol and not pass on the leaked name.  The
expectation is that any update issued will also address this.

The RFC allows DNS only resolvers, proxies and recursive servers
to all generate NXDOMAIN responses in the event of a leak.  This
will result in SERVFAIL in some cases as the validation of the
response will fail but it will still prevent the leak spreading.

> Adrien

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[str4d]

On 02/04/16 08:53, George Michaelson wrote:
> Whats your reaction going to be, to a closed 6761 because if you come
> to the microphone with a "but we built to the userbase, we have
> millions" and make bambi eyes, I feel a bit like saying "you were
> warned"

When and where? In this discussion?

As has been stated long ago in this discussion, I2P has been using .i2p
since 2005 (long before my time), for exactly the same reasons as Tor
used .onion. Using the current discussion as an attempt to retroactively
alter how the IETF has done outreach regarding TLDs in the past is
disingenuous.

> 
> ie, squatting a domain, is squatting a domain, no  matter how much you
> believe in your own process. If you populate code to the label, a
> specific label, you're in moral hazard.

As I have also stated long ago in this discussion, I did in fact look
into an alternate avenue which would be a much better technical fit:
defining an AF_I2P. I could find *no way* to achieve this without
requiring patches to the kernels of every OS that we wanted to release
on. So given the choice between "impossible or indefinitely-blocked
solution" and "solution that works", is it surprising that the Tor and
I2P developers went the way they did?

> 
> You cannot predict what label (if any) you will get. You need to code
> agile, to a label being in another space (eg .alt) which is also
> unknown. it has to be in a .conf or other runtime option, not hard
> coded.

If that's the case, why can't everyone using .home or .mail or .corp
also switch? Answer: legacy software. We have tens of thousands of I2P
routers out there, in use right now. We do have some level of control
over *some* of them via updates (but only if the users accept the
update), but we have zero control over all the client software that has
been written over the last decade that expects to see a .i2p address. At
this point, switching .tld is not an option, which leaves us blocked in
the same position as Tor was regarding non-self-signed SSL certificates.

str4d

> 
> forever.
> 
> -G
> 
> On Fri, Apr 1, 2016 at 7:40 AM, str4d  wrote:
>> On 29/03/16 07:53, John Levine wrote:
>>> Finally, no matter what we do, at some point someone will come by with
>>> .GARLIC which is like .ONION but stronger and they will say (with some
>>> justification) that it's used by a zillion people around the world.
>>> "You should have used GARLIC.ALT." "Yeah, I guess so, but we didn't,
>>> sorry."  Then we'll have to deal with it one way or the other.  I hope
>>> that .alt will push that day off farther into the future but it's
>>> unlikely to push it to infinity.
>>
>> Injecting a little levity: I2P does in fact use a variant of onion
>> routing called garlic routing! But we are already in the 6761 process
>> for .I2P, and have absolutely no desire to take garlic any further than
>> a technical metaphor :)
>>
>> str4d
>>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
> 



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[George Michaelson]

Whats your reaction going to be, to a closed 6761 because if you come
to the microphone with a "but we built to the userbase, we have
millions" and make bambi eyes, I feel a bit like saying "you were
warned"

ie, squatting a domain, is squatting a domain, no  matter how much you
believe in your own process. If you populate code to the label, a
specific label, you're in moral hazard.

You cannot predict what label (if any) you will get. You need to code
agile, to a label being in another space (eg .alt) which is also
unknown. it has to be in a .conf or other runtime option, not hard
coded.

forever.

-G

On Fri, Apr 1, 2016 at 7:40 AM, str4d  wrote:
> On 29/03/16 07:53, John Levine wrote:
>> Finally, no matter what we do, at some point someone will come by with
>> .GARLIC which is like .ONION but stronger and they will say (with some
>> justification) that it's used by a zillion people around the world.
>> "You should have used GARLIC.ALT." "Yeah, I guess so, but we didn't,
>> sorry."  Then we'll have to deal with it one way or the other.  I hope
>> that .alt will push that day off farther into the future but it's
>> unlikely to push it to infinity.
>
> Injecting a little levity: I2P does in fact use a variant of onion
> routing called garlic routing! But we are already in the 6761 process
> for .I2P, and have absolutely no desire to take garlic any further than
> a technical metaphor :)
>
> str4d
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[str4d]

On 29/03/16 07:53, John Levine wrote:
> Finally, no matter what we do, at some point someone will come by with
> .GARLIC which is like .ONION but stronger and they will say (with some
> justification) that it's used by a zillion people around the world.
> "You should have used GARLIC.ALT." "Yeah, I guess so, but we didn't,
> sorry."  Then we'll have to deal with it one way or the other.  I hope
> that .alt will push that day off farther into the future but it's
> unlikely to push it to infinity.

Injecting a little levity: I2P does in fact use a variant of onion
routing called garlic routing! But we are already in the 6761 process
for .I2P, and have absolutely no desire to take garlic any further than
a technical metaphor :)

str4d



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Adrien de Croy]

sorry, that second reference should have also been RFC 2826

neither the word "Maintaining" nor "architectural" are present in 2826 
according to the search function in Chrome.


Adrien


-- Original Message --
From: "Adrien de Croy" <adr...@qbik.com>
To: "Paul Hoffman" <paul.hoff...@vpnc.org>; "dnsop@ietf.org" 
<dnsop@ietf.org>

Sent: 1/04/2016 9:25:07 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01




-- Original Message --
From: "Paul Hoffman" <paul.hoff...@vpnc.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Cc: "adr...@qbik.com" <adr...@qbik.com>
Sent: 1/04/2016 12:31:53 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01


On 30 Mar 2016, at 18:49, John Levine wrote:


Isn't it a little late to be refighting this argument?


+1.


I guess now we have some hindsight maybe we could learn from the 
experiences with .onion and maybe look differently at a proposal for 
.alt.





Folks: this thread is about a specific document, not every other thing 
we have discussed before now. If you want to rediscuss (as I sometimes 
do), please at least reference in the document where your argument 
fits. That way, the document authors can maybe amend the document if 
there is consensus to do so.
Well I would start with what is presented as a quote from RFC 2826 
which isn't actually in RFC 2686 and which seems to be the basis for a 
claim of even doing a special use names registry at all.


In Section 4. Architectural considerations

"Maintaining a globally-unique public namespace that supports different 
name resolution protocols is hence an architectural requirement..."


Adrien




--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Adrien de Croy]

-- Original Message --
From: "Paul Hoffman" <paul.hoff...@vpnc.org>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Cc: "adr...@qbik.com" <adr...@qbik.com>
Sent: 1/04/2016 12:31:53 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01


On 30 Mar 2016, at 18:49, John Levine wrote:


Isn't it a little late to be refighting this argument?


+1.


I guess now we have some hindsight maybe we could learn from the 
experiences with .onion and maybe look differently at a proposal for 
.alt.





Folks: this thread is about a specific document, not every other thing 
we have discussed before now. If you want to rediscuss (as I sometimes 
do), please at least reference in the document where your argument 
fits. That way, the document authors can maybe amend the document if 
there is consensus to do so.
Well I would start with what is presented as a quote from RFC 2826 which 
isn't actually in RFC 2686 and which seems to be the basis for a claim 
of even doing a special use names registry at all.


In Section 4. Architectural considerations

"Maintaining a globally-unique public namespace that supports different 
name resolution protocols is hence an architectural requirement..."


Adrien




--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Paul Hoffman]

On 30 Mar 2016, at 18:49, John Levine wrote:


Isn't it a little late to be refighting this argument?


+1.

Folks: this thread is about a specific document, not every other thing 
we have discussed before now. If you want to rediscuss (as I sometimes 
do), please at least reference in the document where your argument fits. 
That way, the document authors can maybe amend the document if there is 
consensus to do so.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Adrien de Croy]

I don't know the answer to that.  If the leakage is still a significant 
problem, maybe they should be looking at alternatives anyway.


Adrien


-- Original Message --
From: "John Levine" <jo...@taugh.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Cc: "adr...@qbik.com" <adr...@qbik.com>
Sent: 31/03/2016 10:49:52 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01


And I don't think .onion meets the threshold set in terms of having a
clear need and lack of alternative solution to the problem.


Isn't it a little late to be refighting this argument?

RFC 7686 was published in October.

R's,
John


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[John Levine]

>And I don't think .onion meets the threshold set in terms of having a 
>clear need and lack of alternative solution to the problem.

Isn't it a little late to be refighting this argument?

RFC 7686 was published in October.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Adrien de Croy]

sure, we could even call home for a machine-readable list.  That would 
help with future additions to the registry.


that's not the point though, the difficulty is in replacing all existing 
deployed implementations.


And I don't think .onion meets the threshold set in terms of having a 
clear need and lack of alternative solution to the problem.


Regards

Adrien

-- Original Message --
From: "Andrew Sullivan" <a...@anvilwalrusden.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Sent: 31/03/2016 6:38:55 a.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01


On Wed, Mar 30, 2016 at 02:15:29AM +, Adrien de Croy wrote:
 Actually making the code change is not the problem. We could easily 
stub out

 .onion in about 5 minutes.


It seems it would be better if you included a mechanism by which the
registry could from time to time be consulted to see whether there are
more things not to include.  (There is an argument to be made here
that the registry is insufficiently usable by machines, of course.
But we could fix that, too.)

Best regards,

A

--
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Suzanne,


On Mar 29, 2016, at 5:23 PM, Suzanne Woolf  wrote:
> I’ve always seen people assume that an entry in the special use names 
> registry means that ICANN won’t delegate the same string in the DNS root.

I thought putting a name onto the special use names registries was an exercise 
in informing ICANN (and the rest of the world) that the IETF was invoking 
clause 4.3(a) of RFC 2860. The last paragraph of 4.3 states:

"In the event ICANN adopts a policy that prevents it from complying with the 
provisions of this Section 4 with respect to the assignments described in (a) - 
(c) above, ICANN will notify the IETF, which may then exercise its ability to 
cancel this MOU under Section 2 above."

Are you suggesting you believe ICANN would want to trigger that exercise or 
that using the special use registry is not invoking clause 4.3(a) (or something 
else)?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Andrew Sullivan]

On Wed, Mar 30, 2016 at 02:15:29AM +, Adrien de Croy wrote:
> Actually making the code change is not the problem. We could easily stub out
> .onion in about 5 minutes.

It seems it would be better if you included a mechanism by which the
registry could from time to time be consulted to see whether there are
more things not to include.  (There is an argument to be made here
that the registry is insufficiently usable by machines, of course.
But we could fix that, too.)

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Paul Hoffman]

On 29 Mar 2016, at 18:57, Andrew Sullivan wrote:


To that claim I
respond that we'd need evidence that we have such a problem.


draft-grothoff-iesg-special-use-p2p-names claimed BIT and ZKEY, both of 
which are trademarked. The fact that we pretty much told developers to 
not bother us with name applications while with consider 6761bis should 
not be used as a tool to suggest non-existence of problems.


But I also fundamentally disagree that "trademarks" are the only naming 
problem we have. Even untrademarked names can have control issues. 
During the run-up to the current work, this WG heard claims that there 
were different digital cash systems that would want names. Does the 
first of them to get an RFC get "CASH"? During the technical 
considerations for that first application, if a second system also uses 
"CASH" as a switch and rapidly becomes bigger than the first, does the 
IETF consensus process need to take that into account? It is implausible 
that a IETF consensus review of a name application could *not* consider 
topics such as term squatting.


Maybe 6761bis will have prohibitions on any consideration of term 
squatting and trademarks during the technical review, but we have not 
seen any evidence of such wording.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Philip Homburg]

In your letter dated 29 Mar 2016 17:51:54 -0400 you wrote:
>> IETF is about protocols, not names. So I can see room for a special
>> purpose domain like .alt, but why would you open that for people
>> who can't be bothered to create a sensible protocol.
>
>So they don't pollute the rest of the DNS namespace with their silly 
>designs, of course.  Once again, we are not the Network Police, and we 
>cannot keep people from doing whatever they want, even if we think it's 
>dumb.  The best we can do here is try to channel the damage, and tell 
>people that if they use .alt, we promise they'll never collide with a 
>domain allocated by ICANN.

I disagree that this a problem worth solving. 

The internet at large was not bothered by .onion. It was the tor project that
found the need to have their use ratified.

>You might want to re-read the .alt draft.  

What's even worse, this draft would not have helped the .onion case at all.

>Also, it seems utterly implausible to ask ICANN to do protocol 
>management.  In 100% of the domains they've delegated so far, it's plain 
>old RFC 1034/1035 DNS.

So, why can't they learn new tricks?

ICANN is doing names, let them do names. They can always create a procedure
that consults the IETF on protocol issues.

You should not have two organisations trying to manage a single name space.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Adrien de Croy]

Just looking at the justification for all of this

from that draft which quotes RFC2826

"To remain a global network, the Internet requires the existence of a 
globally unique public name space. The DNS name space is a hierarchical 
name space derived from a single, globally unique root."


"Maintaining a globally-unique public namespace that supports different 
name resolution protocols is hence an architectural requirement, and 
some facility for reservation of top-level requirement, and some 
facility for reservation of top-level

domains in the DNS is necessary."

I couldn't even find the second para in RFC2826 (search didn't yield 
it), neither does it follow logically from the first paragraph in any 
case.  Google finds the second para only in the problem statement which 
quotes it from RFC2826.  Maybe it was in an earlier draft of 2826, but 
I'd still expect it to be in google somewhere.


Is this the justification for having an extensible registry of special 
names?


Cheers

Adrien





-- Original Message --
From: "John R Levine" <jo...@taugh.com>
To: "Adrien de Croy" <adr...@qbik.com>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Sent: 30/03/2016 3:17:07 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01


I have to say I'm startled to see that people here aren't aware that
.onion is entirely handled in applications.


a google search for "DNS .onion leaks" comes up with many links, many 
relating to reported bugs in browsers.


Yeah, that's why it'd be nice if the DNS resolver rejected them rather 
than telling the world what you were trying to look for in .onion land.


So I don't know if we can truly claim that resolvers are being 
shielded from .onion by the applications.  Maybe it's better now, it 
would be interesting if Symantec were to update this.


They aren't.  That's why it'd be nice to make that bug less leaky.


don't leak into the DNS.  The only thing that anyone's asking DNS
developers to do is to fail .onion requests rather than forwarding
them along.
That's the problem.  Creating new requirements for DNS developers to 
do anything at all is a huge problem.


It's not a requirement.  It's a request.  I expect it's a lot easier 
than whatever you have to do to deal with .local.  If we adopt .alt, 
you can stub that out too and with any luck you're done.


Having said that, I wish there was a way with a single DNS lookup one 
could resolve both/either IPv4 and/or IPv6 addresses from a name with 
a single query (e.g. the "give me any version address" query), rather 
than having to make 2 lookups and fail over etc.  Would basically 
halve the amount of DNS traffic on the network and resolve a lot of 
pathological cases.


Surely you've been reading the draft-vavrusa-dnsop--for-free 
thread.


R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Patrik Fältström]

On 30 Mar 2016, at 1:23, Suzanne Woolf wrote:

> Doubtless I’m missing something though….is there a citation we can ask the 
> draft authors to incorporate in the future?

The formal references we in SSAC have found are the following:

For .corp and .home:



For .mail:



Note that the rationale include:

> Requirements for ICANN:
>
> Work within the IETF and with other relevant technical communities to 
> identify a notification mechanism for IPv6 that provides similar 
> functionality to that available in IPv4's "Loopback" reserved prefix.
>
> Defer delegating .MAIL indefinitely, and collaborate with the technical and 
> security community to identify the best way to handle .MAIL (e.g. permanent 
> reservation through the IETF process).

   Patrik



signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Adrien de Croy]

don't leak into the DNS.  The only thing that anyone's asking DNS
developers to do is to fail .onion requests rather than forwarding
them along.
That's the problem.  Creating new requirements for DNS developers to 
do anything at all is a huge problem.


It's not a requirement.  It's a request.  I expect it's a lot easier 
than whatever you have to do to deal with .local.  If we adopt .alt, 
you can stub that out too and with any luck you're done.
we ignore .local also otherwise we'd break Active Directory resolution 
which also ignores .local, and happily gives us records for .local 
queries over DNS.  So maybe Microsoft is ignoring it too?


I also don't feel a commercial compulsion to implement a multicast DNS 
resolver and server just to deal with that.


In fact we ignore all special use names except localhost.  Stubbing out 
the private IP range reverse zones would break a lot of stuff.  
Example.com etc are seemingly ignored by the internet at large, since I 
can still resolve it.  That leaves .test?





Having said that, I wish there was a way with a single DNS lookup one 
could resolve both/either IPv4 and/or IPv6 addresses from a name with 
a single query (e.g. the "give me any version address" query), rather 
than having to make 2 lookups and fail over etc.  Would basically 
halve the amount of DNS traffic on the network and resolve a lot of 
pathological cases.


Surely you've been reading the draft-vavrusa-dnsop--for-free 
thread.

Thanks for the pointer, I'll check it out.

Cheers

Adrien



R's,
John


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[John R Levine]

I have to say I'm startled to see that people here aren't aware that
.onion is entirely handled in applications.


a google search for "DNS .onion leaks" comes up with many links, many 
relating to reported bugs in browsers.


Yeah, that's why it'd be nice if the DNS resolver rejected them rather 
than telling the world what you were trying to look for in .onion land.


So I don't know if we can truly claim that resolvers are being shielded from 
.onion by the applications.  Maybe it's better now, it would be interesting 
if Symantec were to update this.


They aren't.  That's why it'd be nice to make that bug less leaky.


don't leak into the DNS.  The only thing that anyone's asking DNS
developers to do is to fail .onion requests rather than forwarding
them along.
That's the problem.  Creating new requirements for DNS developers to do 
anything at all is a huge problem.


It's not a requirement.  It's a request.  I expect it's a lot easier than 
whatever you have to do to deal with .local.  If we adopt .alt, you can 
stub that out too and with any luck you're done.


Having said that, I wish there was a way with a single DNS lookup one could 
resolve both/either IPv4 and/or IPv6 addresses from a name with a single 
query (e.g. the "give me any version address" query), rather than having to 
make 2 lookups and fail over etc.  Would basically halve the amount of DNS 
traffic on the network and resolve a lot of pathological cases.


Surely you've been reading the draft-vavrusa-dnsop--for-free thread.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Adrien de Croy]

and secondly to encourage
developers to stub it out in DNS resolvers so that .onion requests
don't leak into the DNS.  The only thing that anyone's asking DNS
developers to do is to fail .onion requests rather than forwarding
them along.
That's the problem.  Creating new requirements for DNS developers to do 
anything at all is a huge problem.



Actually making the code change is not the problem. We could easily stub 
out .onion in about 5 minutes.


Reliably deploying the change however is physically impossible.

We still have people running versions of WinGate from last century, and 
we don't have a time machine to go back and change those.


Adrien





___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Adrien de Croy]

-- Original Message --
From: "John Levine" <jo...@taugh.com>
To: "dnsop@ietf.org" <dnsop@ietf.org>
Cc: "adr...@qbik.com" <adr...@qbik.com>
Sent: 30/03/2016 2:55:22 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01


Surely .onion could have been handled in the application, without
pushing it down to the resolution layer.


I have to say I'm startled to see that people here aren't aware that
.onion is entirely handled in applications.


a google search for "DNS .onion leaks" comes up with many links, many 
relating to reported bugs in browsers.


I think maybe browser vendors would have had a thing to say or two about 
the prospect of having a new list of things to monitor / maintain.  the 
Verisign study of .onion requests hitting their root servers is also 
interesting, noting that .onion was the 461st most popular TLD.


https://www.verisign.com/assets/onionleakage.pdf?inc=www.verisigninc.com

So I don't know if we can truly claim that resolvers are being shielded 
from .onion by the applications.  Maybe it's better now, it would be 
interesting if Symantec were to update this.




The usual implementation
is a modified SOCKS proxy that treats .onion names specially.

The point of reserving .onion in the DNS is first to ensure that
nobody allocates it as an actual DNS domain,

ok



and secondly to encourage
developers to stub it out in DNS resolvers so that .onion requests
don't leak into the DNS.  The only thing that anyone's asking DNS
developers to do is to fail .onion requests rather than forwarding
them along.
That's the problem.  Creating new requirements for DNS developers to do 
anything at all is a huge problem.


People who implement RFCs are used to being able to do the 
implementation, achieve compliance, and then do nothing - safe in the 
knowledge that future changes would be optional or backward compatible.  
This fundamental principle was broken in 6761


Having said that, I wish there was a way with a single DNS lookup one 
could resolve both/either IPv4 and/or IPv6 addresses from a name with a 
single query (e.g. the "give me any version address" query), rather than 
having to make 2 lookups and fail over etc.  Would basically halve the 
amount of DNS traffic on the network and resolve a lot of pathological 
cases.


Cheers

Adrien




R's,
John


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[John Levine]

>Surely .onion could have been handled in the application, without 
>pushing it down to the resolution layer.

I have to say I'm startled to see that people here aren't aware that
.onion is entirely handled in applications.  The usual implementation
is a modified SOCKS proxy that treats .onion names specially.

The point of reserving .onion in the DNS is first to ensure that
nobody allocates it as an actual DNS domain, and secondly to encourage
developers to stub it out in DNS resolvers so that .onion requests
don't leak into the DNS.  The only thing that anyone's asking DNS
developers to do is to fail .onion requests rather than forwarding
them along.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Adrien de Croy]

Sorry if this is just a reprise of a previous discussion, I'm new to 
this list.
I think the concept of an extensible registry for special use domain 
names is complete madness, and the registry should document only 
existing special cases, and not permit any more registrations.  .onion 
should be rescinded.


IMO It is insane to allow the addition of a name to the special use 
names registry to make every DNS agent on the planet no longer 
compliant.


RFC6761 doesn't seem to really contemplate the logistics of modifying 
all DNS resolvers and servers on the planet.  It's a sisyphean task.


Our product includes a DNS resolver.  Even if we did add support for 
.onion, we can't (and wouldn't even if we could) _force_ our customers 
to upgrade.  So the only thing you can count on is that there will 
remain for considerable time a considerable deployment of resolvers who 
ignore any new special use names.  I'm sure you all know that, but it 
seems foolhardy to negotiate sensitive information over .onion 
resolution when that is highly likely to leak.


Surely .onion could have been handled in the application, without 
pushing it down to the resolution layer.

Adrien de Croy

-- Original Message --
From: "George Michaelson" <g...@algebras.org>
To: "Suzanne Woolf" <suzworldw...@gmail.com>
Cc: "dnsop WG" <dnsop@ietf.org>; "David Conrad" <d...@virtualized.org>
Sent: 30/03/2016 1:19:49 p.m.
Subject: Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

Make the application for .alt actually ask for xn--59g and I'd be 
there.


or even xn--3ve9dwb1a

The application demands .alt? It has the same problems as any other.
Its sole purpose should be uniqueness, and choosing a string which has
semantic meaning for a large community is confronting the issue up
front:  It should a symbol-string which has less chance of being asked
for as a name in social contexts, has more chance of being
justifyable.

-G

On Wed, Mar 30, 2016 at 9:23 AM, Suzanne Woolf <suzworldw...@gmail.com> 
wrote:

 David,

 On Mar 28, 2016, at 11:47 PM, David Conrad <d...@virtualized.org> 
wrote:



 FAQ #22 says CORP, HOME, and MAIL have been deferred indefinitely,


 Yep.  The report on name collisions that ICANN commissioned had the 
following recommendation (recommendation #1 as a matter of fact, see 
https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf, 
top of page 5):


 "The TLDs .corp, .home, and .mail be referred to the Internet 
Engineering Task Force (IETF) for potential RFC 1918-like 
protection/treatment."


 Unfortunately, the IETF decided agains this treatment, so those 
strings remain "deferred indefinitely."



 I suspect it would be helpful to the draft authors and the WG to 
provide a public reference for the implied statement here, because it 
could be important to mapping the current relationship among different 
uses of the namespace.


 You seem to be saying that the fact the IETF hasn’t added those 
strings to the special use names registry, per the recommendation of a 
third party consultant hired by ICANN, is somehow part of why they’re 
“deferred indefinitely” instead of having some other status, but it’s 
not completely clear to me what relationship there is among those 
things.


 I’ve never been able to find any reference to the IETF special use 
names registry, or any discussion of its impact on ICANN policy, in 
the Applicant Guidebook for the previous gTLD round, or indeed 
anywhere else. I also haven’t seen a liaison or other open 
communication from ICANN containing an opinion about having the IETF 
reserve the names you mentioned.


 I’ve always seen people assume that an entry in the special use names 
registry means that ICANN won’t delegate the same string in the DNS 
root. But given other discussion in this thread, where the claim is 
being made that any IETF action regarding strings for “special use” is 
subject to socio-economic pressures just as ICANN actions would be, I 
don’t see the basis of the assumption.


 Doubtless I’m missing something though….is there a citation we can 
ask the draft authors to incorporate in the future?



 thanks,
 Suzanne

 ___
 DNSOP mailing list
 DNSOP@ietf.org
 https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[George Michaelson]

Make the application for .alt actually ask for xn--59g and I'd be there.

or even xn--3ve9dwb1a

The application demands .alt? It has the same problems as any other.
Its sole purpose should be uniqueness, and choosing a string which has
semantic meaning for a large community is confronting the issue up
front:  It should a symbol-string which has less chance of being asked
for as a name in social contexts, has more chance of being
justifyable.

-G

On Wed, Mar 30, 2016 at 9:23 AM, Suzanne Woolf  wrote:
> David,
>
>> On Mar 28, 2016, at 11:47 PM, David Conrad  wrote:
>>
>>> FAQ #22 says CORP, HOME, and MAIL have been deferred indefinitely,
>>
>> Yep.  The report on name collisions that ICANN commissioned had the 
>> following recommendation (recommendation #1 as a matter of fact, see 
>> https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf,
>>  top of page 5):
>>
>> "The TLDs .corp, .home, and .mail be referred to the Internet Engineering 
>> Task Force (IETF) for potential RFC 1918-like protection/treatment."
>>
>> Unfortunately, the IETF decided agains this treatment, so those strings 
>> remain "deferred indefinitely."
>
>
> I suspect it would be helpful to the draft authors and the WG to provide a 
> public reference for the implied statement here, because it could be 
> important to mapping the current relationship among different uses of the 
> namespace.
>
> You seem to be saying that the fact the IETF hasn’t added those strings to 
> the special use names registry, per the recommendation of a third party 
> consultant hired by ICANN, is somehow part of why they’re “deferred 
> indefinitely” instead of having some other status, but it’s not completely 
> clear to me what relationship there is among those things.
>
> I’ve never been able to find any reference to the IETF special use names 
> registry, or any discussion of its impact on ICANN policy, in the Applicant 
> Guidebook for the previous gTLD round, or indeed anywhere else. I also 
> haven’t seen a liaison or other open communication from ICANN containing an 
> opinion about having the IETF reserve the names you mentioned.
>
> I’ve always seen people assume that an entry in the special use names 
> registry means that ICANN won’t delegate the same string in the DNS root. But 
> given other discussion in this thread, where the claim is being made that any 
> IETF action regarding strings for “special use” is subject to socio-economic 
> pressures just as ICANN actions would be, I don’t see the basis of the 
> assumption.
>
> Doubtless I’m missing something though….is there a citation we can ask the 
> draft authors to incorporate in the future?
>
>
> thanks,
> Suzanne
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Suzanne Woolf]

David,

> On Mar 28, 2016, at 11:47 PM, David Conrad  wrote:
> 
>> FAQ #22 says CORP, HOME, and MAIL have been deferred indefinitely,
> 
> Yep.  The report on name collisions that ICANN commissioned had the following 
> recommendation (recommendation #1 as a matter of fact, see 
> https://www.icann.org/en/system/files/files/name-collision-mitigation-final-28oct15-en.pdf,
>  top of page 5):
> 
> "The TLDs .corp, .home, and .mail be referred to the Internet Engineering 
> Task Force (IETF) for potential RFC 1918-like protection/treatment."
> 
> Unfortunately, the IETF decided agains this treatment, so those strings 
> remain "deferred indefinitely."


I suspect it would be helpful to the draft authors and the WG to provide a 
public reference for the implied statement here, because it could be important 
to mapping the current relationship among different uses of the namespace.

You seem to be saying that the fact the IETF hasn’t added those strings to the 
special use names registry, per the recommendation of a third party consultant 
hired by ICANN, is somehow part of why they’re “deferred indefinitely” instead 
of having some other status, but it’s not completely clear to me what 
relationship there is among those things.

I’ve never been able to find any reference to the IETF special use names 
registry, or any discussion of its impact on ICANN policy, in the Applicant 
Guidebook for the previous gTLD round, or indeed anywhere else. I also haven’t 
seen a liaison or other open communication from ICANN containing an opinion 
about having the IETF reserve the names you mentioned.

I’ve always seen people assume that an entry in the special use names registry 
means that ICANN won’t delegate the same string in the DNS root. But given 
other discussion in this thread, where the claim is being made that any IETF 
action regarding strings for “special use” is subject to socio-economic 
pressures just as ICANN actions would be, I don’t see the basis of the 
assumption.

Doubtless I’m missing something though….is there a citation we can ask the 
draft authors to incorporate in the future?


thanks,
Suzanne

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Andrew Sullivan]

On Mon, Mar 28, 2016 at 08:49:01PM -0700, David Conrad wrote:
> 
> On Mar 28, 2016, at 8:36 PM, Andrew Sullivan  wrote:
> > But I think you're smuggling into your argument a claim that
> > they're potentially subject to the IPR and socio-economic issues that
> > have been a problem in the DNS root and TLD zones.  That's in effect
> > an argument that the special-names registrations are not special.  I
> > do not agree with that claim.
> 
> Just to be clear, you believe that the IESG putting a name onto the special 
> names registry means that it will then be immune from IPR and socio-economic 
> issues?
> 

I don't see how that is implied by what I wrote.  Apologies that this
is so long, but given your question it's plain I haven't made myself
clear when keeping the message short.

The IPR and socio-economic issues with respect to the DNS root and
TLDs arise within a context. Part of that context involves the fact
that, in many cases, DNS names appear in URIs and on the sides of
busses as approximately-Internet-wide identifiers and so on. This
makes DNS label string similarity with trademark-law word marks a hot
issue for trademark lawyers. (Early in ICANN's history, several
policies were adopted that implicitly accepted such IPR claims. But it
is irrelevant that ICANN currently has such policies or when or how
they arose, because they are in all cases founded in the use-in-public
nature of DNS names given the way certain pieces of user-accessible
identifiers, including email addresses and the host portion of URIs,
work on the Internet.)

The special-use names registry contains, so far, three kinds of names.
Some names are for special use within a DNS context. Examples include
example.com., invalid., and tld. These are all expected to appear in DNS
contexts, and are generally expected not to resolve in a global DNS
sense. There are also special names that do resolve in a global
context, but that have only local meaning.  The reverse trees for
RFC 1918 addresses and localhost. are of this sort.

The third kind is different, however, because it presents a mechanism
which is, in effect, instructions to the agent attempting the
resolution to use a different technology.  So, for instance, names
terminating in local. are not properly speaking candidates for lookup
in the global DNS _at all_.  They're intended to be used in other
contexts (mDNS names, for instance, are more likely to be encountered
in pick lists).  It is not at all clear that these names are really
approximately-Internet-wide identifiers.  The only worked example we
have of this recently is onion, which betokens that a name is for
lookup and use in the context of onion routing and otherwise probably
shouldn't be.

This technical difference _makes_ a difference for what sorts of IPR
claims could be introduced against such names.  Naturally, there could
be IPR or socio-economic issues associated, but they're not the same
ones as are raised in the DNS and in keeping with prevailing ICANN
policies.  (By way of analogy, certain large Internet Exchanges in
the US and extremely remote parts of the developing world both have "a
bandwidth problem", but trying to tackle them as though they were the
same thing would be to make a gross category mistake.)  It will do us
no good at all to attempt to collapse these different kinds of
problems into a single category, which is why I don't accept Alain's
claim that a name is a name.

Now, some appear to be arguing that we _could_ get an application for
a case that would test the distinctions I make above. To that claim I
respond that we'd need evidence that we have such a problem. So far,
all I've heard is "what if?". If we want to attend to things the IETF
is bad at, solving logically possible problems we don't actually have
instantiated is higher on my list than dealing with social and
economic pressure.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[John R Levine]

IETF is about protocols, not names. So I can see room for a special
purpose domain like .alt, but why would you open that for people
who can't be bothered to create a sensible protocol.


So they don't pollute the rest of the DNS namespace with their silly 
designs, of course.  Once again, we are not the Network Police, and we 
cannot keep people from doing whatever they want, even if we think it's 
dumb.  The best we can do here is try to channel the damage, and tell 
people that if they use .alt, we promise they'll never collide with a 
domain allocated by ICANN.



I see .alt more as a way for the IETF to have some reserved space for
future protcols and have all regular proposals deal with ICANN to get
their name. Though it may make sense for the ICANN community to require a
standards track protocol before they assign any top level name.


You might want to re-read the .alt draft.  That is not at all what it's 
about.  Also, it seems utterly implausible to ask ICANN to do protocol 
management.  In 100% of the domains they've delegated so far, it's plain 
old RFC 1034/1035 DNS.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[John Levine]

>- The IETF decides whether the proposal is technically sound or not
>- There is a .alt domain with a registry. Protocols can go there first come,
>  first served, as long as there is consensus that the proposal is technically
>  sound.

Developers will say to heck with that, and just pick a name and use
it, like they've been doing all along.  If we want people to use .alt
we need to make the friction as low as possible.  If there are a lot
of technically lame .alt hacks in the registry with overlapping names,
so be it.

Remember that we are not the Protocol Police, and neither is anyone else.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Alain Durand]

> On Mar 29, 2016, at 3:50 PM, Paul Hoffman  wrote:
> 
>> On 29 Mar 2016, at 8:25, Philip Homburg wrote:
>> 
>> One option would be to have a process that essentially says:
>> - The IETF decides whether the proposal is technically sound or not
>> - There is a .alt domain with a registry. Protocols can go there first come,
>>  first served, as long as there is consensus that the proposal is technically
>>  sound.
>> - Any another name, requires approval from ICANN, however the IETF will 
>> inform
>>  ICANN about consensus on the technical quality of the proposal.
>> 
>> This way ICANN can create policy on the name part of special names and the
>> IETF can focus on the technical part of those proposals.
> 
> This process would possibly work for the IETF, but how would it work for the 
> developer of the technical protocol? They would not know what name to use in 
> practice until after the IETF consensus call was finished. However, it is 
> clear that many people in the community consider part of the technical review 
> process the question of are there any/many users for the name. In order to 
> get some, they need to start using a TLD (not .alt) name knowing that, if 
> they get rejected, they have to change the name in all deployed instances. 
> Technically, that's feasible; operationally, it is not.

This should be the opposite: start with a name with little perceived value, 
under .ALT or anything already existing, and then if you are successful apply 
for something of higher perceived value and change name in deployed code.
Seems like regular business model to me.

Alain
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Paul Hoffman]

On 29 Mar 2016, at 8:25, Philip Homburg wrote:


One option would be to have a process that essentially says:
- The IETF decides whether the proposal is technically sound or not
- There is a .alt domain with a registry. Protocols can go there first 
come,
  first served, as long as there is consensus that the proposal is 
technically

  sound.
- Any another name, requires approval from ICANN, however the IETF 
will inform

  ICANN about consensus on the technical quality of the proposal.

This way ICANN can create policy on the name part of special names and 
the

IETF can focus on the technical part of those proposals.


This process would possibly work for the IETF, but how would it work for 
the developer of the technical protocol? They would not know what name 
to use in practice until after the IETF consensus call was finished. 
However, it is clear that many people in the community consider part of 
the technical review process the question of are there any/many users 
for the name. In order to get some, they need to start using a TLD (not 
.alt) name knowing that, if they get rejected, they have to change the 
name in all deployed instances. Technically, that's feasible; 
operationally, it is not.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[John R Levine]

"The TLDs .corp, .home, and .mail be referred to the Internet Engineering Task Force 
(IETF) for potential RFC 1918-like protection/treatment."

Unfortunately, the IETF decided agains this treatment, so those strings remain 
"deferred indefinitely."


I think it would be fairer to say we didn't decide to do anything.  It 
didn't help that one of the louder voices in the discussion was am 
applicant for .HOME lobbying to keep his application alive, and lobbying 
and consensus work poorly together.


If we're thinking about closing the 6761 registry, it could make sense to 
revisit the question.  It's somewhat complicated because (as far as I can 
see) .home and .mail are likely to collide forever, but now that CAs have 
stopped signing .corp certificates, its usage might decline.



but along with the four remaining applications for MAIL, there are 5 for CORP 
and 10 for HOME, and they haven't given back the $3.5 million in application 
fees, either.


I might be wrong, but I believe that is because the applicants have, to date, 
refused to terminate their applications for those strings. Hard to give back 
money if people refuse to accept it, no?


If I were an applicant, I would note that if I withdraw voluntarily at 
this point, I get 20% of my money back and ICANN keeps 80%.  Since we now 
know none of the applications for those three names could have been 
successful, I'd want 100% back.  Or I might figure that at this point, the 
incremental cost of waiting to see what happens to .corp is pretty low.


R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Paul Hoffman]

On 28 Mar 2016, at 10:32, Suzanne Woolf wrote:

As a practical focus: sometime ago, DNSOP adopted and then parked 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/. This draft 
proposes a special use names registry entry that would be expected to 
function as the rightmost label in names intended for resolution 
outside of the DNS protocol: something of a meta-protocol switch.


Assuming we understand the problems a bit better now than we did 
before, particularly given the experience of .onion, which of the 
problems we've seen would be solved by telling people "You can use any 
domain names you want, but the safe choice for avoiding operational 
and policy collisions with DNS protocol and namespace is to root your 
chosen domain name space under .alt"?


Some. For a truly well-intentioned protocol developer who wants a 
"switch" name and is willing to trade likely long-term 
exclusivity-of-use for slightly-clunky-naming, ".alt" works very well.



Which technical issues would persist?


If the 6761 registry is still open after putting .alt in it, all the 
technical issues that there are today would remain. Different people 
will feel that different technical issues are the most important ones. 
For me, the biggest is "Anyone can propose to reserve a name with no 
more than a technical protocol proposal, and those are easily cloned 
with very minor revisions", but there are certainly other significant 
technical issues as well.


If the 6761 registry is closed after adding .alt, I think there are no 
more technical issues.


If, as some people have argued, the only problem we really have here 
is separating domain names that might be used in the DNS from domain 
names available for use in other resolution contexts, it may be that 
".alt" is both necessary and sufficient to support future experiment 
and development in the use of domain names.


Will that do it? If not, why not?


It could do it, but only if the 6761 registry is closed. If the registry 
is still open, and the only bar is an Internet-Draft that could gain 
"consensus" after wearing down opponents, the 6761 route will remain 
attractive to those who are willing to spend their time (and the time of 
everyone in the IETF consensus process) to "get" a name.




On 28 Mar 2016, at 11:53, John Levine wrote:


Which technical issues would persist?


I can think of two, plus one non-technical one.

The first technical one is whether there is a registry for .alt names
and if so how it'd operate.  From prior discussion, some people think
it should be FCFS to prevent ambiguity.  I think that would be utterly
counterproductive since it'd lead to a squatter rush, and anyway
there's no way to enforce that people use names they've registered.
FCFS with unlimited name collisions would be OK, to help people figure
out where to get the code to implement various name things they've
come across.


That's not really a technical issue with the draft because the draft 
says:


   There is no IANA controlled
   registry for names under the ALT TLD - it is an unmanaged namespace,
   and developers are responsible for dealing with any collisions that
   may occur under .alt.  Informal lists of namespaces under .alt may
   appear to assist the developer community.



The other, which is a can of worms, is whether we want to define
protocol switches.  At this point, there's an implicit switch used for
.local at the DNS level, where you give it a name and it returns an IP
address that might have come from an A or  record or might have
come from somewhere else.  And there's another higher level one at the
socket level used for .onion, where you give it a name and it gives
you back an open socket that might be a TCP or UDP connection to an
addresss found in an A or  record, or it might be something else.
If there's to be any hope that people could use more than one of these
hacks at a time, a protocol switch would be a big help.


Again, that's not really a technical issue with the draft because the 
draft is completely silent on that.



Finally, no matter what we do, at some point someone will come by with
.GARLIC which is like .ONION but stronger and they will say (with some
justification) that it's used by a zillion people around the world.
"You should have used GARLIC.ALT." "Yeah, I guess so, but we didn't,
sorry."  Then we'll have to deal with it one way or the other.  I hope
that .alt will push that day off farther into the future but it's
unlikely to push it to infinity.


Fully agree. That's why, when thinking about .alt, we need to consider 
two different cases:

  - Add .alt to the 6761 registry
  - Add .alt to the 6761 registry and close the registry
To me, the second gives a much clearer picture to both the IETF 
community about what they will be expected to do in the future, and to 
the developers who want new outside-the-DNS name switches.


--Paul Hoffman

___
DNSOP mailing list

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[joel jaeggli]

On 3/28/16 9:08 PM, George Michaelson wrote:
> On Tue, Mar 29, 2016 at 1:36 PM, Andrew Sullivan  
> wrote:
>> That's in effect an argument that the special-names registrations are not 
>> special.  I
>> do not agree with that claim.
> 
>>From an extreme point of view (which clearly, contextually, I hold)
> thats exactly what I think I fundamentally agree with, in what Alain
> is saying: The special-names are claiming technological override on
> process which ignores the central unity of all name-strings:

It doesn't ignore it, it assumes the unity of namespace. otherwise what
would be the point? you'd just go off and do your own thing...

>  for
> ICANN, for the namespace, these are labels like all the others.

indeed.

> They're asking for a joker-card permit, which I have major issues
> with. That aside, they're just like all the others. The qualities they
> have in the zone, the records which do or do not exist are in another
> plane, orthoginal.
> 
> -G
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[George Michaelson]

On Tue, Mar 29, 2016 at 1:36 PM, Andrew Sullivan  
wrote:
> That's in effect an argument that the special-names registrations are not 
> special.  I
> do not agree with that claim.

>From an extreme point of view (which clearly, contextually, I hold)
thats exactly what I think I fundamentally agree with, in what Alain
is saying: The special-names are claiming technological override on
process which ignores the central unity of all name-strings: for
ICANN, for the namespace, these are labels like all the others.

They're asking for a joker-card permit, which I have major issues
with. That aside, they're just like all the others. The qualities they
have in the zone, the records which do or do not exist are in another
plane, orthoginal.

-G

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

George,

On Mar 28, 2016, at 6:58 PM, George Michaelson  wrote:
> Whats the process to understand how, and why a name gets added to the
> list? Thats not an IETF question, understandably, but it would be nice
> to understand it, even only in outline.


As Suzanne mentioned, there is no process as the new gTLD program (for the last 
round) has been shut down.  If/when a new round is created, there will be a new 
process (one undoubtedly based on the previous process but with enough changes 
to keep things interesting).  As that process does not yet exist, it is 
difficult to outline it.

One might view this as an encouragement for folks within the technical 
community (and the IETF in particular) to be less reticent to participate in 
ICANN processes than in the past, despite how excruciatingly painful that might 
be, but that's just crazy talk.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[joel jaeggli]

On 3/28/16 8:49 PM, David Conrad wrote:
> Andrew,
> 
> On Mar 28, 2016, at 8:36 PM, Andrew Sullivan 
> wrote:
>> But I think you're smuggling into your argument a claim that 
>> they're potentially subject to the IPR and socio-economic issues
>> that have been a problem in the DNS root and TLD zones.  That's in
>> effect an argument that the special-names registrations are not
>> special.  I do not agree with that claim.
> 
> Just to be clear, you believe that the IESG putting a name onto the
> special names registry means that it will then be immune from IPR and
> socio-economic issues?

What IETF activity is immune to IPR or sociology-econmic issues?

> Thanks, -drc
> 
> 
> 
> ___ DNSOP mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 




signature.asc
Description: OpenPGP digital signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Andrew,

On Mar 28, 2016, at 8:36 PM, Andrew Sullivan  wrote:
> But I think you're smuggling into your argument a claim that
> they're potentially subject to the IPR and socio-economic issues that
> have been a problem in the DNS root and TLD zones.  That's in effect
> an argument that the special-names registrations are not special.  I
> do not agree with that claim.

Just to be clear, you believe that the IESG putting a name onto the special 
names registry means that it will then be immune from IPR and socio-economic 
issues?

Thanks,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Alain Durand]

I'm sorry if my point was not clear. My perspective is that, at the end of the 
day, a name is a name is a name. Being on the 6761 registry or in the DNS root 
zone is fundamentally irrelevant when it comes to IPR and other related 
socio-political issues. The same concerns apply.

Alain, speaking solely for myself.

> On Mar 28, 2016, at 5:54 PM, Ralph Droms  wrote:
> 
> 
>> On Mar 28, 2016, at 5:41 PM 3/28/16, Alain Durand  
>> wrote:
>> 
>> Andrew,
>> 
>> This is the very registration in 6761 that makes (or would make) those names 
>> special, i.e. not ordinary. Those name could as well have been reserved in 
>> the previous ICANN gTLD round or in the next one for regular DNS purpose. 
>> The is nothing "non-ordinary" about the strings themselves...
> 
> Let me make the point again that the document that records the Standards 
> Action or IESG approval is what designates a name as a special-use name.  
> Therefore, any designation as a special-use name will have IETF consensus.  
> RFC 6761 only documents the process for recording that designation in the 
> Special-Use Names registry.
> 
> What do you mean by "reserved in the previous ICANN gTLD round"?  Do you mean 
> "assigned to some entity", in which case it's highly unlikely the IETF would 
> come to consensus about designating such a name as a special-use name.  Once 
> a name has been designated as a special-use name, it is no longer part of the 
> DNS namespace available for assignment by ICANN.
> 
> But, I may be misunderstanding your point...
> 
> - Ralph
> 
>> 
>> Alain, speaking solely for myself.
>> 
>>> On Mar 28, 2016, at 3:23 PM, Andrew Sullivan  
>>> wrote:
>>> 
>>> Hi,
>>> 
>>> I think I've answered these questions before, but in case not, here's
>>> what I think:
>>> 
 On Mon, Mar 28, 2016 at 12:15:15PM -0700, David Conrad wrote:
 In what way is ONION not "ordinary"?
>>> 
>>> The label "onion" indicates that an alternative resolution path is
>>> intended.  Moreover, an additional underlying networking protocol is
>>> expected to be in use.
>>> 
 In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not 
 "ordinary"
>>> 
>>> An alternative (to DNS) resolution protocol is similarly expected.  In
>>> some cases, additional underlying network protocols are expected.  In
>>> other cases, it is merely an indication of alternative resolution,
>>> with no alternative underlying network technology.  (Part of the
>>> reason I wanted the different cases separated is because I think it's
>>> an open question whether a different naming protocol with _no_
>>> difference in the underlying technology is a legitimate use of 6761.)
>>> 
 Are HOME, CORP, and MAIL "ordinary"?
>>> 
>>> Yes.  They're expected to resolve in ordinary DNS contexts, though not
>>> necessarily the global one.  My own view is that these ought to be
>>> outside the 6761 registry unless some ICANN-based PDP were to
>>> determine that they should be permanently reserved and that the
>>> reservation ought to be sought in the 6761 registry.
>>> 
>>> Best regards,
>>> 
>>> A (as usual, for myself)
>>> 
>>> --
>>> Andrew Sullivan
>>> a...@anvilwalrusden.com
>>> 
>>> ___
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnsop
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Ralph Droms]

> On Mar 28, 2016, at 5:41 PM 3/28/16, Alain Durand  
> wrote:
> 
> Andrew,
> 
> This is the very registration in 6761 that makes (or would make) those names 
> special, i.e. not ordinary. Those name could as well have been reserved in 
> the previous ICANN gTLD round or in the next one for regular DNS purpose. The 
> is nothing "non-ordinary" about the strings themselves...

Let me make the point again that the document that records the Standards Action 
or IESG approval is what designates a name as a special-use name.  Therefore, 
any designation as a special-use name will have IETF consensus.  RFC 6761 only 
documents the process for recording that designation in the Special-Use Names 
registry.

What do you mean by "reserved in the previous ICANN gTLD round"?  Do you mean 
"assigned to some entity", in which case it's highly unlikely the IETF would 
come to consensus about designating such a name as a special-use name.  Once a 
name has been designated as a special-use name, it is no longer part of the DNS 
namespace available for assignment by ICANN.

But, I may be misunderstanding your point...

- Ralph

> 
> Alain, speaking solely for myself.
> 
>> On Mar 28, 2016, at 3:23 PM, Andrew Sullivan  wrote:
>> 
>> Hi,
>> 
>> I think I've answered these questions before, but in case not, here's
>> what I think:
>> 
>>> On Mon, Mar 28, 2016 at 12:15:15PM -0700, David Conrad wrote:
>>> In what way is ONION not "ordinary"?
>> 
>> The label "onion" indicates that an alternative resolution path is
>> intended.  Moreover, an additional underlying networking protocol is
>> expected to be in use.
>> 
>>> In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not 
>>> "ordinary"
>> 
>> An alternative (to DNS) resolution protocol is similarly expected.  In
>> some cases, additional underlying network protocols are expected.  In
>> other cases, it is merely an indication of alternative resolution,
>> with no alternative underlying network technology.  (Part of the
>> reason I wanted the different cases separated is because I think it's
>> an open question whether a different naming protocol with _no_
>> difference in the underlying technology is a legitimate use of 6761.)
>> 
>>> Are HOME, CORP, and MAIL "ordinary"?
>> 
>> Yes.  They're expected to resolve in ordinary DNS contexts, though not
>> necessarily the global one.  My own view is that these ought to be
>> outside the 6761 registry unless some ICANN-based PDP were to
>> determine that they should be permanently reserved and that the
>> reservation ought to be sought in the 6761 registry.
>> 
>> Best regards,
>> 
>> A (as usual, for myself)
>> 
>> --
>> Andrew Sullivan
>> a...@anvilwalrusden.com
>> 
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Alain Durand]

Andrew,

This is the very registration in 6761 that makes (or would make) those names 
special, i.e. not ordinary. Those name could as well have been reserved in the 
previous ICANN gTLD round or in the next one for regular DNS purpose. The is 
nothing "non-ordinary" about the strings themselves...

Alain, speaking solely for myself.

> On Mar 28, 2016, at 3:23 PM, Andrew Sullivan  wrote:
> 
> Hi,
> 
> I think I've answered these questions before, but in case not, here's
> what I think:
> 
>> On Mon, Mar 28, 2016 at 12:15:15PM -0700, David Conrad wrote:
>> In what way is ONION not "ordinary"?
> 
> The label "onion" indicates that an alternative resolution path is
> intended.  Moreover, an additional underlying networking protocol is
> expected to be in use.
> 
>> In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not "ordinary"
> 
> An alternative (to DNS) resolution protocol is similarly expected.  In
> some cases, additional underlying network protocols are expected.  In
> other cases, it is merely an indication of alternative resolution,
> with no alternative underlying network technology.  (Part of the
> reason I wanted the different cases separated is because I think it's
> an open question whether a different naming protocol with _no_
> difference in the underlying technology is a legitimate use of 6761.)
> 
>> Are HOME, CORP, and MAIL "ordinary"?
> 
> Yes.  They're expected to resolve in ordinary DNS contexts, though not
> necessarily the global one.  My own view is that these ought to be
> outside the 6761 registry unless some ICANN-based PDP were to
> determine that they should be permanently reserved and that the
> reservation ought to be sought in the 6761 registry.
> 
> Best regards,
> 
> A (as usual, for myself)
> 
> -- 
> Andrew Sullivan
> a...@anvilwalrusden.com
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Andrew Sullivan]

Hi,

I think I've answered these questions before, but in case not, here's
what I think:

On Mon, Mar 28, 2016 at 12:15:15PM -0700, David Conrad wrote:
> In what way is ONION not "ordinary"?

The label "onion" indicates that an alternative resolution path is
intended.  Moreover, an additional underlying networking protocol is
expected to be in use.

> In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not "ordinary"

An alternative (to DNS) resolution protocol is similarly expected.  In
some cases, additional underlying network protocols are expected.  In
other cases, it is merely an indication of alternative resolution,
with no alternative underlying network technology.  (Part of the
reason I wanted the different cases separated is because I think it's
an open question whether a different naming protocol with _no_
difference in the underlying technology is a legitimate use of 6761.)

> Are HOME, CORP, and MAIL "ordinary"?

Yes.  They're expected to resolve in ordinary DNS contexts, though not
necessarily the global one.  My own view is that these ought to be
outside the 6761 registry unless some ICANN-based PDP were to
determine that they should be permanently reserved and that the
reservation ought to be sought in the 6761 registry.

Best regards,

A (as usual, for myself)

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Andrew,

On Mar 28, 2016, at 11:33 AM, Andrew Sullivan  wrote:
> I am pretty sure that
> whatever could get registered under RFC 6761, it would not be an
> ordinary name in the DNS.

What do you mean by "ordinary"?
In what way is ONION not "ordinary"?
In what way are GNU, ZKEY, BIT, EXIT, I2P, etc., "ordinary" or not "ordinary"
Are HOME, CORP, and MAIL "ordinary"?

Thanks,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Ralph,

On Mar 28, 2016, at 6:43 AM, Ralph Droms  wrote:
> First, I'll emphasize that the process of designating a name as "special use" 
> is separate from the mechanical process of actually adding a new name to the 
> Special-Use Names registry.

Agreed.

> RFC 6761 explicitly defines the latter process, and implicitly requires open 
> IETF review for the former process.  In my opinion, we can focus on the 
> former process, of deciding whether a name should be designated as having a 
> special use.  This process may have, as you point out, issues regarding 
> trademarks, association of names with organizations, and many others.
> 
> I'm not trying to wish those issues away, and I don't think Andrew is either. 
>  Rather, speaking only for myself, I believe that our open process of 
> community review and consensus is an appropriate starting point for 
> discussion.

In my limited experience, the IETF process is great for (a subset of) technical 
matters. It has perhaps been less than great in social/political/economic 
matters and I thought there was a general reluctance for the IETF to go that 
direction. I am a bit surprised there appears to be a desire, implicit or not, 
to apply the IETF process in these non-technical areas, particularly as many 
assume that part of the reason for 2860 was specifically because the IETF 
wasn't, at least historically, particularly well suited to or interested in 
dealing with these kinds of non-technical issues.

I am a bit curious as to the rationale behind the change of heart.

Regards,
-drc
(Speaking only for myself)


signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[John Levine]

>any domain names you want, but the safe choice for avoiding operational and 
>policy collisions with
>DNS protocol and namespace is to root your chosen domain name space under 
>.alt"?
>
>Which technical issues would persist? 

I can think of two, plus one non-technical one.

The first technical one is whether there is a registry for .alt names
and if so how it'd operate.  From prior discussion, some people think
it should be FCFS to prevent ambiguity.  I think that would be utterly
counterproductive since it'd lead to a squatter rush, and anyway
there's no way to enforce that people use names they've registered.
FCFS with unlimited name collisions would be OK, to help people figure
out where to get the code to implement various name things they've
come across.

The other, which is a can of worms, is whether we want to define
protocol switches.  At this point, there's an implicit switch used for
.local at the DNS level, where you give it a name and it returns an IP
address that might have come from an A or  record or might have
come from somewhere else.  And there's another higher level one at the
socket level used for .onion, where you give it a name and it gives
you back an open socket that might be a TCP or UDP connection to an
addresss found in an A or  record, or it might be something else.
If there's to be any hope that people could use more than one of these
hacks at a time, a protocol switch would be a big help.

Finally, no matter what we do, at some point someone will come by with
.GARLIC which is like .ONION but stronger and they will say (with some
justification) that it's used by a zillion people around the world.
"You should have used GARLIC.ALT." "Yeah, I guess so, but we didn't,
sorry."  Then we'll have to deal with it one way or the other.  I hope
that .alt will push that day off farther into the future but it's
unlikely to push it to infinity.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Andrew Sullivan]

Hi,

On Mon, Mar 28, 2016 at 01:11:56PM +, Alain Durand wrote:
> ICANN history has shown us that anything that has a name attached to it is
> a potentially candidate for such a dispute.

I am not sure I accept this premise.  It seems to me that ICANN's
history is bound up with names in the DNS.  I am pretty sure that
whatever could get registered under RFC 6761, it would not be an
ordinary name in the DNS.  It seems to me for your argument to work,
you need to show that registrations of names that cannot be resolved
as part of the normal DNS resolution mechanism would also be subject
to such a dispute.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Alain Durand]

Sent from my iPhone
> On Mar 28, 2016, at 1:31 PM, Suzanne Woolf  wrote:
> 
> As a practical focus: sometime ago, DNSOP adopted and then parked 
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/. This draft 
> proposes a special use names registry entry that would be expected to 
> function as the rightmost label in names intended for resolution outside of 
> the DNS protocol: something of a meta-protocol switch.

Such a solution as the clear benefit to get the IETF out of the name evaluation 
quagmire. The more I look into it, the more I'm drawn to a solution that would 
look like this: apply 6761 one last time to create .alt (or ._ or whatever) and 
*then* close the registry.

Alain, speaking solely for myself.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Suzanne Woolf]

Dear colleagues,

Thanks to John for this input, and all who've commented so far; but I'd like to 
use John's comment to slightly re-focus this conversation.

It has seemed to me from the beginning of this discussion, and even the 
establishment of the special use names registry, that it's fairly easy to get 
caught up in this aspect of the discussion, which focuses on the implications 
of using specific strings in specific contexts. In particular, we tend to focus 
on possible collisions between the special use names registry and the registry 
representing the public DNS root zone, and on hand-wringing over the fact those 
registries are operated by different parties.

While it's true there's potential for such collisions, and easy to argue that 
the potential needs attention in forming any solutions, potential collision 
between those registries is not necessarily the only or the biggest issue we 
have to address.

So I think it would be good to consider the broader issues, which are not 
specific to which strings are used in which context. 

It seems to me that "the bigger picture" needs to consider that the use of 
domain names is diverging in certain ways from practices and procedures for 
allocating names for use in other contexts, including but not limited to the 
DNS protocol context. This is leading to various complications, including 
possible (and even actual) collisions among domain names as used in different 
contexts; uncertainty around whether a given name can or can't be instantiated 
in a given context; the interaction between IETF registries and what's 
essentially protocol development taking place outside of IETF process; and some 
other architectural and operational issues arising from the fact people find 
domain names useful outside of DNS protocol (and indeed, they always have). 

I'd like very much to see us separate issues that depend on *which* strings are 
used, such as whether anyone's process includes a provision for avoiding a 
specific type of collision, from issues we'd have even if we've set aside a 
subset of the namespace structured to avoid policy issues arising from the use 
of the domain name space in the DNS root.

As a practical focus: sometime ago, DNSOP adopted and then parked 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/. This draft proposes 
a special use names registry entry that would be expected to function as the 
rightmost label in names intended for resolution outside of the DNS protocol: 
something of a meta-protocol switch.

Assuming we understand the problems a bit better now than we did before, 
particularly given the experience of .onion, which of the problems we've seen 
would be solved by telling people "You can use any domain names you want, but 
the safe choice for avoiding operational and policy collisions with DNS 
protocol and namespace is to root your chosen domain name space under .alt"?

Which technical issues would persist? 

If, as some people have argued, the only problem we really have here is 
separating domain names that might be used in the DNS from domain names 
available for use in other resolution contexts, it may be that ".alt" is both 
necessary and sufficient to support future experiment and development in the 
use of domain names. 

Will that do it? If not, why not?

The question of how to think about name resolution context in the internet in 
general-- even separately from domain names-- is the departure point for the 
ARCING BoF.  But the concerns addressed in the special-names-problem draft, 
regarding how domain names are used by DNS and possibly other name resolution 
protocols, seem to be still within scope for DNSOP.


thanks,
Suzanne

On Mar 28, 2016, at 12:35 PM, John Levine  wrote:

>> I understand Andrew's point to be that the decision process regarding 
>> trademark, etc., disputes will
>> take place as part of the review process inherent in meeting the 
>> requirements for publishing 'an IETF
>> "Standards Action" or "IESG Approval" specification', which is required in 
>> RFC 6761 for adding a name
>> to the registry.
> 
> I read it somewhat differently: trademark issues are not technical and
> insofar as they're anyone's problem, they're ICANN's.  There's lots of
> other non-technical arguments about who gets to put names where, such
> as the endless argument about .AFRICA which is now taking a detour
> through U.S. courts.
> 
> One of the things to consider in a 6761 evaluation is whether it's
> really a technical proposal or whether someone's trying to make an end
> around the ICANN process.  If it's really a trademark dispute or
> something else that isn't technically different from the DNS, it's not
> our problem.
> 
> R's,
> John
> 
> 
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[John Levine]

>I understand Andrew's point to be that the decision process regarding 
>trademark, etc., disputes will
>take place as part of the review process inherent in meeting the requirements 
>for publishing 'an IETF
>"Standards Action" or "IESG Approval" specification', which is required in RFC 
>6761 for adding a name
>to the registry.

I read it somewhat differently: trademark issues are not technical and
insofar as they're anyone's problem, they're ICANN's.  There's lots of
other non-technical arguments about who gets to put names where, such
as the endless argument about .AFRICA which is now taking a detour
through U.S. courts.

One of the things to consider in a 6761 evaluation is whether it's
really a technical proposal or whether someone's trying to make an end
around the ICANN process.  If it's really a trademark dispute or
something else that isn't technically different from the DNS, it's not
our problem.

R's,
John

 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Andrew Sullivan]

On Fri, Mar 25, 2016 at 08:29:24PM -0700, David Conrad wrote:
> 
> Sorry, how is it "plain"?

If a name is already somehow implicated in those policies, I should
hope everyone agrees that the IETF and IESG are sane enough not to try
to reserve something in competition with it.  If we don't agree about
that, then I think we have big troubles in general.

> Is it plain that (say) GNU is/is not a candidate for 6761?

As far as I know, right now ICANN's policies have nothing to say about
the string "gnu" in the top level.  So for that reason, if it were
necessary for some other technical reason it doesn't seem it would be
a problem under 6761.  (If I'm wrong about ICANN's policies, then that
changes my view.  That's the sort of evaluation work I'd expect to
happen if we had such a proposal that seemed likely to proceed.  But
this is precisely, for instance, the argument I've made repeatedly in
dnssd and homenet about the proposal to use a "home" pseudo-tld in
parallel with "local".  We shouldn't do it because it's already
implicated elsewhere.)

> Given https://gnunet.org/gns and the purported interest of folks involved in 
> that project to use 6761, what is supposed to happen if the folks at 
> http://www.gnu.com decided to pursue a brand TLD in the next round?  If the 
> folks at https://onion.coop or http://www.theonion.com had applied for a 
> brand TLD in the last round, what would the TOR folks have done?
>

It sure sounds to me like the long-ago accession to trademark
interests in the DNS is coming back to bite us, dunnit?
 
> At the highest level, perhaps what we're talking about is what characterizes 
> "technical use" sufficient to justify application of 2860 4.3(a).
> 

Yes, I think that's right.  It seems obvious to me that both local and
onoin met that test, because they both have a function of triggering
software to do something.  I cannot say that I like this design
pattern, but it is well-established and it is clearly a technical
function.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Andrew,

On Mar 25, 2016, at 7:16 PM, Andrew Sullivan  wrote:
> I think it is plain that a name that is actually somehow implicated in
> the existing root policies (in which I would include names that are
> excluded under some ICANN policy) are just not candidates for 6761
> reservation, and I would expect the necessary consensus involved to
> ensure that happens.

Sorry, how is it "plain"?

Is it plain that (say) GNU is/is not a candidate for 6761?  Given 
https://gnunet.org/gns and the purported interest of folks involved in that 
project to use 6761, what is supposed to happen if the folks at 
http://www.gnu.com decided to pursue a brand TLD in the next round?  If the 
folks at https://onion.coop or http://www.theonion.com had applied for a brand 
TLD in the last round, what would the TOR folks have done?

> For we're talking about names that people have had the opportunity to
> try to claim, but have not done.

I don't think so: this appears to assume a one-time event.

At the highest level, perhaps what we're talking about is what characterizes 
"technical use" sufficient to justify application of 2860 4.3(a).

Thanks,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Ralph Droms]

> On Mar 25, 2016, at 9:37 PM 3/25/16, Paul Hoffman  
> wrote:
> 
> On 25 Mar 2016, at 8:33, Ralph Droms wrote:
> 
>> I'm responding here with none of my various hats on...
> 
> As are we all. (Or, in some of our cases, wearing none of our organization's 
> jaunty logos...)
> 
>> Here's the tl;dr version.  This document has some useful information and 
>> raises, directly and indirectly, some important questions that the IETF 
>> should consider.  Unfortunately, those useful bits are buried in a polemic 
>> that is directed toward a specific outcome.  If this document is accepted as 
>> a WG document, I strongly suggest that it be heavily edited to extract and 
>> emphasize the useful text and discard the rest.
> 
> Understood. However, you said one very significant thing to support that view 
> that is factually incorrect, and goes to the heart of what I read as a 
> motivator for the longer list of problems in 
> draft-adpkja-dnsop-special-names-problem. You say:
> 
>> RD>> I disagree with this characterization of RFC 6761, which provides
>> an explicit registry for behaviors that are specified in other
>> documents for special handling.  My view of the process defined in RFC
>> 6761 is that an RFC is published that describes the special use for
>> part of the domain namespace.  The decision about whether to
>> standardize that use is implicitly part of the RFC publication
>> process.  Once the decision is made to publish the RFC, the effects of
>> the standardized use of the subset of the namespace is recorded in the
>> RFC 6761 registry.
> 
> But that's *not* what RFC 6761 says. Instead, it says:
>   If it is determined that special handling of a name is required in
>   order to implement some desired new functionality, then an IETF
>   "Standards Action" or "IESG Approval" specification [RFC5226] MUST be
>   published describing the new functionality.

You are right.  I wrote imprecisely and reviewed what I wrote hastily.  I would 
have been more correct to simply quote that text from RFC 6761, and point out 
that RFC 6761 leaves the process for determining that a name is to be 
designated as a special-use name as implicitly out of scope.

> Both an IETF "Standards Action" and an "IESG Approval" require IETF 
> consensus; RFC publication does not.

I agree and it's an important point that the process of designating a name for 
special use requires IETF consensus, which implies IETF review and discussion 
of any potential designation.  It was a point I was trying to make but made 
badly.  Thanks for the clarification.

> My reading of the extensive list of problems in 
> draft-adpkja-dnsop-special-names-problem is that most of them stem from lack 
> of IETF consensus. Both the WG Last Call and IETF Last Call on .onion were 
> contentious and were possibly moved forward more due to exhaustion than 
> actual consensus (see RFC 7282).
> 
> Personally, I don't find listing the problems that came out during those 
> consensus calls a "polemic", but you might.

I'll agree to disagree with you on this point.

> 
> --Paul Hoffman

- Ralph




signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Andrew Sullivan]

Hi,

Since we're making disclaimers, ObDisclaimerPersonalViews.

On Fri, Mar 25, 2016 at 08:32:02PM +, Alain Durand wrote:
> IMHO, a "more well-defined decision process" would not help, as I would argue 
> that the IETF (and the IESG as well) is ill-equipped
> to wade in the political/economic/social space tied to policies evaluating 
> which names are OK to reserve and which ones are not.
> My applies to any names, being “special" or not.

I don't think I understand why.  

I think it is plain that a name that is actually somehow implicated in
the existing root policies (in which I would include names that are
excluded under some ICANN policy) are just not candidates for 6761
reservation, and I would expect the necessary consensus involved to
ensure that happens.  (If we don't believe that the necessary IETF
consultations would prevent such a mistake, then we have much bigger
problems than 6761.  Our entire standards process is in trouble.)  It
would also obviously include any names that were part of an ICANN
application for a new TLD.  (This is why I didn't feel comfortable
using 6761 to reserve home and corp, without ICANN's explicit decision
to reject the applications in question and permanently set the names
aside.  I agree that we don't want the special-use registry to become
a stealth way to solve political problems in ICANN's world.)

So the question is whether we have to worry about cases outside those.
I don't know what the political/economic/social space is in that case.
For we're talking about names that people have had the opportunity to
try to claim, but have not done.  So what problem do you think you're
trying to avoid?

On the flip side, if there is some technical use that means a domain
needs to have special use, that is a positive reason for the IETF to
proceed with its own standards-setting procedures, so long as there is
no conflict with ICANN's root zone activities.

> RFC2860 section 4.3 recognized this inadequacy very clearly:
> "Two particular assigned spaces present policy issues in addition to the 
> technical considerations specified by the IETF:
> the assignment of domain names, and the assignment of IP address blocks. 
> These policy issues are outside the scope of this MOU.”

I think you will find that the _very next paragraph_ in that RFC says,

   Note that (a) assignments of domain names for technical uses (such as
   domain names for inverse DNS lookup), (b) assignments of specialised
   address blocks (such as multicast or anycast blocks), and (c)
   experimental assignments are not considered to be policy issues, and
   shall remain subject to the provisions of this Section 4.

The question is whether the 6761 cases fall under "assigment of domain
names for technical uses".  To me, the various questions in 6761
suggest that the answer is "yes", but you might disagree.

Best regards,

A
-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Paul Hoffman]

On 25 Mar 2016, at 8:33, Ralph Droms wrote:


I'm responding here with none of my various hats on...


As are we all. (Or, in some of our cases, wearing none of our 
organization's jaunty logos...)


Here's the tl;dr version.  This document has some useful information 
and raises, directly and indirectly, some important questions that the 
IETF should consider.  Unfortunately, those useful bits are buried in 
a polemic that is directed toward a specific outcome.  If this 
document is accepted as a WG document, I strongly suggest that it be 
heavily edited to extract and emphasize the useful text and discard 
the rest.


Understood. However, you said one very significant thing to support that 
view that is factually incorrect, and goes to the heart of what I read 
as a motivator for the longer list of problems in 
draft-adpkja-dnsop-special-names-problem. You say:



RD>> I disagree with this characterization of RFC 6761, which provides
an explicit registry for behaviors that are specified in other
documents for special handling.  My view of the process defined in RFC
6761 is that an RFC is published that describes the special use for
part of the domain namespace.  The decision about whether to
standardize that use is implicitly part of the RFC publication
process.  Once the decision is made to publish the RFC, the effects of
the standardized use of the subset of the namespace is recorded in the
RFC 6761 registry.


But that's *not* what RFC 6761 says. Instead, it says:
   If it is determined that special handling of a name is required in
   order to implement some desired new functionality, then an IETF
   "Standards Action" or "IESG Approval" specification [RFC5226] MUST 
be

   published describing the new functionality.
Both an IETF "Standards Action" and an "IESG Approval" require IETF 
consensus; RFC publication does not. My reading of the extensive list of 
problems in draft-adpkja-dnsop-special-names-problem is that most of 
them stem from lack of IETF consensus. Both the WG Last Call and IETF 
Last Call on .onion were contentious and were possibly moved forward 
more due to exhaustion than actual consensus (see RFC 7282).


Personally, I don't find listing the problems that came out during those 
consensus calls a "polemic", but you might.


--Paul Hoffman

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Alain Durand]

> On Mar 25, 2016, at 1:48 PM, Ralph Droms  wrote:
> 
>>> 
>>> By design, RFC 6761 makes no
>>> statement about a specific WG or evaluation body or process.
>> 
>> Which is, of course, one of the key problems. It results in an undefined 
>> decision process dependent on the individual subjective evaluation of IESG 
>> members.  Given the economic, political, and social implications of the 
>> naming hairball, this seems like a really bad idea to me.
> 
> It is certainly a key issue and I hope we can get a focused discussion going 
> about whether there is consensus that a more well-defined decision process is 
> needed and, if so, what are the specifics of that process.


Let me speak here solely as a long time (20+ year) IETF participant that has 
been through successes and failures of this organization.
IMHO, a "more well-defined decision process" would not help, as I would argue 
that the IETF (and the IESG as well) is ill-equipped
to wade in the political/economic/social space tied to policies evaluating 
which names are OK to reserve and which ones are not.
My applies to any names, being “special" or not.

RFC2860 section 4.3 recognized this inadequacy very clearly:
"Two particular assigned spaces present policy issues in addition to the 
technical considerations specified by the IETF:
the assignment of domain names, and the assignment of IP address blocks. These 
policy issues are outside the scope of this MOU.”

At the end of the day, this is the key issue in 6761.

Alain.





smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Ralph Droms]

Thanks for the quick followup, David...

> On Mar 25, 2016, at 1:04 PM 3/25/16, David Conrad  
> wrote:
> 
> Ralph,
> 
> On Mar 25, 2016, at 8:33 AM, Ralph Droms  wrote:
>> I'm responding here with none of my various hats on...
> 
> Me too.
> 
>> RD>> I think it's more correct to write that RFC 7686 defines ".onion"
>> as a Special-Use Domain Name, which takes it out of the Domain Name
>> space.
> 
> No.  It is still a domain name in the sense that it is within the universe of 
> identifiers under a singly rooted namespace used on the public Internet (the 
> "domain name namespace").  What it is not is a part of the subset of that 
> namespace that is resolved using the DNS protocol/infrastructure.

Yes, you're right.  I understand and actually meant to write what you wrote...

>> RD>> Similarly, why are .uucp and .bitnet "bad precedents"?
> 
> They are bad precedents because of the challenges they caused for network 
> operations. Specifically, the fact that they were local policy considerations 
> meant that references to a .bitnet or .uucp name within one administrative 
> domain would work but would fail when that reference escaped that 
> administrative domain (e.g., in a cc line of an email address). In my view, 
> this is essentially the same problem that led to the IAB publishing 2826. One 
> of my concerns with 6761 is that it can encourage recreating that 
> operationally challenging world without explaining the inherent risks.

Thanks for that explanation.  I think it would be helpful to include it in any 
future revs of the problem statement.

> 
>> I think the common assumption is that everything
>> not lised in the Special-Use Domain Names registry is in the DNS name
>> space, which would make the Registry a complete catalog.
> 
> I disagree. I believe the domain name namespace can be broken down into:
> 
> 1. In the DNS (exists within the root zone)
> 2. Not in the DNS (exists within the special use registry)
> 3. Not defined (everything else)
> 
> The primary issue I have with 6761 is that while it is relatively clear who 
> the authority is for (1) and (2), it does not provide a clear answer about 
> the authority for (3) or how a name gets put into (1) or (2) when taken in 
> the context of 2860, section 4.3.

OK, I agree with your 3 categories.  I think you elaborated on the observation 
about authority for (3) and process for moving a name to (1) or (2) below...

> 
>> By design, RFC 6761 makes no
>> statement about a specific WG or evaluation body or process.
> 
> Which is, of course, one of the key problems. It results in an undefined 
> decision process dependent on the individual subjective evaluation of IESG 
> members.  Given the economic, political, and social implications of the 
> naming hairball, this seems like a really bad idea to me.

It is certainly a key issue and I hope we can get a focused discussion going 
about whether there is consensus that a more well-defined decision process is 
needed and, if so, what are the specifics of that process.

- Ralph

> 
> Regards,
> -drc
> (speaking only for myself)
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[David Conrad]

Ralph,

On Mar 25, 2016, at 8:33 AM, Ralph Droms  wrote:
> I'm responding here with none of my various hats on...

Me too.

> RD>> I think it's more correct to write that RFC 7686 defines ".onion"
> as a Special-Use Domain Name, which takes it out of the Domain Name
> space.

No.  It is still a domain name in the sense that it is within the universe of 
identifiers under a singly rooted namespace used on the public Internet (the 
"domain name namespace").  What it is not is a part of the subset of that 
namespace that is resolved using the DNS protocol/infrastructure.

> RD>> Similarly, why are .uucp and .bitnet "bad precedents"?

They are bad precedents because of the challenges they caused for network 
operations. Specifically, the fact that they were local policy considerations 
meant that references to a .bitnet or .uucp name within one administrative 
domain would work but would fail when that reference escaped that 
administrative domain (e.g., in a cc line of an email address). In my view, 
this is essentially the same problem that led to the IAB publishing 2826. One 
of my concerns with 6761 is that it can encourage recreating that operationally 
challenging world without explaining the inherent risks.

> I think the common assumption is that everything
> not lised in the Special-Use Domain Names registry is in the DNS name
> space, which would make the Registry a complete catalog.

I disagree. I believe the domain name namespace can be broken down into:

1. In the DNS (exists within the root zone)
2. Not in the DNS (exists within the special use registry)
3. Not defined (everything else)

The primary issue I have with 6761 is that while it is relatively clear who the 
authority is for (1) and (2), it does not provide a clear answer about the 
authority for (3) or how a name gets put into (1) or (2) when taken in the 
context of 2860, section 4.3.

> By design, RFC 6761 makes no
> statement about a specific WG or evaluation body or process.

Which is, of course, one of the key problems. It results in an undefined 
decision process dependent on the individual subjective evaluation of IESG 
members.  Given the economic, political, and social implications of the naming 
hairball, this seems like a really bad idea to me.

Regards,
-drc
(speaking only for myself)





signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Ralph Droms]

I'm responding here with none of my various hats on...

Here's the tl;dr version.  This document has some useful information and 
raises, directly and indirectly, some important questions that the IETF should 
consider.  Unfortunately, those useful bits are buried in a polemic that is 
directed toward a specific outcome.  If this document is accepted as a WG 
document, I strongly suggest that it be heavily edited to extract and emphasize 
the useful text and discard the rest.

If you're still reading...

Let me start with the fundamental difference I have with one of the key 
pre-conclusions of this document.  In my opinion, RFC 6761 and the Special-Use 
Domain Names registry meet the requirement of a complete and useful way to 
record and make available information about domain names designated to be 
special use.  Section 4 of RFC 6761 explicitly leaves the identification of 
special use names to "Standards Action" or "IESG Approval".  I've made several 
comments below in which I think the distinction is important for the accuracy 
and authority of draft-adpkja-dnsop-special-names-problem.

The document does identify some key questions the IETF should
consider:
* does the IETF want to formally sanction protocol switching based on
  the last label?
* should the IETF coordinate the designation of special-use domain
  names with other bodies such as ICANN; if so, how?
* does the IETF want to specify a more formal review process for the
  designation of special-use domain names?

I think this document would be greatly strengthened and far more helpful to the 
dnsop WG and the IETF if it included a clear identification of a list of 
specific problems that have been encountered with the review and publication of 
documents that define special use names in the past, and that might be 
encountered in the future.  Citations of mailing list discussions that lead to 
the identification of the specific problems would be a real plus.

Finally, I think the document would be strengthened by editing out text on 
solutions and editing down the text to state and motivate the problems directly 
and succinctly.

Specific comments, more or less in the order of appearance in 
draft-adpkja-dnsop-special-names-problem-02:

Abstract

   The dominant protocol for name resolution on the Internet is the
   Domain Name System (DNS).  However, other protocols exist that are
   fundamentally different from the DNS, and may or may not share the
   same namespace.

RD>> I think the problem is actually broader than just other
protocols.  We have a namespace that is primarily used for names
intended for resolution through DNS, but, as recorded in RFC 6761,
there are parts of the namespace that are handled in special ways.

   When an end-user triggers resolution of a name on a system which
   supports multiple, different protocols (or resolution mechanisms) for
   name resolution, it is desirable that the protocol used is
   unambiguous, and that requests intended for one protocol are not
   inadvertently answered using another.

RD>> editorial: too much detail for an abstract?

   RFC 6761 introduced a framework by which, under certain
   circumstances, a particular domain name could be acknowledged as
   being special.  This framework has been used twice to reserve top-
   level domains (.local and .onion) that should not be used within the
   DNS, to avoid the possibility of namespace collisions in parallel use
   of non-DNS name resolution protocols.

RD>> I disagree with this characterization of RFC 6761, which provides
an explicit registry for behaviors that are specified in other
documents for special handling.  My view of the process defined in RFC
6761 is that an RFC is published that describes the special use for
part of the domain namespace.  The decision about whether to
standardize that use is implicitly part of the RFC publication
process.  Once the decision is made to publish the RFC, the effects of
the standardized use of the subset of the namespace is recorded in the
RFC 6761 registry.

   Various challenges have become apparent with this application of the
   guidance provided in RFC 6761.  This document aims to document those
   challenges in the form of a problem statement, to facilitate further
   discussion of potential solutions.

RD>> I would phrase the problem as challenges in the process of
reviewing documents that would standardize special uses of names from
the domain name space.

RD>> Editorial nit: the Introduction is usually the first section of
the body of the document.

RD>> In 2. Introduction, and I'm sorry to be repeating myself, in my
opinion RFC 6761 records the special uses of some domain names, as
approved for publication as an Internet Standard.  I'll also repeat
myself that RFC 6761 describes other alternative special handling
aside from protocol switches.  That alternative special handling must
be considered carefully at the time of publication of the defining
RFC, regardless of the nature of the 

Re: [DNSOP] draft-adpkja-dnsop-special-names-problem-01

[Stephane Bortzmeyer]

On Tue, Mar 08, 2016 at 02:09:12PM +,
 Alain Durand  wrote 
 a message of 207 lines which said:

> draft-adpkja-dnsop-special-names-problem-01 has been posted today.

[One warning: I think the entire idea is bad. There is no "problem" to
solve, we have RFC 6761 and it works (it worked for Apple, it can work
for free software like GNUnet). I do not object to an effort to create
a 6761-bis, addressing lacks like the absence of a mailing list
designated to review the proposals like it exists for URI schemes,
media types, etc.]

> The authors know that the subject addressed in this document is
> controversial. We hope it will help clarify the discussion. In many
> places, we know different opinion exits. We have tried to reflect
> the existence of those opposition views to the best of our
> possibilities.

I cannot say it was successful... Quite the contrary, the draft tries
to do too much, by mentioning everything the authors can think about
against RFC 6761, sometimes without a serious evaluation. An example
is mentioning that Tor is a non-IETF protocol, as if it should make
any difference.

> This means that these names can be entered in any application which
> takes exiting DNS names.

The draft speaks sometimes of DNS names, sometimes of domain names,
and does not explain if there is a difference. Clearly, a DNS name
uses the DNS so 7j3ncmar4jm2r3e7.onion is *not* a DNS name (it is a
domain name). [I agree with Paul Hoffman that a section explaining the
difference, and the constraints on DNS names, would be useful.]

> More over, the answers to the seven questions are not available in a
> machine readable form to applications that want to follow [RFC6761].

It's funny, it is one of the few points where there is clearly
something lacking in RFC 6761 and it just deserves one sentence. I
would prefer to see dnsop working on addressing this issue, than on
trying very hard to close to door to new TLDs.

> The discussions in the DNSOP WG and the IETF Last Call processes
> about the .onion registration in the Special Use Domain Names
> registry (1,200 messages) have made it apparent that clarity about
> if and how to treat this "protocol switching" practice would help a
> lot

I don't think the number of messages is a good metric. The issue is
hot because names are sensitive and because of the heavy
politicization of the subject, this is why there have been so many
messages, not because RFC 6761 is not clear.

> What is missing in [RFC6761] is the consideration of the name
> itself.  If one were to contrast the procedures relating to the
> admission of a name to the IETF Special Use Name registry to the
> processes associated with the New gTLD Program operated by ICANN,
> then it is evident that the IETF process does not admit many
> considerations which appear to be areas of evaluation in the new
> gTLD program.

I would not mention the ICANN processes as an example, far from
it. "ICANN has a heavy and political and complicated process for this,
so we must not attempt to do it if we don't have such a process."

> They refer to bad precedents such as .uucp and .bitnet.

In what way were there "bad"? Instead of labelling software with such
terms, one should explain, and draw real lessons from
experience. .bitnet and .uucp were big successes, the software behind
it disappeared but they were not "bad".

> For example, is large scale prior deployment an acceptable criteria?
> A number of voices have clearly answered "no" to that question as it
> would only encourage "squatting" on names.

The draft carefully forgets to mention that many people objected to
.gnu, .zkey and .i2p on the basis of insufficient deployment. People
outside of the IETF who brings things to the IETF receive an extremely
unfriendly welcome, with strong requirments to do one thing and its
complete opposite.

> String similarity ICANN has an entire process for evaluating the
> string similarity / confusability between applied for (and current)
> strings

Which is a complete failure (such as Eurid being refused a name under
the pretext that it collides with a name... which is not even
delegated.) Good thing it does not exist at
IETF. 
https://centr.org/system/files/agenda/attachment/ga55-seppia_idn_delegation-20160217.pdf
https://centr.org/system/files/agenda/attachment/ga51-seppia-similarity_perception_at_icann-20140313.pdf
http://domainincite.com/17538-bulgaria-and-greece-win-idn-cctlds-on-appeal

> However, it should be noted that, if the IETF were to formalize the
> concept of protocol/name switch in the Internet architecture,
> coordination would be require between ICANN and IETF on such names.
> Using the analogy described above of a catalog/registry of such
> switches, care must be taken to make sure we do not end up with 2
> process streams allowed to create entries without any
> synchronization.

This is probably one of the weakest arguments. The processes of ICANN
and IETF are slow, very slow. And a good part