Comments on LGR Procedure Implementation ­ Maximal Starting Repertoire Version 1

[Naela Sarras <naela.sarras@xxxxxxxxx>]

Andrew Sullivan submitted the comment below on 28 March 2014. The comment
was not posted in the form via the automated posting system. Staff were
alerted to the comment by Andrew Sullivan. This submission ensures the
appropriate posting of the comment.


Submitted by ICANN staff on behalf of:
Andrew Sullivan



On 4/7/14 2:45 PM, "Andrew Sullivan" <ajs@xxxxxxxxxxxxxxxxx> wrote:
>
>----- Forwarded message from Andrew Sullivan <ajs@xxxxxxxxxxxxxxxxx> -----
>
>Date: Fri, 28 Mar 2014 12:11:36 -0400
>From: Andrew Sullivan <ajs@
><mailto:ajs@xxxxxxxxxxxxxxxxxx>xxxxxxxxxxxxxxxxx>
>To: comments-msr-03mar14@
><mailto:comments-msr-03mar14@xxxxxxxxx>xxxxxxxxxxxxxxxxx
>Subject: Comments on LGR Procedure Implementation ­ Maximal Starting
>       Repertoire Version 1
>
>Dear colleagues,
>
>I have read "Integration Panel: Maximal Starting Repertoire ‹ MSR-1
>Overview and Rationale", revision Feb 27, 2014.  Some will know that I
>was involved in the development of the ³Procedure to Develop and
>Maintain the Label Generation Rules for the Root Zone in Respect of
>IDNA Labels² (henceforth, "Procedure").  I welcome the opportunity to
>provide comments on this stage of the operation of the Procedure.
>
>First, I want to thank the Integration Panel for emphasising, as it
>does several times in the text, the nature of the MSR.  It is not, as
>the text says, in any way an implicit acceptance of any of the
>MSR-included code points into the root zone.  It is rather a point of
>departure for further work.  I am pleased that the Integration Panel
>has repeated this point, because some of the code points now included
>in the MSR may well nevertheless be excluded in the future.  This may
>result in controversies.  I exhort the Generation Panels to be as
>conservative as they possibly can be in what they request during this
>earliest operation of the Procedure.  It will always be relatively
>easy later to permit a code point that has previously been excluded.
>It will always be near impossible to exclude a code point later if it
>has been used in a delegation.
>
>Given the complicated task on the part of the Generation Panels, I
>observe that the Procedure always anticipated that any panel would be
>in a position to consult experts.  I trust that ICANN will ensure
>adequate funding to make such expertise available to any Generation
>Panel that needs it.  This is a critical part of the functioning of
>the Generation Panels in particular, because while they can reasonably
>be expected to know about particular writing system issues they cannot
>be expected to understand all the implications of a given proposal
>across writing systems or for the DNS.
>
>The MSR text on more than one occasion suggests that Generation Panels
>should discuss things with the Integration Panel.  The Procedure, it
>should be recalled, explicitly permits this sort of collaboration (in
>section B.4.3).  But that section also contains an important caveat,
>which is that the discussions should not be considered confidential
>and that the contents of such discussion should remain public.  While
>the Procedure does not contain the motivation for the caveat, I can
>report that I had two chief concerns when we were developing that
>passage.  One was that there not be a perception of possible collusion
>between the Integration Panel and any Generation Panel.  But another
>was a fear of introducing too much bias from the Integration Panel
>itself; since the Integration Panel must evaluate proposals from the
>Generation Panel, it will not do for the Integration Panel to have too
>great a hand in preparing such proposals.  It is therefore extremely
>important that, if the Integration Panel finds itself drawn into
>details of a particular proposal, it suggest that the Generation Panel
>request some relevant expert assistance.  In addition, it would be
>good to make an announcement of the mailing list where these
>communications are expected to happen, so that those interested may
>follow the conversations.
>
>I should note that I had a brief look at some of the code tables, but
>I did not perform an exhaustive check.  I'm also not sure on what
>basis I could perform such an exhaustive check, which is part of the
>reason I didn't.  It might be good to have totals in the main text
>(probably in section 2) of how many IDNA PVALID code points were
>included and excluded; in that case, a quick numeric check of minimal
>consistency would be possible.
>
>I hope these few comments are valuable.  I thank the Integration
>Panel, its consulting advisors, and the supporting ICANN staff for
>their hard work so far, and look forward to future developments in
>this area.
>
>Best regards,
>
>Andrew Sullivan
>