Subject: [Last-Call] Opsdir last call review of draft-faltstrom-unicode12-03

From: Tim Chown via Datatracker <[email-masked]>
Date: Tue, 16 Nov 2021 05:38:26 -0800

Reviewer: Tim Chown
Review result: Has Nits

Hi,

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in last call may be included
in AD reviews during the IESG review.  Document editors and WG chairs should
treat these comments just like any other last call comments.

This document describes changes between Unicode 6.2.0 and 12.0.0 in the context
of IDNA2008.

The document is generally well-written, and is Ready for publication subject to
a small number of comments and nits, detailed below. being reviewed.

Note that I am not an expert in Unicode or IDNA2008.

General comments:

The draft discusses changes up to Unicode 12.0.0, but I see that Unicode 14.0.0
was recently published; should the changes made in those past 2 years be
included in this document?   Are they major, or minor, to readily allow this?

The draft talks about exceptions, but never explicitly says what an exception
is, to what, and what it would look like and where it would be documented.  It
would be useful for a non-expert reader to clarify this.

The draft includes several Appendix sections, but these are not mentioned in
the document.  I think the context of their inclusion should be given.

There are several sections which summarise the number of changes to characters
between specific versions.  It would be useful to include a reference to these
totals, where they are sourced from.   I found some summary numbers at
https://www.babelstone.co.uk/Unicode/HowMany.html, and I checked that the
“Assigned” totals there matched the totals for “PVALID + CONTEXTO/J and
DISALLOWED”, and these were correct against that source.  But I don’t know
where to check the CONTEXTO/J numbers; perhaps these 27 (2+25) items should be
listed in an appendix, or a specific reference given.

Comments:

In section 1, CONTEXT is explained, but the later use of CONTEXTJ and CONTEXTO
are not.  This would be useful to include.

Section 2, penultimate para, s the first use, unexplained, of CONTEXTO/J.

In Section 2, last para, maybe point forward to the security section regarding
the reason for conservatism?

In Section 3.1, changes from 6.2.0 to 7.0.0 are summarised, but in the Appendix
the difference listed is 6.3.0 to 7.0.0.  Is that intended?

Section 5, paragraph 2 it talks of future Unicode versions that might need
action, but given 14.0.0 is published now, can we say more than “might” here? 
Or do we publish this as a snapshot against 12.0.0 from two years ago?  I guess
this document’s origins were at the time of publication of 12.0.0.

Section 6 - cite the registry?

Nits:

Abstract:
“consisstent” -> “consistent”

Section 1:
Third to last para - “and IETF” -> “and the IETF”

Section 4, line 5, there’s an orphaned “(BackwardCompatible(G))”.

Section 5, “after review” -> “after the review” and “tuning. Like” -> “tuning,
like”

Section 7 - “do not” -> “does not”

Best wishes,
Tim

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 28 Nov 2021 14:52:50 +0100

> treat these comments just like any other last call comments.

Here are my comments on these.

> included in this document?   Are they major, or minor, to readily allow this?

As explained in last sentences of Section 1, review of versions after 12.0.0 is to be made according to RFC 8753, and this document ensures we can do a proper such review of versions after version 12.0.0.

  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.

> would be useful for a non-expert reader to clarify this.

Exceptions is defined in section 2.6 of RFC 5892 <https://datatracker.ietf.org/doc/html/rfc5892#section-2.6>. I think to understand this document at all, one must have read RFC 5892, or at least have some information about the algorithm defined in RFV 5892, which I do not think should be repeated in this document. YMMV.

> the document.  I think the context of their inclusion should be given.

If not the Table of Contents is enough I think I need some help. Do you mean I should add explicit references from the subsections of section 3 to the various appendices which makes things more explicit than what is in the Table of Contents?

> listed in an appendix, or a specific reference given.

All changes are listed in the Appendices.

> are not.  This would be useful to include.

See section 1 of RFC 5892. I will add a clarification as follows:

  As explained in <xref target="RFC5892">RFC
  5892</xref> CONTEXT is in turn divided into CONTEXTJ and
  CONTEXTO.

> Section 2, penultimate para, s the first use, unexplained, of CONTEXTO/J.

Changed to:

  The IDNA2008 rules use the Unicode Standard to
  create a further subset of code points and context that are
  permitted in DNS labels associated with its PVALID, and
  CONTEXT (CONTEXTJ or CONTEXTO) derived property values. DNS
  registries and other organizations that deal with IDNs are
  supposed to create their own subsets from IDNA2008 for use
  by those registries and organizations.

> the reason for conservatism?

Added paragraph at the end:

  See also the Security Considerations section in this
  document.

> the difference listed is 6.3.0 to 7.0.0.  Is that intended?

That is a problem that I obviously never resolved. In reality, this is a document that deals with Unicode from version 6.0.0 to 12.0.0. I have changed the references to be like that, recalculated all tables and values, and updated accordingly.

> this document’s origins were at the time of publication of 12.0.0.

This is a snapshot, so that we can when this is done do the proper review of 12.0.0 to 14.0.0.

> Section 6 - cite the registry?

Reference added.

> “consisstent” -> “consistent”

Fixed

> Third to last para - “and IETF” -> “and the IETF”

Fixed

> Section 4, line 5, there’s an orphaned “(BackwardCompatible(G))”.

Fixed. It was intended to be a more clear reference, but confusing...so I removed it.

> Section 5, “after review” -> “after the review” and “tuning. Like” -> “tuning,

Fixed

> Section 7 - “do not” -> “does not”

Fixed

> Best wishes,

Thanks!

   Patrik

> Tim
>
>
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: John C Klensin <[email-masked]>
Date: Sun, 28 Nov 2021 11:04:26 -0500

--On Sunday, November 28, 2021 14:52 +0100 Patrik Fältström
<paf=[email-masked]> wrote:

>> I have reviewed this document as part of the Operational
>> directorate's ongoing effort to review all IETF documents
>> being processed by the IESG.  These comments were written
>> with the intent of improving the operational aspects of the
>> IETF drafts. Comments that are not addressed in last call may
>> be included in AD reviews during the IESG review.  Document
>> editors and WG chairs should treat these comments just like
>> any other last call comments.
> 
>...

>> The draft discusses changes up to Unicode 12.0.0, but I see
>> that Unicode 14.0.0 was recently published; should the
>> changes made in those past 2 years be included in this
>> document?   Are they major, or minor, to readily allow this?
> 
> As explained in last sentences of Section 1, review of
> versions after 12.0.0 is to be made according to RFC 8753, and
> this document ensures we can do a proper such review of
> versions after version 12.0.0.
>...

Two observations, fwiw...

* I think this document is vastly improved with the recently
posted -04 version.  I'm sure that various of us (myself
included) could suggest further small improvements, but their
potential value would almost certainly be outweighed by the
advantages of just getting this finished and published,
something that almost certainly should have been done two years
ago.  As the text explains adequately, covering version-specific
issues in Section 3, this document is a catch-up job from
Unicode 6.0 in RFC 6452 (November 2011 -- a full ten years) to
Unicode 11.0.  It then incorporates a second catch-up job from
the very carefully reviewed but never published Unicode 11.0
version (draft-faltstrom-unicode11) to cover Unicode 12.0.  I
can see no way to write the document to cover that process that
would be much more clear, at least without making it far longer
(which would interfere with utility even if not with clarity).

*  While I don't think it has anything to do with whether this
document should be published, I hope the community understands
that RFC 8753 is a commitment by the IETF, reinforced by this
document, to do future reviews (including the ones to bring us
current with Unicode 14) according to the principles that were
anticipated in RFCs 5890-5894 and to do them in a timely
fashion.   For those who don't know, that original process was
partially bypassed in all of the reviews that were done between
Unicode 5.2 and the present document (inclusive).    RFC 8753
explains and clarifies that original model, including explaining
why it is important to reinstate it.  So, while I believe this
document should be published whether we have a plan going
forward or not, I hope we will soon see a plan in the very near
future so this document does not end up acting as a tombstone on
IDNA2008 reviews of changes introduced by new Unicode versions.

best,
   john

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 28 Nov 2021 17:07:48 +0100

On 28 Nov 2021, at 17:04, John C Klensin wrote:

> So, while I believe this document should be published whether we have a plan going
> forward or not, I hope we will soon see a plan in the very near future so this document does not end up acting as a tombstone on IDNA2008 reviews of changes introduced by new Unicode versions.

FWIW, this is exactly the same view as mine.

   Patrik