Dear Working Group members, As agreed on yesterday’s call, staff has distributed the attached request for early input to SO/AC/SG/C leaders. Groups have been asked to respond by 4 August 2021. Responses will be maintained on the wiki here: https://community.icann.org/x/tIT8CQ Kind regards, Emily, Julie, Caitlin, and Berry From: GNSO-TPR <gnso-tpr-bounces@icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen@icann.org> Date: Tuesday, 29 June 2021 at 21:55 To: "gnso-tpr@icann.org" <gnso-tpr@icann.org> Subject: [GNSO-TPR] Notes and action items - TPR Meeting #06 - 29 June 2021 Dear TPR Working Group, Please find below the notes and action items from today’s TPR meeting. The next meeting will be Tuesday, 6 July at 16:00 UTC. Best regards, Emily, Julie, Berry, and Caitlin -- Action Items 1. Please refer to the project workplan [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1FunWaz3gN...> for action items. Transfer Policy Review Phase 1 - Meeting #06 Proposed Agenda Tuesday 29 June 2021 at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * The Transfer Policy goals have been edited and posted to the wiki. As a reminder, the WG discussed the goals during its ICANN71 session. (https://docs.google.com/document/d/1Yjj2_CtrqJ46wBbHnaZwqI2ZBf7sBFEN3b3x-rEn...) * Additionally, an updated terms and definitions document has been posted to the wiki. This definition is a baseline document to ensure that everyone is using the same terminology. (https://docs.google.com/document/d/1yU4Tu0cfw9Ppps5V5sC8-Q1qVWtJNPKiQLbI7Vhc...) * Please review and suggest edits (if any). 3. Finalize outreach document to SO/AC/SC/Cs (20 minutes) · Please see draft with comments here: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=s... [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2-...> · From this group’s standpoint, it appears that DNSSEC is out of scope. The group may want to consider making a recommendation that this be looked at somewhere. · The reason why some have raised this issue is because it is often intimately tied to the registration. During a transfer, any services that are inextricably tied to the registration, the registrar should endeavor to keep these services intact. · This is out of scope for this group’s work. · Some hosting companies tie everything together – this policy is only about the domain name transfer process. This should be kept separate. · Should the WG put out a recommendation or a comment? Not sure how a recommendation would go within the GNSO. · This is an issue for registrants, but possibly not an issue for the GNSO to solve · The registrant or end user would like to have some sort of best practice that they could check out when doing a transfer, but the technical elements should not be included in this policy. However, perhaps these elements could end up in some sort of guidelines. · Sounds like direction to support staff is to remove the suggested text and retain only the charter questions. There will be a timestamp on it – the proposal is 35 days to respond. Support Staff can send this out as early as tomorrow. · Action: Support Staff to distribute outreach doc with a response deadline of 35 days. 4. Presentation of updated metrics from ICANN Contractual Compliance (10 minutes) · Please see attached metrics, which will be explained on the call. · The updated metrics were sent to the WG in response to a request from the WG. · Before discussing the metrics, thought it may be helpful to explain the scope of ICANN contractual compliance. · Compliance enforces the policies developed by the community and ensures the obligations set forth in the agreements and policies are met by contracted parties, mainly by processing complaints. Authority is limited to enforcing the requirements in the agreements and policies. · The first table provides the number of all transfer-related complaints. (pre-GDPR and post-GDPR) – to see if there is a change in trends · The number of complaints starting in October 2020 was severely impacted by a failing registrar · All of the sets of metrics are presented in two groups – Kayako and NSP. NSP is the new platform. · The main issues reported are usually hijacked domain names, email accounts, and control panels. · When Kayako was utilized, the categories were selected by complaint processors based on the issue described. There may be instances where the complaint was tagged incorrectly. · Most IRTP registrar complaints deal with the inability to retrieve auth-info code or inability to lock/unlock a domain name · What category would suspension or termination of registrar’s agreement fall into? · In the compliance notices page, you can see the number of termination notices sent to registrars, including a detailed description of the issues · These metrics show the number of complaints received but does not show the closure code · Is it possible to get all of this data together? The reason there is an increase of complaints with respect to a registrar failure – it’s more of when a registrar is starting to fail, you see a lot of people are trying to transfer out. · When the Temp Spec came into place, there was an increase in Whois accuracy complaints. Did this also impact the number of change of registrant complaints? · Do not have the precise data on misfiled complaints. · Remember that these are transfer complaints are not necessarily domain name hijacking complaints · Complaints are very low compared the volume of inter-registrar transfers that do occur 5. Continued discussion of AuthInfo Codes (45 minutes) · Staff has updated the Working Document to summarize deliberations that have taken place so far (see text in blue in the document), incorporating and resolving existing comments: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0A... [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPof...>. · Members are encouraged to review provide feedback. An archive of previous versions of the document is being maintained on the wiki here: https://community.icann.org/x/e4P8CQ · May have the first recommendation coming out of the group re: the term TAC – transfer authorization code · With respect to b2 – who should be the authoritative holder of the TAC? · The registry should be the definitive holder of it. · With respect to the auth-info code, it should only exist when it’s needed. The registrant has a relationship with the registrar. The registrar would give it to the registrant to use. · Authoritative holder could be changed as “manager” of the auth-info code. · The registrar sets the auth-code at the registry, and registrant is the owner of the auth-info code. The registry would likely hash the code. · By default, the registry is the authoritative holder – however the info the registry has is only as good as info provided the registrars. · Would be best if registry would be the TTL of the auth code · In terms of when a law enforcement request comes through or a name is terminated, how is the name transferred to a different party – is there an auth-code involved? · This comes from a discussion we haven’t yet had regarding how the current process works and if there needs to be any changes. · It might be too soon to fully answer these four questions. On the question of storage, if we move in the direction of truly implementing a one-time password, there is no storage necessary. There just has to be a way for the registry to confirm the auth code. Next – the question is how long does it get temporarily stored at the registry. Question to registrar – how much flexibility is needed? Is it a uniform rule or can the registrar choose how to set it? Registries have a tightly-scoped role in the transfer process – confirmation of auth-info codes. If the scope of responsibility is expanded, the question is – what are the advantages of that? What is the purpose of this? · The main benefit would be uniform management – if it is run by 2000 registrars, it would not be uniform. · It would need to be uniform no matter who is managing it if there is a policy requirement that is enforced by ICANN compliance. · With ccTLD registries, the registry is the manager, and from the registrar side – this makes it easier. · Trying to understand the improved security – either way, the registrar is in the middle. The registry (whether creating or not creating the code) – it still has to go through the registrar. If some are worried about who can implement it properly, that seems to be a question of who is more likely to be a good player – a registry or a registrar? That doesn’t seem like an appropriate discussion for this group. · With respect to auditing, this would be easier to audit if it managed by the registry. May be helpful to discuss other elements first and then come back to this specific question. · With respect to the registrant having access to the code – however, rely on a model where the registrar relies on the reseller. Whatever option is ultimately chosen needs to ensure this works for wholesale registrars. · Need to be open to different business models but still say that the registry and registrar does not need to store the ID. · Group to consider the SLA question over the next week to discuss at the next meeting. · There is an opportunity here – the concept of more instantaneous transfers – if we truly move the TAC to a one-time password model, one possibility is that the TAC is calculated on demand – what that suggests is that a five-day period is way too long. · 5 days is also a timestamp for when a registrant requests this – there may be a time in between five days and instantaneous · Maybe once the auth code has been created and given to the registrant, then “as quick as possible” makes sense, but maybe there is a process that leads up to the provision of the auth-info code · It’s not a matter of how fast – most of the processes are instant – in the Netherlands, instant transfers exist for .NL – most registrants have access to the auth-code. In the entire five calendar days – not sure what the use of it is. · As a registrar example, there is a list of blocked domains that are reviewed before giving the auth-code – for historically abused names or high value names – these are reviewed manually first 6. AOB (5 minutes) Next meeting: 6 July 2021 @ 16.00 UTC