Page History

Notes/ Action Items

 Action Items

ACTION ITEM: Deadline by Thursday, 08 July 2021 at 23:59 UTC -- Call for volunteers for a small team to develop draft answers to the charter questions. Volunteers captured from today’s meeting: Jothan Frakes, Volker Greimann, Jody Kolker.

ACTION ITEM: Staff to cancel the full WG meeting on 13 July 2021. Schedule a small team meeting either at the same time or another time.

Also see the project workplan [docs.google.com] for action items. 

Transfer Policy Review Phase 1 - Meeting #07

Proposed Agenda

Tuesday 06 July at 16.00 UTC

1. Roll Call & SOI Updates (5 minutes)

2. Welcome & Chair updates (5 minutes)

3. Work Plan (15 minutes) – See attached.

Presentation by Berry Cobb:

A few highlights and comments about the Work Plan:

• Per PDP3.0, Working Groups are now required to submit its proposed schedule of milestones and deliverable dates to the GNSO Council as the managers of the Policy Development Process.
• The intent of this requirement is to increase predictability for managing current and future policy work in the pipeline for the GNSO. This is also about increasing the accountability of the Working Group, Leadership and Staff to deliver on schedule per its charter requirements.
  • The proposed key milestone dates:16 Jun 2022 – Deliver Phase 1A Initial Report on Transfer Policy for public comment, begin Phase 1B deliberations on Change of Registrant
  • 14 Sep 2022 – Conclude review Phase 1A comments
  • 30 Mar 2023 – Deliver Phase 1B Initial Report for public comment
  • 28 Jun 2023 – Conclude review of Phase 1B public comments
  • 16 Aug 2023 – Deliver Phase 1A, 1B Final Report to the GNSO Council
  • Phase 2 is not in scope for this plan, but this process will be repeated when it begins.
    • Assumptions: meeting once per week; 
    • doesn’t account for downtime (such as US holidays); 
    • there is padding built into the plan, but some is accounted for (such as for holidays);
    • Format: deliberate on charter questions; develop recommendations and draft report; repeat.
    • On the Gantt chart we are taking the work sequentially – initial report for two phases and then final report.
  • This not a plan based solely on calendar days.
  • Less than 80 hours of call time before June of next year to deliver the Phase 1A Initial Report.
  • Committing to this timeline is under promising and over delivering. But still a risk if we can’t meet this plan. Better served to be more aggressive up front. Do have tools such as extending meeting time and increasing meetings if necessary, or working some topics in parallel.
  • Need to send this to the GNSO Council for consideration by next Monday, 12 July. It is on the agenda for the 22 July Council meeting.
• This is a leadership team work product to maintain an accurate representation of the WG’s efforts and schedule. To make up for this, staff will also maintain a more tactical work plan and track the WG’s action items here:https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8uRQq4Oe5Q/edit#gid=0 [docs.google.com] [docs.google.com]. At the conclusion of each month, staff will also produce a project package that contains a compilation of several work products for us to communicate the status and health of this project to the community. 

4. Continued discussion of AuthInfo Codes: Charter Questions B3, B4, and (time permitting) B5 (60 minutes)

From last week’s discussion re: Question b3) The Transfer Policy currently requires registrars to provide the AuthInfo Code to the registrant within [up to] five [calendar] days of a request. Is this an appropriate SLA for the registrar’s provision of the AuthInfo Code, or does it need to be updated? [amendments in strikeout/brackets]

• Seems from the discussion that five calendar days was right.
• Could suggest a slight change to “up to five calendar days”.
• Not sure where the five calendar days came from.

Charter questions b4, b5, and b6: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0AK00/edit?usp=sharing [docs.google.com]. Archive of earlier versions: https://community.icann.org/x/e4P8CQ. For easy reference, the questions are:

• b4) The Transfer Policy does not currently require a standard Time to Live (TTL) for the AuthInfo Code. Should there be a standard Time To Live (TTL) for the AuthInfo Code? In other words, should the AuthInfo Code expire after a certain amount of time (hours, calendar days, etc.)?’
  • Could set a TTL, but perhaps improve the end-user experience with a one-time authorization code. Look at what is a standard/best practice TTL.
  • In Tech Ops discussions 14 days was suggested.
  • Questions to think about: As you decide whether 14 days is enough, consider the overall business process and what is going on here. If the code gets used, expect that part of the system the registry would clear the code and not allow it to be used. So 14 days longer than 5 days would not be right. There is a relationship among these parts. 14 days could be too long given the one-time use principle.
  • Consider that many transfers are initiated that never go through.
  • Does TTL have any real-world benefits/scenarios? If there are none then there is no reason to have TTL.
  • Why do we have to stick to some number of days before it gets deleted?
  • Assume that the 14 days start only when the customer has been given the tag.
  • There would not be an AuthCode on a domain until a transfer is initiated. Once the transfer is complete the AuthCode is deleted.
  • Assume that if the transfer wasn’t completed in 14 days then the registrar would need to request a new AuthCode.
  • Is the 14 days a security risk (with the 5 calendar days)? Yes, the email could be hacked. Seems like 14 days is too long.
  • Consider a shortened TTL for important registrants or domain names.
  • Another example: having a TTL is a good security practice, but there is a relationship between the TTL and the security principle of one-time use.  Need to map out the business process to decide whether to have a TTL and its length; could have a minimum TTL as a principle. Critical question is who controls the TTL. The registrar should own that, but how does the registry know there is a TTL and what it is? Registrars may want to have different lengths of TTLs for different reasons. Need to think of these questions in the overall security picture.
  • If we go down the path of one-time use then the TTL is the maximum time for that one-time use.
  • In many cases the relationship between the registrar and registrant is not a direct one. A request for an AuthCode could go to a reseller or other provider for example, creating a feedback-loop. A registrar may not even know that the request has been made. Need to remember the different models. Whoever does the EPP would know about the request for an AuthCode, so the registrar would know if he does the EPP.
  • More reason to have a short TTL when the AuthCode passes through many hands – not just registrar to registrant.
  • Need to consider how long it will take to implement this. Flexibility depends on who is setting the TTL. For important/high-value domains the registrar may want to set a very short TTL for liability purposes.
  • We will need to revisit this question when we discuss bulk transfers.
  • High value domain names should be protected by Registry Lock or similar, hence an intense dialog between the registrant/owner and the registrar will be needed to make the label ready for a transfer.
  • Consider a manual revocation of the AuthCode, such as if the registrant decides not to transfer.
  • Think about policy versus saying “yes, you can do this” or “no, you can’t do this”.
• b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered?
  • Talked about this a couple of times.
  • Good question as to whether there is a need for it.
  • What you find with a lot of domainers they tend to be more security conscious. Could look at adding security for bulk transfers.
  • In the past the AuthCode has always been unique for each domain name. But some domainers might not be well served to receive one code per domain when they have bulk domains.
  • Not sure there is an issue if you want to do requests in bulk; could just leave it up to the registrar. Just keep it simple and leave the solution to the registrar.
  • Do we get an advantage of trying to standardize across registrars, or leave it up to each registrar and their business models?
• b6) Does the CPH TechOps research provide a logical starting point for future policy work on AuthInfo Codes, or should other options be considered?  Note: As a starting point, the Support Staff Team has included relevant portions of the CPH TechOps paper under the relevant charter questions; however, this does not prevent the WG from considering both the pros and cons of the TechOps suggestions and alternative proposals. 
  • What is missing from the TechOps paper that we should be considering?
  • Already started using a lot of what the TechOps provided.
  • b7) Should required differentiated control panel access also be considered, i.e., the registered name holder is given greater access (including access to the auth code), and additional users, such as web developers would be given lower grade access in order to prevent domain name hijacking?  Note: As a starting point, this charter question was included in response to the following feedback from the Transfer Policy Status Report Survey, “I am concerned about who receive[s] [the AuthCode][.] [I]f we could confirm that only [the] registrant can receive [the AuthCode], then we may no longer need FOA.”This is a business practice and an overstep by ICANN to set as a policy.
  • This could not be a recommendation, but just a comment that these security measures are out there.
  • Sounds like there is agreement that this is out of scope for this PDP; could just create a list of other security practices that the WG considered, but decided not to make them policies.

General Discussion:

• Is there one solution scenario that we can create – TechOps, WG recommendations, etc. – pull together to make a close-to-complete model for AuthInfo Codes and provide them to TechOps for consideration?
• We can definitely pull some draft recommendations/suggestions to pose to TechOps. There is a benefit to pose questions to TechOps.
• Would like to bring up the potential of having a Proof of Ownership field. Some overlap with DNS. Ways to do this now as a paid service. If you had a field you could change you could prove that you have editing ability for that domain. You want to follow the ownership chain back to show that you have the authority to make changes to the DNS.
• On the losing side proof of ownership is already there.
• Helpful to transfer this conversation to the list with a proposal from John Woodworth.
• Need to start coming up with draft recommendations for AuthInfo codes – do this via a small group, or via the full WG?
• Do we have a threshold question that we need to determine before handing this work to TechOps?
• What will be important for this next phase is that it is kept in the context of the current requirements for AuthInfo codes – such as whether there are recommendations for any of the current requirements need to change, or what are recommendations for additional policy requirements.
• Could cancel next week’s meeting and use it for the small team meeting, or could schedule a different time.

ACTION ITEM: Deadline by Thursday, 8 July 2021 at 23:59 UTC -- Call for volunteers for a small team to develop draft answers to the charter questions. Volunteers captured from today’s meeting: Jothan Frakes, Volker Greimann, Jody Kolker.

6. AOB (5 minutes)

- Next meeting: 13 July 2021 @ 16.00 UTC

• SSAD ODP webinar schedule at the same time as our meeting next week. Need to decide if that is an issue.
• Several people wish to attend the SSAD ODP.
• Meeting on 20 July is already cancelled.
• Next meeting is 27 July.

ACTION ITEM: Staff to cancel the full WG meeting on 13 July 2021. Schedule a small team meeting either at the same time or another time.