2022-12-06 Transfer Policy Review PDP WG Call

PROPOSED AGENDA

1. Roll Call & SOI updates

2. Welcome and Chair Updates

3. Revised Reasons that a Registrar of Record MAY Deny a Transfer – Recommendation 19 (Public Comment Review Tool and Public Comment Working Document [docs.google.com])

4. New Reasons that a Registrar a Record MUST Deny a Transfer – Recommendation 20 (Public Comment Review Tool and Public Comment Working Document [docs.google.com])

5. Revised Reasons that a Registrar of Record MUST Deny a Transfer – Recommendation 21 (Public Comment Review Tool and Public Comment Working Document [docs.google.com])

6. Revised Reasons that a Registrar of Record MUST NOT Deny a Transfer – Recommendation 22 (Public Comment Review Tool and Public Comment Working Document [docs.google.com])

7. AOB

BACKGROUND DOCUMENTS

PARTICIPATION

Apologies:  Steinar Grøtterød (At-Large), James Galvin (RySG)

Alternates:  Lutz Donnerhacke (At-Large), Beth Bacon (RrSG)

RECORDINGS

Audio Recording

Zoom Recording

Chat Transcript (see zoom recording / chat messages tab)

GNSO transcripts are located on the GNSO Calendar

Notes/ Action Items

ACTION ITEMS/HOMEWORK:

Ongoing Action Items: Jothan Frakes, Jim Galvin, Jody Kolker, and Rick Wilhelm have volunteered to compile a list of attack vectors and how the recommendations solve for them, or where they are out of scope.

Action Items from 01 December:

1. Recommendation 13:  Question to the Community -- Small Team on TTL Enforcement: Send the proposal to the list with rationale.

2. Recommendation 19: Sarah Wyld to send the proposed revised language and rationale to the WG list on behalf of the Small Team.

3. Recommendation 22:

   1. a) Concern: Fees and b) Concern: Sanctions: Staff to ensure that the rationale reflects the WG’s discussion and agreement.

   2. c) Proposed edit: WG agrees to a revision to the Implementation Guidance as proposed in the Potential next step.

Notes:

1. Roll Call & SOI update

2. Welcome and Chair Updates

Summary of Process Updates from Staff sent to the list:

Process updates

• Rec 2 – Addition of Losing FOA

• Rec xx – Registry Operator provides Gaining Rr’s IANA ID to Losing Rr in the notification of pending transfer request, to be included in Losing FOA and Notification of Transfer Completion

Open Items

• Rec 6 – RrSG reps may suggest further clarifications regarding the designated representative

• Rec 11 – RySG reps may suggest further clarifications regarding when the TAC is considered “used” and is reset to null, relationship to TTL, and/or interaction with Ry Lock

• Rec 13 – Small team is working on a proposal regarding TTL enforcement

• Rec 16 & 17 – Small team is working on a proposal for exceptions to post-create and post-transfer restrictions on transfer

• General – Small group is working on developing a list of threat vectors that the proposed security model is and is not intended to address

 Additional Updates:

• Rec 11:

  • The TAC is used when the registry accepts it; if the registry denies the transfer request the TTL would live on and the TAC could still be used.  The ACK/NACK is still valid. 

  • Registries have some research on the reasons why a registry MAY and MUST deny a transfer.

  • The Gaining Registrar can validate a TAC with an INFO Command – but this does not constitute using it.

  • INFO command has been around for a long time to validate the TAC.  Many registries have mechanisms in place to detect brute force attacks.  RFC 9154 greatly reduces possibility of brute force attacks.

• Rec 13: Probably need to meet one more time, at least.

• Rec 16 & 17: Meeting one more time to see if they can agree on a proposal for the WG to consider.

3. Revised Reasons that a Registrar of Record MAY Deny a Transfer – Recommendation 19 (Public Comment Review Tooland Public Comment Working Document [docs.google.com])

• Extensive discussion on the last call on the wording, “Evidence of fraud or violation of the Registrar’s domain use or anti-abuse policies.”

• There was no strong agreement to change that wording.

• Without agreement on changes or on what is in the Initial Report, we would stay with the status quo, which is “evidence of fraud”.

• Could be helpful to establish a small team to re-evaluate the language over the next week.

ACTION ITEM: Recommendation 19: Small team to re-evaluate the language in Rec 19 -- WG members are -- Owen Smigelski, Sarah Wyld, Keiron Tobin, Zak Muscovitch, and Volker Greiman. See below.

4. New Reasons that a Registrar a Record MUST Deny a Transfer – Recommendation 20 (Public Comment Review Tooland Public Comment Working Document [docs.google.com])

a) Concerns

Discussion:

• WG members agreed that this was discussed and addressed; no further change are needed.

b) Proposed Edit

Discussion:

• WG members agreed that this was discussed and addressed; agreed to keep the language as “MAY”.

5. Revised Reasons that a Registrar of Record MUST Deny a Transfer – Recommendation 21 (Public Comment Review Tooland Public Comment Working Document [docs.google.com])

a) Concern regarding I.A.3.8.1 and I.A.3.8.2

Discussion:

• WG members agreed that this was discussed and addressed; no further change are needed

6. Revised Reasons that a Registrar of Record MUST NOT Deny a Transfer – Recommendation 22 (Public Comment Review Tooland Public Comment Working Document [docs.google.com])

a) Concern: Fees (I.A.3.9.1)

b) Concern: Sanctions

Discussion:

• WG did discuss fees and addressed that in the language.  Registrar can charge a fee, but registrant doesn’t have to pay that.

• We can add in the rationale that the WG discussed fees and agreed that it was out of scope.

• The WG also agreed that sanctions also are out of scope.  This also would duplicate the work in Work Stream 2.

ACTION ITEM: Recommendation 22, a) Concern: Fees and b) Concern: Sanctions: Staff to ensure that the rationale reflects the WG’s discussion and agreement.

c) Concern: Other

Discussion:

• WG has no further comments.

• WG agrees that no changes are necessary.

c) Proposed Edit

Discussion:

• Suggested edit is basically making the Implementation Note the same as the policy provision.

• Suggestion from staff is to emphasize that the Implementation Guidance is specifically about the Auto-Renew Grace Period.

ACTION ITEM: Recommendation 22, c) Proposed edit: WG agrees to a revision to the Implementation Guidance as proposed in the Potential next step.

 d) Proposed edit

e) Proposed edit

Discussion:

• No need for a required NACK; don’t see evidence for this – of illicit transfers,

• No need to define “reseller”.

• Auto NACK is not the way to go – no justification for it.

• WG agrees that there is no need for changes.

AOB: Small Team for Recommendation 19:

ACTION ITEM: Recommendation 19: Small team to re-evaluate the language in Rec 19 -- WG members are -- Owen Smigelski, Sarah Wyld, Keiron Tobin, Zak Muscovitch.

Discussion:

• Need to get the refined scope; probably not going to get the perfect language – need some way to reflect the work in the community on abuse.  Stronger than evidence of fraud but not too strong.

• Question: What are we trying to capture in an anti-abuse policy? Answer: “Evidence of fraud” is very narrow.  But there are concerns are that the suggested revision is too broad: “or violation of the Registrar’s domain use or anti-abuse policies”.

• Question: Why not put in exactly what we are trying to prevent/capture? Ex. Malware, phishing, etc?  Answer: Concerns about content regulation and future-proofing.

• As a reminder, there was another compromise proposal that was narrower than the Initial Report but broader than the status quo: “violation of registrar’s anti-abuse policies, or evidence of fraud”.

• What about “DNS abuse”?  ICANN has a definition for this. Could be the precise term we are looking for.

• DNS security threats include five broad categories of harmful activity:

  • Botnets

  • Malware

  • Pharming

  • Phishing

  • Spam (as it is used to propagate other DNS security threats).

• Can we just say “fraud” and “DNS abuse” – does this lower the bar?  Having “evidence” is important.

• Make it clear that “evidence” applies to “fraud” and “DNS abuse”.

• Suggested wording “"Evidence of (a) fraud or (b) the domain presents an active DNS security threat as defined here: <link>”.

• Small Team agrees with suggested language: "Evidence of (a) fraud or (b) the domain presents an active DNS security threat as defined here: <link>"

ACTION ITEM:  Recommendation 19: Sarah Wyld to send the proposed revised language and rationale to the WG list on behalf of the Small Team.