Page History

Notes/ Action Items

 ACTION ITEMS/HOMEWORK:

Swimlane:

1. WG members to review and provide comments and technical WG members in particular to review language relating to EPP actions to make sure it is accurate/clear.
2. Preliminary Recommendation 11: check the language for operational accuracy – particularly the suggested revised language: “The Registry Operator MUST reset the TAC to null as part of completing the successful transfer request when is accepts a valid TAC from the Gaining Registrar

Proposal on Exemption for Recommendation 17:

 Ongoing Actions:

1. Small Team on Recommendation 13 TTL: Provide revised rationale.
2. Small Team on threat vectors: Provide language.

 Actions from Meeting on 24 January:

1. Re: Recordkeeping: Staff will draft a standalone recommendation with 15 months to insert into the next redline.
2. Re: Recommendation 17: WG members to take the language and suggested revisions back to their groups and provide to the WG at least informal feedback whether the proposed change is supported or not. See attached redline and screenshot.
3. Re: Recommendations 16 & 17: Staff to suggest language to include in Recommendations 16 and 17 re: 30-day restriction replacing existing restrictions (such as 60-day locks)

1. .

Notes:  

1. Roll Call & SOI updates

2. Welcome and Chair Updates

• Reminder – deadline extended for comments to Recommendations 10-22 to 23 January.
• Any updates to the Recommendation 13 TTL rationale?  Not at this point.
• Threat vectors Small Team: In the works.
• Steiner (ALAC): Recommendation 16 – clarify whether there is any consensus on this proposal.  Think the Small Team agreed that an exemption wasn’t needed for the Recommendation 16 restriction (lock) post-registration.  Won’t have a common reason to opt out of the 30 days post-creation lock.  So, Recommendation remains the same.  Not clear yet if there is support for an opt out re: Recommendation 17 (see below).

3. Updated Transfer Process Swimlane (see attached and at: https://community.icann.org/display/TPRPDP/2023-01-17+Transfer+Policy+Review+PDP+WG+Call)

Summary:

• This will never be perfect – it is conceptual in nature and not meant to be a policy document.
• Starting to get busy and complicated – lots of worm holes; even once stable it will be subject to change re: Phase 1b, CoR, Phase 2.  Need to create a space for CoR.

Details of Revision:

• Substantive changes from Initial Report.
• What hasn’t changed is the general use and expiration of the domain.
• Post-Create Transfer Restriction: Gap in the rationale around the reasons for why we are implementing the change as opposed to what is in the marketplace today.
• Timeframes: 1) Made consistent to hours and calendar days across all recommendations; 2) transfer policy is more technical in nature so timeframes will be coded – so set a hours. But include both hours and days as a compromise – hours for technical use, and days for readability.
• Yellow sub process re: established customer procedure – placeholder for now until discussed/agreed in the WG.
• Couple of substantial changes in the first task:
• From the moment the RNH requests the TAC the 120 hour-clock starts.
• “Frictions to Cure” – New part: further deliberations made clear that previous version of the swimlane didn’t account for what really happens – check of validity of the TAC before it is sent to the registry. 
• If an issue it will be the gaining registrar that is notified that the TAC is not valid.  Enter a worm hole.  Process in effect starts over.
• Assuming that the TAC is valid, registry does the check on whether the TTL is expired (Rec 13) – Gaining Registrar will need to send an (operational) notice that the TTL is expired and RNH needs to make a decision. 
• If not expired registry sets to pending transfer, reset the TAC to null, and terminate the TTL.
• RNH receives transfer confirmation – if choose to cancel (Rec 2) the Registrar of Record will invoke the cancellation procedure.  If RNH does accept the transfer the Losing Registrar send the poll message – ask technical-oriented WG members – confirm language adjustments to make it more clear what is actually happening in EPP.
• Challenge at Gaining Registrar is not likely to reflect what actually happens. Logic is there to help facilitate how we are using the worm holes.

Discussion:

• Points of clarity:
• 1) Setting domain to “Pending Transfer” after TTL expired –
• If the TTL is expired means that the TAC is no longer present/valid and should not be treated as present – that’s all the registry knows and if not present would treat it as null – only the Registry of Record knows if it is expired. 
• There is no response from a registry that would say “TTL expired” – it can either accept it, TAC is invalid, or say no transfer is permitted.
• No such thing as the registry checking for an expired TAC. If it is expired it is null/invalid per the registry. 
• So this decision box (TTL expired?) should go away – put a decision box “Is there a TAC present?” then check if it is valid, etc. All the steps around the TTL expired decision box goes away.
• Registries responses on a failed TAC will be purposefully oblique.
• 2) Set Domain to “Pending Transfer”:
• Understand what this means operationally.  A TAC is considered used at the moment a valid TAC is received, not when the transfer is complete.  Once a valid TAC is received it is set to null and the TTL expires and completes the process with the Registrar of Record – a transfer cannot be tried again with that TAC.
• The “pending transfer” and box to the right are all one state.  This is a combination state – the registry does not Set Domain to “Pending Transfer”.
• The pending state is because of the Losing FOA process.
• The losing FOA changed, but the requirements of it haven’t. So, yes. ‘Pendingtransfer’ would still remain.
• Removing the ‘pendingtransfer’ would cause so many issues for CS and also for registrants.
• Confirm that there isn’t anything in the recommendations at this point that is specifically for the registry to Set the Domain to “Pending Transfer”.  May need to take a closer look at this.
• Preliminary Recommendation 11: “The working group recommends that the TAC as created by the Registrar of Record according to Preliminary Recommendation 7, MUST be “one-time use.” In other words, it MUST be used no more than once per domain name. The Registry Operator MUST reset the TAC to null  as part of completing the successful transfer request.”  Final sentence may be misleading.  Need to make sure this language is technically accurate.
• Proposed revised language (change in bold):  “Preliminary Recommendation 11: The working group recommends that the TAC as created by the Registrar of Record according to Preliminary Recommendation 7, MUST be “one-time use.” In other words, it MUST be used no more than once per domain name. The Registry Operator MUST reset the TAC to null as part of completing the successful transfer request when is accepts a valid TAC from the Gaining Registrar.”

ACTION ITEM re: Swimlane

1. WG members to review and provide comments and technical WG members in particular to review language relating to EPP actions to make sure it is accurate/clear.
2. Preliminary Recommendation 11: check the language for operational accuracy – particularly the suggested revised language: “The Registry Operator MUST reset the TAC to null as part of completing the successful transfer request when is accepts a valid TAC from the Gaining Registrar

4. Proposed redline from Small Group on Exemption for Recommendation 17 (see attached)

Proposed redline:

Preliminary Recommendation 17: Registrars MUST apply a 30-day post-change of registrar lock by default for all domain names transferred into a Registrar, however on a case-by-case basis and where an Established Relationship exists, the Registrar may unlock the domain name in less than thirty (30) days for the purpose of an inter-registrar transfer, on a case-by-case basis. An Established Relationship means a RNH who has; a)  received registrar services for a period of  at least thirty (30) days; and b) a history of regular interactions with the Registrar and who has demonstrated a willingness to continue receiving registrar services from the Registrar in the future.

Discussion:

• Idea is to keep the post-transfer and post-create restrictions, but to allow an opt out for the post-transfer limited to Established Relationship.
• When it gets transferred in the restriction is placed, the registrar has the option to remove the restriction upon the request of a RNH with an Established Relationship.
• Lock is still mandatory (“MUST”).
• Would require manual intervention to determine that an RNH has an Established Relationship – makes it harder to remove the lock.
• Still an agreement between the registrar and registrant.
• WG members should review and comment on the proposal.

• Need rationale from the small team on Rec 13 TTL in the next week.  No update provided at this time.
• Need a write up from the small team on threat vectors in the next week.  No update provided at this time.

3. Input received on 21 December redline (recommendations 10-22):https://docs.google.com/document/d/1Zoh8D2GuulpIDbyqwYsfRCSJkiGpa19k02eiEE-tWnE/edit

• No comments received.
• Given no comments, we think that means that WG members are comfortable with it so that there won’t be any surprises later.

4. Proposed language from ICANN Contractual Compliance on record keeping:https://mm.icann.org/pipermail/gnso-tpr/2023-January/000740.html

“Registrar shall retain all records pertaining to the provision of the TAC to a Registered Name Holder, as well as all notifications sent per the requirements under this Transfer Policy. At a minimum, the records retained in accordance with this section shall document the date/time, means and contact(s) to whom the TAC and notifications are sent. Registrar shall maintain these records for the shorter of two (2) years or the longest period permitted by applicable law, and during such period, shall provide such records to ICANN upon reasonable notice.”

• Drafted in accordance with the current RAA and doesn’t prevent the Registrars from setting their own records retention policies.

Discussion:

• Question: Was the gTLD Registration Data policy (not yet finished the IRT) considered? I think it spoke to retention periods.  Answer: This was considered, but this is open for discussion.  Drafted Reg. Data policy suggests 15 months – consider aligning.
• Does there need to be anything said about data processing agreements?
• Seems that the text makes sense.
• Confirming that staff will draft a standalone recommendation with 15 months to insert into the next redline.

ACTION ITEM: Re: Recordkeeping: Staff will draft a standalone recommendation with 15 months to insert into the next redline.

5. Continued discussion on proposed redline from Small Group on Exemption for Recommendation 17 (see attached)

Discussion:

• Suggestions from Sarah Wyld (see attached screen shot): Changes to help clarify: “Registrar will remove the registrar lock…” and change to “fewer than 30 days” (from “less than 30 days”), add “at the Registrar’s discretion” to replace “for the purpose of an inter-registrar transfer”.
• Small team: Suggest not removing “for the purpose of an inter-registrar transfer”.  I think also we should keep “at the Registrar’s discretion” as well as “ClientTransferProhibited”.
• At least one WG member is against the change.  Disabling ability to prevent registrar-hopping.  Also, dependencies on dispute discussions in future.
• Note that the report uses the term “restriction” rather than “lock”.
• Think it is a good point to ask why this was introduced since registrar-hopping is an important consideration and it isn’t currently tracked.  Will also be interdependent with possible rollbacks in the next phase.  If we define this now, will we be able to come back to it?
• If we decide something later that breaks something we’ve already said we’ll have to revisit it.
• No decision from the WG at this time – doesn’t seem like there is strong support at this time.  Would be good to have a Stakeholder Group discussion on this and at least informal support or not.
• Note that this exception would apply only post transfer.

ACTION ITEM: Recommendation 17: WG members to take the language and suggested revisions back to their groups and provide to the WG at least informal feedback whether the proposed change is supported or not.  See attached redline and screenshot.

Additional Issues:

• Question: If we create a 30-day restriction should we explicitly say that any existing 60-day restrictions would go away?  Answer: Important to document – should we put language in the policy or otherwise to make this clear?
• As staff understands it in today’s world most of the requirements are set, are set by varying contracted parties outside of the RA/RAA, so we need to be precise in the policy itself. 
• Need to specify in order to enforce.
• Question: Where to put the language? Should be in the body of the recommendation.

ACTION ITEM: Recommendations 16 & 17: Staff to suggest language to include in Recommendations 16 and 17 re: 30-day restriction replacing existing restrictions (such as 60-day locks).

6. Possible minor modifications to Losing FOA (see bracketed text below)

Preliminary Recommendation 2: The working group did not reach agreement to eliminate or substantially change the Obligations of the Registrar of Record described in Section I.A.3.1 - I.A.3.6 of the Transfer Policy. Therefore, the working group anticipates that these requirements will largely remain in place. The working group recommends the following minor modifications:

• The term [“Transfer Confirmation”] must be used in place of “Standardized Form of Authorization (FOA).” 
• [The [Transfer Confirmation] must include the Gaining Registrar’s IANA ID]
• [The [Transfer Confirmation] must include both an opportunity for the RNH to proactively accept the transfer AND an option to cancel the transfer]
• [The [Transfer Confirmation] must be provided in English and the language of the registration agreement and may also be provided in other languages]

General Discussion:

• Question: Also include a name in addition to IANA ID?  (Many ccTLD registrars do not have an IANA ID)  Could potentially include language as in Rec 14 to provide flexibility.
• Concerns from Sarah re: “opportunity for the RNH to proactively accept the transfer AND an option to cancel the transfer”.

Discussion on each suggestion:

The term [“Transfer Confirmation”] must be used in place of “Standardized Form of Authorization (FOA).”

• WG agrees.

[The [Transfer Confirmation] must include the Gaining Registrar’s IANA ID]:

Discussion:

• Match language in Recommendation 4; name might not mean anything.  The IANA ID is the only unique identifier that exists in the system.
• Staff suggest changing to ““IANA ID(s) of Gaining Registrar(s) and link to ICANN-maintained webpage listing accredited Registrars and corresponding IANA IDs. If available, the name of the Gaining Registrar(s) may also be included.””
• Might want to be careful on this one – by including a name it opens up the possibility of disagreement between the two fields.  Should identify a clear benefit because code will have to change.
• The issue is that a poll message is issued from the registry to the registrar – as long as we define it as coming from the IANA registry there should be no confusion.
• This is added information to help the RNH.
• With respect to resellers, sub-resellers, etc, this is why anchoring it with what’s in the IANA registry is our only option.  such is the “standard” that our system offers to us to work with.
• Re: “IANA ID(s) of Gaining Registrar(s) and link to ICANN-maintained webpage listing accredited Registrars and corresponding IANA IDs. If available, the name of the Gaining Registrar(s) may also be included.” Do we need to specify that this is the name of Gaining Registrar(s) as included in the IANA database?
• Make sure we correct things that have been problems, but also to suggest things that will improve security – which IANA ID will do.  Just don’t require people to use it.
• If we have it let’s use it.
• Having it could be very helpful to registrars and registrants.
• The IANA ID is already being passed around – don’t think there would be contention with “MUST”.
• Going back to Recommendation 4.3 – The ID is maintained by ICANN through IANA.  The requirement is for the ID and a link to the page of IDs with names.  The names can come from there as well.  Losing registrar has a look-up to the IANA database/registry. 
• See: IANA IDs https://www.iana.org/assignments/registrar-ids/registrar-ids.xhtml
• Should be careful to say it comes from the “registry available at IANA”. It’s not IANA’s registry or a registry maintained by IANA.
• WG agrees: Use the exact same text as in Recommendation 4.3.  So same in both places.

[The [Transfer Confirmation] must include both an opportunity for the RNH to proactively accept the transfer AND an option to cancel the transfer]

• This would be a change from the status quo.
• Make mandatory for accept AND option to cancel.
• WG agrees: Stay with status quo – ACK is optional.

[The [Transfer Confirmation] must be provided in English and the language of the registration agreement and may also be provided in other languages]

• See 3.3 The FOA shall be communicated in English, and any dispute arising out of a transfer request, shall be conducted in the English language. Registrars may choose to communicate with the Transfer Contact in additional languages. However, the Registrar choosing to exercise such option is responsible for the accuracy and completeness of the translation into such additional non-English version of the FOA. Further, such non-English communications must follow the processes and procedures set forth in this policy. This includes but is not limited to the requirement that no Registrar shall add any additional information to the FOA used to obtain the consent of the Transfer Contact in the case of a transfer request.
• WG agrees with the suggested text.

Issues for the next meeting:

• Format of the Losing FOA;

1. Should we include in the recommendation that this deadline should be expressed in hours in addition to number of days "3.5 Failure by the Registrar of Record to respond within five (5) calendar days to a notification from the Registry regarding a transfer request will result in a default "approval" of the transfer."
2. Do we need a recommendation that provides specific details about how, when and by whom the pending transfer status is set and removed?

7. AOB

 ACTION ITEM: Proposal on Exemption for Recommendation 17 – WG members to review and comment on the list.  See attached document.