Thanks for your review and comments, Russ. I've extracted the issues from your review and entered them in the GitHub issue tracker for the document.
- Ralph > On Feb 6, 2017, at 2:21 PM, Russ Housley <hous...@vigilsec.com> wrote: > >> >> This message opens a Working Group Last Call for: >> >> "Special-Use Names Problem Statement" >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-sutld-ps/ >> <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 > <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 <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 <mailto:DNSOP@ietf.org> > https://www.ietf.org/mailman/listinfo/dnsop > <https://www.ietf.org/mailman/listinfo/dnsop>
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
