Hi Alexey,
Thanks for this note.
On Tue, Dec 4, 2018 at 8:44 AM Alexey Melnikov <alexey.melnikov@xxxxxxxxx> wrote:
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.
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.
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.
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 and 3), including BackwardCompatible (Section 2.7) (a set that is at release of this document is empty) require IETF Review, as described in RFC 5226 [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)
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
>> ietf@xxxxxxxx mailing lists by 2018-12-31. Exceptionally, comments may
>> be sent to iesg@xxxxxxxx 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.
