[GNSO-Council-IDN-Scoping] [Ext] Re: Actions & Notes: GNSO IDN Scoping Team Meeting on 5 December at 3:00 UTC
Edmon
edmon at registry.asia
Thu Jan 9 06:23:15 UTC 2020
Hi Maxim,
I think there seems to be a disagreement on whether the IDN Implementation Guidelines (IDNG) is already GNSO Policy.
As I mentioned earlier, because it was specifically called out in the GNSO policy recommendation in 2007 (https://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm recommendation 18), I believe the IDNG is part of an existing GNSO policy. So I do not believe it is correct to say we are putting implementation before policy.
What was not considered previously, and what has now become apparent is that how the IDNG gets updated is of importance. Therefore we are including that in Track 2.
If you disagree that IDNG itself is already part of GNSO Policy, then I can understand your logic. But I think it is not a correct understanding.
Let me suggest the following:
==============================
The team recommends two separate but interconnected work tracks to carry out the GNSO policy work related to IDN variants and IDN Implementation Guidelines (there is a minority view that the IDN Implementation Guidelines is not already GNSO policy and therefore any discussion on implementation, i.e. Operational Track 1, should only be pursued):
==============================
And then to also add the following in Page 3 right at the end of the 2nd paragraph "The guidelines were originally developed by...":
==============================
The IDN Implementation Guidelines were specifically included as Recommendation 18 in the Introduction of New Generic Top-Level Domains Final Report https://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm
==============================
Would that work for you?
Edmon
-----Original Message-----
From: Maxim Alzoba [mailto:m.alzoba at gmail.com]
Sent: Thursday, January 9, 2020 1:12 PM
To: Edmon <edmon at registry.asia>
Cc: Steve Chan <steve.chan at icann.org>; gnso-council-idn-scoping at icann.org; 'Pam Little' <pam.little at alibaba-inc.com>
Subject: RE: [GNSO-Council-IDN-Scoping] [Ext] Re: Actions & Notes: GNSO IDN Scoping Team Meeting on 5 December at 3:00 UTC
Edmon,
Do we understand why we should suggest implementation before the policy?
There is no way to properly consider the matters without a review.
If we insist that the order of the streams should be left as is, please change The team to 'some team members', and add that there is a minority view to make the implementation only after the policy work.
Maxim Alzoba
On 9 Jan 2020, 07:53, at 07:53, Edmon <edmon at registry.asia> wrote:
>Maxim,
>
>
>
>This was a discussion that started from the beginning of this group to
>now.
>
>
>
>I think I understand your argument/request, which is why Track 1 now
>basically says IF it can be resolved with staff on the issues, then IDN
>Implementation Guidelines 4.0 (IDNG4.0) can move forward. IF NOT, then
>that the work done in Track 1 will feed into Track 2. And the ICANN
>board can decide to adopt or not adopt the IDNG4.0.
>
>
>
>Upon the completion of the PDP, an IRT would be formed for the purpose
>of what you seem to consider Track 1 to be (if it is to be pushed to
>after Track 2), and also I do not believe it is appropriate to leave
>the IDNG4.0 hanging like that. Track 1 is to more expeditiously
>consider the pertinent matters of IDNG4.0 and see if we can move
>forward with it. Track 2 would, besides looking at IDN Variant TLD
>issues also consider the appropriate process for future
>revisions/updates of IDNG.
>
>
>
>I do believe there is agreement on the above...
>
>
>
>Edmon
>
>
>
>
>
>
>
>
>
>From: Maxim Alzoba [mailto:m.alzoba at gmail.com]
>Sent: Thursday, January 9, 2020 12:33 PM
>To: Steve Chan <steve.chan at icann.org>
>Cc: Edmon <edmon at registry.asia>; gnso-council-idn-scoping at icann.org;
>Pam Little <pam.little at alibaba-inc.com>
>Subject: Re: [GNSO-Council-IDN-Scoping] [Ext] Re: Actions & Notes: GNSO
>IDN Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>Hello Steve,
>
>
>
>For some reason the edits on the page 9
>
>do not reflect what I wrote in this thread
>
>
>
>An operational step can not be done before the policy work is finished
>
>(literally there is no reason for the implementation before the end of
>the policy work, to avoid revisiting the item).
>
> - it is about Operational Track 1, Policy Track step 2 approach).
>
>
>
>And there were no agreement that the way to go is the creation of CPH
>group as
>
>item one, and to say that they are to be the ones who identifies all
>overlaps of the
>
>contracts with the IDN Variants and Guidelines
>
>
>
>The RySG asked to identify the issues , not to make CPH the party
>doing so.
>
>
>
>So please make it (operational track)item 2 (implementation) , starting
>after item 1 (policy track) .
>
>
>
>I am referring to e-mail from RySG to GNSO Council (see attachment to
>https://mm.icann.org/pipermail/council/2019-April/022656.html)
>
>
>
>there is a need of identifications of all overlaps of contracts with
>guidelines,
>
>and I do not expect it to be done is a reasonable time
>
>(do we expect Registries and Registrars to look through the contracts
>without prior work
>
>on identification of those items (when RySG explicitly asked GNSO
>Council to study it to full extent?)
>
>
>
>Literally:
>
>Requests from the RySG to the GNSO Council
>
>
>
>1. Study the full extent of the impacts from the IDN Variant TLD
>Recommendations upon existing registry agreements to determine the
>appropriate expertise needed for the policy development process.
>2. Ask ICANN to provide their criteria by which IDN Tables are approved
>for implementation. RySG believes the criteria used exceeds the
>obligations on the contract (i.e. compliance to IDNA2008 and the IDN
>Guidelines) and it fails to provide a consistent and predictable path
>for service approvals.
>3. Ask ICANN Board to consider holding off on the adoption of the IDN
>Guidelines version 4 until there is a full understanding of the
>operational implementation of the “same entity” requirement on second
>level registrations, which is also a requirement under the IDN variant
>TLD Recommendations.
>
>So I am not sure sending it back to RySG with words - "you could do it
>yourself" works.
>
>
>
>I meant that Registries could have a team helping ICANN with the
>identification of how the IDN tables changed e.t.c. (internal ICANN
>processes, not RA / RAA limited)
>
>
>
>
>
>
>
>
>
>Sincerely Yours,
>
>Maxim Alzoba
>Special projects manager,
>International Relations Department,
>FAITID
>
>m. +7 916 6761580(+whatsapp)
>
>skype oldfrogger
>
>
>
>Current UTC offset: +3.00 (.Moscow)
>
>
>
>
>
>On 8 Jan 2020, at 03:30, Steve Chan via gnso-council-IDN-scoping
><gnso-council-idn-scoping at icann.org
><mailto:gnso-council-idn-scoping at icann.org> > wrote:
>
>
>
>Dear Edmon, Scoping Team Members,
>
>
>
>Staff has made suggested edits to the Options paper, creating a section
>6 for Overall Conclusions of this team; that section includes
>high-level rationale for the recommendations and references to the two
>Annexes. Naturally, these documents will serve as the basis for the
>proposed agenda for the upcoming meeting, which is:
>
>
>
>1. Welcome and roll call
>2. Review of revised and documentation
>3. Agreement on next steps (e.g., Send documentation to the GNSO
>Council for consideration during the Strategic Planning Session)
>4. AOB
>
>
>
>Best,
>
>Steve
>
>
>
>
>
>From: gnso-council-IDN-scoping
><gnso-council-idn-scoping-bounces at icann.org
><mailto:gnso-council-idn-scoping-bounces at icann.org> > on behalf of
>Edmon via gnso-council-IDN-scoping <gnso-council-idn-scoping at icann.org
><mailto:gnso-council-idn-scoping at icann.org> >
>Reply-To: Edmon <edmon at registry.asia <mailto:edmon at registry.asia> >
>Date: Monday, January 6, 2020 at 6:25 PM
>To: "gnso-council-idn-scoping at icann.org
><mailto:gnso-council-idn-scoping at icann.org> "
><gnso-council-idn-scoping at icann.org
><mailto:gnso-council-idn-scoping at icann.org> >
>Subject: Re: [GNSO-Council-IDN-Scoping] [Ext] Re: Actions & Notes: GNSO
>IDN Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>Seeing no further contention on the 2 work track approach, perhaps
>Steve & Ariel can help update the IDN TLD Variants Implementation GNSO
>Options Paper to describe the outcomes from the working group.
>
>
>
>Will anticipate for the Options document to be the main body for our
>recommendations back to the GNSO council:
>
>https://docs.google.com/document/d/1o_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5qxJlc/edit
>[docs.google.com]
><https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1o-5F9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5qxJlc_edit&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=PFP_uXhiJJroQqM72rG-tCcJg-OvVFtMyaSuOtY5EKI&s=UeliTq9vz0X8WXezwjlrMaUcf41mVfRVARjanDC2LzI&e=>
>
>
>
>
>Along with Annex A: Draft IDN Variants Issue Scoping
>
>https://docs.google.com/document/d/13tO5IP64EAnFebdefRahK3vuhIBzUEdl1oeGFBnQVc0/edit
>[docs.google.com]
><https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_13tO5IP64EAnFebdefRahK3vuhIBzUEdl1oeGFBnQVc0_edit&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=PFP_uXhiJJroQqM72rG-tCcJg-OvVFtMyaSuOtY5EKI&s=7H2zw8-mgva9CdMs8GQP-tMaA57MzRGMK-Rtg1Dyv8k&e=>
>
>
>(to be completed by Charter team)
>
>
>
>And Annex B: List of documents for IDN variant TLD work
>
>https://docs.google.com/document/d/1vhbIIpua9_3s_0G-LMNQ3hdWo8SkIxObUSpfJPk-LAQ/edit#heading=h.zf0pvgtgkt1j
>[docs.google.com]
><https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1vhbIIpua9-5F3s-5F0G-2DLMNQ3hdWo8SkIxObUSpfJPk-2DLAQ_edit-23heading-3Dh.zf0pvgtgkt1j&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=PFP_uXhiJJroQqM72rG-tCcJg-OvVFtMyaSuOtY5EKI&s=pFicHsfx7byeAJ0t4rt4XHDN_WaRte9rg1ZKFiNf6rI&e=>
>
>
>
>
>Will try to finalize the above at our meeting scheduled this week on
>Jan 9, 2020, in time for submission to the council before their f2f
>meeting.
>
>
>
>Edmon
>
>
>
>
>
>
>
>From: gnso-council-IDN-scoping
>[mailto:gnso-council-idn-scoping-bounces at icann.org] On Behalf Of Edmon
>via gnso-council-IDN-scoping
>Sent: Wednesday, December 18, 2019 11:30 AM
>To: 'Maxim Alzoba' <m.alzoba at gmail.com <mailto:m.alzoba at gmail.com> >;
>'Tan Tanaka, Dennis' <dtantanaka at verisign.com
><mailto:dtantanaka at verisign.com> >
>Cc: gnso-council-idn-scoping at icann.org
><mailto:gnso-council-idn-scoping at icann.org>
>Subject: Re: [GNSO-Council-IDN-Scoping] [Ext] Re: Actions & Notes: GNSO
>IDN Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>Thanks Keith for the detailed clarification.
>
>And thanks Dennis and Maxim for the exchange.
>
>
>
>I believe we are in agreement that future evolution of the IDN
>Implementation Guidelines should be guided by GNSO policy, for which
>should come out of the anticipated IDN PDP/EPDP.
>
>
>
>I also believe we are in agreement that the proposed IDN Implementation
>Guidelines 4.0 is in need of reconciling with the RA/RAA along with
>operational considerations, before it should be adopted by the ICANN
>board.
>
>
>
>Built on these 2 understandings, and Maxim’s clarification, perhaps an
>adjustment to the 2 work track approach as follows could work?:
>
>
>
>1. A Contracted Party working/negotiation/implementation team that
>would be focused on IDN Implementation Guidelines 4.0 operational
>issues (which includes the above and closely related to RA/RRA), to
>identify and resolve legal and operational concerns; and if found
>resolvable proceed with the guidelines 4.0, else if unresolvable, the
>work will inform work track 2 and serve as the study on impacts from
>the IDN Implementation Guidelines upon existing RA/RAA.
>
>
>
>2. A PDP/EPDP that would have a scope including both the IDN Variant
>TLD define, manage, and coordinate issues as well as the related issue
>of how the IDN Implementation Guidelines should be revised in the
>future so that it becomes a GNSO policy.
>
>
>
>Edmon
>
>
>
>
>
>
>
>PS. I note that Maxim’s quote from the RySG request talks about Impacts
>on the IDN Variant TLD recommendations and not the IDN Implementation
>Guidelines, I am not sure if it was intended, but I understand the core
>concerns on “same registrant/entity” and acceptability of IDN Tables
>(especially as it pertains to legacy formats) which it stems from. And
>thus its inclusion in 1. Above.
>
>
>
>
>
>From: Maxim Alzoba [ <mailto:m.alzoba at gmail.com>
>mailto:m.alzoba at gmail.com]
>Sent: Wednesday, December 18, 2019 1:37 AM
>To: Tan Tanaka, Dennis < <mailto:dtantanaka at verisign.com>
>dtantanaka at verisign.com>
>Cc: <mailto:edmon at registry.asia> edmon at registry.asia;
><mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org
>Subject: Re: [GNSO-Council-IDN-Scoping] [Ext] Re: Actions & Notes: GNSO
>IDN Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>Hello Dennis,
>
>
>
>to make 1. there is a need of identifications of all overlaps of
>contracts with guidelines,
>
>and I do not expect it to be done is a reasonable time
>
>(do we expect Registries and Registrars to look through the contracts
>without prior work
>
>on identification of those items (when RySG explicitly asked GNSO
>Council to study it to full extent?)
>
>
>
>Literally:
>
>Requests from the RySG to the GNSO Council
>
>
>
>1. Study the full extent of the impacts from the IDN Variant TLD
>Recommendations upon existing registry agreements to determine the
>appropriate expertise needed for the policy development process.
>2. Ask ICANN to provide their criteria by which IDN Tables are approved
>for implementation. RySG believes the criteria used exceeds the
>obligations on the contract (i.e. compliance to IDNA2008 and the IDN
>Guidelines) and it fails to provide a consistent and predictable path
>for service approvals.
>3. Ask ICANN Board to consider holding off on the adoption of the IDN
>Guidelines version 4 until there is a full understanding of the
>operational implementation of the “same entity” requirement on second
>level registrations, which is also a requirement under the IDN variant
>TLD Recommendations.
>
>So I am not sure sending it back to RySG with words - "you could do it
>yourself" works.
>
>
>
>I meant that Registries could have a team helping ICANN with the
>identification of how the IDN tables changed e.t.c. (internal ICANN
>processes, not RA / RAA limited)
>
>
>
>
>
>
>
>
>
>Sincerely Yours,
>
>Maxim Alzoba
>Special projects manager,
>International Relations Department,
>FAITID
>
>m. +7 916 6761580(+whatsapp)
>
>skype oldfrogger
>
>
>
>Current UTC offset: +3.00 (.Moscow)
>
>
>
>On 13 Dec 2019, at 22:20, Tan Tanaka, Dennis <dtantanaka at verisign.com
><mailto:dtantanaka at verisign.com> > wrote:
>
>
>
>Hi Maxim,
>
>
>
>Thanks for clarifying. Then, is it fair to state that we are
>gravitating towards the two tracks as laid out in the Dec 11 email?
>(copy below for convenience)
>
>
>
>1. A Contracted Party working/negotiation/implementation team that
>would be focused on IDN Implementation Guidelines 4.0 operational
>issues (which includes the above and closely related to RA/RRA), to
>resolve immediate issues and allow for the guidelines 4.0 to be
>adopted.
>
>
>
>2. A PDP/EPDP that would have a scope including both the IDN Variant
>TLD define, manage, and coordinate issues as well as the related issue
>of how the IDN Implementation Guidelines should be revised in the
>future so that it becomes a GNSO policy.
>
>
>
>Work Track #1 could look at those legal/operational issues you
>mentioned. I believe it would be correct for this team to provide with
>a list of items to an operational review team (I made the name up to
>avoid using implementation review team which has a definition of its
>own) who will be tasked to manage track 1.
>
>
>
>Let us know your thoughts?
>
>
>
>Best,
>
>Dennis
>
>
>
>From: Maxim Alzoba < <mailto:m.alzoba at gmail.com> m.alzoba at gmail.com>
>Date: Friday, December 13, 2019 at 12:58 PM
>To: Dennis Tan Tanaka < <mailto:dtantanaka at verisign.com>
>dtantanaka at verisign.com>
>Cc: Edmon Chung < <mailto:edmon at registry.asia> edmon at registry.asia>, "
><mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org" <
><mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org>
>Subject: [EXTERNAL] Re: [GNSO-Council-IDN-Scoping] [Ext] Re: Actions &
>Notes: GNSO IDN Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>Hello Dennis,
>
>
>
>I did not mean that,
>
>
>
>I think that they need to be used as a starting point and with addition
>of review of legal/operational issues
>
>it could turn into some meaningful implementation.
>
>
>
>I am not against the recommendation of this nature (new languages
>issues may arise, or some stability and security concerns,
>
>who knows).
>
>
>
>Sincerely Yours,
>
>Maxim Alzoba
>Special projects manager,
>International Relations Department,
>FAITID
>
>m. +7 916 6761580(+whatsapp)
>
>skype oldfrogger
>
>
>
>Current UTC offset: +3.00 (.Moscow)
>
>
>
>
>
>
>
>On 13 Dec 2019, at 19:32, Tan Tanaka, Dennis <
><mailto:dtantanaka at verisign.com> dtantanaka at verisign.com> wrote:
>
>
>
>Terminology aside, I don’t think we are in a position to dismiss the
>IDN Implementation Guidelines. But we can address the process concern
>by recommending the GNSO Council to develop a change management process
>for future versions of the document.
>
>
>
>Version 4 has some items that, in my opinion, need to be reconcile with
>the RA. So on this matter I find it acceptable that the CPH and ICANN
>work in good faith to settle those differences.
>
>
>
>Best,
>
>Dennis
>
>
>
>From: gnso-council-IDN-scoping <
><mailto:gnso-council-idn-scoping-bounces at icann.org>
>gnso-council-idn-scoping-bounces at icann.org> on behalf of Maxim Alzoba
>via gnso-council-IDN-scoping <
><mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org>
>Reply-To: Maxim Alzoba < <mailto:m.alzoba at gmail.com>
>m.alzoba at gmail.com>
>Date: Friday, December 13, 2019 at 4:13 AM
>To: Edmon Chung < <mailto:edmon at registry.asia> edmon at registry.asia>
>Cc: " <mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org" <
><mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org>
>Subject: [EXTERNAL] Re: [GNSO-Council-IDN-Scoping] [Ext] Re: Actions &
>Notes: GNSO IDN Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>Hello Edmon,
>
>
>
>there is an issue of the legal nature,
>
> with the "the acceptance of the Guidelines as Consensus Policy"
>
>
>
>only the items, which followed policy development process from GNSO
>Operating Procedures
>
>
>
>can be recognized as Consensus Policy (after all steps are properly
>finished).
>
>
>
>And IDN Guidelines do not fit it so far.
>
>
>
>P.s: An Applicant is not a Registry (please check the text of RA, it
>has nothing to do with the contents of the Application.)
>
>
>
>Sincerely Yours,
>
>Maxim Alzoba
>Special projects manager,
>International Relations Department,
>FAITID
>
>Current UTC offset: +3.00 (.Moscow)
>
>
>
>
>
>
>
>
>On 13 Dec 2019, at 11:55, Edmon via gnso-council-IDN-scoping <
><mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org> wrote:
>
>
>
>On the issue of IDN Variants allocated to the same entity, I can
>appreciate that it has operational impact, but to say that does not
>come from GNSO policy is simply not correct.
>
>
>
>The IDN Outcomes report produced within the new gTLD PDP back in 2007
>specifically describes the matter regarding 2LD registrations and IDN
>Variants. The report is incorporated into the new gTLD
>recommendations. That must be considered GNSO Policy.
><https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_drafts_idn-2Dwg-2Dfr-2D22mar07.htm&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=PFP_uXhiJJroQqM72rG-tCcJg-OvVFtMyaSuOtY5EKI&s=ey7Zh8TYjE3bc6c5TLn22C4tQ_3lHN5SsSTuKbTrCWc&e=>
>https://gnso.icann.org/en/drafts/idn-wg-fr-22mar07.htm [gnso.icann.org]
>
>
>
>================
>
>4.1.6. Limit Confusingly Similar Strings:
>
>Agreement that measures be taken to ensure that an IDN gTLD string with
>variants (see 4.1.4 and 4.1.5 above) be treated in analogy with current
>practice for IDN SLD labels, i.e. strings that only differ from an IDN
>gTLD string by variants (see above) are not available for registration
>by others.
>
>================
>
>
>
>I can understand if there may be questions raised to reconsider it, but
>there is clear GNSO Policy produced by a GNSO PDP on the matter.
>
>
>
>Likewise the acceptance of the ICANN IDN Implementation Guidelines.
>
>Included in Recommendation 18: If an applicant offers an IDN service,
>then ICANN's IDN guidelines must be followed.
>
><https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_issues_new-2Dgtlds_pdp-2Ddec05-2Dfr-2Dparta-2D08aug07.htm&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=PFP_uXhiJJroQqM72rG-tCcJg-OvVFtMyaSuOtY5EKI&s=xXdd-4-uPlF-TMFPe8G9YCo-6wOo08ixfHa40bNEImg&e=>
>https://gnso.icann.org/en/issues/new-gtlds/pdp-dec05-fr-parta-08aug07.htm
>[gnso.icann.org]
>
>
>
>So the acceptance of the Guidelines as Consensus Policy into the RA is
>not an issue in my mind. The Policy issue to be considered is only its
>update process which was what was raised.
>
>
>
>And FWIW, the original IDN Working Group that was formed was a
>representative group selected from different constituencies. If my
>memory serves me right, I was elected from the Registrars Constituency
>at that time to participate in that IDN WG which produced the first IDN
>Implementation Guidelines. Subsequent revisions were less
>representative and mostly through Expert groups.
>
>
>
>Edmon
>
>
>
>
>
>
>
>
>
>From: Maxim Alzoba [ <mailto:m.alzoba at gmail.com>
>mailto:m.alzoba at gmail.com]
>Sent: Friday, December 13, 2019 5:38 AM
>To: Tan Tanaka, Dennis < <mailto:dtantanaka at verisign.com>
>dtantanaka at verisign.com>
>Cc: <mailto:edmon at registry.asia> edmon at registry.asia
>Subject: Re: [GNSO-Council-IDN-Scoping] [Ext] Re: Actions & Notes: GNSO
>IDN Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>I will add my comments below
>
>
>
>
>
>Sincerely Yours,
>
>Maxim Alzoba
>Special projects manager,
>International Relations Department,
>FAITID
>
>Current UTC offset: +3.00 (.Moscow)
>
>
>
>
>
>
>
>
>
>On 13 Dec 2019, at 00:14, Tan Tanaka, Dennis <
><mailto:dtantanaka at verisign.com> dtantanaka at verisign.com> wrote:
>
>
>
>
>
>From: Maxim Alzoba < <mailto:m.alzoba at gmail.com> m.alzoba at gmail.com>
>
>
>
>
>
>
>
>
>Speaking of the process , when ICANN / PTI (IANA) processes new IDN
>tables (which are brought by Applicants or Registries )
>
>is an internal process of ICANN/ PTI and I am not saying that
>
>the process (where ICANN and Registries discuss this to understand the
>way do it)
>
>can be handled separately. (The same might be for the existing tables
>updates process)
>
>
>
>>> Ok. Good to know.
>
>So I do not see things preventing us from helping it to start in Feb
>2020.
>
>
>
>
>
>
>
>
>
>
>
>The "same entity" thing is going to affect the Registrants and since
>Registrants have nothing to do with the RA and Registries ,
>
>there might be a need for RAA amendment (which goes through the
>negotiation with RrSG ExCom).
>
>That is why I was referring to CPH when we discussed changes to the
>contracts.
>
>
>
>>> Agree re: contract implications. Registries might need some kind of
>policy+technical combo to enforce the same entity on registrars. And
>registrars will need to do the same for registrants. The PDP will need
>to be sensible of these relationships and how any potential PDP
>recommendations impacts to RA and RAA, right? However, this would not
>be the first time a PDP recommendation triggers a RA/RAA amendment
>(i.e. RDAP, Clear Display and Labelling) without going through CPH
>ExCom review/blessing. The policy implementation is handled by the IRT.
>
>
>
>The Amendment is triggered, but then it is in the hands of CPH (for RA
>amendment - RySG, for RAA - RrSG).
>
>(I think I might have caused some confusion here about order of things
>to start and cause other things, sorry for that).
>
>
>
>We are (CPH ExComs appointed Working Group, which is not split to
>separate WG of Registries and WG of Registrars yet,
>
>because we are discussing the common for ROs and RRs issues at the
>moment)
>
>right now in the middle of the "RDAP changes to the RA/RAA" process,
>all blessed by ExComs(both CPH), for RA,
>
>according to Art. 7.6 (v) of RA, for RAA 2013 - according to Art. 1.32
>of RAA. (I am one of the members of the group), and it is not handled
>via IRT at this stage (RA and RAA prescribe the process to amend those
>contracts and it is strictly between ICANN and respective part of CPH,
>with the public comments closer to the end of the process).
>
>
>
>As I remember CL&D implementation (published text of the first reading
>of the policy)
>
>was troubled the first time (Reconsideration request to the Board went
>to remove RDAP profile from the policy text, because it was not part of
>policy, just was added by ICANN staff),
>
>then it passed second time as a consensus policy text, which is
>obligatory for Registries and Registrars without changes to RA / RAA .
>
>
>
>According to the Charter of the RySG , GNSO Council reps. of RySG are
>part of RySG ExCom (so I am there too).
>
>
>
>
>
>
>
>
>
>
>
>It was the requirement for the same entity for all variants, which
>could not be accepted without a proper due policy development process.
>
>
>
>>>That would be one of the issues the PDP would need to deliberate. Not
>us within the scoping team.
>
>That is what I meant.
>
>
>
>
>
>
>
>
>
>
>
>P.s: for avoidance of doubt - nothing prevents us from sending a
>clarification letter to Donna
>
>(but we should mention that it is sent to RySG, not a personal opinion
>request).
>
>
>
>Sincerely Yours,
>
>Maxim Alzoba
>Special projects manager,
>International Relations Department,
>FAITID
>
>m. +7 916 6761580(+whatsapp)
>
>skype oldfrogger
>
>
>
>Current UTC offset: +3.00 (.Moscow)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>On 12 Dec 2019, at 23:16, Maxim Alzoba < <mailto:m.alzoba at gmail.com>
>m.alzoba at gmail.com> wrote:
>
>
>
>Hi Dennis,
>
>
>
>I meant that the RA Amendment is a process triggered by RySG ExCom, and
>RAA - by RrSG ExCom,
>
>and that without a proper reason it is not going to happen.
>
>
>
>I think in avoidance of doubt, the idea of 'we need to do something
>with it' is supported.
>
>
>
>GNSO Council decided to review what we have now because RySG ExCom
>asked for it.
>
>
>
>I would recommend to re-read the RySG Letter on this issue.
>
>
>
>Sincerely Yours,
>
>Maxim Alzoba
>Special projects manager,
>International Relations Department,
>FAITID
>
>m. +7 916 6761580(+whatsapp)
>
>skype oldfrogger
>
>
>
>Current UTC offset: +3.00 (.Moscow)
>
>
>
>
>
>
>
>
>
>
>On 12 Dec 2019, at 17:31, Tan Tanaka, Dennis <
><mailto:dtantanaka at verisign.com> dtantanaka at verisign.com> wrote:
>
>
>
>*** Removing Staff***
>
>
>
>I sense that there is a disconnect by way of the terms being used e.g.
>CPH.
>
>
>
>I’m not knowledgeable about the formal procedures, but the fact is
>since the RySG raised the issue about how the IDN table review and
>approval process is being handled, Staff reached out to me (and few
>others as I understand it) to work on an agreeable process. We are
>aiming to kick-off this workstream by early Feb 2020.
>
>
>
>In the last RySG call of Dec 4 I presented a summary of the facts and
>the approach the RySG should take on this matter (i.e. narrowly on IDN
>table review and approval process).
>
>
>
>I bring this up because, as far as I am aware, this is a RySG
>initiative. RrSG is not involved. To my knowledge, Donna is supportive
>of RySG pursuing this. But I’m not sure whether that is equivalent to
>say that the RySG Excom also is.
>
>
>
>My point is. RySG initiated this work because it thought it was worth
>doing. To my knowledge, there was no formal CPH ExComs process to start
>the work.
>
>
>
>Dennis
>
>
>
>From: Maxim Alzoba < <mailto:m.alzoba at gmail.com> m.alzoba at gmail.com>
>Date: Thursday, December 12, 2019 at 5:35 AM
>To: Edmon Chung < <mailto:edmon at registry.asia> edmon at registry.asia>
>Cc: Steve Chan < <mailto:steve.chan at icann.org> steve.chan at icann.org>,
>Dennis Tan Tanaka < <mailto:dtantanaka at verisign.com>
>dtantanaka at verisign.com>, " <mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org" <
><mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org>
>Subject: [EXTERNAL] Re: [GNSO-Council-IDN-Scoping] [Ext] Re: Actions &
>Notes: GNSO IDN Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>Just for clarity,
>
>
>
>The history has nothing to do with the legal obligations of parties.
>
>
>
>CPH ExComs decide what to do basing on the input (in our case not ready
>yet, and no policy to speak of) and the need to things (not much to
>speak either),
>
>not because we think that it might be a good idea.
>
>
>
>CPH Team will not be formed before the decision of CPH ExComs to do so.
>
>
>
>I do not believe that there will be anything to speak of on CPH level
>prior to the delivery of the policy work.
>
>
>
>P.s: and the reason for our group to exist is that CPH saw the
>materials provided by the previous expert group as
>
>no basis for the things to be changed yet (it is possible to check the
>transcripts of the GNSO Council meetings, where the idea was deffered).
>
>
>
>Sincerely Yours,
>
>Maxim Alzoba
>Special projects manager,
>International Relations Department,
>FAITID
>
>
>
>
>
>Current UTC offset: +3.00 (.Moscow)
>
>
>
>
>
>
>
>
>
>
>
>On 12 Dec 2019, at 13:05, Edmon < <mailto:edmon at registry.asia>
>edmon at registry.asia> wrote:
>
>
>
>
>
>The IDN Implementation Guidelines have been put in place since 2003 for
>all Contracted Parties… it was referred to and included in the GNSO
>Policy Recommendations for new gTLDs in 2007 and subsequently in the
>AGB. So it does form part of the GNSO Policies as I understand it.
>
>
>
>The IDN Implementation Guidelines have always included the
>consideration of IDN Variants, albeit in a less robust form than in
>Version 4.0. Much of the IDN Implementation Guidelines work was
>informed and motivated by the consideration of potential homograph
>concerns as well as user experience.
>
>
>
>I understand that in the future, there is interest to re look at how
>the IDN Implementation Guidelines should be reviewed and updated and
>perhaps reformatted, but based on our discussions early on, I believe
>there was agreement that we should focus on a few specific issues
>identified that needed execution corrections/clarifications for version
>4.0:
>
>1. The issue of IDN Tables and to confirm that existing LGRs can be
>used as-is
>
>2. The RA/RAA reference to the IDN Implementation Guidelines
>
>3. The acceptable implementation for allocating IDN Variants to the
>same registrant only
>
>
>
>These could be taken up by a Contracted Party house team directly with
>ICANN staff.
>
>
>
>Edmon
>
>
>
>
>
>
>
>
>
>
>
>From: Maxim Alzoba [ <mailto:m.alzoba at gmail.com>
>mailto:m.alzoba at gmail.com]
>Sent: Thursday, December 12, 2019 5:19 PM
>To: Edmon < <mailto:edmon at registry.asia> edmon at registry.asia>
>Cc: Steve Chan < <mailto:steve.chan at icann.org> steve.chan at icann.org>;
>Tan Tanaka, Dennis < <mailto:dtantanaka at verisign.com>
>dtantanaka at verisign.com>; <mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org
>Subject: Re: [GNSO-Council-IDN-Scoping] [Ext] Re: Actions & Notes: GNSO
>IDN Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>Hi Edmon,
>
>
>
>I do not see the way for the 1. until the 2. resulted in a policy (if
>guidelines extensively refer to variants which is not defined in the
>policy work).
>
>
>
>There is a strong reason for this, without due policy work we can not
>be sure we see all implications.
>
>
>
>For contracted parties where should be something more than pages of
>text that an expert group produced,
>
>and which did not have review of the legal and operational
>implications.
>
>
>
>Sincerely Yours,
>
>Maxim Alzoba
>Special projects manager,
>International Relations Department,
>FAITID
>
>m. +7 916 6761580(+whatsapp)
>
>skype oldfrogger
>
>
>
>Current UTC offset: +3.00 (.Moscow)
>
>
>
>On 12 Dec 2019, at 05:01, Edmon via gnso-council-IDN-scoping <
><mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org> wrote:
>
>
>
>On the topic of
>
>(i) potential conflicts between RA and IDN Guidelines and (ii) updating
>and evolving IDN tables
>
>Based on discussions earlier in the process, I had in my mind that we
>would be recommending 2 streams of work overall:
>
>
>
>1. A Contracted Party working/negotiation/implementation team that
>would be focused on IDN Implementation Guidelines 4.0 operational
>issues (which includes the above and closely related to RA/RRA), to
>resolve immediate issues and allow for the guidelines 4.0 to be
>adopted.
>
>
>
>2. A PDP/EPDP that would have a scope including both the IDN Variant
>TLD define, manage, and coordinate issues as well as the related issue
>of how the IDN Implementation Guidelines should be revised in the
>future so that it becomes a GNSO policy.
>
>
>
>Does this reconcile with other’s recollection and does this direction
>work?
>
>
>
>Edmon
>
>
>
>
>
>From: Steve Chan [ <mailto:steve.chan at icann.org>
>mailto:steve.chan at icann.org]
>Sent: Thursday, December 12, 2019 6:58 AM
>To: Tan Tanaka, Dennis < <mailto:dtantanaka at verisign.com>
>dtantanaka at verisign.com>; <mailto:edmon at registry.asia>
>edmon at registry.asia; <mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org
>Subject: Re: [Ext] Re: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO
>IDN Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>Hi Dennis, Maxim, all,
>
>
>
>Dennis great point - if you take a look at the agenda, you’ll see item
>3 is about next steps. One of the likely items for discussion here is
>how the two documents generated by this group fit together. I believe
>Edmon mentioned that his initial thought is that the options paper,
>which describes the operational issues you note below, would serve as
>the main document and then the scoping document recently discussed
>would serve as more of an Annex, providing evidence of the background
>materials and issue analysis already conducted and available.
>
>
>
>Maxim, the things you mention sound more like substantive discussions
>that would take place during policy development. Based on my
>understanding and using one of your concerns as an example, the remit
>of this scoping team would be to identify if the “same entity”
>recommendations and the impacts on other elements (like RPMs) should be
>examined during policy development, but not to delve into the substance
>of the issue nor consider solutions.
>
>
>
>Best,
>
>Steve
>
>
>
>
>
>From: "Tan Tanaka, Dennis" < <mailto:dtantanaka at verisign.com>
>dtantanaka at verisign.com>
>Date: Wednesday, December 11, 2019 at 2:32 PM
>To: " <mailto:edmon at registry.asia> edmon at registry.asia" <
><mailto:edmon at registry.asia> edmon at registry.asia>, Steve Chan <
><mailto:steve.chan at icann.org> steve.chan at icann.org>, "
><mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org" <
><mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org>
>Subject: [Ext] Re: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN
>Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>Edmon, Steve, et al
>
>
>
>I made a few comments in the Issue Scoping doc; mainly about
>elaborating on the IDN Guidelines issue and incorporating it in the
>“Objectives of a possible EPDP”.
>
>
>
>The below email discusses the policy issues but I’d like to see a
>discussion on the operational issues as well: (i) potential conflicts
>between RA and IDN Guidelines and (ii) updating and evolving IDN
>tables. Perhaps this is coming after we wrap up the policy issues?
>
>
>
>Thanks,
>Dennis
>
>
>
>From: gnso-council-IDN-scoping <
><mailto:gnso-council-idn-scoping-bounces at icann.org>
>gnso-council-idn-scoping-bounces at icann.org> on behalf of Edmon via
>gnso-council-IDN-scoping < <mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org>
>Reply-To: Edmon Chung < <mailto:edmon at registry.asia>
>edmon at registry.asia>
>Date: Tuesday, December 10, 2019 at 6:19 PM
>To: 'Steve Chan' < <mailto:steve.chan at icann.org> steve.chan at icann.org>,
>" <mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org" <
><mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org>
>Subject: [EXTERNAL] Re: [GNSO-Council-IDN-Scoping] Actions & Notes:
>GNSO IDN Scoping Team Meeting on 5 December at 3:00 UTC
>
>
>
>Thanks Steve.
>
>
>
>It seems clear at this point we should recommend for the matters to
>proceed in a separate PDP and not added to existing PDPs.
>
>
>
>One of the important decisions the group needs to make though, is
>whether to recommend to the GNSO Council:
>
>A) A regular PDP, for which an Issues Report needs to be developed
>
>B) An EPDP, for which the only difference from a PDP is a further
>Issues Report is not required
>
>
>
>Given the volume of background information already produced for the
>topic, as well as the rough draft which staff has drawn up, which
>includes the issues (1) as well as the listing of the background
>documents (2):
>
>1.
><https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_13tO5IP64EAnFebdefRahK3vuhIBzUEdl1oeGFBnQVc0_edit-3Fusp-3Dsharing&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=TmpD2MRoV4cj8fKRKGW6fDvb6ZbXB4F2G3snz7xXb-M&s=fgxQh75BEq114Es6f2ywBJSU5OOKfYkfbQB_aUxuorw&e=>
>https://docs.google.com/document/d/13tO5IP64EAnFebdefRahK3vuhIBzUEdl1oeGFBnQVc0/edit?usp=sharing
>[docs.google.com]
>
>2.
><https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1vhbIIpua9-5F3s-5F0G-2DLMNQ3hdWo8SkIxObUSpfJPk-2DLAQ_edit-3Fusp-3Dsharing&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=TmpD2MRoV4cj8fKRKGW6fDvb6ZbXB4F2G3snz7xXb-M&s=rz94O144cTITtmkix4zMJZgOgf9qUACAbfZOXgZc19s&e=>
>https://docs.google.com/document/d/1vhbIIpua9_3s_0G-LMNQ3hdWo8SkIxObUSpfJPk-LAQ/edit?usp=sharing
>[docs.google.com]
>
>
>
>It appears that an EPDP is the appropriate approach because there is
>ample background information on the subject and there does not seem to
>be any clear gaps requiring an Issues report.
>
>
>
>I understand that Maxim has raised concerns about EPDP, but that seems
>to stem from the emotional aftermath of how the EPDP in response to
>GDPR was created more than the actual requirement (i.e. of the Issues
>Report). If there are any other concerns or objections to proceeding
>with EPDP please raise them.
>
>
>
>If we do move forward to recommend an EPDP approach, the chartering
>team can determine the structure and membership of the EPDP working
>group and complete the IDN Variant Issues Scoping (1. Above) which
>would form essentially an issues report for the working group
>consideration.
>
>
>
>Please take a look and we hope to come to conclusion on the matter so
>we can make the recommendation to the council before its meeting in
>January.
>
>
>
>Edmon
>
>
>
>
>
>
>
>From: gnso-council-IDN-scoping [
><mailto:gnso-council-idn-scoping-bounces at icann.org>
>mailto:gnso-council-idn-scoping-bounces at icann.org] On Behalf Of Steve
>Chan via gnso-council-IDN-scoping
>Sent: Saturday, December 7, 2019 4:02 AM
>To: <mailto:gnso-council-idn-scoping at icann.org>
>gnso-council-idn-scoping at icann.org
>Subject: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping
>Team Meeting on 5 December at 3:00 UTC
>
>
>
>Dear Team,
>
>
>
>With apologies for the late delivery, please find below the action
>items and notes captured during the IDN Scoping Team call on Thursday,
>5 December at 3:00 UTC.
>
>
>
>Staff has posted to the wiki space the action items and notes. Please
>note that these are high-level notes and are not meant as a substitute
>for the recording and chat room records, which are posted on the wiki
>at: <https://community.icann.org/x/z5czBw>
>https://community.icann.org/x/z5czBw
>
>
>
>
>
>Best,
>
>Steve
>
>
>
>==
>
>Action Item
>
>- Staff to add SAC060 and SAC052 to the list of documents
>
>- Edmon to determine if he feels like he can make an assessment as to
>which Option the scoping team supports to recommend to the GNSO
>Council. If he is able, he will provide his assessment to the email
>list for input.
>
>
>
>
>
>NOTES
>
>1. Welcome and roll call
>
>
>
>- Edmon may need to leave meeting early
>
>- Update on coordination with the SubPro PDP – SubPro leadership does
>not believe that the IDN work must take place in SubPro. If an IDN
>variants PDP is launched, it can further the related work done in
>SubPro and build upon it.
>
>- Edmon has review the SubPro draft recs and they indeed seem like they
>can be built upon rather than needing to be overturned.
>
>- SubPro may want to consider the technical utilization paper for the
>RZ-LGR, currently under Board consideration, but they should be aware
>that it’s a fluid situation of they indeed review the document now.
>
>- GNSO policies can be replaced by policy development taking place at a
>later date, so a new PDP on IDN variants could in theory develop
>recommendations that go against the SubPro recommendations on IDN
>variants.
>
>
>
>2. Review of new Issue Scoping Document here:
><https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_13tO5IP64EAnFebdefRahK3vuhIBzUEdl1oeGFBnQVc0_edit-3Fusp-3Dsharing&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=TmpD2MRoV4cj8fKRKGW6fDvb6ZbXB4F2G3snz7xXb-M&s=fgxQh75BEq114Es6f2ywBJSU5OOKfYkfbQB_aUxuorw&e=>
>https://docs.google.com/document/d/13tO5IP64EAnFebdefRahK3vuhIBzUEdl1oeGFBnQVc0/edit?usp=sharing
>[docs.google.com]
>
>
>
>- Purpose of this document is to explore whether or not there is
>sufficient background documentation and analysis to serve as a proxy
>for an Issue Report, which could make an EPDP make some sense
>
>- There is also the existing work on IDN variants taking place in
>SubPro
>
>- Document is structured similarly to the substantive part of an Issue
>Report and make sure that all of the required elements are present.
>
>- First part is about identifying the problems that need to be solved,
>which in this case come from the Board resolution (e.g., RZ-LGR must be
>the only source and that policies should be developed to manage IDN
>variant TLDs for current and future gTLDs).
>
>- Also notes that coordination with ccNSO is needed and GNSO concerns
>about the process by which the IDN Guidelines are updated from version
>to version.
>
>- Second section identifies the list of relevant documentation. There
>is also, by reference, a comprehensive list of documents related to IDN
>variants.
>
>
>
>ACTION – Add SAC060 and SAC052 to the list of documents
>
>
>
>- The list is not intended to limit what a PDP may consider, in the
>event something relevant arises later.
>
>- Third part of the document is about the issues and questions a PDP
>should consider and address. Firstly, broken down into the two
>challenges. Lists out the recommendations from the staff report.
>
>- Also lists out questions from the staff report where there may be
>policy implications. This list is captured verbatim from the staff
>paper.
>
>- The Council did not specifically request a charter from the IDN
>Scoping team
>
>- There was not a specific time frame dictated by the Council, but
>there is an expectation that the scoping team will provide its
>recommendations prior to the end of the year. Concerns expressed from
>Maxim about the time constraint.
>
>
>
>3. After discussing agenda item 2, revisiting the options paper:
><https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_1o-5F9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5qxJlc_edit-3Fusp-3Dsharing&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=PFP_uXhiJJroQqM72rG-tCcJg-OvVFtMyaSuOtY5EKI&s=q-wMvlBvsinw-HK4q6rpegNsgb4soBl-hhrA_QBBAI4&e=>
>https://docs.google.com/document/d/1o_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5qxJlc/edit?usp=sharing
>[docs.google.com]
>
>
>
>- In light of the previous discussion about what could be in an issue
>report, based on existing materials and analysis, what option makes the
>most sense?
>
>- Option A is to leverage existing PDPs (i.e., SubPro and RPMs), Option
>B is to separate new gTLDs versus existing gTLDs, Option C is a PDP or
>EPDP, Option D is an expert working group.
>
>- Maxim indicates that there is not support from the entire group to
>for an EPDP, suggestion that he should indicate why he oppose, what he
>prefers, and why. Also indicates that GNSO should not feel obligated to
>follow pace of ccNSO.
>
>
>
>ACTION – Edmon to determine if he feels like he can make an assessment
>as to which Option the scoping team supports to recommend to the GNSO
>Council. If he is able, he will provide his assessment to the email
>list for input.
>
>
>
>- Maxim notes that some believe that the set of documents is not
>holistic and that further analysis is needed.
>
>
>
>4. Possible next steps
>
>
>
>- None, discussed above
>
>
>
>5. AOB
>
>
>
>- None
>
>
>
>Steven Chan
>
>
>Policy Director, GNSO Support
>
>
>
>Internet Corporation for Assigned Names and Numbers (ICANN)
>
>12025 Waterfront Drive, Suite 300
>
>Los Angeles, CA 90094-2536
>
>
>
>
>Email: <mailto:steve.chan at icann.org> steve.chan at icann.org
>
>Skype: steve.chan55
>
>Mobile: +1.310.339.4410
>
>
>
>Find out more about the GNSO by visiting:
><https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=o7Auz997kA-HPv9PHJCjFVZw7Pgo8krw4MxfqCwBrIU&e=>
>https://learn.icann.org/
>
>Follow @GNSO on Twitter:
><https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGNSO&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=kWw4fQPNjw2lVKy1UjTxS2F0BmjEAzaDFWNmsYywbmE&e=>
>https://twitter.com/ICANN_GNSO
>
>Transcripts and recordings of GNSO Working Group and Council events are
>located on the
><https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_group-2Dactivities_calendar&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=DRa2dXAvSFpCIgmkXhFzL7ar9Qfqa0AIgn-H4xR2EBk&m=jLNFXvpu9gNdUeHi-G6sjWNCF9w4_AwhzzUDFZy2elE&s=-L6chFfv0OperrXHHpTF722WnH3FZIutn4cS16IvpOg&e=>
>GNSO Master Calendar
>
>_______________________________________________
>gnso-council-IDN-scoping mailing list
><mailto:gnso-council-IDN-scoping at icann.org>
>gnso-council-IDN-scoping at icann.org
><https://mm.icann.org/mailman/listinfo/gnso-council-idn-scoping>
>https://mm.icann.org/mailman/listinfo/gnso-council-idn-scoping
>
>_______________________________________________
>By submitting your personal data, you consent to the processing of your
>personal data for purposes of subscribing to this mailing list
>accordance with the ICANN Privacy Policy (
><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=PFP_uXhiJJroQqM72rG-tCcJg-OvVFtMyaSuOtY5EKI&s=XHXuHJPtbGjh_zdYhVt01OORIhX7sFvDYlaB-sS89Tk&e=>
>https://www.icann.org/privacy/policy [icann.org]) and the website Terms
>of Service (
><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=PFP_uXhiJJroQqM72rG-tCcJg-OvVFtMyaSuOtY5EKI&s=Dr3Nzj5b_RxajwXFwVMZ52xWzsTYEMyr_J5oUWwx3yM&e=>
>https://www.icann.org/privacy/tos [icann.org]). You can visit the
>Mailman link above to change your membership status or configuration,
>including unsubscribing, setting digest-style delivery or disabling
>delivery altogether (e.g., for a vacation), and so on.
>
>
>
>_______________________________________________
>gnso-council-IDN-scoping mailing list
><mailto:gnso-council-IDN-scoping at icann.org>
>gnso-council-IDN-scoping at icann.org
><https://mm.icann.org/mailman/listinfo/gnso-council-idn-scoping>
>https://mm.icann.org/mailman/listinfo/gnso-council-idn-scoping
>
>_______________________________________________
>By submitting your personal data, you consent to the processing of your
>personal data for purposes of subscribing to this mailing list
>accordance with the ICANN Privacy Policy (
><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_policy&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=PFP_uXhiJJroQqM72rG-tCcJg-OvVFtMyaSuOtY5EKI&s=XHXuHJPtbGjh_zdYhVt01OORIhX7sFvDYlaB-sS89Tk&e=>
>https://www.icann.org/privacy/policy [icann.org]) and the website Terms
>of Service (
><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_privacy_tos&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=PFP_uXhiJJroQqM72rG-tCcJg-OvVFtMyaSuOtY5EKI&s=Dr3Nzj5b_RxajwXFwVMZ52xWzsTYEMyr_J5oUWwx3yM&e=>
>https://www.icann.org/privacy/tos [icann.org]). You can visit the
>Mailman link above to change your membership status or configuration,
>including unsubscribing, setting digest-style delivery or disabling
>delivery altogether (e.g., for a vacation), and so on.
>
>
>
>_______________________________________________
>gnso-council-IDN-scoping mailing list
>gnso-council-IDN-scoping at icann.org
><mailto:gnso-council-IDN-scoping at icann.org>
>https://mm.icann.org/mailman/listinfo/gnso-council-idn-scoping
>
>_______________________________________________
>By submitting your personal data, you consent to the processing of your
>personal data for purposes of subscribing to this mailing list
>accordance with the ICANN Privacy Policy
>(https://www.icann.org/privacy/policy) and the website Terms of Service
>(https://www.icann.org/privacy/tos). You can visit the Mailman link
>above to change your membership status or configuration, including
>unsubscribing, setting digest-style delivery or disabling delivery
>altogether (e.g., for a vacation), and so on.
More information about the gnso-council-IDN-scoping
mailing list