> This message opens a Working Group Last Call for:
>
> "Special-Use Names Problem Statement"
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/
> Proposed status: informational
>
> Starts: 2 Feb. 2017
> Ends: 23 Feb. 2017 (3 weeks)
>
> Discussion should go to the mailing list.
>
> Is this draft ready to advance for publication as an Informational RFC, and
> as guidance for possible updates to RFC 6761? Does it describe the relevant
> issues clearly, and cover all the relevant ones that should be taken into
> account in future work in the IETF on the special use names registry or RFC
> 6761?
I think the document should be published an Informational RFC once the comments
are resolved. I think it offers a good foundation for a future rfc6761bis
document.
I have several comments…
I think the title should be Special-Use Domain Names Problem Statement. The
abstract talks about domain names, so the title should match.
Will I-D.lewis-domain-names be published as an Informational RFC as well? If
not, then the Introduction needs to extract highlights from that document.
These three bullets in Section 3 overlap:
o Both ICANN and the IETF have the authority and formal processes to
assign names from the pool of unused names, but no formal
coordination process exists. The lack of coordination complicates
the management of the root of the Domain Namespace and may lead to
conflicts in name assignments [SDO-ICANN-SAC090].
o The IETF and ICANN each have administrative authority over the
Domain Namespace. Not all developers of protocols on the internet
agree that this authority should reside with the IETF and ICANN.
o Although IETF and ICANN nominally have authority over this
namespace, neither organization can enforce that authority over
any third party who wants to just start using a subset of the
namespace.
I think there is one main point and two observations. The main point is that
both ICANN and the IETF have the authority and formal processes to assign
previously unused names. The first observation is that ICANN and the IETF need
to coordinate to avoid conflicts. The second observation is that some think
that the authority is misplaced. The second observation needs to be expanded
to state the consequence, which I assume is squatting. If I guessed correctly,
the text should explain that squatting leads to conflicts. The third
observation is that neither ICANN nor the IETF has any technical means to
prevent squatting.
I think that the Section 3 bullet on .local should explain that the amount of
time involved was excessive, but part of the reason was that the process for
special-use assignments was being invented. As a result, .onion took much less
time.
I think that theSection 3 bullet that references
https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html should be
reworded. The information in the Ed Note probably does not belong in the
Informational RFC.
I think that Section 4.2.5 should include a reference to the SSAC document. I
know it is also referenced elsewhere.
And a few Nits…
The “SUDN” and “SUTLDN” acronyms are defined, but they are not used very often.
I wonder is spelling it out in every case would be more clear.
In Section 3, there is bad formatting and duplicate informations in the bullet
about ICANN Reserved Names. I suggest:
s/(see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names )/(seeSection
2.2.1.2.1of [SDO-ICANN-DAG])
In Section 4.1.1:
s/TOR browser/Tor Browser [TP]/
s/connecting over TOR/connecting over the Tor network/
[TP] = https://www.torproject.org
In Section 4.1.3:
s/Memorandum of Understanding[RFC2860]/Memorandum of Understanding [RFC2860]/
Russ_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
