[DNSOP] Some proposals for draft-adpkja-dnsop-special-names-problem-02

["Paul Hoffman" <[e-mail]>]

Greetings. The authors have done a great job of cleaning up the document 
since the -01, but there are still many open issues. It would be grand 
if we could use the mailing list to discuss this before the face-to-face 
meeting in under two weeks.

Below are the issues I brought up on the -01 document that are still not 
addressed in the -02. Maybe these are not what the rest of the WG wants, 
but it would be good to find out.

--Paul Hoffman

==========

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.