Internationalized Domain Names for Applications (IDNA) Review for New Unicode Versions
RFC 8753

Abstract

   The standards for Internationalized Domain Names in Applications
   (IDNA) require a review of each new version of Unicode to determine
   whether incompatibilities with prior version or other issues exist

nit: I think "prior versions", "a prior version", or "the prior version"
is better.

   and, where appropriate, to allow the IETF to decide on the trade-offs
   between compatibility with prior IDNA versions and compatibility with
   Unicode going forward.  That requirement, and its relationship to

nit: I'd consider "necessary" instead of "appropriate", though both are
admittedly somewhat subjective in evaluation.

Section 1

[same comments as for abstract]

Section 3.1

   preserving backward compatibility within IDNA.  The 2018 review (for
   Unicode 11.0 and versions in between it and 6.0) [IDNA-Unicode12]
   also concluded that maintain Unicode compatibility, rather than IDNA
   backward compatibility, should be maintained.  That decision was

nit: duplicated "maintain[ed]"?

Section 3.2

   The second type of review is not clearly explained in RFC 5892, but
   is intended to identify cases in which newly-added code points, or
   perhaps even newly-discovered problematic older ones, violate design
   assumptions of IDNA, identify defects in those assumptions, or are
   inconsistent (from an IDNA perspective) with Unicode commitments
   about assignment, properties, and stability of newly-added code
   points.  [...]

Absent references to additional discussion, the "perhaps even
newly-discovered problematic older ones" clause does not seem terribly
well supported by what I have read in RFC 5892.  (I do not have any good
supporting arguments for taking a different position, though.)

   Because resolution of problems identified by this part of the review
   may take some time even if that resolution is to add additional
   contextual rules or disallow one or more code points, there will be
   cases in which it will be appropriate to publish the results of the
   algorithmic review and provide IANA with corresponding tables, with
   warnings about code points whose status is uncertain until there are
   IETF consensus conclusions about how to proceed.  The affected code

This seems to presume that having IANA continue to publish tables is
required or desirable.  I see that Section 5 notes situations in which
those presumptions should be challenged, which presumably means that the
authors do not feel that the present is such a situation?

Section 4

   At the time the IDNA2008 documents were written, the assumption was
   that, if new versions of Unicode introduced incompatible changes, the
   Standard would be updated to preserve backward compatibility for
   users of IDNA.  For most purposes, this would be done by adding to

nit: in Section 2 we use the lowercase "the standard".  Additionally,
nowhere do we call out that in this document "the standard" (whether
minuscule or majuscule) refers to IDNA2008.

not-nit: it is perhaps a little bit of a stretch to go from the language
of RFC 5892 to "the assumption was", though I have no better
alternative.

   Subsequent to the publication of this document, changes in Unicode
   detected by algorithmic reviews that would break compatibility with
   derived properties associated with prior versions of Unicode or that
   preserve such compatibility within IDNA at the price of departing
   from current Unicode specifications must be documented (in documents
   expected to be published as standards track RFCs), explained to, and
   reviewed by the IETF.

This is a very long sentence, and it seems that in the current
formulation, "that would break compatibility with derived properties"
binds to "algorithmic reviews" and not "changes in Unicode".
Additionally, as was perhaps touched on in the secdir review, the
presence of "explained to" is unusual, in that documents reviewed by the
IETF are generally considered to be products of the IETF and not for the
purpose of explaining things to the IETF.  So, I suppose that I am
asking for the "explanation on request".  (I do agree that "documented"
and 'explained" are different/non-redundant, but am not certain that
both need to be called out in this document.)

                        Doing things that way is not only at variance
   with the language in RFC 5892 but is also inconsistent with the
   intent of commitments to the registry and user communities to ensure
   that IDN labels, once valid under IDNA2008, would remain valid and,
   excepting those that were invalid because they contained unassigned
   code points, those that were invalid remained invalid.

nit(?): I'm not entirely sure how much value there is in attempting to
ascribe "intent" to events in the past and getting farther so.

   This document restores and clarifies that original language and
   intent: absent extremely strong evidence on a per-code point basis
   that preserving the validity status of possible existing (or
   prohibited) labels would cause significant harm, Unicode changes that
   would affect IDNA derived properties are to be reflected in IDNA
   exceptions that preserves the status of those labels.  There is one

This seems to be attempting to impose a requirement without naming a
responsible party or timeline for completion.  As such, it seems
unlikely to be an unqualified success...
Also, nit: s/preserves/preserve/ to keep singular/plural parity

   partial exception to this principle.  If the new code point analysis
   (see Section 3.2) concludes that some code points or collections of
   code points should be further analyzed, those code points, and labels
   including them, should be considered unsafe and used only with
   extreme caution because the conclusions of the analysis may change
   their derived property values and status.

It would perhaps be prudent to reiterate that the "new code point
analysis" is permitted(?) to expose "newly-discovered problematic older
[codepoints]".

Section 8

I agree with others that just describing as "Designated Expert(s)" and
leaving the normal expert-appointing procedures in place for both
classes of expert is the best option.  (I do note that any changes here
should also be reflected in Appendix A.)

   As discussed in Section 5, and if they have not already done so, IANA
   is requested to modify the IDNA tables collection [IANA-IDNA-Tables]

"if they have not already done so" seems unlikely to age well.

   The "Note" in that registry should also be revised to be consistent
   with the above, perhaps to say:

I don't think we need to soften this with "perhaps"; we are in a
position where we can assert the contents of the Note.

      It should be stressed that these are not normative that, in
      principle, an application can do its own calculations and these

nit: there seems to be a missing word (maybe for "in that" or "and
that"?)

   As long as the intent is preserved, the specific text is at IANA's
   discretion.

[my sense is that IANA is happy to have fewer qualitative judgments to
make on its own]