Last Call Review of draft-faltstrom-unicode12-03
review-faltstrom-unicode12-03-genart-lc-housley-2021-10-14-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-faltstrom-unicode12-03
Reviewer: Russ Housley
Review Date: 2021-10-14
IETF LC End Date: 2021-11-16
IESG Telechat date: unknown

Summary: Almost Ready


Major Concerns:

Section 4 says:

   ...  As including an exception would require
   implementation changes in deployed implementations of IDNA20008, the
   editor proposes that such a BackwardCompatible rule NOT to be added
   to IDNA2008.  This also ensures all sandhi marks being treated in an
   equal way.

   The IETF has decided to NOT add a BackwardCompatible rule to IDNA2008
   (i.e.  Section 2.7 of RFC 5892 [RFC5892]) for this code point.

This document is implementing the recommendations (assuming that the
IETF Last Call confirms there is consensus).  So, this sentence should
reflect that as a way forward, not a recommendation.  I suggest:

   ...  As including an exception would require
   implementation changes in deployed implementations of IDNA20008, the
   IETF has decided to not add a BackwardCompatible rule to IDNA2008
   (i.e.  Section 2.7 of RFC 5892 [RFC5892]) for this code point.  This
   also ensures all sandhi marks being treated in an equal way.

Section 5:

   s/conclusion of this document is to not add/conclusion is to not add/

It is not the conclusion of the document, it is the consensus of the
IETF (assuming that the IETF Last Call confirms that position).


Minor Concerns:

Section 2.1:  s/4892/5892/

Section 2.3 says: "... CONTEXTJ, and CONTEXTO ..."  CONTEXT is explained
earlier in the document, but please provide a brief explanation of these
derived property values.  They are used later in the document too.


Nits:

Section 1, last 3 paragraphs, says:

   There were three incompatible changes in the Unicode standard after
   Unicode 5.2.0 [Unicode-5.2.0] up to including Unicode 6.0.0
   [Unicode-6.0.0], as described in RFC 6452 [RFC6452].  The code points
   U+0CF1 and U+0CF2 had a derived property value change from DISALLOWED
   to PVALID while U+19DA had a change in derived property value from
   PVALID to DISALLOWED.  They were examined in great detail and IETF
   concluded that the consensus is that no update was needed to RFC 5892
   [RFC5892] based on the changes made to the Unicode standard.

   As described in Section 3, more changes have been made to code points
   between Unicode version 6.0.0 and Unicode version 12.0.0
   [Unicode-12.0.0] so that the derived property values have been
   changed in an incompatible way.  This document concludes that no
   exceptions are to be added to RFC 5892 [RFC5892] even though there
   are changes in the derived property value as a result of the changes
   made in Unicode between version 6.2.0 and 12.0.0.

   Further, in 2015, the Internet Architecture Board (IAB) issued a
   statement [IAB] which requested the IETF to resolve the issues
   related to the code point ARABIC LETTER BEH WITH HAMZA ABOVE (U+08A1)
   that was introduced in Unicode 7.0.0 [Unicode-7.0.0].  This document
   concludes that this code point is not to be added to the exception
   list either.  It should be noted that the review on U+08A1 indicated
   that it is not an isolated case and that a number of PVALID code
   points of long standing may have similar issues.  The problem
   resulted in a clarification of the review process of new Unicode
   versions RFC 8753 [RFC8753].  This clarification of the review
   process will impact review of Unicode versions after version 12.0.0.

I propose a shorter summary that I think says the same thing:

   There were three incompatible changes between Unicode 5.2.0
   [Unicode-5.2.0] and Unicode 6.0.0 [Unicode-6.0.0]; they are
   described in RFC 6452 [RFC6452].  The code points U+0CF1 and U+0CF2
   had a derived property value change from DISALLOWED to PVALID, and
   the code point U+19DA had a change in derived property value from
   PVALID to DISALLOWED.  These changes were examined in great detail,
   but the IETF concluded that these changes to the Unicode standard
   did not warrant an update to RFC 5892 [RFC5892].

   As described in Section 3, more incompatible changes have been made
   to code points between Unicode 6.0.0 and Unicode 12.0.0
   [Unicode-12.0.0]; however, the changes in the derived property values
   do not result in exceptions being added to RFC 5892 [RFC5892].

   Further, in 2015, the Internet Architecture Board (IAB) issued a
   statement [IAB] that asked the IETF to resolve the issues around
   the code point ARABIC LETTER BEH WITH HAMZA ABOVE (U+08A1) that was
   introduced in Unicode 7.0.0 [Unicode-7.0.0].  Again, no exception is
   being added to RFC 5892 [RFC5892]; however, it should be noted that
   the review of the issues around U+08A1 indicated that this code point
   is not an isolated case and that a number of PVALID code points of
   long standing may have similar issues.  The problem resulted in a
   clarification of the review process of new Unicode versions, which
   are published in RFC 8753 [RFC8753].  This clarification of the
   review process will impact the future review of Unicode versions
   beyond 12.0.0.
   
Section 2.3: s/version 3.2 of The Unicode Standard/Unicode 3.2/