[GNSO-TPR] Notes and action items - TPR WG Meeting #32 - 18 Jan 2022

[Julie Hedlund]

Dear TPR WG Members,

Please find below the notes and action items from today’s call.

The next TPR WG meeting will be on Tuesday, 25 January 2022 at 16:00 UTC.

Best regards,

Emily, Julie, Berry, and Caitlin

Action Items:

Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdocs.google.com*2Fdocument*2Fd*2F1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy-raY*2Fedit__*3B!!PtGJab4!tVlReslxdp4FVqbtvaBGc0balBYYf8nmPv8Fd4I7wkegiaNANR3DTiMqhsdOVSNozdJdnVI*24&data=04*7C01*7Crcarney*40godaddy.com*7Cd65072730ccf413e9c3f08d9a5224acf*7Cd5f1622b14a345a6b069003f8dc4851f*7C0*7C0*7C637722389110981711*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=MFXWvsgjs2Vq*2BUPOVfyCajb4AISeQ7LpF5F46rlr0Oo*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PtGJab4!oCSoSUMrN-UqvVVo5WG7t__ox54piuqwF197CBe5ASw-VLom5Y2NRR3715R6CFnpujK--Evvvw$> (beginning on p. 14)

Recommendation 15:
ACTION ITEM: Delete recommendation 15 unless there are objections over the next week.

Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e21Qo/edit__;!!PtGJab4!scgfZPPhhC0vJmcLab2Ft-04ELHGqPlfC9j9qw1MfRWpcLWVW9Yvdo2DLz6UuLTGUNU6dHsqSg$> (beginning on p. 16)

Recommendation 16:
ACTION ITEM: Change from a “Candidate” recommendation to a recommendation.

Swimlane Diagram:
ACTION ITEM: Staff to update the swimlane diagram per the discussion.


Transfer Policy Review Phase 1 - Meeting #32
Tuesday 18 January 2022 at 16:30 UTC

1. Roll Call & SOI updates (5 minutes)

  *   No updates provided.
2. Welcome & Chair updates (5 minutes)

  *   Jim Galvin, RySG: The RySG is looking at a number of issues.  We will press on those issues in our group and then bring them to the PDP WG for discussion.
3. Second reading: TAC and FOA (15 minutes)

Losing FOA Working Document <https://urldefense.com/v3/__https:/nam10.safelinks.protection.outlook.com/?url=https*3A*2F*2Furldefense.com*2Fv3*2F__https*3A*2Fdocs.google.com*2Fdocument*2Fd*2F1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy-raY*2Fedit__*3B!!PtGJab4!tVlReslxdp4FVqbtvaBGc0balBYYf8nmPv8Fd4I7wkegiaNANR3DTiMqhsdOVSNozdJdnVI*24&data=04*7C01*7Crcarney*40godaddy.com*7Cd65072730ccf413e9c3f08d9a5224acf*7Cd5f1622b14a345a6b069003f8dc4851f*7C0*7C0*7C637722389110981711*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C1000&sdata=MFXWvsgjs2Vq*2BUPOVfyCajb4AISeQ7LpF5F46rlr0Oo*3D&reserved=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!PtGJab4!oCSoSUMrN-UqvVVo5WG7t__ox54piuqwF197CBe5ASw-VLom5Y2NRR3715R6CFnpujK--Evvvw$> (beginning on p. 14)

Recommendation 13:

  *   Suggest several edits on last week’s call.
  *   Removed 13.2.
  *   Provided revised new 13.2.
  *   11 Jan: Consider making this two different bulleted lists: 1. TAC is provided via control panel 2. TAC is not provided via control panel.
  *   Two footnotes: Old footnote is #2, new footnote is #3.  Do we need to be clearer that the notification is not via the control panel?  Also, is the new footnote #3 helpful? “The Registrar of Record may choose to send the "Notification of TAC Provision" and the TAC together in a single communication.”   Want the TAC notification to be provided through some other mechanism than how it was delivered.  So if you deliver the TAC via email the notification should be via some other method.  Want to make sure the registrant gets the notice.
  *   Notification can include the TAC.
  *   Concerns about limiting methods.
  *   One is to make sure it gets to the registrant and two that it gets delivered via a distinct mechanism.
  *   Think there's value in making sure that the domain owner is notified that the TAC was provided.
  *   The thought here is to notify the registrant directly.  You could still ask your reseller to do it, but it will be the registrar’s responsibility.
  *   It doesn’t have to be a “MUST” but important to call out the different mechanisms – put is as a “SHOULD”.
  *   Should be fine as a footnote.
Recommendation 15:

  *   Do we need this recommendation?  What is the purpose?  Registrars could do it anyway.
  *   Doesn’t make any sense to have this recommendation.
  *   Only value would be for the consistency and transparency in the process.
  *   Not sure how it adds to consistency if it is only optional.
  *   If we make it optional it still has a cost, such as in the time spent on implementation.
  *   Can lead to confusion as an optional requirement.
ACTION ITEM: Delete recommendation 15 unless there are objections over the next week.

Gaining FOA Working Document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e21Qo/edit__;!!PtGJab4!scgfZPPhhC0vJmcLab2Ft-04ELHGqPlfC9j9qw1MfRWpcLWVW9Yvdo2DLz6UuLTGUNU6dHsqSg$> (beginning on p. 16)

Recommendation 16:
“The Working Group recommends eliminating from the Transfer Policy the requirement that the Gaining Registrar send a Gaining Form of Authorization. This requirement is detailed in sections [xxxx] of the Transfer Policy.”

  *   Pretty straightforward.  Rationale explains how we got to this recommendation.
ACTION ITEM: Change from a “Candidate” recommendation to a recommendation.

4. Overview of swimlane diagram for inter-registrar transfer process (60 minutes) – see attached document

  *   Expect that this while change when we get into NACKing of transfers and the bulk transfer discussion.
  *   Goal is to pick up where we left off when Sarah produced a Google sheet of the current state transfer process.  Staff agreed that we need a more visual representation.
  *   Charter questions are not in the order that actually occurs in the charter process.
  *   Swimlane model has interactions occurring across the rows, otherwise read from top left to bottom right.
  *   The primary objects: 1) Blue boxes are a required step for the process flow; 2) Tan box is a sub-process step (such as for the NACK, etc.), which could lead to a separate process page; 3) White circle is a “worm hole”; 4) Diamonds are decision points.
  *   Specific recommendations are called out for the steps where they apply, subject to change when recommendations are finalized.
  *   Like that this raises the question of whether we need a recommendation to confirm that domains in Expiry Grace Period may still be transferred.
  *   The question of whether there needs to be a recommendation at some point concerning transfer of expired domain – out of scope but WG can consider making a statement (not a recommendation).
  *   Recommendation #15 is going away (if no objections), so this will be removed.
  *   There has to be a section shortly after the decision to transfer the domain that the RNH has to decide on the gaining registrar, inc. make an account at the gaining registrar.
  *   Recommendation 13.2 (original) goes away and replaces 13.3.
  *   Recommendations 5.1 and 5.2 may go away so those steps are shaded.
  *   Question re: “OR Move Domain to G-Rr Credentials; Add 1 Year to Registration GFoA” – is this the current policy?  Answer: Yes. See “The completion by Registry Operator of a holder-authorized transfer under Section I.A shall result in a one-year extension of the existing registration, provided that in no event shall the total unexpired term of a registration exceed ten (10) years.” This is out of scope of our charter so it would stay at one year.
Setting the TAC to Null:

  *   Per Recommendation 11.2, the Registrar of Record/Losing Registrar has the option to set the TAC to null.  WG may want to consider providing some color commentary on what would happen if the TAC was set to null – such as resolving the issue on why it is set to null; address the issue of whether the transfer moves forward – go into a worm hole at letter A.
  *   The registry takes the submitted TAC from the Gaining Registrar and it either matches or it doesn’t.  There does need to be a process whereby the Registrar of Record can change their mind, and thus they can set it to NULL.  The registry MUST set the TAC to NULL when the transfer is successful, i.e., the TAC gets to be used once.
  *   From the point of view of a registry operator, from a pure process point of view: the registry only cares if the TAC matches when we get a request or not.  If it doesn’t match the transfer is non-eligible.  If it matches the transfer is successful, and then the TAC is set to null so it is only used once.  It is an outside step if the Registrar of Record changes its mind – the registry doesn’t care – just whether the TAC matches/is valid.
  *   Confirmed that in the swimlane if the Registrar or Record chooses to set the TAC to null the registry won’t see it.
  *   From a swimlane perspective the fact that the TAC could be set to null by the Registrar of Record shouldn’t appear in this process flow.
  *   Doesn't setting TAC to null need a corresponding box in the Registry lane to show that it's affected in the registry system?
  *   We have a draft recommendation #11.2 that the Registrar of Record can set the TAC to null – so how should we reflect that recommendation?
  *   The problem is where it is in this document – doesn’t below in this spot.  Should be between the TAC is provisioned and when it goes to the registry.
  *   Doesn’t fit well in the swimlane model – it’s just here for reference.
  *   Move the TAC to null to a secondary page and then move the steps around.
Transfer Locks:

  *   The question here concerning the order of the steps depends on what you are giving priority to.   Need to find out if the transfer is going to occur – given that a TAC is present in my system I need to find out whether you are the right person for the transfer.  Once I have a valid TAC I know the domain should transfer; at that point I look for any domain locks and resolve them.  Don’t want to do a lock release before I know whether a transfer is eligible.
  *   Question: There are different types of locks – which ones are we talking about here?  Answer: We are being generic since putting in all of the locks would make it very complex with sub-process pages; we also need to consider NACK locks.
  *   If you want to keep it high level that is okay, but make sure they are different processes not tied to each other.
  *   To check if the domain is locked and the TAC if valid happens at the same time – don’t need to say what order they are in.
  *   In EPP and policy at ICANN there is client lock and registry lock – may be other non-policy locks.
  *   client lock = registrar / server lock = registry – 2 types of locks but for a variety of reasons.
  *   There are also court-ordered locks (UDRP).
  *   Maybe there’s a process step for the Registrar of Record to clear registrar/client locks and a separate place for server locks.
  *   Some registrars may keep a client lock on for security. Corporate registrars may remove client lock at a later point in the process if RNH/registrars are concerned.
  *   There is a point where you talk about removing a client lock – there needs to be further elaboration and removal of client locks and what that means.  There should be some discussion of what it means for the server lock.
  *   So maybe the only discussion is whether or not there will be a policy about unlocking prior to transfer (which  means removing the client lock release earlier in the swimlanes).  In that case, I agree a step when the TAC is received at the registry to resolve any locks that are present is sufficient.
  *   Probably needs to be discussion about what it means to release locks, but no policy recommendation I would think.
  *   Staff has built an inventory of the types of locks and where they are applied that will be useful for the upcoming discussion on locks.
ACTION ITEM: Staff to update the swimlane diagram per the discussion.

5. AOB (5 minutes)

     *   Next call: Tuesday 25 January 2022 at 16:00 UTC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220118/21aaf059/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TPR_P1_Swimlane_20220118.pdf
Type: application/pdf
Size: 113562 bytes
Desc: TPR_P1_Swimlane_20220118.pdf
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20220118/21aaf059/TPR_P1_Swimlane_20220118-0001.pdf>