Re: [Gen-art] Genart last call review of draft-faltstrom-unicode12-03

[Lars Eggert <[e-mail]>]

Russ, thank you for your review. I have entered a No Objection ballot for this document.

Lars


> On 2021-10-14, at 23:36, Russ Housley via Datatracker <[e-mail]> wrote:
> 
> Reviewer: Russ Housley
> Review result: Almost Ready
> 
> 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/
> 
> 
> 
> _______________________________________________
> Gen-art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art