Subject: Re: Cancelled: Last Call: <draft-faltstrom-unicode11-05.txt> (IDNA2008 and Unicode 11.0.0) to Informational RFC

From: Alexey Melnikov <[email-masked]>
Date: Tue, 4 Dec 2018 16:42:57 +0000

Hi,

On 04/12/2018 15:24, IESG Secretary wrote:
> The Last Call on draft-faltstrom-unicode11-05 has been cancelled, and
> the document's state has been changed back to "AD Evaluation."
>
> For more information about IESG states for Internet-Drafts, please see
> <https://datatracker.ietf.org/doc/help/state/draft-iesg/>

Based on private feedback received during the first day of IETF LC I 
decided to cancel IETF LC. Two main points of this feedback:

1) Document status might be wrong, because it is updating Proposed 
Standards, while itself being Informational.

2) Suggestion to ask Internationalization Directorate (to be formed 
shortly) to review this document before proceeding further. In 
particular there were concerns that interactions with other drafts to be 
reviewed by the Directorate might require changes to this document.

Hopefully Internationalization's Directorate review can be done before 
the end of the year, so that I can restart IETF LC.

Best Regards,

Alexey

>> The IESG has received a request from an individual submitter to
>> consider the following document: - 'IDNA2008 and Unicode 11.0.0'
>>    <draft-faltstrom-unicode11-05.txt> as Informational RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solicits
>> final comments on this action. Please send substantive comments to the
>> [email-masked] mailing lists by 2018-12-31. Exceptionally, comments may
>> be sent to [email-masked] instead. In either case, please retain the
>> beginning of the Subject line to allow automated sorting.
>>
>> Abstract
>>
>>   This document describes changes between Unicode 6.3.0 and Unicode
>>   11.0.0 in the context of IDNA2008.  It further suggests for the IETF
>>   a path forward regarding ensuring IDNA2008 follows the evolution of
>>   the Unicode Standard.
>>
>>   In a few cases changes have been made in the Unicode Standard related
>>   to the algorithm IDNA2008 specifies.  IDNA2008 do give the ability to
>>   add exceptions for backward compatibility to the algorithm but the
>>   conclusions provided in this document suggests no such changes.
>>
>>   Thus this document requests that IANA update the tables to Unicode
>>   11.
>>
>>   In addition, all registries should continue the practice of
>>   calculating a repertoire using conservatism and inclusion principles.
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-faltstrom-unicode11/
>>
>> IESG discussion can be tracked via
>> https://datatracker.ietf.org/doc/draft-faltstrom-unicode11/ballot/
>>
>> No IPR declarations have been submitted directly on this I-D.

---

From: Ted Hardie <[email-masked]>
Date: Tue, 4 Dec 2018 09:19:27 -0800

Hi Alexey,

Thanks for this note.

> Standards, while itself being Informational.
Can you say what documents you believe it is updating?  The draft itself
does not contain an updates header and it is not clear to me which
documents are meant.

> the end of the year, so that I can restart IETF LC.
I would like to register my dismay that you have chosen to gate processing
this draft on finalizing the formation of a directorate.  Directorates
exist to advise Area Directors, and you are certainly welcome to seek
advice from anyone you choose on this matter.  But choosing to stop a call
for the whole IETF community to consider a draft while you seek this advice
from an unformed group seems to me to be giving primacy of an informal
system over a formal one.  Running them in parallel by having the
directorate chime in during the IETF last call would be typical; having the
same individuals who would form the directorate give the solicited reviews
during this period seems like an adequate cover for a case in which the
directorate is in formation.  Waiting until the directorate is formed
seems, in contrast, to imply a power in the directorate itself which should
not be there but should instead be in the NomCom appointed AD.

I also wish to voice my dismay with the delay.  The IAB brought the set of
concerns which motivated the suspension of expert actions to the IETF in
January of 2015 and amended in February of that year, seeking action from
the IETF to resolve the issue.  After the LUCID BoF, there was no relevant
action for more than two years.  In March of this year, the IAB asked the
expert to go ahead with his analysis, given that the lack of progress has
meant that the current system has fragmented in its use of Unicode
version.  I personally continue to believe that this fragmentation is
harmful and that delay is exacerbating a situation that is already bad.

The expert's analysis has been substantially complete since summer, and
this is a document which describes his conclusions as expert as to why the
IANA should update the tables to Unicode 11.

RFC 5892 has the following statement in its IANA considerations:

   If non-backward-compatible changes or other problems arise during the
   creation or designated expert review of the table of derived property
   values, they should be flagged for the IESG.  Changes to the rules
   (as specified in Sections 2
<https://tools.ietf.org/html/rfc5892#section-2> and 3
<https://tools.ietf.org/html/rfc5892#section-3>), including
BackwardCompatible
   (Section 2.7 <https://tools.ietf.org/html/rfc5892#section-2.7>) (a
set that is at release of this document is empty)
   require IETF Review, as described in RFC 5226
<https://tools.ietf.org/html/rfc5226> [RFC5226
<https://tools.ietf.org/html/rfc5226>].

There are no changes to the rules in this document and, while section 4.3
highlights some conditions that might fall under "other problems", it
concludes that all of the changes are either acceptable or have no effect
on the derived property.  To speak plainly, the expert could simply request
that IANA update these tables based on his analysis and be acting according
to the responsibilities given him.  That he has published and sought
feedback on his analysis is a testimony to his desire to get it right, but
that does not change the nature of this document.  It informs the IETF
community of the analysis that led to the expert's conclusion.  It does not
make any changes to the IDNA protocols; indeed Patrik carefully highlights
this in his recommendation:

   To increase overall harmonization in the use of internationalized
   domain names, the author recommends that the derived property values
   MUST be calculated as specified in the documents listed in section
   Section 3.1 also with code points in Unicode Version 11.0.0
   [Unicode-11.0.0].

I appreciate your willingness to sponsor this document and to solicit
review. But please be careful in so doing that you do not go beyond the
bounds of the IANA instructions given in the IDNA documents.  Tha could
create delays which compound a situation already fractured in ways that are
damaging the community.

best regards,

Ted Hardie
(as an individual)

---

From: S Moonesamy <[email-masked]>
Date: Tue, 04 Dec 2018 10:15:32 -0800

Hi Alexey,
At 08:42 AM 04-12-2018, Alexey Melnikov wrote:
>particular there were concerns that interactions with other drafts 
>to be reviewed by the Directorate might require changes to this document.
>
>Hopefully Internationalization's Directorate review can be done 
>before the end of the year, so that I can restart IETF LC.

I took a quick look at the draft.  It is basically about an update to 
a IANA registry.  There might be a minor issue process-wise if I am 
not mistaken.

It is unusual to cancel a Last Call because of a directorate 
review.  Sometimes one can take the "right" decision but that could 
be misperceived because of the way in which the decision is taken.

Regards,
S. Moonesamy

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 4 Dec 2018 18:22:28 +0000

Hi SM,

On 04/12/2018 18:15, S Moonesamy wrote:
>> particular there were concerns that interactions with other drafts to 
>> be reviewed by the Directorate might require changes to this document.
>>
> It is unusual to cancel a Last Call because of a directorate review.  
> Sometimes one can take the "right" decision but that could be 
> misperceived because of the way in which the decision is taken.
Wrong document status (point #1) will require another IETF LC, so I 
decided on the balance it was the right thing to do.

Best Regards,

Alexey

---

From: John C Klensin <[email-masked]>
Date: Tue, 04 Dec 2018 13:46:30 -0500

--On Tuesday, December 4, 2018 10:15 -0800 S Moonesamy
<[email-masked]> wrote:

>> Hopefully Internationalization's Directorate review can be
>> done  before the end of the year, so that I can restart IETF
>> LC.
> 
> I took a quick look at the draft.  It is basically about an
> update to a IANA registry.  There might be a minor issue
> process-wise if I am not mistaken.
> 
> review.  Sometimes one can take the "right" decision but that
> could be misperceived because of the way in which the decision
> is taken.

SM,

To supplement, Alexey's response (which I greatly appreciate,
along with the decision), if you are interested in both the
substance of the issue and why this directorate and its reviews
are a little different from the norm, please review the
discussions of the last couple of days on the IDNrp list
([email-masked]).

best,
   john

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Dec 2018 13:51:17 -0600

On Tue, Dec 04, 2018 at 04:42:57PM +0000, Alexey Melnikov wrote:
> Based on private feedback received during the first day of IETF LC I decided
> to cancel IETF LC. Two main points of this feedback:
> 

I mean, that's the sort of nit that LC can raise as needing to be fixed,
but not the sort of nit that should cause LC to fail or be cancelled.

> 2) Suggestion to ask Internationalization Directorate (to be formed shortly)
> to review this document before proceeding further. In particular there were
> concerns that interactions with other drafts to be reviewed by the
> Directorate might require changes to this document.
> 
> Hopefully Internationalization's Directorate review can be done before the
> end of the year, so that I can restart IETF LC.

Usually there is no ordering requirement between IETF LC and directorate
review (the directorates being informal advisors to the IESG).  However,
if I18N directorate does not exist yet, and that could mean that IETF LC
could complete long before the directorate review, then I think it's
quite fair to hold up the IETF LC until the directorate is up and
running.

Nico
--

---

From: S Moonesamy <[email-masked]>
Date: Tue, 04 Dec 2018 14:23:49 -0800

Hi John,
>discussions of the last couple of days on the IDNrp list

Thanks for the hint.  I am interested in the issue.

Regards,
S. Moonesamy

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 5 Dec 2018 10:53:55 +0000

> but not the sort of nit that should cause LC to fail or be cancelled.
Unfortunately, no. IETF process requires another IETF LC, if the 
document moves up the ladder (Informational -> Proposed Standard).
> quite fair to hold up the IETF LC until the directorate is up and

Indeed.

I would encourage all interested parties that are likely to end up on 
this Directorate to be quite speedy in their deliberations.

Best Regards,

Alexey