Hello team, I had a few minutes this morning to go through the homework (thanks Caitlin and Berry for providing clear notes and action items!) 1. Wave 1 deliverable - Section 3.11 looks good to me, I didn't see anything missing or incorrect  2. Issue Scoping doc - Specific Transfer Policy changes suggested in the TechOpsdoc should be called out on the Scoping doc. Most of it is already there (e.g. section 2, "Should the transfer check of the Losing Registrar be mandatory or optional?", this is covered under Losing FOA; or the TechOps suggestion of a fast reverse transfer process but also time to validate the request I think will be handled both under Reverse FOA and TEAC and maybe TDRP discussions),or it's operational changes that shouldn't be in the scoping doc (the "flow" sections). That said, one gap on the Scoping doc was potential changes to authcode handling  (who is authoritative, what is the TTL, etc). This seems to me like a big enough deal that it should have its own row on the Scoping doc, so I've added it near the bottom. Thanks, -- Sarah Wyld Domains Product Team Tucows +1.416 535 0123 Ext. 1392 On 2/27/2020 12:42 PM, Caitlin Tubergen wrote:

Dear Colleagues:

 

Please find below the notes and action items from today’s Transfer Policy Review Scoping Team meeting.

 

As a reminder, the next meeting will be *Thursday, 19 March *at 16:00 UTC. Support Staff will send calendar invites shortly.

 

Best regards,

 

Berry and Caitlin

* *

*Transfer Policy Review Scoping Team Meeting #5*

*Thursday, 27 February 2020 *

*16:00 UTC*

 

_Action Items_

1. Team Members to review section 3.11 of the ICANN Org Rec. 27 Wave 1 deliverable <https://gnso.icann.org/en/drafts/epdp-phase-1-recommendation-27-18feb20-en.p...> in detail by *_Thursday, 5 March_*. Specifically, Team members should provide feedback if they support or do not support section 3.11. 2. In reviewing the Collaborative Issue Scoping Document <https://docs.google.com/document/d/1HXDmFuxSM6smWGga_Kc13bk2NYNsHlcQNm58S-0A...>, Team to ensure: (1) the document is comprehensive; (2) relevant dependencies are identified; (3) urgency levels are identified; (4) whether the Team is recommending a “start from scratch” or “update the existing policy using the issues identified” by *_Thursday, 5 March_*. 3. Following Team’s updates to the Collaborative Issue Scoping Document <https://docs.google.com/document/d/1HXDmFuxSM6smWGga_Kc13bk2NYNsHlcQNm58S-0A...>, Support Staff to update the Draft GNSO Scoping Document <https://docs.google.com/document/d/1sXxp5TsUskcrW444D6lYCLy6YX99Wyus/edit> by *_Monday, 9 March_*. Support Staff to remove previous references to EPDP, as the Team is no longer suggesting to move forward with an EPDP on Gaining Registrar FOAs. 4. Support Staff to draft and circulate a draft GNSO Council resolution, which would acknowledge the Scoping Team’s proposal to the Council and authorize ICANN org to start an Issues Report by *_Thursday, 26 March._* 5. Beginning on Monday, 9 March, Team Members to review the Draft GNSO Scoping Document and provide proposed edits (in suggestion mode only) by *_Thursday, 19 March_.*

 

 

*_Agenda_*

1. Roll Call & SOI Updates  2. Discussion of ICANN org Rec. 27 deliverable

1. Background: this document represents ICANN Org’s Wave 1 deliverable <https://gnso.icann.org/en/drafts/epdp-phase-1-recommendation-27-18feb20-en.p...> and identifies elements of Consensus Policies that will be affected as a result of EPDP implementation, e.g., elimination of the administrative field results in a change to the definition of Transfer Contact under the Transfer Policy

·         The EPDP Phase 1 Team recommended a survey of all existing consensus policies and the Wave 1 deliverable represents ICANN org staff’s in depth review of how the Phase 1 recommendations affect current ICANN consensus policies. 

·         It is important that the TPRST read through this document.

·         Most issues identified in this report are already identified by this group in its scoping document, but this report dives into more specific detail.

·         This report also classifies the changes to the the Transfer Policy as HIGH impact, which is helpful for the Council’s prioritization exercise. Specifically, this shows why it is important for future Transfer Policy work to be addressed, as the Temp Spec and New Reg Data policy renders the Transfer Policy a “broken” consensus policy.

                        TPRST reaction:

* Action: TPRST to review section 3.11 of the ICANN Org Rec. 27 Wave 1 deliverable <https://gnso.icann.org/en/drafts/epdp-phase-1-recommendation-27-18feb20-en.p...> in detail by Thursday, 5 March. Specifically, Team members should provide feedback if they support or do not support section 3.11 * Leadership and Support Staff foresee this Team to meet two more times (19 March and 26 March).

2. Agree on next steps

4.                  Discuss path to completion of recommendation to GNSO Council

2. Has the Scoping Team had sufficient time to identify Transfer Policy issues that need further policy work?

c.                   Reference docs:

1. Collaborative Issue Scoping Document <https://docs.google.com/document/d/1HXDmFuxSM6smWGga_Kc13bk2NYNsHlcQNm58S-0A...> 2. Suggested model for how to proceed <https://docs.google.com/spreadsheets/d/1SkPzufLyU0Z8gbJdxsnF76EHanq7DZyt32Ko...> 3. Draft GNSO Scoping Document <https://docs.google.com/document/d/1sXxp5TsUskcrW444D6lYCLy6YX99Wyus/edit>

* It seems that the group sees an advantage in multiple PDPs. * The GNSO Council will ultimately make the decision of how to proceed with the work.  * The document still lists EPDP for the FOA issue, so this should be updated based on the group’s previous discussion that in light of the recent board resolution, the FOA issue does not need to go through an EPDP. For a normal PDP, ICANN staff would develop an Issues Report that would be reviewed by the GNSO Council. * As part of this Team’s deliverable to the GNSO Council, Support Staff’s suggestion would be to include a draft resolution, which would acknowledge the Scoping Team’s proposal and authorize ICANN org to start an Issues Report.  * As a reminder, even if the group recommends a new PDP or series of PDPs, that work would most likely not start until one of the current PDPs finishes. In parallel, staff can develop the Issue Report. * Following the posting of the draft Issues report, the Final Issues report, which goes to the GNSO Council could include an accompanying document that represents a draft charter. This “draft charter” is not meant to preempt the work of the ultimate charter drafting team. It would, however, be helpful to provide a preliminary sizing on the amount of effort it will take to complete the proposed PDP or series of PDPs. The sizing will be impossible until there is an agreed scope of work to be done. * Once the issue report is finished, the final Issues Report will include a draft charter and a motion to launch a charter drafting team.  * The Initial Issues Report would go out for public comment for the standard 40 days before the Final Issues Report goes to the GNSO Council. The core of the charter, such as the delivery schedule or rough sizing would be a section within the Issues Report. Note: The draft Charter should not be included in the public comment proceeding b/c it would be a distraction.

3. Group composition preferences (open, experts only, represented)

·         There may be a compromise b/w an open model and a closed model.

·         Perhaps groups who do not wish to actively participate could have a representative(s) act in a “super observer capacity”. In other words, the representative(s) are not required to attend and participate in every meeting, but would be responsible for following the work and reporting back to their respective constituencies. The idea behind this is to ensure the PDP work would not “come as a surprise” to any group.

General TPRST feedback:

* Looking through the Initial Scoping Doc and the issues raised within it - if this goes through a normal PDP - this process seems cumbersome and takes a lot of time. Could these issues be fit into a single PDP or not more than two PDPs?

·         Burnout effect could be mitigated by multiple PDPs

·         Until we know what the exact scope is - at least from Staff’s perspective, what would be helpful to inform the Council - should issues be addressed one by one, or should we start from scratch? That is the most important question that the group needs to have a proposed answer on.

·         Not advocating for starting from scratch; however, that does have its merits 

4. Agree on next steps

5.                  Wrap and confirm next meeting 

* Confirm action items 

·         Support Staff to update the GNSO Scoping Doc letter to remove the reference to EPDP

·         Support Staff to draft a proposed GNSO Council resolution, which will be submitted to the Council with the Scoping Document

·         Team Members to review section 3.11 of the ICANN Org Rec. 27 Wave 1 deliverable <https://gnso.icann.org/en/drafts/epdp-phase-1-recommendation-27-18feb20-en.p...> in detail by Thursday, 5 March. Specifically, Team members should provide feedback if they support or do not support section 3.11

·         Team Members to review the issues chart and ensure it is comprehensive (including urgency level) and include dependencies (if any) by Thursday, 6 March.

·         The Team needs to wrap by 3 April.

·         The Team will meet the 19th and 26th - by the 26 March, Support Staff can have the draft resolution.

·         From 9 March - 19 March, this Team can review the next version of the draft. 

·         Document needs to be delivered to the GNSO Council by 6 April.

* Next TPRST Meeting will be *Thursday, 19 March 2020 at 16:00 UTC*.

 

 

_______________________________________________ GNSO-TPRST mailing list GNSO-TPRST@icann.org https://mm.icann.org/mailman/listinfo/gnso-tprst