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

[DNSOP] WG last calls on dnssd WG drafts of interest to dnsop

[Ralph Droms (rdroms)]

The dnssd WG is currently conducting two WG last calls of interest to dnsop WG 
participants:

draft-ietf-dnssd-mdns-dns-interop-02
draft-ietf-dnssd-hybrid-03

Both of these last calls are scheduled to conclude on March 31.  The dnssd WG 
chairs would greatly appreciate review and feedback on these documents, posted 
to dn...@ietf.org  Results of the WG last calls will be reviewed at the dnssd 
WG meeting in Buenos Aires.

- Ralph and Tim




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,

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] The right alt string (was Re: draft-adpkja-dnsop-special-names-problem-01)

[Andrew Sullivan]

On Mon, Mar 28, 2016 at 06:31:57PM -, John Levine wrote:

> The URI definition in RFC 3986 says the host is a
> "reg-name" which refers to section 2.1 of RFC 1123 which says a
> hostname is letters, digits, and hyphens

Duh.  Now that you mention this, I realise that I actually had this
idea once before and chased that set of references and drew the same
conclusion.  So much for relying on my memory, but thank you for
hitting me again with the clue-by-four.  Maybe 3d time will be a
charm.

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

[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] The right alt string (was Re: draft-adpkja-dnsop-special-names-problem-01)

[John Levine]

>_alt or even _ would be better labels for this purpose.  Part of the
>goal has been to make these strings usable in applications (in "domain
>name slots", as 5890 calls them).  Would "_" work?  Would "_alt"?  I
>have doubts, but I thought I'd ask.

I don't think so.  The URI definition in RFC 3986 says the host is a
"reg-name" which refers to section 2.1 of RFC 1123 which says a
hostname is letters, digits, and hyphens.  So underscores won't work
in names in web browsers which are, as far as I can tell, the main
place people are likely to use these names-that-are-not-names.

Nice thought, though.

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]

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

[DNSOP] The right alt string (was Re: draft-adpkja-dnsop-special-names-problem-01)

[Andrew Sullivan]

On Mon, Mar 28, 2016 at 01:32:29PM -0400, 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.
> 

One of the possibly amusing things that struck me lately is that
marking out the string even more clearly for this purpose might take
some of the venom from the sting.  In that context, let me ask whether
_alt or even _ would be better labels for this purpose.  Part of the
goal has been to make these strings usable in applications (in "domain
name slots", as 5890 calls them).  Would "_" work?  Would "_alt"?  I
have doubts, but I thought I'd ask.

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

[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

[DNSOP] Document Action: 'Client Subnet in DNS Queries' to Informational RFC (draft-ietf-dnsop-edns-client-subnet-07.txt)

[The IESG]

The IESG has approved the following document:
- 'Client Subnet in DNS Queries'
  (draft-ietf-dnsop-edns-client-subnet-07.txt) as Informational RFC

This document is the product of the Domain Name System Operations Working
Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-edns-client-subnet/





Technical Summary

 This draft defines an EDNS0 extension to carry information about the
 network that originated a DNS query, and the network for which the
 subsequent response can be cached.

Working Group Summary

This draft originally showed up in dnsext working group and was highly 
criticized and eventually dropped.   Since then, dnsext closed down, the 
ability to get EDNS option codes because a simple expert review process and not 
Internet Standard, and the scope of this document was changed to document what 
*currently* exists in the world, and how it behaves. 

The extensive security writeup, several notes about privacy, and a number of 
implementation and operational notes included in the text were key in getting 
consensus support to publish the document.

Document Quality

There are security issues with this version, as raised by various people.  They 
are correct, and the intent is not to correct the security flaws with this 
document, but to describe how this option behaves currently.  It is suggested a 
new version will be worked on in a year which addresses the security issues, 
and addresses other issues about this option.

Personnel

Document Shepherd:   Suzanne Woolf
Area Director:   Joel Jaggeli

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