Re: [DNSOP] WGLC for draft-ietf-dnsop-sutld-ps

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 <housley@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>