[GNSO-TPR] Input Due 30 November: Draft Revisions to Recommendations 2-9

James Galvin jgalvin at identity.digital
Tue Nov 29 16:10:10 UTC 2022


One clarification I would add is that in Step 1, where you say the RNH 
unlocks the domain, this means removing all registrar locks.  It does 
not include removing registry locks, since they may be associated with 
Registry Lock Services and those are explicitly out of scope for this 
PDP.

A registry has a responsibility to resolve its registry locks at some 
time beginning with the receipt of a valid TAC and ending upon the 
actual transfer of the domain.

Jim



On 22 Nov 2022, at 13:48, Sarah Wyld wrote:

> Hello team,
>
> I’ve reviewed our draft updated recommendations and the strawman for 
> Rec 2. Left some minor changes in the redline doc. 
>
> I want to provide more context specifically around the suggestion for 
> an alternative to the Losing FOA, we can call it the “TAC ACK” 
> process. Prior to our public comment review, the WG seemed aligned on 
> the decision to drop the Losing FOA; we must certainly address all the 
> concerns raised in the public comments, and I think we can do that 
> while also maintaining our goal of streamlining the transfer process 
> by further exploring the TAC ACK option.
>
> What the process would look like: 
> 1. RNH unlocks domain and requests TAC from the Registrar of Record 
> (Losing Rr) 
> 2. Losing Rr sends a TAC ACK email to the RNH saying “Someone 
> requested a TAC; if this wasn’t you, click <NACKlink>. If it was 
> you, you can either do nothing and we’ll provide you the TAC in 5 
> days or you can click <ACKlink> and we’ll give you the TAC right 
> now”
> a. If RNH clicks <NACKlink>, the TAC is never set at the Ry, and other 
> things might happen (e.g. account password reset, etc) 
> b. If RNH clicks <ACKlink>, the Losing Rr provisions the TAC at the Ry 
> and issues it to the RNH (Rec 3 Notification of TAC Issuance)
> c. If no response, Losing Rr waits 5 days and then provisions the TAC 
> at the Ry and issues it to the RNH (Rec 3 Notification of TAC 
> Issuance)
> 3. When the RNH receives the TAC, they provide it to the gaining Rr 
> and the transfer is completed (Rec 4 “Notification of Transfer 
> Completion” etc)
>
> Why this is beneficial: 
> • Registrant agency: the Registrant has the option to cancel the 
> transfer right away, following the same process as with the current 
> Losing FOA (which has the option to NACK, and which auto-ACKs after a 
> 5 day pending period) 
> • Just-in-time notifications: The TAC ACK process occurs right when 
> the RNH is preparing for the transfer, rather than at some point later 
> on after they’ve initiated it with the gaining Rr and moved 
> on/stopped thinking about it 
> • Simplicity: Registrants consistently request fewer emails overall 
> and fewer steps specifically in the transfer process, and have 
> requested an ‘instant transfer’ process for years
>
> Risks & mitigations: 
> • Risk: There would be no notification/’stop the transfer’ 
> moment after the transfer is initiated with the gaining registrar; 
> Mitigation: (a) there is a notification/stop moment at the time of TAC 
> request, and (b) the fast-undo process we are committed to creating in 
> the next phase of this WG would specifically address these issues and 
> could certainly include reverting DNS if it was changed 
> • Risk: Level of development effort does not balance benefit; 
> Mitigation: The level of effort will differ for different providers, 
> and we shouldn‘t reject ideas just because they take work, 
> especially since we’re already making changes to the transfer 
> process as a whole. Now is exactly the time to do this! 
>
> The working group hasn’t reached consensus on eliminating the Losing 
> FOA, but we also haven’t reached consensus on keeping it. I still 
> believe that this “TAC ACK” proposal would address the entirely 
> valid concerns about security and registrant agency, while also 
> providing noticeable improvement for registrants who have repeatedly 
> and for quite some time requested a faster transfer process. I hope we 
> can discuss this proposal alongside the Losing FOA strawman.
>
> Thank you,
>
> -- 
> Sarah Wyld, CIPP/E
>
> Policy & Privacy Manager
> Pronouns: she/they
>
> swyld at tucows.com
>
> From: Emily Barabas
> Sent: November 16, 2022 12:18 PM
> To: gnso-tpr at icann.org
> Subject: [GNSO-TPR] Input Due 30 November: Draft Revisions 
> toRecommendations 2-9
>
> Dear working group members,
>  
> As discussed on yesterday’s call, staff had an action item to 
> provide a redline revision of the Initial Report reflecting agreed 
> updates to Recommendations 3-9 (see pages 18-24), as well as a 
> strawman draft of the new Recommendation 2 and response to Charter 
> Question A7. The redline is attached. The Recommendation 2 strawman is 
> available here.
>  
> Please carefully review these documents in coordination with the 
> groups you represent. If you feel that there are items that need to be 
> revised, please enter them here. For each item, please include:
>  
> • Report version (the date listed in the header of the document) and 
> applicable line numbers ( these are listed along the left margin of 
> the document).
> • Name and group you represent: If multiple WG members represent a 
> group, input should be in coordination with these other members.
> • Rationale: please provide a clear explanation for why you are 
> proposing the revision.
> • Specific proposed revision: Provide the language you would like to 
> see added/removed/edited.
>  
> The deadline for submitting input is 30 November 2022. After the 
> deadline, the working group will discuss the items submitted in the 
> input document. Following review of those items, the text will be 
> considered stable.
>   
> Please do not hesitate to reach out with any questions about the 
> review process.
>  
> Kind regards,
>  
>  Caitlin, Julie, Berry, and Emily
>  
>  
>
>
> Emily Barabas
> Policy Development Support Senior Manager
> Internet Corporation for Assigned Names and Numbers (ICANN)
> Phone: +31 (0)6 84507976
> www.icann.org
>  

> _______________________________________________
> GNSO-TPR mailing list
> GNSO-TPR at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-tpr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20221129/2080ff42/attachment-0001.html>


More information about the GNSO-TPR mailing list