Reviewer: Paul Wouters
Review result: Has Nits
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any
other last call comments.
This document collects IDNA information from Errata's, external information
such as ICANN, and some wisdom gathered since RFC 5891 was published and
presents this set of information for operations of domains to make their
domains more secure with respect to IDNA and its (ab)use.
The Security Section is a clear summary that states the operators should really
heed the advise of this document (and the documents references and updated)
Issue:
It seems the document asks for the IANA Consideration section to be removed.
Instead, it should keep the Section but use the text along the lines of " This
document has no IANA actions.". This helps people who are looking through
various RFC's to find IANA considerations.
Minor issues:
I find the term "For-profit domain" very confusing as .pizza is a very much for
profit domain. Normally, the terms "Generic domain" and "Brand domain" although
I guess the latter is usually avoided in written text. While the term is
described to mean a Generic Domain, I think it would be better to use Generic
domain instead of For-profit domain.
Registries choosing to make exceptions -- allow code points that
recommendations such as the MSR do not allow -- should make such
decisions only with great care and only if they have considerable
understanding of, and great confidence in, their appropriateness.
This paragraph seems really to say "Registries SHOULD NOT make exceptions" and
seems a good place for some RFC 2119 wording.
I find the term "registry" in this document confusing, as it could refer to an
"IANA registry", "script registry" or "domain registry". Perhaps always spell
this out to make the context clearer? Or alternatively, perhaps introduce the
term Registry (with captial R) and use that to refer to domain registries.
[ID.draft-klensin-idna-unicode-review] is in progress. Its status
should be checked in conjunction with application of the present
specification.
I think this is meant as informational to the RFC Editor ? Perhaps these
documents should go out as a cluster?
Note I find some documents are references within [square brackets] but not all
of them, even some RFC's are in brackets and others are not. Please make this
consistent.
The algorithm and rules of RFCs 5891 and 5892
missing xref's to the RFCs?
registries SHOULD normally consult
Either use "SHOULD" or "normally", not both? It's a little odd.
to fully satisfy the mandate set out above
Instead of mandate, which is a bit generic and confusing, why not refer to the
mentioned "IAB guidance", which I think it is referring to ?
may provide useful guidance.
Remove the word "may"
