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