Re: [DNSOP] moving forward on special use names

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 09/20/2016 08:57 AM, Suzanne Woolf wrote:
>
> In a real sense the question at hand is a very practical one:
> “Which of these documents do you think needs less work?"
> 

Having read both drafts, and from the perspective of "Names resolved *
with an agreed non-DNS protocol", I agree with Avri that they can be
complementary, and find draft-tldr-sutld-ps-04 to "need less work".

This despite my other message which situates the problem space out of
these two drafts.

Regards,

==
hk
-BEGIN PGP SIGNATURE-

iQJ8BAEBCgBmBQJX4xUEXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9gckP/AtTeoArzbW/yB9HbfLVE0BI
MEAZlaETW22K2axs+h9Xg0Yge0F0vmmUqRZMZ7rF0UegppZra0M5biF2RxAxFN7n
2iw/Jz0xmq+5TjCzc6SoBvOL8DUbFIbl2auD3F/E/zbvaHEZU240xq+PCv7018KB
aApWdLH+/dMb3xZwmXunOm4gzxwD3TyZcYTRRnTN+7Y+SGXRdoeoC0h8Qs4QSdle
VHofvLvNreCd2sUP41YjsI4Frz9SDtBHaBJds4R/0iUiPTUgOU5+qygRpfPKckVB
sp6kq0ZPOxRAC3h46+vCfOoCpJmkTtV7XdDv8plGHNK7XayVmQepdoCJt8IQYDdu
Fnt+MhND+h3rihkLzL/Hxpr9cNWybIdiP8szdvHW9Cvt6LD/uH5nLUq9fIDkurS4
ju/CKWsQnHMgrQM5tJfnwXFDERfMpP1rzNrfRQsJVtvF+MNjN3AmCNYFivgQcKyO
A5cfreYZ9J/hCaaL+E9wX25GIQY0TKxOwOTuaGgH4+ck1hqbF8+EHjrbQ942J4+2
3ip/aDj6FOhtpEA68FNJGiG+p1zkNp0S/CBHDWMcEozM6qaAErVa64N9B0jqCeWs
y5819q47/2RfAa+PaAmQKT5bRLiIxNpjRKJ4jvA/dfLvHE0rn8exeks8gjAC+Rle
81muRwDKNixMboVxalQz
=s4YJ
-END PGP SIGNATURE-

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

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

I have a lot of sympathy for the worry about boiling the ocean, but
actually my fear is that if we do not enumerate all the problems and talk
about what we have to give up to solve this one or that one, we will never
reach consensus regardless of how small a teakettle we put on to boil,
because we will have left out people who have a strong stake in those
unaddressed problems, and they will not agree to the document, because
despite us not having addressed those problems, nevertheless the resulting
document will impact them.

On Tue, Sep 20, 2016 at 3:17 PM, Alain Durand 
wrote:

>
> On Sep 20, 2016, at 7:46 AM, Suzanne Woolf  wrote:
>
> The “toxic waste” names are a “use case” in the sense that people keep
> asking about. The identified need for a default namespace in the homenet
> protocols represents another use case.
>
>
>
> There are many use cases for reserving names under 6761 or an updated
> version of it. We saw that last year: people have an unlimited imagination
> on how to use such special names… good or bad, this is not the question.
>
> It could be tempting for the problem statement to list all of those use
> cases. Actually, if 6761 did not exist, that might even have been the right
> thing to do. But this is not where we are now.
>
> Where we are is that the iETF ran into a number of issues running both the
> process and the registry described in RFC6761. Draft-adpkja is attempting
> to list those issues, first by looking at process issues (section 3), then
> issues related to the operation of the registry (section 4), and, at last,
> looking at issues related to the strings under consideration themselves
> (section 4). The perspective taken by the authors is that these set of
> issues are real. Each of them need to, and can be, addressed. Hence a
> problem statement that focuses narrowly on something that can be fixed as
> opposed to boiling the ocean listing issues that, if the discussion from
> the last 18 months is any guidance, the working group may never reach
> consensus on.
>
> Alain, strictly speaking on my own behalf, not my employer’s.
>
>
>
> ___
> 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] moving forward on special use names

[Suzanne Woolf]

Indeed….Please keep in mind we’re not talking about a final document here. 
While it would be nice to have a document that was almost ready for WG 
consensus, there’s room to discuss the final scope in the WG.

The “toxic waste” names are a “use case” in the sense that people keep asking 
about. The identified need for a default namespace in the homenet protocols 
represents another use case.


Suzanne


> On Sep 20, 2016, at 7:29 AM, Ted Lemon  wrote:
> 
> What is out of scope of the problem statement is saying what to do about 
> them. :)
> 
> On Tue, Sep 20, 2016 at 5:32 AM, David Cake  > wrote:
> I tend to think that they may be within scope for the problem statement, but 
> it is likely that existing solutions (e.g. ICANN refusing to delegate them 
> while they remain toxic) are adequate to deal with the problem.
> 
> David
> 
> > On 19 Sep 2016, at 8:47 AM, John R Levine  > > wrote:
> >
> >> Dealing with toxic waste names is out of scope for the problem statement.
> >
> > Well, that's one theory.  Let's see of other people agree.
> >
> > R's,
> > John
> >
> > Regards,
> > John Levine, jo...@taugh.com , Taughannock 
> > Networks, Trumansburg NY
> > Please consider the environment before reading this e-mail. https://jl.ly 
> > 
> >
> > ___
> > 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] moving forward on special use names

[Ted Lemon]

What is out of scope of the problem statement is saying what to do about
them. :)

On Tue, Sep 20, 2016 at 5:32 AM, David Cake  wrote:

> I tend to think that they may be within scope for the problem statement,
> but it is likely that existing solutions (e.g. ICANN refusing to delegate
> them while they remain toxic) are adequate to deal with the problem.
>
> David
>
> > On 19 Sep 2016, at 8:47 AM, John R Levine  wrote:
> >
> >> Dealing with toxic waste names is out of scope for the problem
> statement.
> >
> > Well, that's one theory.  Let's see of other people agree.
> >
> > R's,
> > John
> >
> > Regards,
> > John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> > Please consider the environment before reading this e-mail.
> https://jl.ly
> >
> > ___
> > 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] moving forward on special use names

[Edward Lewis]

So as not to incur the wrath of Tim (again),

(He knows what I mean.)

On 9/12/16, 16:19, "DNSOP on behalf of Suzanne Woolf"  wrote:

>As we discussed in Berlin, we need to move forward with adopting a problem 
>statement draft for further work on special use domain names. 

>The drafts are:
>https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/
>https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/

I've read both, the -03 of the former and -06 of the latter.

Grading them strictly on providing a concise problem statement regarding issues 
with the Special Use Domain Name registry, "draft-adpkja-" stays more on topic 
than "draft-tldr".

I had been holding off on replying for a number of reasons.  There's been more 
than enough words spilled over this already and over a fairly long duration - 
without much milestone-hitting progress.

Still, as esoteric as this topic has become, I believe that having a Special 
Use Domain Name registry is important.  I don't want to see it wither away 
because no one wants to fix it.  It is important to have a means to document 
the uses of domain names that are not DNS compatible, specifically referring to 
the difference between the zone administrators of the DNS as described in STD 
13 documents and the administrative models implemented via distributed hash 
tables.

The IETF needs a stronger registry for these names.  The "draft-adpkja-" is 
more helpful in this regard as it focuses on the registry today and addresses 
specific shortcomings (even if I'd edit them some - but that's what a WG 
document is for).  "draft-tldr-" covers a far wider net, covering far ranging 
issues, winnowing them down to an actionable set would require more time.

For example, "draft-tldr" describes this: "enforce ... authority over any third 
party who wants to just start using a subset of the namespace".  For a while I 
was concerned about this use case too, but it is simply something that cannot 
be treated in documents.  In my notes on the document, I kept repeating - it's 
not about control or authority but about maximizing interoperability.  I say 
this as an example of places where "draft-tldr" is trying to describe a problem 
much more expansive than what "needs solvin'" (at this moment, at least).

Aside - I had other comments on "draft-tldr", including whether it was wise to 
introduce new terminology in a problems statement document.  In a solutions 
document, perhaps, but in a problems statement the new terms cause more 
confusion.  When I came to section 4.2 my note was "what was SUTLIN again?"  
This might fall in to the layer of nits but structurally, creating a new 
vocabulary seems to indicate a solution path is already in mind.



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

Re: [DNSOP] moving forward on special use names

[George Michaelson]

This is an instance of embedding. {th...@example.com}.{non-DNS-part}
is not subject to special delegation rules in some sense, because the
test of {non-DNS-part} requires no DNS action. If its synonymous with
_special_label_.{non-DNS-part}.{example.com} then its about a
conversation with upper systems to perform the transformation. If
{non-DNS-part} doesn't obey domain rules, and is not deterministically
structured, it can be {non-DNS-part}.some.sub.dom.ain eg .ALT and work
fine. It doesn't have to be a terminal on the RHS.

For .onion we were told this was non-negotiably not available. So now
we have the generic problem: upper name handling systems 'above' the
DNS don't want to be required to do work, to mangle apparent-names,
purported-named (whatever they are) according to any proscriptive
ruleset, to determine what to do: They want the DNS to do the work,
that drives them into a state to handle the exceptions.

Thats where my primary complaint in shut-it-down came in: This is an
unreasonable burden on the hierarchy of domain-names, as a thing in
itself.

"we" can't have it both ways. We can't have clean domain-name models
and coerce the domain-name model to cope with non-domain-name
concepts. And "we" can't keep it simple up in applications/URI space,
if we have to do special-case handling up there.

Shame we did think 6761 fixed this: it doesn't.

On Mon, Sep 19, 2016 at 11:57 AM, Ted Lemon  wrote:
> Okay, this is an interesting application that would certainly require some
> sort of 6761-style action.   Do you believe that it is not covered by the
> current problem statement?
>
> On Sun, Sep 18, 2016 at 9:00 PM, Phill  wrote:
>>
>> There is actually a fifth type of name, escaped names. Right now, the only
>> names we have of this type are SRV protocol tags, (_http._tcp.example.com)
>> and internationalized names (xn—wev.com)
>>
>> I want to add a third set of escaped names, one that has similar
>> functionality to .onion but does not leak as much information.
>>
>> example.com.m
>> f--
>> b2gk
>> 6
>> -
>> duf5
>> y
>> -
>> gyyl
>> -
>> jn5e
>> d
>>
>>
>> This is a strong domain name and to interpret it we require a policy that
>> is validated under the UDF fingerprint b2gk
>> 6
>> -
>> duf5
>> y
>> -
>> gyyl
>> -
>> jn5e
>> d. This in turn is a base 32 encoding of 92 bits of digest value plus an 8
>> bit version string. The fingerprint is over a content type identifier plus
>> some content as specified here.
>>
>> https://tools.ietf.org/html/draft-hallambaker-udf-03
>>
>> The content is typically going to be some sort of cryptographic key (PGP,
>> PKIX, SSH, JOSE, whatever) that signs some sort of assertion that states how
>> the address ‘example.com’ is to be interpreted.
>>
>> The trick here is that we can now bind security policy direct to any DNS
>> name without having to muck about with DNSSEC, or for that matter any other
>> PKI standard other than the particular standard we want.
>>
>>
>> Lets say that Alice is using OpenPGP and her OpenPGPv5 key is
>> mw83i-32ri4-83klq-3odp3. We can form an address from that:
>>
>> al...@example.com.mf--mw83i-32ri4-83klq-3odp3
>>
>> Now that isn’t an address that we can interpret without access to Alice’s
>> public key. Which is actually what I kinda want because I am fed up of spam.
>> The fact that I give you my address does not mean I want just anyone being
>> able to use it.
>>
>> In the ordinary course of business, my ‘strong name aware’ mailer knows
>> that it has to resolve mf--mw83i-32ri4-83klq-3odp3 somehow before it can use
>> that email address. If I just type it into Outlook, the client will happily
>> pass it on to my mail server and then it will get ‘stuck’ unless the mail
>> system can figure out how to use that address. Which is exactly what you
>> would want to happen with confidential mail.
>>
>> If the address can be resolved, the result is normally going to be a
>> policy that says what protocols the address can be used with and how.
>>
>> Now, naturally, a split horizon DNS would be one natural place to provide
>> access to a resolution service, but it need not be the only one.
>>
>>
>> The use of strong DNS names represents a major step forward in achieving a
>> genuinely decentralized Web. Instead of there being an institution at the
>> trust apex of the Internet, there is a digest function and a PKI scheme.
>>
>>
>> On Sep 16, 2016, at 2:13 PM, John Levine  wrote:
>>
>> The drafts are:
>> https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/
>> https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/
>>
>>
>> Having read them both, neither one thrills me but I'd give the nod to
>> adpkja.  The "Internet Names" in tldr seems to me a bad idea, since
>> there are a lot of other names on the Internet such as URIs and handle
>> system names, and this is about domain names.
>>
>> It seems to me there are four kinds of names we have to worry about, and
>> neither draft 

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

Okay, this is an interesting application that would certainly require some
sort of 6761-style action.   Do you believe that it is not covered by the
current problem statement?

On Sun, Sep 18, 2016 at 9:00 PM, Phill  wrote:

> There is actually a fifth type of name, escaped names. Right now, the only
> names we have of this type are SRV protocol tags, (_http._tcp.example.com)
> and internationalized names (xn—wev.com)
>
> I want to add a third set of escaped names, one that has similar
> functionality to .onion but does not leak as much information.
>
> example.com.m
> ​f--​
> b2gk
> ​
> 6
> ​-​
> duf5
> ​
> y
> ​-​
> gyyl
> ​​-
> jn5e
> ​d​
>
>
> This is a strong domain name and to interpret it we require a policy that
> is validated under the UDF fingerprint b2gk
> ​
> 6
> ​-​
> duf5
> ​
> y
> ​-​
> gyyl
> ​​-
> jn5e
> ​d​. This in turn is a base 32 encoding of 92 bits of digest value plus an
> 8 bit version string. The fingerprint is over a content type identifier
> plus some content as specified here.
>
> https://tools.ietf.org/html/draft-hallambaker-udf-03
>
> The content is typically going to be some sort of cryptographic key (PGP,
> PKIX, SSH, JOSE, whatever) that signs some sort of assertion that states
> how the address ‘example.com’ is to be interpreted.
>
> The trick here is that we can now bind security policy direct to any DNS
> name without having to muck about with DNSSEC, or for that matter any other
> PKI standard other than the particular standard we want.
>
>
> Lets say that Alice is using OpenPGP and her OpenPGPv5 key is
> mw83i-32ri4-83klq-3odp3. We can form an address from that:
>
> al...@example.com.mf--mw83i-32ri4-83klq-3odp3
>
> Now that isn’t an address that we can interpret without access to Alice’s
> public key. Which is actually what I kinda want because I am fed up of
> spam. The fact that I give you my address does not mean I want just anyone
> being able to use it.
>
> In the ordinary course of business, my ‘strong name aware’ mailer knows
> that it has to resolve mf--mw83i-32ri4-83klq-3odp3 somehow before it can
> use that email address. If I just type it into Outlook, the client will
> happily pass it on to my mail server and then it will get ‘stuck’ unless
> the mail system can figure out how to use that address. Which is exactly
> what you would want to happen with confidential mail.
>
> If the address can be resolved, the result is normally going to be a
> policy that says what protocols the address can be used with and how.
>
> Now, naturally, a split horizon DNS would be one natural place to provide
> access to a resolution service, but it need not be the only one.
>
>
> The use of strong DNS names represents a major step forward in achieving a
> genuinely decentralized Web. Instead of there being an institution at the
> trust apex of the Internet, there is a digest function and a PKI scheme.
>
>
> On Sep 16, 2016, at 2:13 PM, John Levine  wrote:
>
> The drafts are:
> https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/
> https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/
>
>
> Having read them both, neither one thrills me but I'd give the nod to
> adpkja.  The "Internet Names" in tldr seems to me a bad idea, since
> there are a lot of other names on the Internet such as URIs and handle
> system names, and this is about domain names.
>
> It seems to me there are four kinds of names we have to worry about, and
> neither draft calls them all out clearly:
>
> * Names resolved globally with the DNS protocol, i.e.
>  ordinary DNS names
>
> * Names resolved globally with an agreed non-DNS protocol, e.g.
>  .onion via ToR
>
> * Names resolved locally with an agreed non-DNS protocol, e.g,
>  .local via mDNS
>
> * Names resolved locally with unknown protocols, e.g. .corp and
>  .home, the toxic waste names
>
> 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
>
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[Phillip Hallam-Baker]

There is actually a fifth type of name, escaped names. Right now, the only
names we have of this type are SRV protocol tags, (_http._tcp.example.com)
and internationalized names (xn—wev.com)

I want to add a third set of escaped names, one that has similar
functionality to .onion but does not leak as much information.

example.com.m
​f--​
b2gk
​
6
​-​
duf5
​
y
​-​
gyyl
​​-
jn5e
​d​


This is a strong domain name and to interpret it we require a policy that
is validated under the UDF fingerprint b2gk
​
6
​-​
duf5
​
y
​-​
gyyl
​​-
jn5e
​d​. This in turn is a base 32 encoding of 92 bits of digest value plus an
8 bit version string. The fingerprint is over a content type identifier
plus some content as specified here.

https://tools.ietf.org/html/draft-hallambaker-udf-03

The content is typically going to be some sort of cryptographic key (PGP,
PKIX, SSH, JOSE, whatever) that signs some sort of assertion that states
how the address ‘example.com’ is to be interpreted.

The trick here is that we can now bind security policy direct to any DNS
name without having to muck about with DNSSEC, or for that matter any other
PKI standard other than the particular standard we want.


Lets say that Alice is using OpenPGP and her OpenPGPv5 key is
mw83i-32ri4-83klq-3odp3. We can form an address from that:

al...@example.com.mf--mw83i-32ri4-83klq-3odp3

Now that isn’t an address that we can interpret without access to Alice’s
public key. Which is actually what I kinda want because I am fed up of
spam. The fact that I give you my address does not mean I want just anyone
being able to use it.

In the ordinary course of business, my ‘strong name aware’ mailer knows
that it has to resolve mf--mw83i-32ri4-83klq-3odp3 somehow before it can
use that email address. If I just type it into Outlook, the client will
happily pass it on to my mail server and then it will get ‘stuck’ unless
the mail system can figure out how to use that address. Which is exactly
what you would want to happen with confidential mail.

If the address can be resolved, the result is normally going to be a policy
that says what protocols the address can be used with and how.

Now, naturally, a split horizon DNS would be one natural place to provide
access to a resolution service, but it need not be the only one.


The use of strong DNS names represents a major step forward in achieving a
genuinely decentralized Web. Instead of there being an institution at the
trust apex of the Internet, there is a digest function and a PKI scheme.




On Sep 16, 2016, at 2:13 PM, John Levine  wrote:

The drafts are:
https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/
https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/


Having read them both, neither one thrills me but I'd give the nod to
adpkja.  The "Internet Names" in tldr seems to me a bad idea, since
there are a lot of other names on the Internet such as URIs and handle
system names, and this is about domain names.

It seems to me there are four kinds of names we have to worry about, and
neither draft calls them all out clearly:

* Names resolved globally with the DNS protocol, i.e.
 ordinary DNS names

* Names resolved globally with an agreed non-DNS protocol, e.g.
 .onion via ToR

* Names resolved locally with an agreed non-DNS protocol, e.g,
 .local via mDNS

* Names resolved locally with unknown protocols, e.g. .corp and
 .home, the toxic waste names

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] moving forward on special use names

[Phill]

There is actually a fifth type of name, escaped names. Right now, the only 
names we have of this type are SRV protocol tags, (_http._tcp.example.com) and 
internationalized names (xn—wev.com)

I want to add a third set of escaped names, one that has similar functionality 
to .onion but does not leak as much information.

example.com.m​f--​b2gk​6​-​duf5​y​-​gyyl​​-jn5e​d​

This is a strong domain name and to interpret it we require a policy that is 
validated under the UDF fingerprint b2gk​6​-​duf5​y​-​gyyl​​-jn5e​d​. This in 
turn is a base 32 encoding of 92 bits of digest value plus an 8 bit version 
string. The fingerprint is over a content type identifier plus some content as 
specified here.

https://tools.ietf.org/html/draft-hallambaker-udf-03 


The content is typically going to be some sort of cryptographic key (PGP, PKIX, 
SSH, JOSE, whatever) that signs some sort of assertion that states how the 
address ‘example.com’ is to be interpreted.

The trick here is that we can now bind security policy direct to any DNS name 
without having to muck about with DNSSEC, or for that matter any other PKI 
standard other than the particular standard we want.


Lets say that Alice is using OpenPGP and her OpenPGPv5 key is 
mw83i-32ri4-83klq-3odp3. We can form an address from that:

al...@example.com.mf--mw83i-32ri4-83klq-3odp3

Now that isn’t an address that we can interpret without access to Alice’s 
public key. Which is actually what I kinda want because I am fed up of spam. 
The fact that I give you my address does not mean I want just anyone being able 
to use it.

In the ordinary course of business, my ‘strong name aware’ mailer knows that it 
has to resolve mf--mw83i-32ri4-83klq-3odp3 somehow before it can use that email 
address. If I just type it into Outlook, the client will happily pass it on to 
my mail server and then it will get ‘stuck’ unless the mail system can figure 
out how to use that address. Which is exactly what you would want to happen 
with confidential mail.

If the address can be resolved, the result is normally going to be a policy 
that says what protocols the address can be used with and how.

Now, naturally, a split horizon DNS would be one natural place to provide 
access to a resolution service, but it need not be the only one.


The use of strong DNS names represents a major step forward in achieving a 
genuinely decentralized Web. Instead of there being an institution at the trust 
apex of the Internet, there is a digest function and a PKI scheme.


> On Sep 16, 2016, at 2:13 PM, John Levine  wrote:
> 
>> The drafts are:
>>  https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/
>>  
>> https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/
> 
> Having read them both, neither one thrills me but I'd give the nod to
> adpkja.  The "Internet Names" in tldr seems to me a bad idea, since
> there are a lot of other names on the Internet such as URIs and handle
> system names, and this is about domain names.
> 
> It seems to me there are four kinds of names we have to worry about, and
> neither draft calls them all out clearly:
> 
> * Names resolved globally with the DNS protocol, i.e.
>  ordinary DNS names
> 
> * Names resolved globally with an agreed non-DNS protocol, e.g.
>  .onion via ToR
> 
> * Names resolved locally with an agreed non-DNS protocol, e.g,
>  .local via mDNS
> 
> * Names resolved locally with unknown protocols, e.g. .corp and
>  .home, the toxic waste names
> 
> 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] moving forward on special use names

[John R Levine]

Dealing with toxic waste names is out of scope for the problem statement.


Well, that's one theory.  Let's see of other people agree.

R's,
John

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

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

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

Dealing with toxic waste names is out of scope for the problem statement.
The problem of toxic waste names is mentioned in the tldr problem statement
as a problem, which could potentially be dealt with if the working group
decides it's in scope.   That's why the document is written the way it is.
  Remember, the point of this document is not to supersede RFC 6761: it's
to describe the problem that we have been moved to solve as a result of the
challenges we have faced and the things we have learned while trying to
follow the process described in RFC 6761.

On Sun, Sep 18, 2016 at 7:43 PM, John Levine  wrote:

> >To John's point, short isn't actually good, because it's important to
> >document the context--
>
> No, really, short is essential.  I'm happy to add the context once we
> have a concise statement of what the problem is.
>
> > But we tried to keep the actual
> >problem statement short and pithy; if you really think it's too long,
> >perhaps you could suggest shorter wordings that still capture the actual
> >problems.
>
> Ah.  See previous message for some examples.  In neither of the
> documents can I tell whether dealing with the toxic waste names is
> supposed to be in or out of scope.
>
> R's,
> John
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[John Levine]

>To John's point, short isn't actually good, because it's important to
>document the context--

No, really, short is essential.  I'm happy to add the context once we
have a concise statement of what the problem is.

> But we tried to keep the actual
>problem statement short and pithy; if you really think it's too long,
>perhaps you could suggest shorter wordings that still capture the actual
>problems.

Ah.  See previous message for some examples.  In neither of the
documents can I tell whether dealing with the toxic waste names is
supposed to be in or out of scope.

R's,
John

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

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

Avri, thanks for the markups--I will take care of the ones that are
actionable, and respond in a separate message, because I want to address
the question of merging explicitly, along with John's comment about brevity.

Why not merge the two documents?  This sounds reasonable on the surface,
but please understand how we got here.   The chairs asked the design team
to write a document.   Certain members of the design team wrote a document,
the initial version of which was published prior to the Yokohama IETF.   A
second version was published prior to Buenos Aires, and I decided that I
should really read it and send comments.

I read the document, wrote about four pages of comments, realized that my
comments were going to be longer than the document, and decided to talk to
people in the community before continuing.  I went out and talked to
various people in the community in Buenos Aires, including someone from
ICANN, members of the IAB, working group participants, the author of RFC
6761, members of the adpkja design team, and various others, and concluded,
based on those conversations, that we needed a new document.   Based on
that, I wrote a document that _does not reflect my personal opinion_, and
then bounced it off Ralph, one of the adpkja design team members, to see if
I'd done okay.   He had some suggestions, which were incorporated.

So the document as it stands is an attempt, which I believe was successful,
to enumerate a comprehensive set of problems relating to the problem 6761
attempted to address, as expressed by the various people I consulted.
These people are mentioned by name in the acknowledgments section.   I
didn't consult everybody, but I think most of the people whom I didn't
consult agree with what's in adpkja, which I read thoroughly, so I believe
I captured their positions as well.  Importantly, the people I consulted do
not all agree on what the scope of the problem is; that's why it was so
important to collect all of their input.

Both sets of authors have already incorporated into their respective
documents what they think is good about the other document.   Either
document, effectively, contains what that set of authors thinks a merge
should look like.   So suggesting a merge at this point doesn't make sense.
  What we really need to know is which document the working group thinks is
a better starting place.   If there's something missing from that document
that the working group wants to add, they can do so after it is adopted.

To John's point, short isn't actually good, because it's important to
document the context--this is a fairly important discussion, and it doesn't
make sense to lose the history of it.   But we tried to keep the actual
problem statement short and pithy; if you really think it's too long,
perhaps you could suggest shorter wordings that still capture the actual
problems.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[John Levine]

>On 12-Sep-16 16:19, Suzanne Woolf wrote:
>> It seems unlikely that they can be combined, so we simply have to ask
>> the WG to choose.

The more I think about it, the more I think that they're both too
long, and we'd be better off with a one or two sentence description of
what we're trying to do, perhaps along these lines:

  * Describe how and when to recognize domain names that are handled
  in ways other than the DNS.  (That's mDNS and .onion)

or

  * Describe how and when to recognize domain names that should not
  be delegated in the DNS. (That's the toxic waste.)

or maybe something else, so long as it's short.


Also, FYI:

>> 4.2.4. Name Collision in the DNS ...

>This study is from before the new gTLD program.  The assumption in the
>report need to be tested against what actually happened in the round of
>new gTLDs before it can be included as part of the fact basis for this
>work.  We also need information on the degree of success that the
>various mitigation strategies had in overcoming possible problems to
>have a full picture of the problem as it has been shown in practice.

At a meeting a couple of weeks ago, I believe that someone said that
the junk traffic at the roots for each of .corp, .home and .mail still
greatly exceeds all of the traffic for the new gTLDs.  So I think it's
safe to say none of the mitigation strategies have worked.

The wildcard 127.0.53.53 and such are clever, but none of the domains
that have been delegated had significant collision issues to start
with so it's hard to argue they've been effective.

R's,
John

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

Re: [DNSOP] moving forward on special use names

[avri doria]

On 12-Sep-16 16:19, Suzanne Woolf wrote:
> It seems unlikely that they can be combined, so we simply have to ask
> the WG to choose.

I do not understand this point.  Having now read both IDs, I see
relevant points for the ongoing discussion in both of them.   I see them
as complementary where both contribute to defining the problem in a
comprehensive way.

I think it would make sense to ask the authors to combine their efforts,
that being a first step in finding consensus on how to proceed -
otherwise the back and forth continues once a winner is picked.  Perhaps
enlist the help of one of the neutral knowledgeable people in the group
to bring the two groups of authors together in a base draft that
discusses the issues in language both groups can live with with a strict
focus on problems and their explanation.  I may be misreading the 2 IDs,
but I do not think there should be that many sticking points once there
is a decision to work it out.

I think trying to pick a winner from these two documents, both useful
expositions of the issues, is not the best way to produce a problem
statement.


Some individual comments on the drafts.

---

Some specific comments on TLDR Special-Use Names Problem

> Although IETF and ICANN nominally have authority over this
> namespace, neither organization can enforce that authority over
> any third party who wants to just start using a subset of the
> namespace. Reasons for doing this may include:

I would recommend also including something like "ignorance of there
being procedures, or lack of knowledge that the IETF & ICANN have
processes"as one of the bullets.

> this process is
> likely to be slow and difficult, with an uncertain outcome.
>
I am not sure how this differentiates from other IETF processes.  They
all take longer than one would expect and always have an uncertain
outcome.   This makes it seem like this problem is somehow special in
that respect.

> There is demand for more than one name resolution protocol for
> Internet Names, but Internet Names contain no metadata to indicate
> which protocol to use to resolve them.

probably worth indicating that one DNS mechanism that exists is broken
and that others are offering non standard methods of adding metadata or
treating existing data as metadata.

> More than one name resolution protocol is bad, in the sense
> that a single protocol is less complicated to implement and
> deploy.

This would seem contingent on there being no way to differentiate
applicability


> However, the MoU specifically exempts domain names
> assigned for technical use, and uses the example of ’IN-ADDR.ARPA’
> and ’IP6.ARPA’ to illustrate.

I think the issue here is the breadth of the definition for 'technical
use'. Most any names issue can be defined in such a way so as to have a
technical use. 

> 4.2.1. Multicast DNS

This section seems to be arguing a case as much as explaining an issue.

> 4.2.2. The .onion Special-Use TLD

Need to also look at the precedent this has set and whether the IETF
wishes to reinforce this as a precedent.

> 4.2.4. Name Collision in the DNS
> Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by
> ICANN that attempts to characterize the potential risk to the
> Internet of adding global DNS delegations for names that were not
> previously delegated in the DNS, not reserved under any RFC, but also
> known to be (.local) or surmised to be (.corp) in significant use for
> special-use-type reasons (local scope DNS, or other resolution
> protocols altogether).

This study is from before the new gTLD program.  The assumption in the
report need to be tested against what actually happened in the round of
new gTLDs before it can be included as part of the fact basis for this
work.  We also need information on the degree of success that the
various mitigation strategies had in overcoming possible problems to
have a full picture of the problem as it has been shown in practice.



re Problem Statement for the Reservation of Special-Use Domain Names
using RFC6761

> The applicants for [RFC6761] status cannot be guaranteed that
> leakage will not occur and will need to take this into account
> in their protocol design.

This seems an example of a statement that includes both a problem and a
possible solution.

Additionally I think that putting the names pictures in the broader
context is important, even though dnsop WG will be restricted to
solutions based on DNS. Seems important to understand the larger system
DNS is part of these days and moving into the future.

avri


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

On Sat, Sep 17, 2016 at 8:30 PM, Alain Durand 
wrote:
>
> The working group now need to decide if they’d rather like a limited and
> concise description of issues surrounding 6761 or if they rather like a
> discussion of the larger issues surrounding special names in general.
>

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

Re: [DNSOP] moving forward on special use names

[Alain Durand]

> On Sep 17, 2016, at 4:08 PM, Ted Lemon  wrote:
> 
> Alain, here's an example, from the abstract:
> 
>When an end-user triggers resolution of a name on a system that
>supports multiple, different protocols or resolution mechanisms, it
>is desirable that the protocol used is unambiguous, and that requests
>intended for one protocol are not inadvertently answered using
>another protocol.
> 
> This is a solution described in terms of a problem, not a problem statement.

Seriously? I don’t see any solution being described here. Plus, this is an 
abstract, not the meat of the document.



> This problem pervades the document.   You haven't stepped back and wiped the 
> slate clean and tried to explain the problem that we have--you've just 
> described the problem with 6761.   You've retrofitted some of what's 
> described in the tldr document, so that the document as it is now is in a 
> sense more comprehensive, but it's still structured on the basis of the set 
> of assumptions you started with, so that it tends to drive in a particular 
> direction, rather than trying to neutrally describe the problems.
> 
> If you look at the tldr document, you will see that the set of problems that 
> are stated there imply _contradictory_ solutions.   This is because that's 
> the problem we face: there is no easy solution to this problem, and we need 
> to consider the tradeoffs.   If I were to read your document without 
> considering the larger problem space, the solution it implies would be very 
> clear.   That's not the case for the tldr document.   There is no one clear 
> solution implied by the tldr document.   That was a deliberate choice.   We, 
> as a working group, need to think about the tradeoffs, and not just go in a 
> particular direction.

On October 8th, 2016, the chairs asked the design team to work on a 6761 
problem statement, Here is the text from Susanne:

""Efforts by the IETF to administer the Special Use Names registry under the 
provisions of RFC 6761 have proven to be controversial, consume large amounts 
of time and attention, and lead to outcomes that are confusing, unsatisfying, 
or both to operators and implementers. As a first stage towards implementing 
the guidance of the IESG on this subject 
(http://www.ietf.org/blog/2015/09/onion/ 
, and IESG comments during the 
discussion of the draft at 
http://datatracker.ietf.org/doc/draft-ietf-dnsop-onion-tld/ballot/ 
), the DT 
is asked to produce a brief internet-draft for Yokohama, outlining the issues. 
It's expected to be structured as a problem statement to the extent practical, 
as we've come to the preliminary conclusion that one of the challenges in 
applying RFC 6761 is that it's unclear on what problem it's intended to solve 
and what criteria to consider.”

It is pretty clear to me that the problem statement was to be limited to 
RFC6761, which we executed on.
You are perfectly free to believe we were wrong in our understanding of the 
chair’s directions, or that, the chairs were wrong in their direction.

The working group now need to decide if they’d rather like a limited and 
concise description of issues surrounding 6761 or if they rather like a 
discussion of the larger issues surrounding special names in general.

Now, I will pause and give space to other working group participants to express 
their opinion.

Alain.




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

Re: [DNSOP] moving forward on special use names

[Ralph Droms]

> On Sep 17, 2016, at 11:37 AM, Ted Lemon  wrote:
> 
> I would just like to point out that what we are talking about doing is 
> documenting the problem that we think needs to be addressed.   One of the 
> reasons we published a new document about this is that it seemed that the 
> original effort had gone way too far down the path toward solutions, without 
> there being a clear agreement on what problems exist, and what problems we as 
> a working group can get consensus to try to address.
> 
> This discussion is again going down the solution space path.   I understand 
> the motivation, and I don't disagree with it, but I really would like to get 
> a problem statement before we start talking about solutions.

Emphatically +1.

- Ralph

> 
>> On Sat, Sep 17, 2016 at 10:18 AM, Alain Durand  
>> wrote:
>> What would really help here would be standardize a way to measure toxicity. 
>> We could then track a specific string toxicity over time, and maybe then 
>> define a threshold where it is OK or not OK to delegate that particular 
>> string.
>> 
>> I would personally agree with your assessment that maintaining this list in 
>> 6761 is problematic, for the reason mentioned in section 3.f of darft-adpkja:
>> 
>> "f.  [RFC6761] does not have provision for subsequent management of
>>the registry, such as updates, deletions of entries, etc…”
>> 
>> 
>> Alain.
>> 
>> 
>>> On Sep 16, 2016, at 8:10 PM, John Levine  wrote:
>>> 
>>> This is the toxic waste bit.  The names don't make sense in the 6761
>>> special use registry, since they're not being used in any way that is
>>> or can be standardized, but they also aren't suitable for delegation
>>> due to widespread de facto use.  I also expect that if we redid last
>>> year's debate in anything like the same way, we'd have the same
>>> result, one or two highly motivated people who work for TLD applicants
>>> would sabotage it.
>>> 
>>> As I hardly need tell you, it is utterly unclear whether it makes more
>>> sense to have the IETF reserve them or, to switch hats and encourage
>>> ICANN to put them on a list of names that aren't in use but can't be
>>> delegated as SAC045 suggests.
>>> 
>>> One reason that the latter makes slightly more sense is that it's
>>> likely that some of those names will eventually become less polluted,
>>> so the list needs to be reconsidered every once in a while (years.)
>>> For example, I gather that it's been a decade since Belkin stopped
>>> making routers that leak .belkin traffic, and at some point most of
>>> them will be gone.
>> 
>> 
>> ___
>> 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] moving forward on special use names

[Alain Durand]

> On Sep 17, 2016, at 11:38 AM, Ted Lemon  wrote:
> 
> One of the reasons we published a new document about this is that it seemed 
> that the original effort had gone way too far down the path toward solutions, 
> without there being a clear agreement on what problems exist, and what 
> problems we as a working group can get consensus to try to address.

Ted,

You have repeated that claim many times. I have asked you last meeting, and 
will ask you again, to point out exactly where do you think the current adpkja 
document goes into solution space.

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

Re: [DNSOP] moving forward on special use names

[John R Levine]

I would just like to point out ...


I would like to wait and see what other people think about it.

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

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

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

I would just like to point out that what we are talking about doing is
documenting the problem that we think needs to be addressed.   One of the
reasons we published a new document about this is that it seemed that the
original effort had gone way too far down the path toward solutions,
without there being a clear agreement on what problems exist, and what
problems we as a working group can get consensus to try to address.

This discussion is again going down the solution space path.   I understand
the motivation, and I don't disagree with it, but I really would like to
get a problem statement before we start talking about solutions.

On Sat, Sep 17, 2016 at 10:18 AM, Alain Durand 
wrote:

> What would really help here would be standardize a way to measure
> toxicity. We could then track a specific string toxicity over time, and
> maybe then define a threshold where it is OK or not OK to delegate that
> particular string.
>
> I would personally agree with your assessment that maintaining this list
> in 6761 is problematic, for the reason mentioned in section 3.f of
> darft-adpkja:
>
> "f.  [RFC6761] does not have provision for subsequent management of
>the registry, such as updates, deletions of entries, etc…”
>
>
> Alain.
>
>
> On Sep 16, 2016, at 8:10 PM, John Levine  wrote:
>
> This is the toxic waste bit.  The names don't make sense in the 6761
> special use registry, since they're not being used in any way that is
> or can be standardized, but they also aren't suitable for delegation
> due to widespread de facto use.  I also expect that if we redid last
> year's debate in anything like the same way, we'd have the same
> result, one or two highly motivated people who work for TLD applicants
> would sabotage it.
>
> As I hardly need tell you, it is utterly unclear whether it makes more
> sense to have the IETF reserve them or, to switch hats and encourage
> ICANN to put them on a list of names that aren't in use but can't be
> delegated as SAC045 suggests.
>
> One reason that the latter makes slightly more sense is that it's
> likely that some of those names will eventually become less polluted,
> so the list needs to be reconsidered every once in a while (years.)
> For example, I gather that it's been a decade since Belkin stopped
> making routers that leak .belkin traffic, and at some point most of
> them will be gone.
>
>
>
> ___
> 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] moving forward on special use names

[Alain Durand]

What would really help here would be standardize a way to measure toxicity. We 
could then track a specific string toxicity over time, and maybe then define a 
threshold where it is OK or not OK to delegate that particular string.

I would personally agree with your assessment that maintaining this list in 
6761 is problematic, for the reason mentioned in section 3.f of darft-adpkja:

"f.  [RFC6761] does not have provision for subsequent management of
   the registry, such as updates, deletions of entries, etc…”


Alain.


> On Sep 16, 2016, at 8:10 PM, John Levine  wrote:
> 
> This is the toxic waste bit.  The names don't make sense in the 6761
> special use registry, since they're not being used in any way that is
> or can be standardized, but they also aren't suitable for delegation
> due to widespread de facto use.  I also expect that if we redid last
> year's debate in anything like the same way, we'd have the same
> result, one or two highly motivated people who work for TLD applicants
> would sabotage it.
> 
> As I hardly need tell you, it is utterly unclear whether it makes more
> sense to have the IETF reserve them or, to switch hats and encourage
> ICANN to put them on a list of names that aren't in use but can't be
> delegated as SAC045 suggests.
> 
> One reason that the latter makes slightly more sense is that it's
> likely that some of those names will eventually become less polluted,
> so the list needs to be reconsidered every once in a while (years.)
> For example, I gather that it's been a decade since Belkin stopped
> making routers that leak .belkin traffic, and at some point most of
> them will be gone.



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

Re: [DNSOP] moving forward on special use names

[John Levine]

>Speaking of history, DNSOP spent a huge amount of time talking about those
>specific strings a year or two ago (and decided to not adopt Lyman's doc).
>We can mention the issue in more depth (John, do you have any suggested
>text (especially if we can avoid mentioning the specific strings again)?),
>but we don't want to get into relitigating the whole topic here.

This is the toxic waste bit.  The names don't make sense in the 6761
special use registry, since they're not being used in any way that is
or can be standardized, but they also aren't suitable for delegation
due to widespread de facto use.  I also expect that if we redid last
year's debate in anything like the same way, we'd have the same
result, one or two highly motivated people who work for TLD applicants
would sabotage it.

As I hardly need tell you, it is utterly unclear whether it makes more
sense to have the IETF reserve them or, to switch hats and encourage
ICANN to put them on a list of names that aren't in use but can't be
delegated as SAC045 suggests.

One reason that the latter makes slightly more sense is that it's
likely that some of those names will eventually become less polluted,
so the list needs to be reconsidered every once in a while (years.)
For example, I gather that it's been a decade since Belkin stopped
making routers that leak .belkin traffic, and at some point most of
them will be gone.

R's,
John

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

Re: [DNSOP] moving forward on special use names

[Warren Kumari]

On Friday, September 16, 2016, Ted Lemon  wrote:

> Hm, possibly what you mean is that it's not mentioned explicitly enough.
> I think the document covers the problem in quite a bit of detail, but the
> private domains stuff is mostly in the history section; I could understand
> if you felt that this provided insufficient clarity.
>

Speaking of history, DNSOP spent a huge amount of time talking about those
specific strings a year or two ago (and decided to not adopt Lyman's doc).
We can mention the issue in more depth (John, do you have any suggested
text (especially if we can avoid mentioning the specific strings again)?),
but we don't want to get into relitigating the whole topic here.

W



>
> On Fri, Sep 16, 2016 at 6:10 PM, John R Levine  > wrote:
>
>> Section 4.1.2 of the tldr document actually says almost exactly what you
>>> said in your four-pronged strategy, but without the pejorative bit.
>>>
>>
>> I just looked at it again, and don't see anything about the toxic waste
>> names.  Since they're the ones that are hard, I really think we need to
>> call them out.  Feel free to come up with a different metaphor if you don't
>> like the one about a part of the DNS space that's too polluted to use.
>>
>> R's,
>> John
>>
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[John R Levine]

Perhaps this would be a good time to stop and see if anyone else is paying 
attention.


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

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

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

Hm, possibly what you mean is that it's not mentioned explicitly enough.
I think the document covers the problem in quite a bit of detail, but the
private domains stuff is mostly in the history section; I could understand
if you felt that this provided insufficient clarity.

On Fri, Sep 16, 2016 at 6:10 PM, John R Levine  wrote:

> Section 4.1.2 of the tldr document actually says almost exactly what you
>> said in your four-pronged strategy, but without the pejorative bit.
>>
>
> I just looked at it again, and don't see anything about the toxic waste
> names.  Since they're the ones that are hard, I really think we need to
> call them out.  Feel free to come up with a different metaphor if you don't
> like the one about a part of the DNS space that's too polluted to use.
>
> R's,
> John
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

   o  When a top-level name is used as a means either of marking the
  rest of a Domain Name for resolution using a protocol other than
  DNS, or is used for resolution of names with no global meaning,
  not all software that processes such names will understand the
  names' special meanings.  Consequently, any such use results in
  queries for those names being sent to authoritative servers.


On Fri, Sep 16, 2016 at 6:10 PM, John R Levine  wrote:

> Section 4.1.2 of the tldr document actually says almost exactly what you
>> said in your four-pronged strategy, but without the pejorative bit.
>>
>
> I just looked at it again, and don't see anything about the toxic waste
> names.  Since they're the ones that are hard, I really think we need to
> call them out.  Feel free to come up with a different metaphor if you don't
> like the one about a part of the DNS space that's too polluted to use.
>
> R's,
> John
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[John R Levine]

Section 4.1.2 of the tldr document actually says almost exactly what you
said in your four-pronged strategy, but without the pejorative bit.


I just looked at it again, and don't see anything about the toxic waste 
names.  Since they're the ones that are hard, I really think we need to 
call them out.  Feel free to come up with a different metaphor if you 
don't like the one about a part of the DNS space that's too polluted to 
use.


R's,
John

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

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

Section 4.1.2 of the tldr document actually says almost exactly what you
said in your four-pronged strategy, but without the pejorative bit.
However, it only talks about this in the case of special-use names, not in
the case of names generally.   I certainly generally agree with the
taxonomy you're proposing, although I could do without the pejorative bit,
and I think it needs to mention RFC 6303-style names, which I think you
left out.   Whether this taxonomy belongs in the document is certainly a
valid question.   The taxonomy that is _in_ the document could fairly
easily be adapted to say what you said, and I would support doing that.

On Fri, Sep 16, 2016 at 5:58 PM, John R Levine  wrote:

> ... and I have just posted a new version with the term Domain Names -
>> I (and I think Ted) prefer Internet Names, but our preferences are not
>> important, we want to do whatever the WG wants.
>>
>
> Personally, I'm more concerned with getting the issues identified, and
> then we can decide what to call them.  Anyone else like my four pronged
> strategy?
>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail. https://jl.ly
>
> ___
> 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] moving forward on special use names

[John R Levine]

... and I have just posted a new version with the term Domain Names -
I (and I think Ted) prefer Internet Names, but our preferences are not
important, we want to do whatever the WG wants.


Personally, I'm more concerned with getting the issues identified, and 
then we can decide what to call them.  Anyone else like my four pronged 
strategy?


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

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

Re: [DNSOP] moving forward on special use names

[Warren Kumari]

On Fri, Sep 16, 2016 at 3:18 PM, Warren Kumari  wrote:
> On Fri, Sep 16, 2016 at 2:57 PM, Ted Lemon  wrote:
>> On Fri, Sep 16, 2016 at 2:13 PM, John Levine  wrote:
>>>
>>> Having read them both, neither one thrills me but I'd give the nod to
>>> adpkja.  The "Internet Names" in tldr seems to me a bad idea, since
>>> there are a lot of other names on the Internet such as URIs and handle
>>> system names, and this is about domain names.
>>
>>
>> BTW, if this is your only reason for preferring one document to the other,
>> it's pretty thin.   Maybe "Internet Names" is the wrong term to use.   It's
>> one that we came up with pretty much on the spur of the moment
>
> Actually, IIRC it originally came from a suggestion made in the ARCING
> BoF, where it enjoyed quite strong support.
> But, we are (of course) happy to change it to whatever the WG wants.
> When reading these documents and choosing your preferred one, please
> keep in mind that whatever you select is a *starting point* -- the
> authors of whichever document will incorporate whatever changes the WG
> asks for.

... and I have just posted a new version with the term Domain Names -
I (and I think Ted) prefer Internet Names, but our preferences are not
important, we want to do whatever the WG wants.
If y'all want us to change back, 'tis trivial (this is in git)

W


>
>>  in Buenos
>> Aires, because we didn't want to use "Domain Names," because "Domain Names"
>> is too easily confused with "Domain Name System Protocol."   Personally, I
>> like Domain Names, but I agree that the term begs for confusion.
>>
>> Point being, whichever document you like, we ought to figure out what term
>> to use.   If it's "Domain Name," I'm fine with that.  I  used "Internet
>> Name" because that seemed to be the consensus in the room, not because I'm
>> wedded to it.
>
> Yup, we will do whatever the WG asks of us.
> W
>
>>
>> ___
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
>>
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>---maf



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

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

Re: [DNSOP] moving forward on special use names

[Warren Kumari]

On Fri, Sep 16, 2016 at 2:57 PM, Ted Lemon  wrote:
> On Fri, Sep 16, 2016 at 2:13 PM, John Levine  wrote:
>>
>> Having read them both, neither one thrills me but I'd give the nod to
>> adpkja.  The "Internet Names" in tldr seems to me a bad idea, since
>> there are a lot of other names on the Internet such as URIs and handle
>> system names, and this is about domain names.
>
>
> BTW, if this is your only reason for preferring one document to the other,
> it's pretty thin.   Maybe "Internet Names" is the wrong term to use.   It's
> one that we came up with pretty much on the spur of the moment

Actually, IIRC it originally came from a suggestion made in the ARCING
BoF, where it enjoyed quite strong support.
But, we are (of course) happy to change it to whatever the WG wants.
When reading these documents and choosing your preferred one, please
keep in mind that whatever you select is a *starting point* -- the
authors of whichever document will incorporate whatever changes the WG
asks for.

>  in Buenos
> Aires, because we didn't want to use "Domain Names," because "Domain Names"
> is too easily confused with "Domain Name System Protocol."   Personally, I
> like Domain Names, but I agree that the term begs for confusion.
>
> Point being, whichever document you like, we ought to figure out what term
> to use.   If it's "Domain Name," I'm fine with that.  I  used "Internet
> Name" because that seemed to be the consensus in the room, not because I'm
> wedded to it.

Yup, we will do whatever the WG asks of us.
W

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



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

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

Re: [DNSOP] moving forward on special use names

[John R Levine]

Split horizon is another thing.   I'm talking about locally resolved zones
(RFC 6303).


I see that as a kind of split horizon.  One of the problems with the toxic 
waste is that we don't know how much of it is from names that are supposed 
to be resolved locally but escaped (much of .corp I would guess) and how 
much is just mistakes (.belkin.)


R's,
John



On Fri, Sep 16, 2016 at 2:46 PM, John Levine  wrote:


In article 

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

On Fri, Sep 16, 2016 at 2:13 PM, John Levine  wrote:

> Having read them both, neither one thrills me but I'd give the nod to
> adpkja.  The "Internet Names" in tldr seems to me a bad idea, since
> there are a lot of other names on the Internet such as URIs and handle
> system names, and this is about domain names.
>

BTW, if this is your only reason for preferring one document to the other,
it's pretty thin.   Maybe "Internet Names" is the wrong term to use.   It's
one that we came up with pretty much on the spur of the moment in Buenos
Aires, because we didn't want to use "Domain Names," because "Domain Names"
is too easily confused with "Domain Name System Protocol."   Personally, I
like Domain Names, but I agree that the term begs for confusion.

Point being, whichever document you like, we ought to figure out what term
to use.   If it's "Domain Name," I'm fine with that.  I  used "Internet
Name" because that seemed to be the consensus in the room, not because I'm
wedded to it.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

Split horizon is another thing.   I'm talking about locally resolved zones
(RFC 6303).

On Fri, Sep 16, 2016 at 2:46 PM, John Levine  wrote:

> In article 

Re: [DNSOP] moving forward on special use names

[John Levine]

In article 

Re: [DNSOP] moving forward on special use names

[Ted Lemon]

Don't forget names resolved locally with the DNS Protocol, like
1.1.168.192.in-addr.arpa.   A lot of the names you describe as "toxic
waste" are likely resolved this way.

On Fri, Sep 16, 2016 at 2:13 PM, John Levine  wrote:

> >The drafts are:
> >   https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/
> >   https://datatracker.ietf.org/doc/draft-adpkja-dnsop-
> special-names-problem/
>
> Having read them both, neither one thrills me but I'd give the nod to
> adpkja.  The "Internet Names" in tldr seems to me a bad idea, since
> there are a lot of other names on the Internet such as URIs and handle
> system names, and this is about domain names.
>
> It seems to me there are four kinds of names we have to worry about, and
> neither draft calls them all out clearly:
>
> * Names resolved globally with the DNS protocol, i.e.
>   ordinary DNS names
>
> * Names resolved globally with an agreed non-DNS protocol, e.g.
>   .onion via ToR
>
> * Names resolved locally with an agreed non-DNS protocol, e.g,
>   .local via mDNS
>
> * Names resolved locally with unknown protocols, e.g. .corp and
>   .home, the toxic waste names
>
> 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] moving forward on special use names

[John Levine]

>The drafts are:
>   https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/
>   
> https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/

Having read them both, neither one thrills me but I'd give the nod to
adpkja.  The "Internet Names" in tldr seems to me a bad idea, since
there are a lot of other names on the Internet such as URIs and handle
system names, and this is about domain names.

It seems to me there are four kinds of names we have to worry about, and
neither draft calls them all out clearly:

* Names resolved globally with the DNS protocol, i.e.
  ordinary DNS names

* Names resolved globally with an agreed non-DNS protocol, e.g.
  .onion via ToR

* Names resolved locally with an agreed non-DNS protocol, e.g,
  .local via mDNS

* Names resolved locally with unknown protocols, e.g. .corp and
  .home, the toxic waste names

R's,
John




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

Re: [DNSOP] moving forward on special use names

[Alain Durand]

> On Sep 12, 2016, at 6:43 PM, Warren Kumari  wrote:
> 
> Please, I know many are tired of this topic, but it really is important, so 
> please participate and send in your views.

+1
I also would like to strongly recommend people read the latest version of each 
documents. They both have evolved significantly over time.

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

Re: [DNSOP] moving forward on special use names

[Warren Kumari]

On Monday, September 12, 2016, Suzanne Woolf  wrote:

> Dear Colleagues,
>
>
> As we discussed in Berlin, we need to move forward with adopting a problem
> statement draft for further work on special use domain names.
>
> Issues of usage around the domain name space are part of our charter, and
> the IESG has expressed interest more than once in having a clear basis for
> dealing with future cases such as the request for .onion in the special use
> domain names registry or the needs of the HNCP protocol. The Chairs
> determined that the WG should have a problem statement before attempting to
> specify changes to RFC 6761 or other possible solutions.
>
> The problem statement needs to be a WG document, with a WG commitment to
> get to consensus on it.
>
> We have two internet-drafts that have been submitted for discussion as
> problem statements. They’re both individual submissions and the work of
> their named authors. They cover many common features of the landscape but
> they’re also written from slightly different viewpoints. It seems unlikely
> that they can be combined, so we simply have to ask the WG to choose.
>
> Both drafts have been revised in the last few days.
>
> The drafts are:
> https://datatracker.ietf.org/doc/draft-tldr-sutld-ps/
> https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/
>
> We’re opening a 2-week discussion period for the WG, to end on Sept. 26.
> At the end of that time we’ll adopt one of these drafts for further work by
> the WG.
>


Thank you - we are looking forward to any and all comments, and a healthy
debate...

Please, I know many are tired of this topic, but it really is important, so
please participate and send in your views.

W



>
>
> Shortly thereafter we will also be soliciting views on how the IETF might
> address the problems we’ve identified with special use domain names.
>
> Please read these drafts and tell us which you think the WG can adopt as a
> problem statement, from the IETF perspective, about the various issues
> we’ve discussed on special use names. We need your comments on the record—
> being able to demonstrate the WG’s decision process is important— so please
> write to the list.
>
> Assuming some level of agreement on a problem statement, we’re tentatively
> scheduling an interim WG meeting for next steps, in mid-October.
>

>
> thanks all,
> Tim & Suzanne
>
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop