Page History

Versions Compared

Key

This line was added.
This line was removed.
Formatting was changed.

...

Note
Notes/ Action Items 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. 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 work streamsworkstreams. - 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. The reason the Council created this group is to be able to rely on the “expert” to scope the PDP. - 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 what items 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).

Note

Notes/ Action Items

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. 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 work streamsworkstreams.

- 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. The reason the Council created this group is to be able to rely on the “expert” to scope the PDP.

- 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 what items 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).

...

Content

Space Tools

Versions Compared

Old Version 10

New Version 11

Key