Subject: [DNSOP] I-D Action: draft-ietf-dnsop-alt-tld-02.txt

From: [email-masked]
Date: Sun, 13 Sep 2015 07:59:10 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Domain Name System Operations Working Group of the IETF.

        Title           : The ALT Special Use Top Level Domain
        Authors         : Warren Kumari
                          Andrew Sullivan
	Filename        : draft-ietf-dnsop-alt-tld-02.txt
	Pages           : 10
	Date            : 2015-09-13

Abstract:
   This document reserves a string (ALT) to be used as a TLD label in
   non-DNS contexts or for names that have no meaning in a global
   context.  It also provides advice and guidance to developers
   developing alternate namespaces.

   [ Ed note: This document lives in GitHub at:
   https://github.com/wkumari/draft-wkumari-dnsop-alt-tld . Issues and
   pull requests happily accepted. ]

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-alt-tld/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-alt-tld-02

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 15 Sep 2015 14:28:56 -0700

Some comments.

On the Intro text:

There exists a zone which is published independently from that published 
by the IANA, to which roughly as many resolvers recurse as do those 
which recurse to the zone published by the IANA. The text "even in 
systems that are not part of the global DNS administered by IANA" 
unfortunately suggests that the mechanism of recursion differs, 
depending on whether or not resolution is attempted against the IANA 
published zone and its delegations, or a similar zone and its similar 
delegations.

IMO, nothing is gained, and something may be lost, by suggesting that 
the DNS begins, and ends, with the IANA published zone.

More on the Intro (1) text:

The terminal alpha sequence ".alt" in a sequence of labels signals the 
absence of a delegation, here we assume from the IANA root zone. It does 
not necessarily signal that any one or more component labels are 
inconsistent with label processing rules.  The text "normal registration 
and lookup rules do not apply" is overly restrictive (see above), and 
conflates the process overhead of "registration" (see provreg, ICANN, 
"variants", et seq.) and "lookup rules" (see IDNA and not a lot else).

IMO, nothing is gained, and something may be lost, by suggesting that 
label processing uniquely identifies a zone publisher.

On the Terminology (1.2):

While 2826 expressed a technical comment, it did not prevent independent 
re-publication of the data published by the IANA, nor the publication of 
a limited number of additional data records.

IMO, nothing is gained, and something may be lost, by suggesting that:
(1) the DNS ("DNS context") is properly restricted to the zone published 
by the IANA,
(2) reference to any other zone publisher is "non-DNS", and
(3) label sequences not registered (here, see provreg, ICANN, variants, 
et seq.) in an IANA zone delegated registry are necessarily semantically 
distinct from label sequences registered in an IANA zone delegated 
registry, for some non-trivial difference other than this registration 
property.

Reference to a text more recent than 1034 would be useful.

On the Background (2) text:

The closing sentence of paragraph 1 contains a statement for which no 
support exists. While it is true that DNS is "the primary resolution 
system on the Internet", the same statement was true of HOSTTABLES prior 
to the transition, and HOSTTABLES shared neither the "hierarchical", the 
"distributed" nor the "caching" nature of the DNS.

The closing paragraph conjectures some design goal (resolution 
concealment) that would "necessarily be defeated" by leakage. This seems 
overly confident.

There is a great deal of text in this section (#2), which revisits the 
presumption incorrectly offered in the intro text.

Incorrect processing of label sequences of a UTF8 implementation 
resulting in settlement costs motivated deployment of another mechanism 
to prevent "leakage".

On the ALT Namespace (3) text:

The authors of 2929, IIRC, chose not to make normative reference to 
US-ASCII when discussing text labels, allowing the possible subsequent 
signaling to special application layer processing by text labels 
composed of non-ASCII characters.

The choice of a sequence of US-ASCII ALPHA characters to signal special 
application layer processing is ad hoc.

The US-ASCII ALPHA character sequence NXDOMAIN has signaled non-resolved 
status to human eyeballs since 2308, as an alternate expression for the 
"Name Error" RCODE described in 1035 Section 4.1.1.  Were a US-ASCII 
ALPHA character sequence terminating label to be required to signal the 
label sequence is not to be looked up, per 1034 et seq., this sequence 
would have obvious and unambiguous meaning tied to 2308, hence to 1035, 
a property the proposed terminating label lacks.

On the IANA Considerations (4) text:

The text of 4.1 is unnecessary, as label sequences terminated in the 
label composed of a specified sequence of US-ASCII ALPHA characters are, 
according to this document, not "domain names" or "DNS names" or "names" 
in the context of the DNS.

On the Security Considerations (5) text:

The text is unnecessarily speculative and the risk statement offered 
unranked compared to other well-known risks which are reflected in other 
"Security Considerations" texts.

On the Acknowledgements (6) text:

The sentence beginning "The authors understand that ..." is 
grammatically awkward and unnecessary.

That concludes my reading of draft-ietf-dnsop-alt-tld-02.txt.  I would 
prefer that this draft not be published, even as an informational RFC.

Eric Brunner-Williams
Eugene, Oregon

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 15 Sep 2015 14:43:07 -0700

On 15 Sep 2015, at 14:28, Eric Brunner-Williams wrote:

> Some comments.
>
> On the Intro text:
>
> There exists a zone which is published independently from that 
> published by the IANA, to which roughly as many resolvers recurse as 
> do those which recurse to the zone published by the IANA. The text 
> "even in systems that are not part of the global DNS administered by 
> IANA" unfortunately suggests that the mechanism of recursion differs, 

Can you say more about this zone? Having details would be useful.

> the DNS begins, and ends, with the IANA published zone.

If the operators of the other zone you allude to want to follow this 
spec, that's fine, but trying to write a spec that covers all possible 
root zones seems much more difficult than writing a spec about the DNS 
about which that this group cares most.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 16 Sep 2015 10:46:04 -0400

Hi Eric,

Thanks for your review.  Some remarks in line.

On Tue, Sep 15, 2015 at 02:28:56PM -0700, Eric Brunner-Williams wrote:
> 
> IMO, nothing is gained, and something may be lost, by suggesting that the
> DNS begins, and ends, with the IANA published zone.

I don't believe the document suggests either that beginning or ending,
and I'd like you to point to the text that does (since I don't
understand the text you quoted but that I elided here as making such a
suggestion).  The I-D _does_ rely on the premise that the global DNS
for the Internet relies on the IANA root.  I think that it does, and I
note that the IAB some time ago published a document that seems to
agree with me.  It may be that on this or that network (potentially
even large ones) people are using alternative roots, special
otherwise-undelegated names (e.g. corp), or whatever.  Those parts of
the DNS are not on the Internet, even if those servers are part of
some internet and even if people on the Internet could in principle
use those servers for resolution.  The global DNS is the one shared
implicitly by all attached to the Internet, and that's rooted at IANA.
If we reach the point where the IANA root and other DNS systems start
to drift apart, we will no longer have one global name space, but
multiple such name spaces none of which is the name space of the
Internet.  That's precisely why this issue is fraught.

> with label processing rules.  The text "normal registration and lookup rules
> do not apply" is overly restrictive (see above), and conflates the process
> overhead of "registration" (see provreg, ICANN, "variants", et seq.) and
> "lookup rules" (see IDNA and not a lot else).

I reject your above argument, so I don't think it's overly
restrictive, and since we explicitly separate registration and lookup
(since we name each of them) I don't understand why you think there's
a conflation.

> IMO, nothing is gained, and something may be lost, by suggesting that label
> processing uniquely identifies a zone publisher.

Where does the text suggest that, please?

> re-publication of the data published by the IANA, nor the publication of a
> limited number of additional data records.

No indeed.  Where exactly do you think the I-D suggests either of
those things?

> (1) the DNS ("DNS context") is properly restricted to the zone published by
> the IANA,

It's not "properly restricted".  But we're limiting the scope of the
"normal" DNS to be anchored in the global DNS.  Would it help if we
added these sentences: "It is worth noting that some uses of DNS
happen outside the global DNS.  For the purposes of this document,
those uses are no different to any other use of domain names that are
not part of the normal DNS."?

> support exists. While it is true that DNS is "the primary resolution system
> on the Internet", the same statement was true of HOSTTABLES prior to the
> transition, and HOSTTABLES shared neither the "hierarchical", the

Yes, and those were three of the reasons discussed in the introduction
of RFC 882 for why DNS was needed.  Since people in fact adopted the
DNS and those were the reasons for doing so, we claim there's a
teleological explanation there.  If you really think this is
controversial, I don't suppose it'll hurt to remove the sentence, but
since this is a WG document I'd like more than one such objection
(because, quite frankly, your argument here seems at best thin to me).

> The closing paragraph conjectures some design goal (resolution concealment)
> that would "necessarily be defeated" by leakage. This seems overly
> confident.

It's an analytic truth, so I'm pretty confident.

> presumption incorrectly offered in the intro text.

Since we disagree about that incorrectness, I presume we disagree here
too.

> Incorrect processing of label sequences of a UTF8 implementation resulting
> in settlement costs motivated deployment of another mechanism to prevent
> "leakage".

This seems to be a claim about the motivation of something, but it's
completely obscure to me what that something is; and anyway, I'm not
sure what these settlement costs were or where they are documented.
How is this relevant to the section?

> The authors of 2929, IIRC, chose not to make normative reference to US-ASCII
> when discussing text labels, allowing the possible subsequent signaling to
> special application layer processing by text labels composed of non-ASCII
> characters.

The normativity of US-ASCII there is irrelevant; the main thing is
that 2929 (and its successors, of which there are a few) doesn't constrain anything to LDH.  But so what?

> application layer processing is ad hoc.

I think it's specified somewhere, but it's certainly arbitrary.

> "Name Error" RCODE described in 1035 Section 4.1.1.  Were a US-ASCII ALPHA
> character sequence terminating label to be required to signal the label
> sequence is not to be looked up, per 1034 et seq., this sequence would have
> obvious and unambiguous meaning tied to 2308, hence to 1035, a property the
> proposed terminating label lacks.

Are you suggesting (I can't tell) that we replace "alt" with
"nxdomain"?  If so, I see two objections.  First, as you have already
pointed out, the DNS and the global DNS are not coterminus in scope.
Therefore I can freely imagine someone using the alt tree to publish
application-specific data that _is_ to be looked up in the DNS, just
not in the global DNS.  This is actually discussed in section 4.1 of
the draft.  So "nxdomain" would be wrong in that case.  Moreover,
nxdomain is longer than alt, so it shortens the already-cramped space.

> The text of 4.1 is unnecessary, as label sequences terminated in the label
> composed of a specified sequence of US-ASCII ALPHA characters are, according
> to this document, not "domain names" or "DNS names" or "names" in the
> context of the DNS.

They certainly are domain names, and the text of 4.1 is quite clearly
needed under the rules of RFC 6761.

> "Security Considerations" texts.

Do you have specific changes you want to see?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]