Dear all,

Thanks to Raymond (ALAC), Farzi (NCSG), Sarah (RrSG), and Jothan (RrSG) for stepping forward for the small team. If anyone else would like to volunteer, please email staff by end of day tomorrow, Friday 1 April.

Kind regards,

Julie, Caitlin, Berry, and Emily

From: Emily Barabas <emily.barabas@icann.org>
Date: Wednesday, 30 March 2022 at 11:50
To: "gnso-tpr@icann.org" <gnso-tpr@icann.org>
Subject: VOLUNTEERS NEEDED: Small group on reasons for denial (NACK)

Dear all,

As a reminder, we are looking for a handful of volunteers to join a small group that will finalize proposed revisions on the reasons for denial. This will be a short-lived group and participation is not expected to be a significant time commitment. Please respond here if you are interested in participating.

Kind regards,

Julie, Caitlin, Berry, and Emily

From: GNSO-TPR <gnso-tpr-bounces@icann.org> on behalf of Julie Hedlund <julie.hedlund@icann.org>
Date: Tuesday, 29 March 2022 at 19:40
To: "gnso-tpr@icann.org" <gnso-tpr@icann.org>
Subject: [GNSO-TPR] Notes and action items - TPR WG Meeting #40 - 29 Mar 2022

Dear TPR WG Members,

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

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

Best regards,

Emily, Julie, Berry, and Caitlin

Action Items:

ACTION ITEM: WG members to reply to the WG email distribution list if they are interested in joining a small team to review the NACKing/reasons for denial working document [docs.google.com] to finalize draft language for review by the full WG.

Transfer Policy Review Phase 1 - Meeting #40

Tuesday 29 March 2022 at 1600 UTC

1. Roll Call & SOI updates (5 minutes)

2. Welcome & Chair updates (5 minutes)

We left our denial/reasons for NACKing with open items; we are looking to have a spin-off small team to look at the NACKing working document to clean up any items we left open. Maybe 5-6 people. Trying to get the draft language solidified to bring to the group. If you are interested let us know. Good to have a representative group if possible.

3. Continue discussion on bulk use cases (75 minutes) – See: Working document [docs.google.com]

Question for discussion: Are there two different paths – one where a year is added on; the other moving from one registrar to another but not changing the life cycle?
Question for discussion: Registry back-end operators – how would a transaction identify as a bulk transfer when it was one of many? In a bulk scenario even if only 10 when they are going to multiple back-end registries? Would this be allowed? Put it differently, how many domain names do you need to make a bulk transfer?
Suggested Answer: (Theo Guerts) It is a question of scale. The sweet spot is around 2500 hundred domain names, because then you have to plan your transfers in batches. Suggest not adding an extra year with a bulk transfer.
Maybe there’s two types of bulk. Some registries do this already and some don’t.
If you transfer with multiple registries involved: If a registrar is contemplating transferring a bunch of names across registries – you could have ones that aren’t interrelated.
When we think about the normal transfer process it includes the extension of the registration term by 1 year in an automated fashion over EPP, subject to FOA and NACKing. ICANN has a bulk transfer method without term extensions, but that involves certain business considerations. There is a PPA (partial portfolio) not by EPP and not with a term extension, but as a registry service.
BTAPPA already does that and leaves the expiry date intact. (BTAPPA = Verisign bulk transfer service.)
Other registries offer BTAPPA as well. But certain qualifications have to be met to use it. Simple bulk transfers not in conjunction with a merger, sale, etc. are not allowed under BTAPPAs.
Question for Roger or staff: Is this out of scope for this WG?
When you do bulk transfers you have to prioritize. You go from TLD to TLD.
it’s not clear how us adding simple bulk transfer would impact ICANN’s expedited RSEP for BTAPPA.
Resellers often are out of the question and we are stuck.
Bulk transfer is a database switch from registrar to registrar.
When two different back-end registries are involved there are two different thought processes. Two separate scenarios.
Question: What number is considered bulk and does it apply to the registrar or registry?
Bulk transfers are a very sharp knife/powerful tool. They are a very focused thing.
Question for Theo: What did you mean by “resellers are stuck”? Answer: The transfer process is focused on the registrant being able to transfer wherever they like, and they have to help the resellers. Some registrars create barriers for resellers to transfer. A reseller can't easily move its business to a new Registrar. Resellers have the issue that they have no rights under the RAA.
For bulk transfers you may have three scenarios – a few names, some names, a huge number of names. Are there three buckets or more?
Holida can correct me if I am wrong, but I don't believe that there is a limit on who can report issues to Compliance. (Compliance agrees that this is a correct observation.)
How can we make a policy binding for a contracted party but also for resellers who are not contracted? Or is there a different way to handle this? We cannot create contract language for registrars.
RAA Sec. 3.12: Registrar is responsible for the provision of Registrar Services for all Registered Names that Registrar sponsors being performed in compliance with this Agreement, regardless of whether the Registrar Services are provided by Registrar or a third party, including a Reseller.
There are two things: bulk transfers and BTAPPA. Standard transfer policy has a lot of requirements, while the BTAPPA is an industry tool. BTAPPA wasn’t designed for bulk commercial use.
This bulk discussion is not about BTAPPA; we will talk about that later. Is there a policy that falls somewhere in between?
Don’t think there is a charter question related to extending a year for a transfer. (Staff confirmed that there is not.)
BTAPPA comes at a pretty high cost – would there be fees associated with a bulk transfer between BTAPPA and the current policy?
Is this a problem that this transfer policy should resolve, or does it fall outside of this policy? Maybe pose the question to the community and ask for suggestions?
Here is the charter question for the current phase of work: b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered?
Not sure the charter question above relates to the current discussion.
Questions for phase 2:
- In light of these challenges described in section 3.1.7.2 of the Final Issue Report, should the required fee in Section I.B.2 of the Transfer Policy be revisited or removed in certain circumstances?
- Should the scope of voluntary bulk transfers, including partial bulk transfers, be expanded and/or made uniform across all registry operators? If so, what types of rules and considerations should govern voluntary bulk transfers to partial bulk transfers?
Some of this discussion may be more appropriate for phase 2.

Charter Question b5) Should the ability for registrants to request AuthInfo Codes in bulk be streamlined and codified? If so, should additional security measures be considered?

Note: As a starting point, this charter question was added in response to the following feedback to the Transfer Policy Status Report Survey from the RrSG:[It’s] [d]ifficult for Registered Name Holders to retrieve [AuthInfo Codes] for a long list of domains as there are no requirements to permit bulk [AuthCode] requests. (Note: the discussion of partial bulk transfers and the BTAPPA process will be discussed in Phase 2 under question i2. This discussion is limited to the consideration of bulk retrieval of AuthInfo Codes.)

Do think there need to be additional security measures, compliance, and registries adding a claw-back option.
This is an interesting question – you get a bunch of names move in volume, but the request is to lower the security, which would make it more dangerous. Seems that we should be looking at additional security measures.
Notifications are a big part of that security mechanism – do they need to be enhanced?
Could bring in a lot of legal issues and problems for individual registrants, so having a claw-back mechanism could be helpful.
Re: the TAC and moving large numbers of names from one registrar to another – from a security point of view there should be one TAC per name, but if you want to simplify the process maybe think about extra security for getting the single TAC for multiple domain names. If you are going to do multiple transfers in parallel then the TACs should have extra security, such as two-factor authentication.
I’d like to see an additional communication method, requirement for password to be re-entered, capture of IP login etc. Just throwing some ideas out there.
In that scenario (using the same TAC on multiple domains) the Registrar could also remove (expire) the TAC after a shorter window.
Just because it’s possible to generate a TAC for each domain name transfer, doesn’t mean that all registrars will do it that way.
Should check to see if the current draft recommendations allow for efficient bulk transfers.
If we wanted to be most security then the TAC should be unique for each domain name at the registrar. If you are randomly generating them at each usage then you achieve that. But that is a bit tedious and not customer service friendly for bulk transfer, so you could add additional security feature for bulk transfers per domain name, such as two-factor authentication, or a shorter window for TAC identity. Maybe as a suggestion rather than a must.
If a TAC is unique at the registrar level is different from saying the TAC and domain name is unique.
136867 – example authorization code from Google as a two-factor authentication. It expires after a short time, a window during which it is valid. Needs to be paired with a URL for a certain amount of time.
The big focus is whether one TAC can be assigned to transfer multiple domain names and, if so, are there additional security measures.

4. AOB (5 minutes)

Next call: Tuesday 5 April 2022 at 16:00 UTC