Re: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 3 October 8:00 UTC
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@icann.org> on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org> Reply-To: Steve Chan <steve.chan@icann.org> Date: Wednesday, October 9, 2019 at 12:52 AM To: Ariel Liang <ariel.liang@icann.org>, "gnso-council-idn-scoping@icann.org" <gnso-council-idn-scoping@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@icann.org> on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org> Reply-To: Steve Chan <steve.chan@icann.org> Date: Friday, October 4, 2019 at 1:38 PM To: Ariel Liang <ariel.liang@icann.org>, "gnso-council-idn-scoping@icann.org" <gnso-council-idn-scoping@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... and document 3 is directly available here: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-.... 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_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5qx.... Best, Steve From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces@icann.org> on behalf of Ariel Liang via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org> Reply-To: Ariel Liang <ariel.liang@icann.org> Date: Friday, October 4, 2019 at 12:40 PM To: "gnso-council-idn-scoping@icann.org" <gnso-council-idn-scoping@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...>. 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).
I agree with Dennis, Would like to add to 2) In addition to operational and technical concerns for "same entity" there are legal concerns, such as, but not limited to (two TMs having rights for strings, which are seen as a variants to each other, existing owners, who have such couples of strings , e.t.c, potential need to update URS and UDRP... Maxim Alzoba On 10 Oct 2019, 00:11, at 00:11, "Tan Tanaka, Dennis via gnso-council-IDN-scoping" <gnso-council-idn-scoping@icann.org> wrote:
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@icann.org> on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org> Reply-To: Steve Chan <steve.chan@icann.org> Date: Wednesday, October 9, 2019 at 12:52 AM To: Ariel Liang <ariel.liang@icann.org>, "gnso-council-idn-scoping@icann.org" <gnso-council-idn-scoping@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@icann.org> on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org> Reply-To: Steve Chan <steve.chan@icann.org> Date: Friday, October 4, 2019 at 1:38 PM To: Ariel Liang <ariel.liang@icann.org>, "gnso-council-idn-scoping@icann.org" <gnso-council-idn-scoping@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... and document 3 is directly available here: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-....
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_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5qx....
Best, Steve
From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces@icann.org> on behalf of Ariel Liang via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org> Reply-To: Ariel Liang <ariel.liang@icann.org> Date: Friday, October 4, 2019 at 12:40 PM To: "gnso-council-idn-scoping@icann.org" <gnso-council-idn-scoping@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...>. 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).
------------------------------------------------------------------------
_______________________________________________ gnso-council-IDN-scoping mailing list gnso-council-IDN-scoping@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.
Is this “research” envisioned to be “external experts”? or do we think we can achieve this with the discussions within a GNSO PDP? Looking at the topic, I feel it maybe the latter? In other words, my question is while these set of recommendations/documents from staff are good input to the PDP, the outcomes of the PDP does not have to affirm the recommendations. In fact we may well disagree with some of them and recommend as GNSO Policy otherwise? Edmon From: gnso-council-IDN-scoping [mailto:gnso-council-idn-scoping-bounces@icann.org] On Behalf Of Maxim Alzoba via gnso-council-IDN-scoping Sent: Thursday, October 10, 2019 6:36 AM To: Tan Tanaka, Dennis <dtantanaka@verisign.com>; gnso-council-idn-scoping@icann.org Subject: Re: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 3 October 8:00 UTC I agree with Dennis, Would like to add to 2) In addition to operational and technical concerns for "same entity" there are legal concerns, such as, but not limited to (two TMs having rights for strings, which are seen as a variants to each other, existing owners, who have such couples of strings , e.t.c, potential need to update URS and UDRP... Maxim Alzoba On 10 Oct 2019, at 00:11, "Tan Tanaka, Dennis via gnso-council-IDN-scoping" <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org> > wrote: 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 a. 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? a. 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? a. In general agreement with the above caveats. Talk to you tomorrow. Best, Dennis From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces@icann.org <mailto:gnso-council-idn-scoping-bounces@icann.org> > on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org> > Reply-To: Steve Chan <steve.chan@icann.org <mailto:steve.chan@icann.org> > Date: Wednesday, October 9, 2019 at 12:52 AM To: Ariel Liang <ariel.liang@icann.org <mailto:ariel.liang@icann.org> >, "gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org> " <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@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@icann.org <mailto:gnso-council-idn-scoping-bounces@icann.org> > on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org> > Reply-To: Steve Chan <steve.chan@icann.org <mailto:steve.chan@icann.org> > Date: Friday, October 4, 2019 at 1:38 PM To: Ariel Liang <ariel.liang@icann.org <mailto:ariel.liang@icann.org> >, "gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org> " <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@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... and document 3 is directly available here: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-.... 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_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5qx.... Best, Steve From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces@icann.org <mailto:gnso-council-idn-scoping-bounces@icann.org> > on behalf of Ariel Liang via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org> > Reply-To: Ariel Liang <ariel.liang@icann.org <mailto:ariel.liang@icann.org> > Date: Friday, October 4, 2019 at 12:40 PM To: "gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org> " <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@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...> . 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). _____ gnso-council-IDN-scoping mailing list gnso-council-IDN-scoping@icann.org <mailto:gnso-council-IDN-scoping@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.
Hello Edmon, if we intend to make / change GNSO policy it is a PDP. Sincerely Yours, Maxim Alzoba Special projects manager, International Relations Department, FAITID Current UTC offset: +3.00 (.Moscow)
On 10 Oct 2019, at 05:07, Edmon via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org> wrote:
Is this “research” envisioned to be “external experts”? or do we think we can achieve this with the discussions within a GNSO PDP? Looking at the topic, I feel it maybe the latter? In other words, my question is while these set of recommendations/documents from staff are good input to the PDP, the outcomes of the PDP does not have to affirm the recommendations. In fact we may well disagree with some of them and recommend as GNSO Policy otherwise? Edmon
From: gnso-council-IDN-scoping [mailto:gnso-council-idn-scoping-bounces@icann.org <mailto:gnso-council-idn-scoping-bounces@icann.org>] On Behalf Of Maxim Alzoba via gnso-council-IDN-scoping Sent: Thursday, October 10, 2019 6:36 AM To: Tan Tanaka, Dennis <dtantanaka@verisign.com <mailto:dtantanaka@verisign.com>>; gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org> Subject: Re: [GNSO-Council-IDN-Scoping] Actions & Notes: GNSO IDN Scoping Team Meeting 3 October 8:00 UTC
I agree with Dennis,
Would like to add to 2) In addition to operational and technical concerns for "same entity" there are legal concerns, such as, but not limited to (two TMs having rights for strings, which are seen as a variants to each other, existing owners, who have such couples of strings , e.t.c, potential need to update URS and UDRP...
Maxim Alzoba On 10 Oct 2019, at 00:11, "Tan Tanaka, Dennis via gnso-council-IDN-scoping" <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org>> wrote:
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 a. 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? a. 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? a. In general agreement with the above caveats.
Talk to you tomorrow.
Best, Dennis
From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces@icann.org <mailto:gnso-council-idn-scoping-bounces@icann.org>> on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org>> Reply-To: Steve Chan <steve.chan@icann.org <mailto:steve.chan@icann.org>> Date: Wednesday, October 9, 2019 at 12:52 AM To: Ariel Liang <ariel.liang@icann.org <mailto:ariel.liang@icann.org>>, "gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org>" <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@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@icann.org <mailto:gnso-council-idn-scoping-bounces@icann.org>> on behalf of Steve Chan via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org>> Reply-To: Steve Chan <steve.chan@icann.org <mailto:steve.chan@icann.org>> Date: Friday, October 4, 2019 at 1:38 PM To: Ariel Liang <ariel.liang@icann.org <mailto:ariel.liang@icann.org>>, "gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org>" <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@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... <https://www.icann.org/resources/pages/idn-variant-tld-implementation-2018-07...> and document 3 is directly available here: https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-... <https://www.icann.org/en/system/files/files/idn-variant-tld-recommendations-...>.
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_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5qx... <https://docs.google.com/document/d/1o_9bfnkKufrSxiJGxpNcOcfTK2VLWp5XYQvwe5qx...>.
Best, Steve
From: gnso-council-IDN-scoping <gnso-council-idn-scoping-bounces@icann.org <mailto:gnso-council-idn-scoping-bounces@icann.org>> on behalf of Ariel Liang via gnso-council-IDN-scoping <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org>> Reply-To: Ariel Liang <ariel.liang@icann.org <mailto:ariel.liang@icann.org>> Date: Friday, October 4, 2019 at 12:40 PM To: "gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@icann.org>" <gnso-council-idn-scoping@icann.org <mailto:gnso-council-idn-scoping@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 <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...>. 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).
gnso-council-IDN-scoping mailing list gnso-council-IDN-scoping@icann.org <mailto:gnso-council-IDN-scoping@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://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
gnso-council-IDN-scoping mailing list gnso-council-IDN-scoping@icann.org <mailto:gnso-council-IDN-scoping@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://www.icann.org/privacy/policy <https://www.icann.org/privacy/policy>) and the website Terms of Service (https://www.icann.org/privacy/tos <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.
participants (3)
-
Edmon -
Maxim Alzoba -
Tan Tanaka, Dennis