Re: [Last-Call] Genart last call review of draft-faltstrom-unicode12-03

[Patrik Fältström <[e-mail]>]

On 14 Oct 2021, at 22:36, Russ Housley via Datatracker 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

Updates done based on this review.

> 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.

Taken care of

> 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).

Taken care of

> Minor Concerns:
>
> Section 2.1:  s/4892/5892/

Ohhhh...good catch! Thanks!

> 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.

Taken care of based on other review.

> 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.

Thanks!

> Section 2.3: s/version 3.2 of The Unicode Standard/Unicode 3.2/

Done!

   Patrik