Re: [DNSOP] back to: Some distinctions and a request

Hi,

I think that Andrew's effort to distinguish between a domain name and
a DNS name is useful.  It gives us some clear terminology to use to
discuss domain names that wish to use a non-DNS name resolution
method.

RFC6761 introduces a mechanism for the handling of these types of cases.  
In the recent cases of .onion, .gnu, .zkey etc. we have software using domain
names but wishing to use a non-DNS name resolution mechanism.

This is a "hand in glove" use of RFC6761.  For persons wishing not to
allow the use of RFC6761 for these names, it would seem that you have
two options:

1. Invalidate RFC6761 indicating it was a mistake.  This is not a disaster,
mistakes are made and sometimes need to be rectified.

2. Form a different community for the assessment of these issues, and 
decide not to participate in that process.  Thus, "you" are not allowing the
use.

Option 2 may not be such a silly idea.  Some members of the community
made it clear that they do not wish for DNSOP to be a clearing house for
RFC6761.

I assume that .gnu, .zkey, .bit communities would have the patience to
wait for the formation of an alternative processing mechanism, but there
is time pressure on .onion due to the upcoming work with certificates.

Thus, it would seem that a decision is required from this community for
the .onion case.

Needless to say, I support all of these cases where software is using
the domain name syntax but using a non-DNS name resolution mechanism.

I provide that support because they are addressing the issue of privacy
which the greater IETF community embraced with RFC7258.

The DPRIVE WG are working on privacy enhancements *within* the
DNS system.  It is a difficult problem, though many useful contributions
are emerging.  The above non-DNS using softwares approach the
same issue in a different manner: dont use DNS at all.  The advantage
of this approach is that all of the challenges that DPRIVE are wrestling
with are not encountered at all.  The only requirement is the registration
via RFC6761.

Hugo Connery
--
'If privacy is outlawed, only outlaws will have privacy.' P Zimmerman.
________________________________________
From: DNSOP [dnsop-bounces@ietf.org] on behalf of Andrew Sullivan [ajs@anvilwalrusden.com]
Sent: Thursday, 2 July 2015 03:42
To: dnsop@ietf.org
Subject: Re: [DNSOP] More after onion? was Re: Some distinctions and a  request

Hi Ed,

On Wed, Jul 01, 2015 at 12:26:43PM +0000, Edward Lewis wrote:
> I'm sympathetic to the use the path of least resistance - e.g., use names
> that syntactically are DNS names

I note that the Subject: line of your note still contains a vestigial
reference to the thread I started recently on this, and your message
nevertheless returns to collapsing "domain names" and "DNS names".

I don't know whether I've simply failed to explain the distinction I'm
trying to make, or whether you reject the premise.  Could you please
be clear about which it is?

To me, the _point_ of onion. is that it is not a DNS name.  You're
right that it has the same syntax -- because it is a domain name, but
not (intended to be) a DNS name.  The registration of the name in the
special use registry would achieve that end.

You might object that this distinction is extremely hard, because
there's nothing about the label itself to signal this namespace shift,
and unaware clients will therefore automatically just treat such names
as DNS names, not special-use domain names.

I happen to agree with that, but we cannot hold back this tide: it was
let loose once local. became an in-band protocol switch, without any
registration, in Apple's widely-deployed Bonjour service.  We might
wish that people hadn't abused the namespace to turn it into protocol
switches as well as everything else, but the history of SRV through
Bonjour shows that this technique is popular and unlikely to go away.
Commanding the tide to stay back when you are neck deep in water is
not likely to work.

Therefore, I claim, we need to make some clear distinctions and
understand what has actually happened, and then adjust to the new reality.

Best regards,

A

--
Andrew Sullivan
ajs@anvilwalrusden.com

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