Subject: [DNSOP] Some proposals for draft-adpkja-dnsop-special-names-problem-01

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 09 Mar 2016 15:08:44 -0800

Greetings. The draft is a significant improvement over the -00, and is 
much appreciated. I have given the authors a raft of editorial changes 
offline. This message is just about proposals for more significant 
changes.

--Paul Hoffman

==========

IETF and ICANN

Section 6.2.4 of draft-adpkja-dnsop-special-names-problem-01 is 
supposedly about the ICANN process, but it keeps talking about the IETF 
as well. This leaves the problem statement with no clear discussion of 
ICANN's process.

Proposal: heavily edit Section 6.2.4 to be just about ICANN, and make it 
Section 6.3 to make it more clearly parallel with Section 6.2, "IETF 
Internal Considerations".

==========

Differences in encoding

Section 4 mentions that labels in .onion do not have the 63-octet limit 
that names in the DNS have. However, there are differences listed for 
names in .local. Labels in .local MUST be valid UTF-8 strings. Thus, 
even though labels in names (not hostnames) can contain any sequence of 
octets, labels in .local are more restricted.

Proposal: mention this difference in Section 4.

==========

Onion URI

In section 4, it says:

    Application architects see using special name tags
    (a la .onion) as an easy way to get new features deployed.  They
    consider the hurdles of deploying new URI schemes such as
    http:/onion/onion-name as too onerous and too slow to deploy for
    their needs.

The example is malformed.

Proposal: The example should be both http://onion/onion-name and 
onion:/onion-name.

==========

Default action

Near the end of Section 4, it says:

    In effect, it would associate TLDs with indications on how
    applications and resolvers should treat them.  However, such an
    approach would leave open the question of not-yet-defined TLDs.  No
    resolution mechanism could be associated with those.

During the earlier discussion, many people pointed out that the default 
action is to assume that names are in the DNS unless they are in the 
registry.

Proposal: Change the text to reflect the current default action:

    In effect, it would associate TLDs with indications on how
    applications and resolvers should treat them.  However, such an
    approach would leave open the question of not-yet-defined TLDs.
    Systems would continue to assume that not-yet-defined TLDs are
    part of the DNS until they are listed in the registry.

==========

The use of .alt

There was a significant amount of interest in the WG's .alt proposal 
(draft-ietf-dnsop-alt-tld-03). However, that draft is never mentioned in 
the problem statement, and is only obliquely referred to once near the 
end of Section 4. During earlier discussions many people said that the 
.alt proposal solves many of the difficult problems listed in the 
problem statement.

Proposal: Add greater discussion of the .alt proposal to Section 4 
(architectural considerations), Section 5 (technical considerations, in 
this case about the lack of registry for .alt), and in a few places in 
Section 6.2.