Subject: Re: [DNSOP] Fwd: New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

From: Warren Kumari <[email-masked]>
Date: Fri, 04 Dec 2015 23:01:31 +0000

On Thu, Oct 29, 2015 at 9:27 AM Joe Abley <[email-masked]> wrote:

> Hi all,
>
> Our esteemed chairs have recently outlined a path forward for addressing
> the IESG's concerns relating to the implementation of RFC 6761,
> triggered by the experience of assessing RFC 7686 ('The ".onion"
> Special-Use Domain Name'). The IESG's concerns are summarised in
> <http://www.ietf.org/blog/2015/09/onion/>.
>
> Paraphrasing Suz and Tim (please correct me if I mis-speak) the approach
> to be taken in this working group is to try to achieve consensus on a
> problem statement as a first step, following which we will be in better
> shape to have focused discussion of potential solutions. A call for
> volunteers was made to augment an earlier ad-hoc design-team design-team
> to write up that problem statement, consisting of Alain Durand, Peter
> Koch and me, and I gather that some eligible thrill-seekers have already
> put their names forward to join us.
>
> A very rough first cut of a problem statement was submitted hurriedly
> before the 00 cut-off deadline in order to try and move this
> conversation forward (see below). This text doesn't even represent
> particularly strong consensus amongst Peter, Alain and me, never mind
> the yet-to-be-fully-formed design team or the working group as a whole,
> but it's a starting point. An earlier rendering of the text with
> different organisation (that was not submitted) can be found at
> <https://github.com/ableyjoe/draft-adpkja-dnsop-special-names-problem>.
>
> I take full, personal responsibility for the gratuitous definition of
> "aardvark", and the ancient, historical quotes from the namedroppers
> archive that you'll find in appendix A. You're welcome.
>
>
Thanks again to the design team for writing this....

Before I forget, here are some readability / grammar nits. I have some more
substantive comments too, but I wanted to send these over before I
accidentally close that buffer :-)

================
Abstract

......

[RFC6761] introduced a framework by which, under certain
circumstances, a particular domain name could be acknowledged as
being special.  This framework has been used to make top-level domain
reservations, that is, particular top-level domains that should not
[O] reservations, that is, particular
[P] reservations; that is, particular
[R] grammar
...
be used within the DNS to accommodate parallel use of non-DNS name
resolution protocols by end-users and avoid the possibility of
namespace collisions.
....
1.  Terminology

Clear and unambiguous use of terminology is important for the clear
formulation of any problem statement.  The DNS protocol suffers from
imprecise and overloaded terminology (e.g. see
[I-D.ietf-dnsop-dns-terminology]) without confusing matters further
with terms and concepts from other naming systems that are similar,
but different.

[o] The DNS protocol suffers from
imprecise and overloaded terminology (e.g. see
[I-D.ietf-dnsop-dns-terminology]) without confusing matters further
with terms and concepts from other naming systems that are similar,
but different.
[P] The DNS protocol suffers from imprecise and overloaded terminology
(e.g. see
[I-D.ietf-dnsop-dns-terminology]). The use of terms and concepts from other
naming systems that are similar (but different) simply confuses matters
further.
[R] readability -- I *think* this is what was meant?
In the interests of clarity, the following terms used in this
document are to be interpreted as follows:

.....
4.  Architectural considerations

The first thing to consider in this discussion is that not all names
(or domain names) are par of the Domain Name System.  See [ID-lewis-
[O] are par of the
[P] are part of the
[R] typo

domain-names] for an in-depth discussion on this topic.
....

LOCAL is used by the Multicast DNS protocol specified in [RFC6762]
which is similar in some respects to the DNS, but which uses
different well-known port number and is limited to a particular
[O] different well-known port number
[P] a different well-known port number
[R] grammar

multicast scope;
....

It should also be noted that there are other choice than using the
[O] there are other choice
[P] there are other choices
[R] grammar

most significant label for a protocol switch.  In particular, a
proposal to move those protocol switches under a specific top level
domain has been discussed (.ALT).  If that architecture choice is
made, some of the questions listed in the sections bellow would
[O] bellow
[P] below
[R] spelling

become moot.

5.  Technical considerations
.....
Such documents might well be opaque to many
readers ([RFC6762] is a seventy-page protocol specification, for
example, which is arguably not the most expressive way to set
[O] expressive
[P] effective
[R] optional; might be a better word choice?
expectations of non-technical end-users).

At the time of writing, the DNSOP working group charter does not
clearly indicate that DNSOP is the proper venue for the evaluation to
be carried out, although it also says that matters regarding the
namespace are on topic.  Also, as pointed out in section 3.2), we are
[O])
[P]
[R] no matching open parenthesis

6.2.2.  Technical criteria

Regardless of the actual name being proposed as protocol switch, it
is also not clear what technical criteria should the evaluation body
use to examine the merit of an application for such a reserved name/
[O] what technical criteria should the evaluation body
use
[P] what technical criteria the evaluation body should use
[R] readability

===========

> I will unfortunately not be in Yokohama next week, but I would encourage
> anybody interested in the general problem space to discuss it on this
> list. I think it's reasonable to consider the current and future design
> team victims to be a secretariat for this discussion, and the content of
> any consensus on this needs to come from an open and transparent
> discussion here, in the working group.
>
>
> Joe
>
> Forwarded message:
>
> > From: [email-masked]
> > To: Joe Abley <[email-masked]>, Peter Koch <[email-masked]>, Peter Koch
> > <[email-masked]>, Alain Durand <[email-masked]>
> > Subject: New Version Notification for
> > draft-adpkja-dnsop-special-names-problem-00.txt
> > Date: Mon, 19 Oct 2015 16:26:08 -0700
> >
> >
> > A new version of I-D, draft-adpkja-dnsop-special-names-problem-00.txt
> > has been successfully submitted by Alain Durand and posted to the
> > IETF repository.
> >
> > Name:         draft-adpkja-dnsop-special-names-problem
> > Revision:     00
> > Title:                Problem Statement for the Reservation of Top-Level
> Domains in
> > the Special-Use Domain Names Registry
> > Document date:        2015-10-19
> > Group:                Individual Submission
> > Pages:                12
> > URL:
> >
> https://www.ietf.org/internet-drafts/draft-adpkja-dnsop-special-names-problem-00.txt
> > Status:
> >
> https://datatracker.ietf.org/doc/draft-adpkja-dnsop-special-names-problem/
> > Htmlized:
> > https://tools.ietf.org/html/draft-adpkja-dnsop-special-names-problem-00
> >
> >
> > Abstract:
> > The dominant protocol for name resolution on the Internet is the
> > Domain Name System (DNS).  However, other protocols exist that are
> > fundamentally different from the DNS, but which have syntactically-
> > similar namespaces.
> >
> > When an end-user triggers resolution of a name on a system which
> > supports multiple, different protocols for name resolution, it is
> > desirable that the protocol to be used is unambiguous, and that
> > requests intended for one protocol are not inadvertently addressed
> > using another.
> >
> > [RFC6761] introduced a framework by which, under certain
> > circumstances, a particular domain name could be acknowledged as
> > being special.  This framework has been used to make top-level domain
> > reservations, that is, particular top-level domains that should not
> > be used within the DNS to accommodate parallel use of non-DNS name
> > resolution protocols by end-users and avoid the possibility of
> > namespace collisions.
> >
> > Various challenges have become apparent with this application of the
> > guidance provided in [RFC6761].  This document aims to document those
> > challenges in the form of a problem statement, to facilitate further
> > discussion of potential solutions.
> >
> >
> >
> >
> > Please note that it may take a couple of minutes from the time of
> > submission
> > until the htmlized version and diff are available at tools.ietf.org.
> >
> > The IETF Secretariat
> >
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Warren Kumari <[email-masked]>
Date: Tue, 29 Dec 2015 16:48:06 +0000

On Fri, Dec 4, 2015 at 6:01 PM Warren Kumari <[email-masked]> wrote:

> Before I forget, here are some readability / grammar nits. I have some
> more substantive comments too, but I wanted to send these over before I

... and some more notes below:

Abstract:
I found this to be really confusing, especially in an abstract:
"This framework has been used to make top-level domain
reservations, that is, particular top-level domains that should not
be used within the DNS to accommodate parallel use of non-DNS name
resolution protocols by end-users and avoid the possibility of
namespace collisions."

How about:
"This framework has been used to reserve top-level domains that should not
be used within the DNS to avoid the possibility of
namespace collisions in parallel use of non-DNS name
resolution protocols"
Still not great, but (IMO) less confusing..

Section 1:
I think it is time to remove the Aardvark.

Section 2:
The below seems to be missing some words, and also seems convoluted.
"In recent years, using the last label of a domain name (aka TLD) as
switch to indicate how to treat name resolution has been experimented
using the framework of [RFC6761]. "

How about:
"In a number of recent cases, the framework in RFC6761 has been used to
allow the last label in a name to act as a switch to indicate the
resolution process (or how to treat name resolution).
Examples of such switches include: .example (don't resolve), .local (use
mDNS), .onion (use tor), any TLD registered in IANA-maintained root-zone
(use DNS)."

"It could indicate to switch to another name space (eg .onion), use a
different protocol (eg tor, or mdns), or indicate to use a local DNS"

s/tor/Tor/g
s/mdns/mDNS/g

4.  Architectural considerations
The first thing to consider in this discussion is that not all names
(or domain names) are par of the Domain Name System
s/par/part/

"If we accept the notion that the most significant label of a domain
name is actually a protocol switch, it implies that we are actually
building a catalog of all top level domains that explain which are
are switches."
I'm not quite sure what this is trying to say, especially the last bit
("that explain which are
are switches."). Perhaps: "we are actually building a catalog of all top
level domains and what resolution protocol each one invokes" ?

"Note that such a catalog does not formally exist today."
Is this actually true? Isn't the IANA Special Use Names Registry ("
http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml"
) *supposed* to be that? I'm not saying that it is actually complete or
accurate, but if I were looking for the "formal" place where this would be
Id probably point there...

5.  Technical considerations
"However, it is not clear what any of those audiences might reasonably
expect as a result of a successful request to add a top-level domain to the
Registry."
Hmmm. I'd thought that a reasonable expectation from many of the audiences
is that the string is reserved and would not be used as a resolution switch
by others. I'm *assuming* that, e.g the Tor folk reasonably expect that
someone applying for the DNS TLD .onion would not be granted it. This seems
to match up with what e.g the CABForum seemed to expect that having it
reserved would accomplish.
Additionally, having a reference in a Registry (e.g an RFC) provides a
place to provide information on how the name should be handled, especially
in the cases where it leaks - for example, the .ALT draft requests that the
string be added to the "Locally Served DNS Zones" ( [RFC6303]) to attempt
to limit the pollution.

Section 6.1.  Non-exhaustive list of external organizational considerations
Missing a period at the end of the last sentence.

Section 6.2.1.  Process
s/DNSop/DNSOP/g

Section 6.2.2.  Technical criteria
"Regardless of the actual name being proposed as protocol switch, it
is also not clear what technical criteria should the evaluation body
use to examine the merit of an application for such a reserved name/
protocol switch.  For example, is large scale prior deployment an
acceptable criteria?"
I believe that a major issue (apart from the obvious '"define "large"') is
that this encourages people to simply squat on a string and use it until
they reach some threshold. Part of the justification for .ALT was that it
provided a sandbox for people to build a community and test their name
resolution system, without squatting. Once they reach some threshold, then
(perhaps) they could demonstrate large scale deployment.  I understand that
this document isn't (necessarily) advocating for "large scale prior
deployment"  as a criteria, but I think that it should at least mention
that this criteria would encourage squatting.

6.2.3.  Name evaluation
"When processing gTLD applications, ICANN has a process to review
those to check if the proposed names are potentially offensive to
certain communities, have political ramifications, etc.. It is worth
asking if the IETF should have a similar process in place to evaluate
specific proposed reserved names, and, if so, how such process would
be implemented, and how appeals should be handled?"
The ICANN process is huge and hulking, and has many moving parts. There is
also much politics and subtleties. This is not always clear to people who
are not involved in it, and so the readers of this document may
underestimate the (monetary + time + political + ickiness) cost in the IETF
spinning up a parallel process. There is also the root problem of what
happens if ICANN approves .foo as a (DNS) TLD at the same time that the
IETF approves .foo as a protocol switch. Or, ICANN turns down .narnia on
geographic (political) grounds and then Eustace Scrubb comes to the IETF to
get it approved as a protocol switch. Or if ICANN determines "damn" to be
offensive, what this means for the IETF evaluating it.
I understand that the document is not (necessarily) advocating for the IETF
setting up a parallel system, but it is (IMO) worth discussing that there
exists the (strong) possibility of collisions between the two policy
processes -- this is kinda at the root of the entire issue.

W

> [I-D.ietf-dnsop-dns-terminology]). The use of terms and concepts from
> other naming systems that are similar (but different) simply confuses
> matters further.
>> > Title:                Problem Statement for the Reservation of
>> Top-Level Domains in

---

From: Stuart Cheshire <[email-masked]>
Date: Tue, 29 Dec 2015 13:32:28 -0800

Hi Joe, Peter, Alain,

I have some feedback on draft-adpkja-dnsop-special-names-problem-00.

There seems to have been lots of recent discussion regarding confusion surrounding RFC 6761. I’m a little surprised by this, since I didn’t think RFC 6761 was unclear. But then as co-author, that’s my failing. I thought it clearly stated our intention, and I thought the IETF Last Call scrutiny should have identified any ambiguity, but apparently not.

>    In recent years, using the last label of a domain name (aka TLD) as
>    using the framework of [RFC6761].

Not only the last label. The last _n_ labels are also commonly used as the algorithmic method for determining what names qualify as special. Some examples:

10.in-addr.arpa.
168.192.in-addr.arpa.
example.com.
example.net.
example.org.

>    This switch practice is not explicitly documented anywhere.

That was the intention of the seven-question list: to have protocol specifications explicitly document their “switch practice” -- i.e. how their special names are to be unambiguously recognized, and what software should do having recognized one of them.

>    Answers to these seven questions provide guidance to the
>    corresponding seven audiences on how to handle a special-use domain
>    name once it has been reserved by inclusion in the Registry.
>    However, they are inadequate for making the determination whether a
>    particular domain name qualifies as being special in the first place.

You have it backwards. The seven questions were not “what to expect *after* this special-use registration is done”; they were the justifications *why* the special-use registration should be granted, required in a document demonstrating that it (a) provides a result that the community judges to be good, and (b) the aforementioned good result cannot reasonably be achieved better another way.

>    The lack of a more elegant way to specify a name resolution protocol
>    in (for example) a URI amounts to an architectural oversight.

I’m not sure I agree that there *is* a more elegant way to achieve the desired effect. Unless you intend to actually describe some hypothetical “more elegant way” of doing this, I suggest simply removing this unsupported implication from the document.

>    made, some of the questions listed in the sections bellow (sic) would
>    become moot.

RFC 6761 is not, and has never been, about TLDs. It is about special behaviours, and how to trigger them. As such, whether the protocol switch is a TLD, or SLD, or 3LD, or whatever, has no bearing at all on “the questions listed in the sections below”. The same concerns would apply equally, regardless of how the algorithmic determination of “specialness” is to be performed. RFC 6761 states that the algorithmic determination is *typically* done by looking for a certain suffix (i.e., one or more labels). I deliberately did not want RFC 6761 to over-specify this, so as to leave the door open for someone smarter than me who might come along in the future and propose some new and valid algorithmic determinant that I had not anticipated. Clearly a document stating that any name containing any label starting with an “x” is now “special” ought to be thrown out by the IESG as unreasonable, but there could be other valid ideas beyond my current imagination.

>    Note: [RFC6761] mentions the reserved names could be any label in any
>    random string, not just the rightmost one (or ones).

Can you cite the actual text that says that? I couldn’t find what particular text you’re paraphrasing there.

>    What does it mean to have a "non-DNS" entry in the registry
>    described above?

The answers to the seven questions, and other text in the associated protocol specification, are supposed to tell you what it means.

>    Are applications supposed to check that registry to know what to do?

No.

>    Can/Should applications do this check dynamically?

No.

>    What if an application makes this dynamic check and realizes the
>    name contains a switch it does not know how to treat?

Not applicable. The closest equivalent to the run-time mechanism you’re hinting at is something that already exists: The global DNS. Putting in authoritative NXDOMAIN results for all appropriate special-use names is the best way to achieve the result you want.

>    it is not clear who is responsible for carrying out an
>    evaluation.  A document which requests additions to the Registry
>    might be performed by the IESG, by the IAB, by the DNSOP working
>    group, by an ad-hoc working group, by expert review or any
>    combination of those approaches.  [RFC6761] provides no direction.

RFC 6761 says:

   When IANA receives a request to record a new "Special-Use Domain
   Name", it should verify, in consultation with the IESG, that the IETF
   "Standards Action" or "IESG Approval" document [RFC5226] includes the
   required "Domain Name Reservation Considerations" section stating how
   the special meaning of this name affects the behavior of hardware,
   software, and humans in the seven categories.  If IANA and the IESG
   determine that special handling of this "Special-Use Domain Name" is
   appropriate, IANA should record the Special-Use Domain Name, and a
   reference to the specification that documents it, in the registry.

I confess I has assumed that IANA would designate some person with the expertise and experience to evaluate whether “... special handling of this "Special-Use Domain Name" is appropriate ...”, much as requests for TCP and UDP ports are evaluated. That was my mistake. I should have been explicit about the intended review process.

>    For example, is large scale prior deployment an acceptable criteria?

Large scale prior deployment should *not* be required -- that would just make squatting a necessary prerequisite for getting a special use name assigned. RFC 6761 was intended to provide a legitimate path for proposals to be evaluated on technical merit, rather than de facto squatting.

>    Going back to the previous point of prior usage of the protocol, in
>    the case of LOCALHOST, LOCAL and ONION, those particular domain names
>    were already in use by a substantial population of end-users at the
>    time they were requested to be added to the Registry.  Rightly or
>    not, the practical cost of a transition was argued as a justification
>    for their inclusion in the registry.

No. The justification for having an entry in the registry was to facilitate the desired special behaviour. The particular choice of what name went in the registry was influenced by existing usage, but the justification for having the entry itself was motivated by the desire for special behaviour. If the IETF process went a bit more smoothly, the IETF would have more participation in the choice of name *before* it becomes too late to easily change that.

As I read it, draft-adpkja-dnsop-special-names-problem seems to focus far too intently on the issue names. (But then, that is what ICANN is in the business of selling, so maybe it’s not surprising.) The substance of RFC 6761 is about enabling special behaviours, and using special names to trigger those special behaviours is merely a means to the end. What is interesting and important, and worthwhile for the IETF to support, is the special behaviours, not the names.

Stuart Cheshire