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