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"