[GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 3 October 8:00 UTC

Wed Oct 9 21:11:34 UTC 2019

Hi Steve, all

Sorry for the late post. I re-read the material and have a few topics that we can use to start the discussion:

1)          Is there disagreement with the conclusions? if so, which ones and why

     *   I disagree with the report’s assertion that IDN tables could be more easily managed if IDN tables are represented in machine readable format, thus asking to consider the implementation of RFC7940 (LGR in XML format). RFC7940 is a format (like CSV, TXT) to represent something, in this case a label generation ruleset or IDN table. Registries have working implementations that do not necessarily are on XML. RFC7940 could be used to build a new registration system, but it is unpractical to think that registries will retrofit their existing systems with it.

2)          Is there additional research and analysis needed?

     *   Viability of implementing the “same entity” at the second level. The recommendation touches the surface as to how the “same entity” can be implemented at the second level and the subsequent changes needed to support other operations, like transfer and update operations, availability and RDDS queries.  I think this area needs more research and analysis to find a solution that is widely supported by registries and registrars.

3)          Do you agree with the recommendations, but think there are details or precision missing? In other words, are there gaps in the recommendations?

     *   In general agreement with the above caveats.

Talk to you tomorrow.

Best,
Dennis

From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces at icann.org> on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping at icann.org>
Reply-To: Steve Chan <steve.chan at icann.org>
Date: Wednesday, October 9, 2019 at 12:52 AM
To: Ariel Liang <ariel.liang at icann.org>, "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 3 October 8:00 UTC

Hello all,

Having not seen any discussion on list yet, this is a friendly reminder to review the email below and try and share some of your thoughts in advance of the upcoming meeting on Thursday.

Best,
Steve

From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces at icann.org> on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping at icann.org>
Reply-To: Steve Chan <steve.chan at icann.org>
Date: Friday, October 4, 2019 at 1:38 PM
To: Ariel Liang <ariel.liang at icann.org>, "gnso-council-idn-scoping at icann.org" <gnso-council-idn-scoping at icann.org>
Subject: Re: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 3 October 8:00 UTC

Thanks Ariel, all,

For the first action item, staff would like to suggest that the group concentrate on the IDN Variant TLD Implementation documentation and in particular, document number 3, which provides the recommendations, rationale, and some considerations about actions that the GNSO might need to take in the consideration of the recommendations. The collection of documents is here:  https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07-26-en and document 3 is directly available here: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-analysis-25jan19-en.pdf.

As suggested by Edmon, it would be helpful if the group starts the discussion now on list, in advance of the meeting, about these recommendations. It may be helpful to consider the recommendations from the perspective of the questions posed previously:

1)      Is there disagreement with the conclusions? if so, which ones and why
2)      Is there additional research and analysis needed?
3)      Do you agree with the recommendations, but think there are details or precision missing? In other words, are there gaps in the recommendations?

Separately, please note that the Options document has been updated (still in red-line) to try and memorialize some of the draft agreements related to the IDN Guidelines (see page 8): https://docs.google.com/document/d/1o_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5qxJlc/edit?usp=sharing.

Best,
Steve

From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces at icann.org> on behalf of Ariel Liang via gnso-council-IDN-scoping <gnso-council-idn-scoping at icann.org>
Reply-To: Ariel Liang <ariel.liang at icann.org>
Date: Friday, October 4, 2019 at 12:40 PM
To: "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 3 October 8:00 UTC

Dear All,

Please find below the action items and notes captured during the IDN Scoping Team call on Thursday, 3 October at 8:00-9: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/UIcCBw

Best Regards,
Ariel

==
ACTION ITEMS
- Staff to recirculate the relevant documents for the scoping team to review and identify which variant TLD recommendations would be appropriate to address in this potential IDN (e)PDP.
- Staff to find an alternative timeslot for a meeting on Thursday, 10 Oct (possibly day time in NA).

NOTES
- It is hard to separate the second level items clearly from the IDN variant management issues. Need to find a way to reconcile them.
- There is agreement on having one PDP and one process. If additional tasks needed to be added, it can be incorporate through charter amendment, etc.
- The root zone document is different from the IDN guidelines and the variant management recommendations document. It was not originally scoping team’s plan to discuss.
- The RZ-LGR recommendations might be relevant. If the Board accepts the RZ-LGR recommendations, and if/when a PDP is initiated for this work, future policy work related to RZ-LGR recommendations will need to be incorporated in the scope of the IDNs related PDP.
- RZ-LGR stemmed from the lack of definition of variants. Different generation panels came together to propose LGRs for the script. Right now, RZ-LGR has not been adopted. There is no policy process to make them official. RZ-LGR will produce more consistency and predictability.
- RZ-LGR is developed by the language community. The very origin is the last round of new gTLDs.
- Separate the purely technical/linguistic aspects from the tech/operational/legal aspects.
- Use an open PDP working group model, so members/experts from the ccNSO can participate.
- There is already an existing process of updating the RZ-LGR: https://www.icann.org/resources/pages/root-zone-lgr-2015-06-21-en [icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_pages_root-2Dzone-2Dlgr-2D2015-2D06-2D21-2Den&d=DwMGaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=UAy6fqdE7uFkRCc7uzN4yui8bwTtqofadZHiQEIO1vw&m=CsCu7SxRqZ9fuPIgilrVy1cUhQPQtI_VhQ-SZpoTYs4&s=1QZhoBHKgMbyplmB81mJ5AN5mD2nlmWLK5DNOqx5eUM&e=>. Should we review the LGR process at this time, focusing on its inclusiveness?
- LGR implementation process took 10 years (stemmed from an earlier PDP recommendation).
- There can be two streams of work. May not have enough volunteers to participate in the two workstreams.
- PDP 3.0 recommends making the scope of effort as lean as possible, focusing on the things that need to be done.
- Should we look at the IDN variant TLD recommendation, and see which one(s) can be a potential target for policy work? In this way, when a PDP is launched, we have a clear understanding what needs to be done.
- Include the RZ-LGR document as part of the reference document of the future PDP. The process includes a chartering group to define the scope of the PDP. Scoping team is the ‘traffic cop’?
- The expectation from the Council is that this scoping team needs to provide guidance on the actual scope of the effort. The Council will rely on the expertise and experience of the scoping team to develop the charter, hence the scoping team includes people outside the Council.
- Does RZ-LGR have enough overlap with other IDN issues? There should only be one PDP.
- It’s not necessarily about a narrow scope, but make the scope only as wide as it needs to be. It’s easy to end up with a bloated scope (see SubPro PDP).
- Don’t lump IDN issues into SubPro PDP; don’t use an expert group. Having a separate PDP is the way to go.
- SubPro is about future TLDs, and the variant TLD policy will impact existing TLDs (i.e. existing contracts).
- The difference between an EPDP and a PDP is that there is no Issue Report for an EPDP. There are several staff reports published already and they went through the community comments. The chartering process is to identify the relevant items for the EPDP. The scoping team should recommend the mechanism, but up to the Council to decide.
- Scoping team should be in the position to report to the Council during its October meeting.
- ACTION ITEM: Staff to recirculate the relevant documents for the scoping team to review and identify which variant TLD recommendations would be appropriate to address in this potential IDN (e)PDP.
- ACTION ITEM: Staff to find an alternative timeslot for a meeting on Thursday, 10 Oct (possibly day time in NA).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-council-idn-scoping/attachments/20191009/b5b49630/attachment-0001.html>