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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
