[GNSO-TPR] Notes and action items - TPR Meeting #18 - 21 September 2021

[Julie Hedlund]

Dear TPR Working Group,

Please find below the notes and action items from today’s TPR meeting on Tuesday, 21 September 2021 at 16:00 UTC.

The next meeting will be Tuesday, 28 September at 16:00 UTC.

Best regards,

Emily, Caitlin, Berry, and Julie
--

Action Items:

See the updated Work Plan and Action Items here: https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8uRQq4Oe5Q/edit?usp=sharing [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8uRQq4Oe5Q/edit?usp=sharing__;!!PtGJab4!qxlptUrJ1ANf6GnP-fUZ6w_hjjv1maS31O6P-jcfehCIc93D4QInTWi7OmJVvuXvAH-MaWGjsQ$>

Notes:

Transfer Policy Review Phase 1 - Meeting #18 – Tuesday, 21 September at 16:00 UTC
Proposed Agenda

1. Roll Call & SOI Updates (5 minutes)
2. Welcome & Chair updates (5 minutes)

  *   WG member updates: none.
  *   Leadership and staff are working on some draft candidate recommendations on AuthInfo codes/charter questions; we’ll be sending the document to WG members to review, probably this week.
3. Wrap up of discussion of Losing FOA (15 minutes) – see Losing FOA working document [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1wCUMe9ii6g05kUZ558IuUvJaS6K2t0GZJYvlfOy-raY/edit?usp=sharing__;!!PtGJab4!pH-fxLWYEprQO9DyqWSbC14W_OLC_culrcqZYtiJUsV_mPbV_Afa_Nw_JiR57DxQM2F9lhlp1w$> and Transfer Steps and Notifications chart [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/17ADMRTYxN5sA-e3WoEI96KxlH5YRALBsxgwOmpsCC0g/edit*gid=0__;Iw!!PtGJab4!pH-fxLWYEprQO9DyqWSbC14W_OLC_culrcqZYtiJUsV_mPbV_Afa_Nw_JiR57DxQM2GTrLFWQA$>

  *   Seems like we got to a very good spot last week. Got through all of the charter questions and perhaps ended up with having an early optional notification of TAC request, a required notification of TAC provision, and required notification of TAC completion.
4. New Topic: Gaining FOA (60 minutes) – see Gaining FOA Working Document<https://docs.google.com/document/d/1QOCzbLh7w4hdijpAsg6_lybddr0nlsFDcWjdz5e21Qo/edit?usp=sharing>
Highlights:

  *   Identical in format to the Losing FOA document.
  *   Language shows how the Gaining FOA has to be transmitted, to whom, when the Gaining FOA will expire and requirements for retention, actual of Gaining FOA in English, relevant language from Temporary Specification – registrar not currently required to send the Gaining FOA (until this is settled in this policy WG.
  *   Charter questions:
     *   Tables provide previous feedback.
     *   Relevant feedback from survey respondents (2018).
     *   WG may want to consider the highlighted questions:
        *   Concerns from registrars with wholesale elimination of Gaining FOA due to lack of a paper trail.
     *   Re: Temp Spec – “Until such time when the RDAP service (or other secure methods for transferring data) is required by ICANN to be offered…” is there another portal that could be used to transfer data?
  *   How we typically work is that nothing changes without consensus.  So we should look at what the reasons are for it not staying/being eliminated.
Discussion:

  *   Wondering how valuable are the previous comments (as in the table).  Don’t need to rethink some very old stuff.
  *   IRTP-D did deliberate this many years ago and the landscape has change.
  *   There are registrars that think this is important for evidentiary purposes.  If Gaining FOA is eliminated, how to mitigate these concerns.
  *   Could say that we have added the TAC notification as a replacement of the gaining FOA.  The board removed compliance enforcement because it’s not possible to follow today.
  *   What are the reasons to get rid of it/replace it?
  *   Is the Gaining FOA still needed?  We haven’t been providing it for the last few years.
  *    If you make it a requirement then you will have to find a way to do it under GDPR.
Charter Questions:
a1) Is the requirement of the Gaining FOA still needed? What evidence did the Working Group rely upon in making the determination that the Gaining FOA is or is not necessary to protect registrants?
Green Bullet Point Responses (YES column):

  *   First bullet:
     *   The requirement to have a paper trail is a good one, but doesn’t have to happen with the Gaining FOA.  We could find another way.
     *   Does the gaining FOA add any security for the registrant that is not afforded adequately elsewhere in the process. For the “other stuff” I agree with Sarah, let’s see if we can retain it somewhere else in the process.
  *   Second bullet: Does the Gaining FOA provide a tool for the registries?  WG members from Registries can check.
  *   Third bullet: maybe the Losing FOA notifications address this concern (“It is very important that the FOA confirmation letter is sent to the original registrant, which may affect the security of the domain name.”)
  *   Fourth bullet:
     *   Can see that it is handy to have, such as in China, but wonder if what is stated here is still accurate.
     *   We can’t decide what personal data could be public, or is there a way to make this happen behind the scenes?
     *   Can’t see any way how the gaining registrar should be able to get the current registrant e-mail.
     *   This bullet isn't telling us any new factors we need to include. So far all we have is that we should have some sort of paper trail to rely on in disputes, which we're already doing with the TAC and other notification process.
     *   The gist so far from these comments is that we need some way of logging a transfer took place.
     *   We have the TAC and the notifications that have already been discussed.
     *   We don’t have any ideas on how to share the personal data (current Registrant information including the losing registrar's name, the Registrant Name & Organization, the Registrant Email Address, Phone etc, so the gaining registrar still can send the FOA Email to the Registrant for authorization.)
     *   Sounds like the WG would be in favor of transferring the data if it was possible under GDPR.  Nice to have but not realistic anymore.
  *   Fifth bullet:
     *   This is the record-keeping piece again.
     *   This one and the next one are just to protect against bad transfers/disputes.
  *   Sixth bullet (re: mitigate unauthorized transfer):
     *   Think we have moved this to the actual TAC itself.  That the TAC is only valid during transfer.
     *   ICANN Compliance: We have seen reporters file complaints about not receiving AuthInfo codes because they needed it in order to transfer resellers. Not sure if the AuthInfo code was actually needed to transfer resellers or if Reporter just didn’t understand the difference between switching resellers and switching registrars.  Most cases get closed after educating reporters and finding that requests are not for inter-registrar transfer.
  *   Seventh bullet (must have approval from registrant):
     *   We have them notified, if not approval.
     *   The notification of the TAC goes to the registrant and enables them to stop the transfer.
     *   From understanding of GDPR the transfer of the domain does require extraordinary measures to protect the data subject and a lawful basis can be determined to transfer the data.  The WG could consider asking for legal advice – would be a budget request to the GNSO Council.
     *   We will need consensus to undo this and the WG should think about whether there is a better solution to deliver the benefits.
     *   Keeping it alive is impossible.  Why process the data if it’s not required?
     *   Data minimization = use the least amount of data possible to do the job. We know we can do transfers securely without having the losing registrar send RNH data to the gaining registrar, so minimization tells us not to.
     *   Or we could look at lawful bases and see if they apply. Performance of the contract doesn’t work, because the contract is not between losing and gaining registrars. Consent also is hard to convey to a third party with certainty that it’s valid. Legitimate interest means the need to process data must outweigh the privacy rights, and since we know we can do transfers without it, that doesn’t apply.
  *   Eight bullet (re: hijack): Back to the issue of providing a paper trail.  Solved by record-keeping.
  *   Ninth bullet (mandatory email notices): We are solving this.
  *   Tenth bullet: Goes back to the TAC (confirming a transfer).
  *   Eleventh bullet: Goes to having the proper documentation in place to confirm the transfer.
     *   Disagree that it's always better to have more records. We should have the right records and we should employ the 'data minimization' principle discussed earlier.
  *   Twelfth bullet: Dealt with this.  Replaced with Losing FOA notification and TAC.
  *   Thirteenth bullet (last re: evidence for court cases/disputes):
     *   Wonder how this is dealt with now without Gaining FOA?
     *   Disputes plug into this.
Red Bullet Point Responses (NO column): We have already been raising these points.  Will be important to look at for rationale.
A2) If the Working Group determines the Gaining FOA should still be a requirement, are any updates (apart from the text, which will likely need to be updated due to the gTLD Registration Data Policy) needed for the process? For example, should additional security requirements be added to the Gaining FOA (two-factor authentication)?

  *   The last sentence – we took the Losing FOA a little broader to answer the question about additional security requirements.
  *   Think we've established that there should be new/different security requirements, and that is separate from the FOA, so we should move on.
Green Bullet Point Responses (YES column);

  *   First bullet (re: verification, not just notification):  Seems we have addressed this.
  *   Second bullet (re: sharing registrant’s email through registry):
     *   Doesn’t change the legal issues.
     *   Via registry is better than entirely public, but I think we've already established that we don't need it.
a3) The language from the Temporary Specification provides, “[u]ntil such time when the RDAP service (or other secure methods for transferring data) is required by ICANN to be offered, if the Gaining Registrar is unable to gain access to then-current Registration Data for a domain name subject of a transfer, the related requirements in the Transfer Policy will be superseded by the below provisions...”. What secure methods (if any) currently exist to allow for the secure transmission of then-current Registration Data for a domain name subject to an inter-registrar transfer request?

  *   Don’t think we need to answer this question because we’ve decided that we don’t need the data – no purpose for it.
  *   If there is a reason for this to happen, we’d need to come up with a mechanism.  We haven’t needed it for 3 years.
  *   Gets back to the question – is it necessary to transfer the data?  We have shown that we don’t need to process vast amounts of data for a transfer.
  *   Seems that we’ve already had this discussion.
5.  AOB (5 minutes)

  *   Next meeting: 28 September 2021 @ 16.00 UTC
  *   Start with Chart Question 4.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-tpr/attachments/20210921/1e8f11a9/attachment-0001.html>