June 2021 - GNSO-TPR - lists.icann.org

Re: [GNSO-TPR] [Ext] RE: Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs
by Emily Barabas July 2, 2021

July 2, 2021

Hi Barbara, Thanks for continuing the discussion on this issue. In looking again at the clarification text I shared below, and realizing that it might be helpful to frame this a little differently to explain why we are talking about “thin” Registries: The Gaining Registrar has a choice under the Transfer Policy between looking at Whois data from the Registrar of Record or the Registry. There are cases where the Gaining Registrar decides to go to the Registry rather than the Registrar of Record, even though the Registry is "thin" and displays less information than the Registrar of Record. As a result of making this choice, the Gaining Registrar does not access the necessary information to send a Gaining FOA, and proceeds with the workaround in which the Registrant manually re-enters information with the Gaining Registrar. The Registrant does not need to follow COR requirements in this scenario even if the information they enter with the Gaining Registrar is different from the information used with the Registrar of Record. Please let me know if this summary helps to clarify. Kind regards, Emily From: "Knight, Barbara" <bknight(a)verisign.com> Date: Thursday, 24 June 2021 at 18:44 To: Emily Barabas <emily.barabas(a)icann.org>, "swyld(a)tucows.com" <swyld(a)tucows.com>, "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [Ext] RE: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs Hi Emily, I am fine with the clarification but still contend that for it to be accurate, you will need to change “thin” (highlighted below) to “thick” as it is my understanding that thin is intended to refer to the registry and registries that are thin do not have registrant or other contact information associated with domain names. Registrars would only be able to obtain the data from registries that are “thick”. Thanks. Regards, Barbara From: Emily Barabas <emily.barabas(a)icann.org> Sent: Wednesday, June 23, 2021 3:15 PM To: Knight, Barbara <bknight(a)verisign.com>; swyld(a)tucows.com; gnso-tpr(a)icann.org Subject: [EXTERNAL] Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Barbara and Sarah, Please find below a clarification regarding the scenario described in charter question d3: * Gaining Registrar allows a new customer to input the Registrant information when requesting an inbound inter-registrar transfer. The information entered by the customer does not match Registration Data available in the Whois display. * In the case of “thin” domain names, the Gaining Registrar obtains information from the Registry. These two items are interrelated and describe the situation when the Losing Registrar’s RDDS displayed the registration data at the time of transfer request, and the Gaining Registrar did not use Losing Registrar’s RDDS to verify the authenticity of a transfer request, but obtained information from the Registry RDDS output and therefore registration data was not available to send a Gaining FOA (when cases involve “thin” domain names, Registry RDDS does not list the Registrant data, while Registrar RDDS still displays it). Section I.A.1.1. of the Transfer Policy states, “Registrars may use Whois data from either the Registrar of Record or the relevant Registry for the purpose of verifying the authenticity of a transfer request; or from another data source as determined by a consensus policy.” It appeared the Gaining Registrar could use either the Registrar or Registry output. This was also relevant because the Gaining Registrar would then not be required to follow COR requirements because Appendix G Section 1.2 states if the Gaining Registrar is unable to gain access to then-current Registration Data for a domain name subject of a transfer, “Registrant MUST independently re-enter Registration Data with the Gaining Registrar. In such instance, the Gaining Registrar is not REQUIRED to follow the Change of Registrant Process as provided in Section II.C. of the Transfer Policy.” Because there is no requirement in the Transfer Policy that requires a Gaining Registrar to obtain registration data from the Losing Registrar, ICANN Compliance is unable to point out a specific section when the Gaining Registrar does not apply the COR process even when the Registration Data is available from the Losing Registrar’s RDDS output. Kind regards, Emily From: GNSO-TPR <gnso-tpr-bounces(a)icann.org<mailto:gnso-tpr-bounces@icann.org>> on behalf of "Knight, Barbara via GNSO-TPR" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Reply to: "Knight, Barbara" <bknight(a)verisign.com<mailto:bknight@verisign.com>> Date: Wednesday, 23 June 2021 at 20:38 To: "swyld(a)tucows.com<mailto:swyld@tucows.com>" <swyld(a)tucows.com<mailto:swyld@tucows.com>>, "gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs I agree with Sarah’s comments relating to the questions relating to DNS. With regard to the alternative language to correct the “thin” issue, I think that we have to be careful on this one. Even in cases where the Registry holds the data relating to the registrant and admin contacts, technically, the registrar data is authoritative. Further, if there is a proxy or privacy service or the data is redacted due to privacy laws, the registry would most likely not have the underlying data. Given this, I am not sure what the answer is on how to clarify. Regards, Barbara From: GNSO-TPR <gnso-tpr-bounces(a)icann.org<mailto:gnso-tpr-bounces@icann.org>> On Behalf Of Sarah Wyld Sent: Wednesday, June 23, 2021 2:08 PM To: Roger D Carney via GNSO-TPR <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: [EXTERNAL] Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi all, I thought we had confirmed at recent meetings that transferring DNS settings is not in scope for this PDP as it was not included in the scoping paper, issues report, etc. As such, I’m concerned that if we add in questions on that topic to our request for early input it will confuse responders and set inaccurate expectations about what is in scope here. I do agree with the comment on point d4, "thin” is out of place. Perhaps it could say “In cases where the Registry holds registration data, the Gaining Registrar obtains information from the Registry.” Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/her swyld(a)tucows.com<mailto:swyld@tucows.com> +1.416 535 0123 Ext. 1392 [cid:image001.png@01D7683D.15EFCD90] From: Steve Crocker<mailto:steve@shinkuro.com> Sent: June 23, 2021 1:54 PM To: Emily Barabas<mailto:emily.barabas@icann.org> Cc: gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org> Subject: Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs Emily, et al, I have added some words related to coordination of DNS operations during a change of registrar. I was not able to edit the document directly via Google docs, so I downloaded the document and inserted changes. Tracking is turned on. I inserted my suggested changes between "c" and "d" so I used the letter x. I believe this belongs in this phase, 1a, because phase 1b looks like it's focused specifically on a change of registrant. The question of coordination of DNS operation could be relevant during a change of registrant but will be much more likely to be relevant during a change of registrar without a change of registrant. Thanks, Steve On Wed, Jun 23, 2021 at 6:08 AM Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> wrote: Dear Working Group members, Tomorrow, Thursday, 24 June is the last day to suggest edits to the outreach letter to SO/AC/SG/Cs: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> As a point of clarification, the current task is to make sure that the text of the letter is acceptable and determine if any additional questions need to be asked of SO/AC/SG/Cs as part of this request for input beyond the listed charter questions. Once the WG has finalized the letter, it will be sent to SO/AC/SG/Cs who will have approximately five weeks to respond. Please feel free to reach out with any questions. Kind regards, Emily, Julie, Caitlin, and Berry From: GNSO-TPR <gnso-tpr-bounces(a)icann.org<mailto:gnso-tpr-bounces@icann.org>> on behalf of Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> Date: Monday, 21 June 2021 at 11:39 To: "gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: [GNSO-TPR] Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs Dear Working Group members, As a reminder, if you would like suggest additional questions to include in the request for early input to SO/AC/SG/Cs, please add these questions to the Google Doc no later than this Thursday, 24 June: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> Kind regards, Emily, Julie, Caitlin, and Berry From: Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> Date: Tuesday, 8 June 2021 at 19:28 To: "gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs Dear Working Group members, As discussed on today’s call, the leadership team has prepared a draft outreach document to send to SO/AC/SG/Cs requesting early input on the topics within the TRP PDP’s charter. You can find the draft here: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> If you would like to propose edits to the text or would like to suggest additional questions for early input to include in the document, please add comments directly into the Google Document. If anyone is unable to use Google Drive, Word and PDF versions are attached for reference. You can also use Google Doc comments to provide feedback on questions or edits that have been proposed by other members. Please provide your input no later than 24 June 2021. The Working Group call on 29 June will be focused on finalizing this document for submission to the SO/AC/SG/Cs. Kind regards, Emily, Julie, Caitlin, and Berry Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org [secure-web.cisco.com]<https://urldefense.com/v3/__http:/secure-web.cisco.com/1oS_8dAlACq_cWvUqN4f…> _______________________________________________ GNSO-TPR mailing list GNSO-TPR(a)icann.org<mailto:GNSO-TPR@icann.org> https://mm.icann.org/mailman/listinfo/gnso-tpr [secure-web.cisco.com]<https://urldefense.com/v3/__https:/secure-web.cisco.com/1ILLIILxFHVpSlgFinN…>

2 1

Re: [GNSO-TPR] Notes and action items - TPR Meeting #06 - 29 June 2021
by Emily Barabas June 30, 2021

June 30, 2021

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(a)icann.org> on behalf of Caitlin Tubergen <caitlin.tubergen(a)icann.org> Date: Tuesday, 29 June 2021 at 21:55 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)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/1FunWaz3g…> 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-rE…) * 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-Q1qVWtJNPKiQLbI7Vh…) * 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=… [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_obh0… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…>. · 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

1 0

Notes and action items - TPR Meeting #06 - 29 June 2021
by Caitlin Tubergen June 29, 2021

June 29, 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<https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8u…> 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-rE…) * 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-Q1qVWtJNPKiQLbI7Vh…) * 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=… [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_obh0… [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/document/d/1O9PAnxWFUuPo…>. · 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

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 06 July 2021 at 16:00 UTC
by Andrea Glandon June 29, 2021

June 29, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 06 July 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> Visit the Wiki Agenda meeting page: https://community.icann.org/x/WgTpCQ Check your time zone: https://tinyurl.com/3zvakspb ONLY FOR MEMBERS & ALTERNATES: * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Please rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Andrea

1 0

Post Call | Transfer Policy Review PDP WG | Tuesday, 29 June 2021 at 16:00 UTC
by Andrea Glandon June 29, 2021

June 29, 2021

Dear all, All recordings for the Transfer Policy Review PDP WG call held on Tuesday, 29 June 2021 at 16:00 UTC can be found on the agenda wiki page <https://community.icann.org/x/VwTpCQ> (attendance included) and the GNSO Master calendar [gnso.icann.org]<https://urldefense.com/v3/__https:/gnso.icann.org/en/group-activities/calen…>. These include: * Attendance (please let me know if your name has been left off the attendance list) * Audio recording * Zoom chat archive * Zoom recording (including audio, visual, rough transcript) * Transcript As a reminder only members and alternates can join the call as a Panelist, observers can join as an Attendee to listen. For additional information, you may consult the mailing list archives <https://mm.icann.org/pipermail/gnso-tpr/> and the main wiki page<https://community.icann.org/x/P4aUCQ>. Thank you. With kind regards, Andrea

1 0

**Meeting begins in 15 minutes** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 29 June 2021 at 16:00 UTC
by Andrea Glandon June 29, 2021

June 29, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 29 June 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> Visit the Wiki Agenda meeting page: https://community.icann.org/x/VwTpCQ Check your time zone: https://tinyurl.com/5k3u34hf [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5k3u34hf__;!!PtGJab4!ukWZuIg…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Please rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

**REMINDER** Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 29 June 2021 at 16:00 UTC
by Julie Bisland June 28, 2021

June 28, 2021

Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 29 June 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> Visit the Wiki Agenda meeting page: https://community.icann.org/x/VwTpCQ Check your time zone: https://tinyurl.com/5k3u34hf [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5k3u34hf__;!!PtGJab4!ukWZuIg…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Please rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs
by DiBiase, Gregory June 25, 2021

June 25, 2021

I have to agree with Volker here. If registrars are not required to provide DNS service for a particular domain that they manage (to my knowledge provision of this service is not mandated anywhere in ICANN policy or bylaws), I think DNS service falls outside the scope of the Transfer Policy. Thanks, Greg From: Volker Greimann <vgreimann(a)key-systems.net> Sent: Thursday, June 24, 2021 2:42 AM To: Steve Crocker <steve(a)shinkuro.com> Cc: DiBiase, Gregory <dibiase(a)amazon.com>; gnso-tpr(a)icann.org Subject: RE: [EXTERNAL] [GNSO-TPR] Final Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. I still think this is out of scope for domain transfers as it is an ancillary optional service that becomes imp[ortant on the occasion of the transfer, but is not relevant for the function of the transfer itself and falls outside our remit. -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net/> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Thu, Jun 24, 2021 at 2:19 AM Steve Crocker <steve(a)shinkuro.com<mailto:steve@shinkuro.com>> wrote: Greg, Thanks for your email. I'm suggesting that registrars who provide DNS service should cooperate in transition and multi-operation of DNS service. While it is true that only some registrants use their registrar's DNS service, it is also true that almost all registrars offer DNS service to their registrants. Moreover, they usually do so free of charge. I try not to lump DNS service with other services. The other services, e.g. hosting and mail depend on DNS, but DNS service is not dependent on any of those. In this sense DNS is part of the infrastructure and not the same as applications. Steve On Wed, Jun 23, 2021 at 8:09 PM DiBiase, Gregory <dibiase(a)amazon.com<mailto:dibiase@amazon.com>> wrote: Hi Steve, DNS service will not always be provided by the gaining or losing registrar. Are you suggesting conditional rules (e.g., if the registrar of record is providing DNS service, then xyz…) may be warranted? In other words, there could be additional obligations for registrars depending on what ancillary services they offer a particular customer? Thanks, Greg From: GNSO-TPR <gnso-tpr-bounces(a)icann.org<mailto:gnso-tpr-bounces@icann.org>> On Behalf Of Steve Crocker Sent: Wednesday, June 23, 2021 1:03 PM To: Volker Greimann <vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net>> Cc: gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org> Subject: RE: [EXTERNAL] [GNSO-TPR] Final Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe. Volker, I'm certainly not suggesting ICANN *regulate* hosting and mail services. Hosting and mail services are almost always sold as separate services. DNS is usually provided for free. Further, DNS is a supporting service, not a user service. But the implied sense of your question is that we're talking about ICANN *regulating* DNS service. I think that's too narrow of an interpretation. ICANN's interest, and, indeed what everyone's interest should be, is for users to receive reliable and safe service. DNS service falls into a bit of a gray area because it's often supplied by the registrar at no additional cost and hence intimately entangled in the registration service. This is helpful to the registrants, so that's good. But it also means it comes into play during a transfer. The basic proposition, which I think everyone here is working towards, is that registrars should work cooperatively to provide a smooth transition during transfers. In those cases where the registrar is providing DNS service, this means working cooperatively to provide smooth transition of the DNS service during transfers. Thanks, Steve On Wed, Jun 23, 2021 at 3:43 PM Volker Greimann <vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net>> wrote: Hi Steve, with regard to registrar services, DNS services are ancillary services at best and mostly fall outside of the ICANN mandate. Many registrants do not use the free DNS services provided by many registrars but third party services. Yes, it is true that many registrants do use the services of their registrar, and that sloppy planning of a migration can lead to outages, but that is not a service that ICANN regulates, or should regulate. The same issues apply when the losing registrar provides hosting or mail services after all. If not done well, there will be outages. Are you suggesting ICANN should regulate hosting and mail services as well? -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net/> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Wed, Jun 23, 2021 at 8:54 PM Steve Crocker <steve(a)shinkuro.com<mailto:steve@shinkuro.com>> wrote: Volker, If the registrar is also supplying the DNS service and the registrant initiates a change of registrar, the existing registrar will stop providing the DNS service. Therefore, the registrant is forced to change DNS service as part of changing registrars. If the registrant also wishes for the DNS service to continue to work during the transition, some careful coordination between the two DNS operations is required. Steve On Wed, Jun 23, 2021 at 2:08 PM Volker Greimann <vgreimann(a)key-systems.net<mailto:vgreimann@key-systems.net>> wrote: I keep wondering what DNS settings and operations have to do with transfers in the first place. Surely the correct DNS settings are the responsibility of the registrant? Volker On Wed 23. Jun 2021 at 19:54, Steve Crocker <steve(a)shinkuro.com<mailto:steve@shinkuro.com>> wrote: Emily, et al, I have added some words related to coordination of DNS operations during a change of registrar. I was not able to edit the document directly via Google docs, so I downloaded the document and inserted changes. Tracking is turned on. I inserted my suggested changes between "c" and "d" so I used the letter x. I believe this belongs in this phase, 1a, because phase 1b looks like it's focused specifically on a change of registrant. The question of coordination of DNS operation could be relevant during a change of registrant but will be much more likely to be relevant during a change of registrar without a change of registrant. Thanks, Steve On Wed, Jun 23, 2021 at 6:08 AM Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> wrote: Dear Working Group members, Tomorrow, Thursday, 24 June is the last day to suggest edits to the outreach letter to SO/AC/SG/Cs: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> As a point of clarification, the current task is to make sure that the text of the letter is acceptable and determine if any additional questions need to be asked of SO/AC/SG/Cs as part of this request for input beyond the listed charter questions. Once the WG has finalized the letter, it will be sent to SO/AC/SG/Cs who will have approximately five weeks to respond. Please feel free to reach out with any questions. Kind regards, Emily, Julie, Caitlin, and Berry From: GNSO-TPR <gnso-tpr-bounces(a)icann.org<mailto:gnso-tpr-bounces@icann.org>> on behalf of Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> Date: Monday, 21 June 2021 at 11:39 To: "gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: [GNSO-TPR] Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs Dear Working Group members, As a reminder, if you would like suggest additional questions to include in the request for early input to SO/AC/SG/Cs, please add these questions to the Google Doc no later than this Thursday, 24 June: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> Kind regards, Emily, Julie, Caitlin, and Berry From: Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> Date: Tuesday, 8 June 2021 at 19:28 To: "gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs Dear Working Group members, As discussed on today’s call, the leadership team has prepared a draft outreach document to send to SO/AC/SG/Cs requesting early input on the topics within the TRP PDP’s charter. You can find the draft here: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> If you would like to propose edits to the text or would like to suggest additional questions for early input to include in the document, please add comments directly into the Google Document. If anyone is unable to use Google Drive, Word and PDF versions are attached for reference. You can also use Google Doc comments to provide feedback on questions or edits that have been proposed by other members. Please provide your input no later than 24 June 2021. The Working Group call on 29 June will be focused on finalizing this document for submission to the SO/AC/SG/Cs. Kind regards, Emily, Julie, Caitlin, and Berry Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/> _______________________________________________ GNSO-TPR mailing list GNSO-TPR(a)icann.org<mailto:GNSO-TPR@icann.org> https://mm.icann.org/mailman/listinfo/gnso-tpr _______________________________________________ GNSO-TPR mailing list GNSO-TPR(a)icann.org<mailto:GNSO-TPR@icann.org> https://mm.icann.org/mailman/listinfo/gnso-tpr -- -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net/> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached.

5 4

20 Jul 21 Cancellation-Transfer Policy Review PDP WG
by Andrea Glandon June 25, 2021

June 25, 2021

Dear all, Apologies for the confusion. Only the meeting for 20 July 2021 was cancelled due to conflicts for the chair and the liaison. Only this meeting was cancelled in Outlook, all other occurrences should still be on your calendar. Thank you. Andrea Glandon GNSO SO/AC Support Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: acglandon76 Find out more about the GNSO by visiting: https://learn.icann.org/ Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO [twitter.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar [gnso.icann.org]<https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Canceled: Transfer Policy Review PDP WG
by ICANN Policy Calendar June 25, 2021

June 25, 2021

Meeting: Transfer Policy Review PDP WG Date/Time: Recurring call every Tuesday at 16:00 UTC for 90 minutes, 29 June 2021 through 31 August 2021 Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> Visit the 29 June Wiki Agenda meeting page: https://community.icann.org/x/VwTpCQ (see left side for other meeting dates) Check your time zone: https://tinyurl.com/5k3u34hf ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form<https://docs.google.com/forms/d/e/1FAIpQLScXP3-H595xH4EFgaR3ydOr-1o9BLAVGUI…> to communicate who the alternate is replacing and for which period. This information will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For Audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6

2 1

Proposed agenda for meeting #06 on Tuesday 29 June 2021 at 16.00 UTC
by Emily Barabas June 25, 2021

June 25, 2021

Dear Working Group members, Please find below the proposed agenda for the meeting scheduled to take place on Tuesday 29 June 2021 at 16.00 UTC. Kind regards, Emily, Julie, Caitlin, and Berry 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) 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=… 4. Presentation of updated metrics from ICANN Contractual Compliance (10 minutes) * Please see attached metrics, which will be explained on the call. 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_obh0…. 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 6. AOB (5 minutes) Next meeting: 6 July 2021 @ 16.00 UTC Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs
by Knight, Barbara June 24, 2021

June 24, 2021

I agree with Sarah’s comments relating to the questions relating to DNS. With regard to the alternative language to correct the “thin” issue, I think that we have to be careful on this one. Even in cases where the Registry holds the data relating to the registrant and admin contacts, technically, the registrar data is authoritative. Further, if there is a proxy or privacy service or the data is redacted due to privacy laws, the registry would most likely not have the underlying data. Given this, I am not sure what the answer is on how to clarify. Regards, Barbara From: GNSO-TPR <gnso-tpr-bounces(a)icann.org> On Behalf Of Sarah Wyld Sent: Wednesday, June 23, 2021 2:08 PM To: Roger D Carney via GNSO-TPR <gnso-tpr(a)icann.org> Subject: [EXTERNAL] Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi all, I thought we had confirmed at recent meetings that transferring DNS settings is not in scope for this PDP as it was not included in the scoping paper, issues report, etc. As such, I’m concerned that if we add in questions on that topic to our request for early input it will confuse responders and set inaccurate expectations about what is in scope here. I do agree with the comment on point d4, "thin” is out of place. Perhaps it could say “In cases where the Registry holds registration data, the Gaining Registrar obtains information from the Registry.” Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/her swyld(a)tucows.com<mailto:swyld@tucows.com> +1.416 535 0123 Ext. 1392 From: Steve Crocker<mailto:steve@shinkuro.com> Sent: June 23, 2021 1:54 PM To: Emily Barabas<mailto:emily.barabas@icann.org> Cc: gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org> Subject: Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June:Draft outreach document requesting early input from SO/AC/SG/Cs Emily, et al, I have added some words related to coordination of DNS operations during a change of registrar. I was not able to edit the document directly via Google docs, so I downloaded the document and inserted changes. Tracking is turned on. I inserted my suggested changes between "c" and "d" so I used the letter x. I believe this belongs in this phase, 1a, because phase 1b looks like it's focused specifically on a change of registrant. The question of coordination of DNS operation could be relevant during a change of registrant but will be much more likely to be relevant during a change of registrar without a change of registrant. Thanks, Steve On Wed, Jun 23, 2021 at 6:08 AM Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> wrote: Dear Working Group members, Tomorrow, Thursday, 24 June is the last day to suggest edits to the outreach letter to SO/AC/SG/Cs: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> As a point of clarification, the current task is to make sure that the text of the letter is acceptable and determine if any additional questions need to be asked of SO/AC/SG/Cs as part of this request for input beyond the listed charter questions. Once the WG has finalized the letter, it will be sent to SO/AC/SG/Cs who will have approximately five weeks to respond. Please feel free to reach out with any questions. Kind regards, Emily, Julie, Caitlin, and Berry From: GNSO-TPR <gnso-tpr-bounces(a)icann.org<mailto:gnso-tpr-bounces@icann.org>> on behalf of Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> Date: Monday, 21 June 2021 at 11:39 To: "gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: [GNSO-TPR] Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs Dear Working Group members, As a reminder, if you would like suggest additional questions to include in the request for early input to SO/AC/SG/Cs, please add these questions to the Google Doc no later than this Thursday, 24 June: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> Kind regards, Emily, Julie, Caitlin, and Berry From: Emily Barabas <emily.barabas(a)icann.org<mailto:emily.barabas@icann.org>> Date: Tuesday, 8 June 2021 at 19:28 To: "gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>" <gnso-tpr(a)icann.org<mailto:gnso-tpr@icann.org>> Subject: Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs Dear Working Group members, As discussed on today’s call, the leadership team has prepared a draft outreach document to send to SO/AC/SG/Cs requesting early input on the topics within the TRP PDP’s charter. You can find the draft here: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> If you would like to propose edits to the text or would like to suggest additional questions for early input to include in the document, please add comments directly into the Google Document. If anyone is unable to use Google Drive, Word and PDF versions are attached for reference. You can also use Google Doc comments to provide feedback on questions or edits that have been proposed by other members. Please provide your input no later than 24 June 2021. The Working Group call on 29 June will be focused on finalizing this document for submission to the SO/AC/SG/Cs. Kind regards, Emily, Julie, Caitlin, and Berry Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://secure-web.cisco.com/1oS_8dAlACq_cWvUqN4f7y0muWP-pmJni073GXfM130lPs5…> _______________________________________________ GNSO-TPR mailing list GNSO-TPR(a)icann.org<mailto:GNSO-TPR@icann.org> https://mm.icann.org/mailman/listinfo/gnso-tpr<https://secure-web.cisco.com/1ILLIILxFHVpSlgFinNdQHz5rZEitnX2lnFbhqDIZuXFBi…>

2 2

Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs
by Steve Crocker June 24, 2021

June 24, 2021

Volker, I'm certainly not suggesting ICANN *regulate* hosting and mail services. Hosting and mail services are almost always sold as separate services. DNS is usually provided for free. Further, DNS is a supporting service, not a user service. But the implied sense of your question is that we're talking about ICANN *regulating* DNS service. I think that's too narrow of an interpretation. ICANN's interest, and, indeed what everyone's interest should be, is for users to receive reliable and safe service. DNS service falls into a bit of a gray area because it's often supplied by the registrar at no additional cost and hence intimately entangled in the registration service. This is helpful to the registrants, so that's good. But it also means it comes into play during a transfer. The basic proposition, which I think everyone here is working towards, is that registrars should work cooperatively to provide a smooth transition during transfers. In those cases where the registrar is providing DNS service, this means working cooperatively to provide smooth transition of the DNS service during transfers. Thanks, Steve On Wed, Jun 23, 2021 at 3:43 PM Volker Greimann <vgreimann(a)key-systems.net> wrote: > Hi Steve, > > with regard to registrar services, DNS services are ancillary services at > best and mostly fall outside of the ICANN mandate. Many registrants do not > use the free DNS services provided by many registrars but third party > services. Yes, it is true that many registrants do use the services of > their registrar, and that sloppy planning of a migration can lead to > outages, but that is not a service that ICANN regulates, or should > regulate. > The same issues apply when the losing registrar provides hosting or mail > services after all. If not done well, there will be outages. > > Are you suggesting ICANN should regulate hosting and mail services as well? > > -- > Volker A. Greimann > General Counsel and Policy Manager > *KEY-SYSTEMS GMBH* > > T: +49 6894 9396901 > M: +49 6894 9396851 > F: +49 6894 9396851 > W: www.key-systems.net > > Key-Systems GmbH is a company registered at the local court of > Saarbruecken, Germany with the registration no. HR B 18835 > CEO: Oliver Fries and Robert Birkner > > Part of the CentralNic Group PLC (LON: CNIC) a company registered in > England and Wales with company number 8576358. > > This email and any files transmitted are confidential and intended only > for the person(s) directly addressed. If you are not the intended > recipient, any use, copying, transmission, distribution, or other forms of > dissemination is strictly prohibited. If you have received this email in > error, please notify the sender immediately and permanently delete this > email with any files that may be attached. > > > On Wed, Jun 23, 2021 at 8:54 PM Steve Crocker <steve(a)shinkuro.com> wrote: > >> Volker, >> >> If the registrar is also supplying the DNS service and the registrant >> initiates a change of registrar, the existing registrar will stop providing >> the DNS service. Therefore, the registrant is forced to change DNS service >> as part of changing registrars. If the registrant also wishes for the DNS >> service to continue to work during the transition, some careful >> coordination between the two DNS operations is required. >> >> Steve >> >> >> On Wed, Jun 23, 2021 at 2:08 PM Volker Greimann < >> vgreimann(a)key-systems.net> wrote: >> >>> I keep wondering what DNS settings and operations have to do with >>> transfers in the first place. Surely the correct DNS settings are the >>> responsibility of the registrant? >>> Volker >>> >>> On Wed 23. Jun 2021 at 19:54, Steve Crocker <steve(a)shinkuro.com> wrote: >>> >>>> Emily, et al, >>>> >>>> I have added some words related to coordination of DNS operations >>>> during a change of registrar. I was not able to edit the document directly >>>> via Google docs, so I downloaded the document and inserted changes. >>>> Tracking is turned on. I inserted my suggested changes between "c" and "d" >>>> so I used the letter x. >>>> >>>> I believe this belongs in this phase, 1a, because phase 1b looks like >>>> it's focused specifically on a change of registrant. The question of >>>> coordination of DNS operation could be relevant during a change of >>>> registrant but will be much more likely to be relevant during a change of >>>> registrar without a change of registrant. >>>> >>>> Thanks, >>>> >>>> Steve >>>> >>>> >>>> On Wed, Jun 23, 2021 at 6:08 AM Emily Barabas <emily.barabas(a)icann.org> >>>> wrote: >>>> >>>>> Dear Working Group members, >>>>> >>>>> >>>>> >>>>> *Tomorrow,** Thursday, 24 June is the last day to suggest edits to >>>>> the outreach letter *to SO/AC/SG/Cs: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… >>>>> [drive.google.com] >>>>> <https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> >>>>> >>>>> >>>>> >>>>> As a point of clarification, the current task is to make sure that the >>>>> text of the letter is acceptable and determine if any additional questions >>>>> need to be asked of SO/AC/SG/Cs as part of this request for input beyond >>>>> the listed charter questions. Once the WG has finalized the letter, it will >>>>> be sent to SO/AC/SG/Cs who will have approximately five weeks to respond. >>>>> Please feel free to reach out with any questions. >>>>> >>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> >>>>> >>>>> Emily, Julie, Caitlin, and Berry >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From: *GNSO-TPR <gnso-tpr-bounces(a)icann.org> on behalf of Emily >>>>> Barabas <emily.barabas(a)icann.org> >>>>> *Date: *Monday, 21 June 2021 at 11:39 >>>>> *To: *"gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> >>>>> *Subject: *[GNSO-TPR] Reminder - Deadline for feedback 24 June: Draft >>>>> outreach document requesting early input from SO/AC/SG/Cs >>>>> >>>>> >>>>> >>>>> Dear Working Group members, >>>>> >>>>> >>>>> >>>>> As a reminder, if you would like suggest additional questions to >>>>> include in the request for early input to SO/AC/SG/Cs, *please add >>>>> these questions to the Google Doc no later than this* *Thursday, 24 >>>>> June*: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… >>>>> [drive.google.com] >>>>> <https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> >>>>> >>>>> Emily, Julie, Caitlin, and Berry >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From: *Emily Barabas <emily.barabas(a)icann.org> >>>>> *Date: *Tuesday, 8 June 2021 at 19:28 >>>>> *To: *"gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> >>>>> *Subject: *Deadline for feedback 24 June: Draft outreach document >>>>> requesting early input from SO/AC/SG/Cs >>>>> >>>>> >>>>> >>>>> Dear Working Group members, >>>>> >>>>> >>>>> >>>>> As discussed on today’s call, the leadership team has prepared a draft >>>>> outreach document to send to SO/AC/SG/Cs requesting early input on the >>>>> topics within the TRP PDP’s charter. You can find the draft here: >>>>> >>>>> https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… >>>>> [drive.google.com] >>>>> <https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> >>>>> >>>>> >>>>> >>>>> If you would like to propose edits to the text or would like to >>>>> suggest additional questions for early input to include in the document, >>>>> please add comments directly into the Google Document. If anyone is unable >>>>> to use Google Drive, Word and PDF versions are attached for reference. You >>>>> can also use Google Doc comments to provide feedback on questions or edits >>>>> that have been proposed by other members. >>>>> >>>>> >>>>> >>>>> *Please provide your input no later than 24 June 2021*. The Working >>>>> Group call on 29 June will be focused on finalizing this document for >>>>> submission to the SO/AC/SG/Cs. >>>>> >>>>> >>>>> >>>>> Kind regards, >>>>> >>>>> >>>>> >>>>> Emily, Julie, Caitlin, and Berry >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Emily Barabas >>>>> >>>>> Policy Manager, GNSO Policy Development Support >>>>> >>>>> Internet Corporation for Assigned Names and Numbers (ICANN) >>>>> >>>>> Phone: +31 (0)6 84507976 >>>>> >>>>> www.icann.org >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> GNSO-TPR mailing list >>>>> GNSO-TPR(a)icann.org >>>>> https://mm.icann.org/mailman/listinfo/gnso-tpr >>>> >>>> _______________________________________________ >>>> GNSO-TPR mailing list >>>> GNSO-TPR(a)icann.org >>>> https://mm.icann.org/mailman/listinfo/gnso-tpr >>> >>> -- >>> -- >>> Volker A. Greimann >>> General Counsel and Policy Manager >>> *KEY-SYSTEMS GMBH* >>> >>> T: +49 6894 9396901 >>> M: +49 6894 9396851 >>> F: +49 6894 9396851 >>> W: www.key-systems.net >>> >>> Key-Systems GmbH is a company registered at the local court of >>> Saarbruecken, Germany with the registration no. HR B 18835 >>> CEO: Oliver Fries and Robert Birkner >>> >>> Part of the CentralNic Group PLC (LON: CNIC) a company registered in >>> England and Wales with company number 8576358. >>> >>> This email and any files transmitted are confidential and intended only >>> for the person(s) directly addressed. If you are not the intended >>> recipient, any use, copying, transmission, distribution, or other forms of >>> dissemination is strictly prohibited. If you have received this email in >>> error, please notify the sender immediately and permanently delete this >>> email with any files that may be attached. >>> >>

2 2

Re: [GNSO-TPR] Final Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs
by Steve Crocker June 23, 2021

June 23, 2021

Volker, If the registrar is also supplying the DNS service and the registrant initiates a change of registrar, the existing registrar will stop providing the DNS service. Therefore, the registrant is forced to change DNS service as part of changing registrars. If the registrant also wishes for the DNS service to continue to work during the transition, some careful coordination between the two DNS operations is required. Steve On Wed, Jun 23, 2021 at 2:08 PM Volker Greimann <vgreimann(a)key-systems.net> wrote: > I keep wondering what DNS settings and operations have to do with > transfers in the first place. Surely the correct DNS settings are the > responsibility of the registrant? > Volker > > On Wed 23. Jun 2021 at 19:54, Steve Crocker <steve(a)shinkuro.com> wrote: > >> Emily, et al, >> >> I have added some words related to coordination of DNS operations during >> a change of registrar. I was not able to edit the document directly via >> Google docs, so I downloaded the document and inserted changes. Tracking >> is turned on. I inserted my suggested changes between "c" and "d" so I >> used the letter x. >> >> I believe this belongs in this phase, 1a, because phase 1b looks like >> it's focused specifically on a change of registrant. The question of >> coordination of DNS operation could be relevant during a change of >> registrant but will be much more likely to be relevant during a change of >> registrar without a change of registrant. >> >> Thanks, >> >> Steve >> >> >> On Wed, Jun 23, 2021 at 6:08 AM Emily Barabas <emily.barabas(a)icann.org> >> wrote: >> >>> Dear Working Group members, >>> >>> >>> >>> *Tomorrow,** Thursday, 24 June is the last day to suggest edits to the >>> outreach letter *to SO/AC/SG/Cs: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… >>> [drive.google.com] >>> <https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> >>> >>> >>> >>> As a point of clarification, the current task is to make sure that the >>> text of the letter is acceptable and determine if any additional questions >>> need to be asked of SO/AC/SG/Cs as part of this request for input beyond >>> the listed charter questions. Once the WG has finalized the letter, it will >>> be sent to SO/AC/SG/Cs who will have approximately five weeks to respond. >>> Please feel free to reach out with any questions. >>> >>> >>> >>> Kind regards, >>> >>> >>> >>> Emily, Julie, Caitlin, and Berry >>> >>> >>> >>> >>> >>> *From: *GNSO-TPR <gnso-tpr-bounces(a)icann.org> on behalf of Emily >>> Barabas <emily.barabas(a)icann.org> >>> *Date: *Monday, 21 June 2021 at 11:39 >>> *To: *"gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> >>> *Subject: *[GNSO-TPR] Reminder - Deadline for feedback 24 June: Draft >>> outreach document requesting early input from SO/AC/SG/Cs >>> >>> >>> >>> Dear Working Group members, >>> >>> >>> >>> As a reminder, if you would like suggest additional questions to include >>> in the request for early input to SO/AC/SG/Cs, *please add these >>> questions to the Google Doc no later than this* *Thursday, 24 June*: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… >>> [drive.google.com] >>> <https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> >>> >>> >>> >>> >>> >>> Kind regards, >>> >>> >>> >>> Emily, Julie, Caitlin, and Berry >>> >>> >>> >>> >>> >>> *From: *Emily Barabas <emily.barabas(a)icann.org> >>> *Date: *Tuesday, 8 June 2021 at 19:28 >>> *To: *"gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> >>> *Subject: *Deadline for feedback 24 June: Draft outreach document >>> requesting early input from SO/AC/SG/Cs >>> >>> >>> >>> Dear Working Group members, >>> >>> >>> >>> As discussed on today’s call, the leadership team has prepared a draft >>> outreach document to send to SO/AC/SG/Cs requesting early input on the >>> topics within the TRP PDP’s charter. You can find the draft here: >>> >>> https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… >>> [drive.google.com] >>> <https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> >>> >>> >>> >>> If you would like to propose edits to the text or would like to suggest >>> additional questions for early input to include in the document, please add >>> comments directly into the Google Document. If anyone is unable to use >>> Google Drive, Word and PDF versions are attached for reference. You can >>> also use Google Doc comments to provide feedback on questions or edits that >>> have been proposed by other members. >>> >>> >>> >>> *Please provide your input no later than 24 June 2021*. The Working >>> Group call on 29 June will be focused on finalizing this document for >>> submission to the SO/AC/SG/Cs. >>> >>> >>> >>> Kind regards, >>> >>> >>> >>> Emily, Julie, Caitlin, and Berry >>> >>> >>> >>> >>> >>> Emily Barabas >>> >>> Policy Manager, GNSO Policy Development Support >>> >>> Internet Corporation for Assigned Names and Numbers (ICANN) >>> >>> Phone: +31 (0)6 84507976 >>> >>> www.icann.org >>> >>> >>> >>> >>> _______________________________________________ >>> GNSO-TPR mailing list >>> GNSO-TPR(a)icann.org >>> https://mm.icann.org/mailman/listinfo/gnso-tpr >> >> _______________________________________________ >> GNSO-TPR mailing list >> GNSO-TPR(a)icann.org >> https://mm.icann.org/mailman/listinfo/gnso-tpr > > -- > -- > Volker A. Greimann > General Counsel and Policy Manager > *KEY-SYSTEMS GMBH* > > T: +49 6894 9396901 > M: +49 6894 9396851 > F: +49 6894 9396851 > W: www.key-systems.net > > Key-Systems GmbH is a company registered at the local court of > Saarbruecken, Germany with the registration no. HR B 18835 > CEO: Oliver Fries and Robert Birkner > > Part of the CentralNic Group PLC (LON: CNIC) a company registered in > England and Wales with company number 8576358. > > This email and any files transmitted are confidential and intended only > for the person(s) directly addressed. If you are not the intended > recipient, any use, copying, transmission, distribution, or other forms of > dissemination is strictly prohibited. If you have received this email in > error, please notify the sender immediately and permanently delete this > email with any files that may be attached. >

1 0

Final Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs
by Emily Barabas June 23, 2021

June 23, 2021

Dear Working Group members, Tomorrow, Thursday, 24 June is the last day to suggest edits to the outreach letter to SO/AC/SG/Cs: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> As a point of clarification, the current task is to make sure that the text of the letter is acceptable and determine if any additional questions need to be asked of SO/AC/SG/Cs as part of this request for input beyond the listed charter questions. Once the WG has finalized the letter, it will be sent to SO/AC/SG/Cs who will have approximately five weeks to respond. Please feel free to reach out with any questions. Kind regards, Emily, Julie, Caitlin, and Berry From: GNSO-TPR <gnso-tpr-bounces(a)icann.org> on behalf of Emily Barabas <emily.barabas(a)icann.org> Date: Monday, 21 June 2021 at 11:39 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: [GNSO-TPR] Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs Dear Working Group members, As a reminder, if you would like suggest additional questions to include in the request for early input to SO/AC/SG/Cs, please add these questions to the Google Doc no later than this Thursday, 24 June: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> Kind regards, Emily, Julie, Caitlin, and Berry From: Emily Barabas <emily.barabas(a)icann.org> Date: Tuesday, 8 June 2021 at 19:28 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs Dear Working Group members, As discussed on today’s call, the leadership team has prepared a draft outreach document to send to SO/AC/SG/Cs requesting early input on the topics within the TRP PDP’s charter. You can find the draft here: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… [drive.google.com]<https://urldefense.com/v3/__https:/drive.google.com/file/d/1MsaU6sc3TU3azo2…> If you would like to propose edits to the text or would like to suggest additional questions for early input to include in the document, please add comments directly into the Google Document. If anyone is unable to use Google Drive, Word and PDF versions are attached for reference. You can also use Google Doc comments to provide feedback on questions or edits that have been proposed by other members. Please provide your input no later than 24 June 2021. The Working Group call on 29 June will be focused on finalizing this document for submission to the SO/AC/SG/Cs. Kind regards, Emily, Julie, Caitlin, and Berry Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

3 3

Re: [GNSO-TPR] Transfer statistics for .NO - the top level for Norway
by Steinar Grøtterød June 22, 2021

June 22, 2021

Hi Volker, Based on the numbers given by NORID, your calculation is correct. Whether a 20% transfer rate is to be considered “high” or “low” compared to other TLDs, is hard to say. My point in sending this to the group, was to give an example that FOAs may not be needed. A valid auth-code is the criteria for a successful inter-registrar transfer – no “paperwork” Regards, Steinar From: Volker Greimann <vgreimann(a)key-systems.net> Date: Tuesday, 22 June 2021 at 17:06 To: Steinar Grøtterød <steinar(a)recito.no> Cc: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: Re: [GNSO-TPR] Transfer statistics for .NO - the top level for Norway So that means that about 20% of all .NO domains are transferred every year, auth-code only? -- Volker A. Greimann General Counsel and Policy Manager KEY-SYSTEMS GMBH T: +49 6894 9396901 M: +49 6894 9396851 F: +49 6894 9396851 W: www.key-systems.net<http://www.key-systems.net/> Key-Systems GmbH is a company registered at the local court of Saarbruecken, Germany with the registration no. HR B 18835 CEO: Oliver Fries and Robert Birkner Part of the CentralNic Group PLC (LON: CNIC) a company registered in England and Wales with company number 8576358. This email and any files transmitted are confidential and intended only for the person(s) directly addressed. If you are not the intended recipient, any use, copying, transmission, distribution, or other forms of dissemination is strictly prohibited. If you have received this email in error, please notify the sender immediately and permanently delete this email with any files that may be attached. On Sat, Jun 19, 2021 at 12:23 PM Steinar Grøtterød <steinar(a)recito.no<mailto:steinar@recito.no>> wrote: Dear Working Group Members, On request to NORID - the .NO Registry Operator, I have received the following numbers for inter-registrar transfers; 2017: 156 270 2018: 149 835 2019: 152 558 2020: 167 688 2021 per 31. May: 70 728 The .NO domain name policy requires only a valid auth-code for an inter-registrar transfer, i.e. no FOAs are required. The above statistics do not include transfers to "REG0" - a process NORID uses for a deletion of a .NO domain name. According to NORID, the number of “disputes” are zero (0) after mandatory auth-codes were implemented for an inter-registrar transfer. Per Dec 31 2020, the total .NO domain names were 805 539 (reference https://www.norid.no/en/aktuelt/2020-et-ar-for-digitale-sjumilssteg/) Updated statistics: https://www.norid.no/en/om-domenenavn/nokkeltall/ The .NO domain name registration policy can be found on https://www.norid.no/en/om-domenenavn/regelverk-for-no/ Thanks to Hilde Thunem, CEO of NORID for the transfer statistics.. Regards, Steinar Grøtterød At-Large _______________________________________________ GNSO-TPR mailing list GNSO-TPR(a)icann.org<mailto:GNSO-TPR@icann.org> https://mm.icann.org/mailman/listinfo/gnso-tpr

1 0

Reminder - Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs
by Emily Barabas June 21, 2021

June 21, 2021

Dear Working Group members, As a reminder, if you would like suggest additional questions to include in the request for early input to SO/AC/SG/Cs, please add these questions to the Google Doc no later than this Thursday, 24 June: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… Kind regards, Emily, Julie, Caitlin, and Berry From: Emily Barabas <emily.barabas(a)icann.org> Date: Tuesday, 8 June 2021 at 19:28 To: "gnso-tpr(a)icann.org" <gnso-tpr(a)icann.org> Subject: Deadline for feedback 24 June: Draft outreach document requesting early input from SO/AC/SG/Cs Dear Working Group members, As discussed on today’s call, the leadership team has prepared a draft outreach document to send to SO/AC/SG/Cs requesting early input on the topics within the TRP PDP’s charter. You can find the draft here: https://drive.google.com/file/d/1MsaU6sc3TU3azo2-pCWW9A6GWJ0a7XzT/view?usp=… If you would like to propose edits to the text or would like to suggest additional questions for early input to include in the document, please add comments directly into the Google Document. If anyone is unable to use Google Drive, Word and PDF versions are attached for reference. You can also use Google Doc comments to provide feedback on questions or edits that have been proposed by other members. Please provide your input no later than 24 June 2021. The Working Group call on 29 June will be focused on finalizing this document for submission to the SO/AC/SG/Cs. Kind regards, Emily, Julie, Caitlin, and Berry Emily Barabas Policy Manager, GNSO Policy Development Support Internet Corporation for Assigned Names and Numbers (ICANN) Phone: +31 (0)6 84507976 www.icann.org<http://www.icann.org/>

1 0

Transfer statistics for .NO - the top level for Norway
by Steinar Grøtterød June 19, 2021

June 19, 2021

Dear Working Group Members, On request to NORID - the .NO Registry Operator, I have received the following numbers for inter-registrar transfers; 2017: 156 270 2018: 149 835 2019: 152 558 2020: 167 688 2021 per 31. May: 70 728 The .NO domain name policy requires only a valid auth-code for an inter-registrar transfer, i.e. no FOAs are required. The above statistics do not include transfers to "REG0" - a process NORID uses for a deletion of a .NO domain name. According to NORID, the number of “disputes” are zero (0) after mandatory auth-codes were implemented for an inter-registrar transfer. Per Dec 31 2020, the total .NO domain names were 805 539 (reference https://www.norid.no/en/aktuelt/2020-et-ar-for-digitale-sjumilssteg/) Updated statistics: https://www.norid.no/en/om-domenenavn/nokkeltall/ The .NO domain name registration policy can be found on https://www.norid.no/en/om-domenenavn/regelverk-for-no/ Thanks to Hilde Thunem, CEO of NORID for the transfer statistics.. Regards, Steinar Grøtterød At-Large

1 0

Notes and action items - TPR Phase 1 Meeting #06 - 16 June 2021
by Julie Hedlund June 16, 2021

June 16, 2021

Dear Working Group Members, Please find below the notes and action items from today’s meeting during ICANN71. The next meeting will be on Tuesday, 29 June at 16:00 UTC for 90 minutes. Best regards, Emily, Julie, Berry, and Caitlin -- Action Items Please refer to the Work Plan and Action Items List [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/spreadsheets/d/1FunWaz3g…> for updated action items. 1. Discussion of Policy Goals See the Jamboard at: https://jamboard.google.com/d/1atFQTx8qQbeiWqF1aMdAUkgaVNz7r57COA61nMXvIA4/… Policy Goals Brainstorm: Policy Goals for Previous Policy Development Work: * Enable registered name holders to move their domain names to a new provider, thereby increasing consumer choice and competition; * Ensure the IRTP includes sufficient protections to prevent fraudulent domain name transfers and domain name hijacking; * Clarify the language of the IRTP so that ICANN-accredited registrars consistently interpret and apply the policy; * Clarify the language and visibility of the Transfer Dispute Resolution Policy so that providers/panelists consistently interpret and apply the policy. Additional Goals: * DNSSEC transfer has a role in mitigating domain name hijacking. We should clarify this and define guidelines for DNS transfer during registration transfer. * Efficient/ registrant-friendly transfer? Second Goal: -- Question Re: “to prevent fraudulent domain name transfers and domain name hijacking” – are these the same or different? -- Want to prevent bad transfers, but facilitate good ones. -- Maybe remove “and domain name hijacking”? -- One well-known form of fraudulent transfer is slamming, i.e. misleading the customer in order to charge for overpriced services after transfer, but not actually hijack the domain. ACTION ITEM: For the second goal, rewrite to: ““…prevent fraudulent domain name transfers, in particular to prevent the misuse of the transfer mechanism for domain name hijacking”.” Fourth Goal: -- Question: Why is this goal here? Answer: Before the IRTP there was no efficiency. It is better now, but still needs improvement. -- Question: How do we know when we achieve this goal? Answer: We can tie a charter question back to the specific goal. New goal on DNSSEC: -- On DNSSEC, you almost always have to transfer the domain service when you transfer the domain name. How to make this efficient and cost effective. -- I think the positive goal (facilitate valid transfers) is captured in the first green box, so the second box still seems to me to contain redundancy. I propose we remove "and domain name hijacking". -- It’s not clear why DNSSEC should be a goal of this PDP, as it was not something identified in the issues report. Maybe consider it later after we’ve considered other items in our charter? -- It does sound like DNSSEC transfer is more of a technical concern than a policy one. -- Maybe we all should work/establish at “best practice” document after the new IRTP is settled. This “best practice” should obviously include transfers of signed zone. -- There is a country code solution in the Netherlands, but for gTLDs the registry is not involved. Keys have to be available in the new and old locations. There are a variety of reasons for why there is a loss of service during transfer for DNSSEC services. -- Is making DNS service transfers in scope of this PDP? -- Maybe it is important to keep an explicit reference to domain hijacking even if not all fraudulent transfers are hijacking, and not all hijackings are by way of domain transfer. So the phrase could we worded as follows: “prevent fraudulent domain name transfers, in particular to prevent the misuse of the transfer mechanism for domain name hijacking”. -- Issue comes up if you are moving from one registrar to another and also changing the name service. If gaining registrar wants to continue the name service it needs the cooperation of the losing registrar if it is offering the name service. -- Change of registrant might also cause unwanted DNSSEC disruption if the new registrant runs a successor service instead of a new service with the same domain name. -- But, you could change the name service before the registrar transfer, so these could be separate operations. -- From the Registrant point of view it is a concern if DNSSEC implies a disruption in the transfer. Thus, a clear statement needs to be in place when the parties explore the transfer. -- DNSSEC, if implemented correctly, CAN be used as a way to ensure strong authentication that replaces less safe forms of authentication based on email. As a result, removing DNSSEC from the scope would deprive the community of improvements to the transfer process that can only be based on DNSSEC. So it might be good to keep DNSSEC part of the scope, but ensure solutions are available in the absence of DNSSEC too. SUMMARY: This issue (domain name service transfer) is not part of the charter. DNSSEC service transfer is important but we aren’t going to solve it here. CPH TechOps Principles: * The transfer process must comply with current data privacy regulations * The transfer process must be instant, but with enough time to validate the legitimacy of a transfer * A transfer token shall be sufficient to authorize a transfer * No personal data shall be transferred from the old to the new registrar * The existing gTLD transfer policy should be changed as little as possible Second Principle: -- Re: “The transfer process must be instant, but with enough time to validate the legitimacy of a transfer” – note that this is the entire process from beginning to the end. Need to qualify that it should be “as efficient as possible”. -- Seems clear what “instant” means – could change the language to say that the “transfer should be processed” instantly. Update to be more specific. -- Is the “instant transfer” a high-level goal, or is that a piece of a high-level goal. ACTION ITEM: Rewrite the second principle to a high-level goal that the “The transfer shall be processed as efficiently as possible.” Third Principle: -- The principle “A transfer token shall be sufficient to authorize a transfer” is too overreaching. There can be very good reason to say that it is necessary but not sufficient. In particular, a well-organize transfer involves proactive cooperation between gaining and losing registrar, rather than a dangerous event for which the losing registrar is unprepared. If we just forget our old habits for a moment, we can see that allowing a concept of “backup registrar” or “primary sponsoring registrar plus secondary sponsoring registrar” would go a long way to make transfers much more secure. -- This may be too broad. Fourth Principle: -- Re: “No personal data shall be transferred from the old to the new registrar” – not sure we need this. Not sure we need to restrict this. -- Add “Policy shall not require”? Fifth Principle: -- Re: “The existing gTLD transfer policy should be changed as little as possible” – think this one can be removed. -- Originally the goal was to provide as much security and thought without changing the policy a lot. We are here to look at it as a whole and change what is needed. -- Maybe not appropriate for this PDP. 2. Discussion of Charter Topic 4 – AuthInfo Code Management See: https://docs.google.com/document/d/1O9PAnxWFUuPofLQCWIQXz8lT7KEj1HgH3b_obh0… Charter Questions: b1) Is AuthInfo Code still a secure method for inter-registrar transfers? What evidence was used by the Working Group to make this determination? -- Answer to the question is “not today, but it could be”. There are certain security principles that aren’t being protected. -- Compliance is looking for data. But this may not be intuitive to inform the question of how secure AuthInfo code is. So we would need to go to the CPH. -- Wondering if Compliance is looking at how many times TDRP has been used? -- Need to come up with the policy or business definers to for TechOps to consider the questions – or those that are relevant. -- Frame the questions to TechOps in context, such as that the goal of the AuthInfo code is to ensure that the registrant asking for the transfer is the same registrant who owns the domain. -- The data/metrics from ICANN org is of importance. However, there are members of the PDP that have experience - and maybe data, from ccTLD transfers. These data could be handy to have. -- It’s not the amount of complaints that we’re looking for, it’s the amount of unauthorized transfers that have been reversed. -- Distinction for consider: what we are talking about here are the security requirements for the transfer. That the transfer is authorized by the registrant and that the identity is confirmed by the AuthInfo code. Or whether additional security requirements are necessary. But the additional security requirements of the code are what allow the mechanism to achieve the goal – these two security issues should be separate. 1) mechanism, and 2) what to do with the mechanism to achieve the goal. -- Precision is required here for any input we seek from TechOps/CPs. -- The current AuthInfo functions much like a one-time password. It is not fully implemented that way. -- If we move down the path of wanting to depend on the Transfer Authorization Code (TAC), then we need to think carefully about its security requirements. -- So this group may want to keep this in mind when formulating possible future recommendations of things that can be measured and data gathered from CPs to help measure the success of the new policy requirements. -- The goal is to remove the FOAs and using a TAC/AuthCode, and making sure that the registrant asking for the transfer is the registrant authorized to do so. Have to assume that when answering the questions, until that doesn’t work. -- Is there an ask for the CPs coming out of this PDP to gather certain data? -- The available evidence is a leading indicator, but it isn’t definitive. Important to gather that information, but it won’t answer the question. The experts here might be able to answer it or not. -- There have been a lot of changes in the last three years to make the AuthCode more secure, so the data won’t tell the whole story. -- AuthCodes have proved secure in the last three years, but need to ask for the data from TechOps to answer the question. ACTION ITEMS: 1) Once the WG has clarified policy parameters for AuthInfo Codes, staff with the WG to draft letter to CPH TechOps asking for input on a technical solution (or technical solutions) to meet those parameters. 2) Staff with the WG to draft a survey to send to Registrars asking for input and evidence/data regarding the security of AuthInfo Codes. 3. Next Meeting 29 June 2021: The WG will continue discussion on the charter questions at the next meeting, beginning with the following question. B2) The registrar is currently the authoritative holder of the AuthInfo Code. Should this be maintained, or should the registry be the authoritative AuthInfo Code holder? Why? As a starting point, the CPH Tech Ops Group concluded “to reach a uniform, transparent, and predictable process, Registries should be in control of the storage and processing of the AuthCode, regarding the technical part.”

1 0

(apologies, resending to corrected list) Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 29 June 2021 at 16:00 UTC
by Julie Bisland June 9, 2021

June 9, 2021

NOTE: The next time the Transfer Policy Review PDP WG meets will be during ICANN71: 16 June 2021 @ 12:30 UTC [71.schedule.icann.org]<https://urldefense.com/v3/__https:/71.schedule.icann.org/meetings/MRRdeaFX8…>. Registration is compulsory to access the ICANN71 meeting schedule. Information can be found on this page [events.icann.org]<https://urldefense.com/v3/__https:/events.icann.org/ICANNEventsPortal/icann…> **************************************************** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 29 June 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> Visit the Wiki Agenda meeting page: https://community.icann.org/x/VwTpCQ Check your time zone: https://tinyurl.com/5k3u34hf [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/5k3u34hf__;!!PtGJab4!ukWZuIg…> ONLY FOR MEMBERS & ALTERNATES: * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Please rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Meeting Invitation | Transfer Policy Review PDP WG call | Tuesday, 29 June 2021 at 16:00 UTC
by Julie Bisland June 9, 2021

June 9, 2021

NOTE: The next time the Transfer Policy Review PDP WG meets will be during ICANN71: 16 June 2021 @ 12:30 UTC [71.schedule.icann.org]<https://urldefense.com/v3/__https:/71.schedule.icann.org/meetings/MRRdeaFX8…>. Registration is compulsory to access the ICANN71 meeting schedule. Information can be found on this page [events.icann.org]<https://urldefense.com/v3/__https:/events.icann.org/ICANNEventsPortal/icann…> **************************************************** Dear all, The next Transfer Policy Review PDP WG call is scheduled for Tuesday, 29 June 2021 at 16:00 UTC for 90 minutes. Zoom Room Information: Main Zoom Webinar link: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/j/95363727469?pwd=N3A3OWFS…> Passcode: @TP/^*4wg# If you are joining via audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6 [icann.zoom.us]<https://urldefense.com/v3/__https:/icann.zoom.us/u/acdLFXPLp6__;!!PtGJab4!v…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> Visit the Wiki Agenda meeting page: https://community.icann.org/x/VwTpCQ Check your time zone: https://tinyurl.com/5k3u34hf ONLY FOR MEMBERS & ALTERNATES: * Please join via the above Main Zoom Webinar link and staff will promote you to panelist. * Members (and alternates replacing members), please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form [docs.google.com]<https://urldefense.com/v3/__https:/docs.google.com/forms/d/e/1FAIpQLScXP3-H…> to communicate the replacement (alternate) and the duration. This information will be publicly posted to the Alternate Log-Transfer Policy Review PDP<https://community.icann.org/x/V4aUCQ> wiki page. * Alternates (not replacing a member): Please rename your line by adding THREE Zs (zzz) before your name and add, in parentheses (your affiliation - alternate) after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY FOR OBSERVERS: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. Thank you. Kind regards, Julie

1 0

Notes and action items - TPR Phase 1 Meeting #05 - 8 June 2021
by Caitlin Tubergen June 8, 2021

June 8, 2021

Dear Working Group Members, Please find below the notes and action items from today’s meeting. The next meeting will be during ICANN71 on Wednesday, 16 June at 12:30 UTC. Best regards, Emily, Julie, Berry, and Caitlin -- Action Items Please refer to the Work Plan and Action Items List<https://docs.google.com/spreadsheets/d/1FunWaz3gNZl8mPi5pNKti2GsfPC_9_DTt8u…> for updated action items. Transfer Policy Review Phase 1 - Meeting #05 Proposed Agenda Tuesday 8 June 2021 at 16.00 UTC 1. Roll Call & SOI Updates (5 minutes) 2. Welcome & Chair updates (5 minutes) * Support Staff plans to share the draft SO/AC/SG/Cs outreach document with the WG following this call. * The proposed deadline for adding comments and proposing additional questions will be 24 June. Support Staff will aim to finalize the document during the 29 June call. * We intend to use Google Drive as our primary method for working on shared documents, pending no objections. (No objections were raised during the call.) 3. Discussion of AuthInfo Codes (75 minutes) * The first section of the document provides the relevant policy language from the Transfer Policy and the Interim Registration Data Policy. * The working definition can evolve over time. The definition, as written, was pulled from ICANN’s website. As the Team is working through the charter questions, please have the working definition in mind so that we can finalize this for the report later in the process. * Regarding “unique codes”, curious how this actually works for the non-technical or non-registrar members. Is it possible that two registrars could develop the same random code, for example? Has this ever happened? Is an authinfo code collision possible? * From a technology point of view, yes – this is possible, but something to keep in mind is the code has to be correlated to something. The likelihood of this happening in terms of the same two people trying to transfer a domain name – is next to zero. If this is a concern, the domain name could be hashed. * Charter Question b1) Is AuthInfo Code still a secure method for inter-registrar transfers? What evidence was used by the Working Group to make this determination? * As a starting point, it’s important to know what we are trying to achieve with the auth-info code as an overarching question before reviewing who the manager of the code should be. * In terms of evidence, there must be some evidence that we can look at – like ICANN compliance tickets re: auth codes being insecure, people not being able to get access, etc. * Since the dependency on auth codes have changed, it may be helpful to look backwards and forwards – (pre-Temp Spec elimination of Gaining FOA and post-Temp Spec elimination of Gaining FOA). * Do not think if asking if auth codes are secure enough at the right question? The real question is – what are we trying to achieve with auth codes – what we are trying to derive from a security point of view. * What is the difference between the auth code and the one-time password referenced in the document? * In EPP, it’s called authinfo; however, it’s called other names such as password, authorization code. Use of onetime password is a way of saying this is a goal we are trying to achieve. A onetime password has all of the goals you would want to achieve. * "Transfer Authorization Code" may be an optional replacement of the term auth code because it is more descriptive * There should be one standard term used across the board, so registrants don't get confused * From a security point of view with no consideration to business processes, our use of authinfo codes is not secure enough. There are changes that are necessary and should be made. For one, it is not uniformly managed and processed at independent registrars. We need to create homogeneity about what it means to create an authinfo code. With that in mind, there is discussion to be had about how a transfer works and how we adapt the security principles that come with a onetime password and make sure they are covered. * If we create a transfer authorization code, are we creating an identification that could be PII which could be problematic with data privacy laws? * Many systems are adopting two-factor authorization – suggest that, if possible, recommend that two-factor authentication be enabled such that the domain name owner can verify this is a genuine transfer request * The auth code could be personal data, but not necessarily. The auth code does not say who someone is, so it would be difficult to identify a natural person, although in some edge cases, it could be used to validate information. This should be protected similar to how passwords are protected. If it is personal data, there would be a legitimate interest for processing the personal data. * The goal should be secure transfers. The authinfo code is a good method for registrar transfers. There are small things to do to make it more secure, such as TTL – which makes it a onetime password. * The whole transfer process is a pain and a lot of people do not understand it. Making it secure does not mean that people will use it. Usability is another issue the group should consider. * The question about usability and bulk are excellent and important questions – that is why we need to talk about the business processes that need to be in place. What are the uniform steps that we are going to follow to make this work? Where is the uniformity within each of those steps that we all agree to abide by? Is bulk a separate process, or will it be incorporated in? These are all choices to be made, and they’re all related. * It’s not just about the security about the auth code itself; it’s also about getting the auth code. There should be an easy way for the registrar to actually get the auth code * There should be requirements regarding explaining how a registrant can get its auth code * If it comes to security level of the auth code, we could have a look at ccTLDs. We could copy what is already out there. * It sounds like the group thinks the auth code is a secure mechanism that needs improvements * With respect to onetime use, the first issue is whether or not we believe the goal is to make sure that we are correlating the registrant at both ends – from the incumbent registrar to the gaining registrar. With that in mind, a onetime password might be enough. Two-factor authentication may be overkill for this application but could be dissuaded if others disagree with this position. We should have guidance about how to create an auth code, how long it has to be, and other technical guidance regarding its lifetime and when they come into existence and when they don’t. When you start getting into where and how it’s used, then you talk about the management. How much of a role do registries have? There are a few things we need to get through and not prepared to answer these questions without more information. * Registrars have to answer the question about two-factor authentication. You would want one system that everyone is going to have so there is interoperability. * 2FA is more of a hindrance – this would not go down well, and not sure this is what we are trying to achieve. In terms of looking at best practices, it could be optional, but some smaller registrars may not have the capability and it would not be a fair approach. * We should not lock down to one specific type of security. Many registrars already use 2FA. * Some people think a transfer should be instant – how would the code be evaluated and provided in this instance * Regarding when not to provide an auth code, this comes to provisioning. * To the extent there’s a security impact, then it’s a policy consideration. For example, minimum length for the auth info would be policy consideration. For example, uniqueness of an auth info would be a policy consideration. Guidance but not requirements on how to create an auth info would be helpful but not necessarily binding. Is it created as needed? Does it have a lifetime? These are policy considerations that have a security impact. If authinfo is going to replace the FOA, there needs to be some considerations added. * Who is going to have the operational burden? The second part that needs to be determined whether the registrar is responsible for doing certain checks or the registry. * Design of a specific onetime password scheme is better done by specialists, not a group like this. What this group will be good at is setting general requirements and evaluating a proposed scheme in terms of its usability, cost of implementation, etc. * This group needs determine what the concerns are and have a technical group design something with these concerns in mind and pass it back to the WG for confirmation 4. Next steps & closing (5 minutes) Next meeting (ICANN71 session): 16 June 2021 @ 12:30 UTC

1 0

June -July 2021 calls | Transfer Policy Review PDP WG
by Julie Bisland June 8, 2021

June 8, 2021

**We are sending in advance to get dates on everyone’s calendar. Dear all, The calls for June and July 2021 for the Transfer Policy Review PDP WG are listed below and the .ics files are attached to this email. Please be sure to download them the your inbox calendars. The scheduled start time is 16:00 UTC for 90 minutes. * Tuesday, 29 June 2021 * Tuesday, 06 July 2021 * Tuesday, 13 July 2021 * Tuesday, 20 July 2021 * Tuesday, 27 July 2021 NOTE: The next call takes place during ICANN71: 16 June 2021 @ 12:30 UTC<https://71.schedule.icann.org/meetings/MRRdeaFX8gLWGzZan#/?limit=10&sortByF…>. Reminder: Registration is compulsory to access the ICANN71 meeting schedule. Information can be found on this page [events.icann.org]<https://urldefense.com/v3/__https:/events.icann.org/ICANNEventsPortal/icann…> Future meeting invitations will be sent out closer to the date of the meeting. Thank you. Kind regards, Julie -- Julie Bisland GNSO SO/AC Support coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

2 1

August 2021 calls | Transfer Policy Review PDP WG
by Julie Bisland June 8, 2021

June 8, 2021

**We are sending in advance to get dates on everyone’s calendar. Dear all, The calls for August 2021 for the Transfer Policy Review PDP WG are listed below and the .ics files are attached to this email. Please be sure to download them the your inbox calendars. The scheduled start time is 16:00 UTC for 90 minutes. * Tuesday, 03 August 2021 * Tuesday, 10 August 2021 * Tuesday, 17 August 2021 * Tuesday, 24 August 2021 * Tuesday, 31 August 2021 Future meeting invitations will be sent out closer to the date of the meeting. Thank you. Kind regards, Julie -- Julie Bisland GNSO SO/AC Support coordinator Internet Corporation for Assigned Names and Numbers (ICANN) Skype ID: 79613b691cb8a6c1 Find out more about the GNSO by visiting: https://learn.icann.org/<https://urldefense.proofpoint.com/v2/url?u=https-3A__learn.icann.org_&d=DwM…> Follow @GNSO on Twitter: https://twitter.com/ICANN_GNSO<https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_ICANN-5FGN…> Transcripts and recordings of GNSO Working Group and Council events are located on the GNSO Master Calendar <https://urldefense.proofpoint.com/v2/url?u=https-3A__gnso.icann.org_en_grou…>

1 0

Transfer Policy Review PDP WG
by ICANN Policy Calendar June 8, 2021

June 8, 2021

Meeting: Transfer Policy Review PDP WG Date/Time: Recurring call every Tuesday at 16:00 UTC for 90 minutes, 29 June 2021 through 31 August 2021 Join the Zoom Webinar: https://icann.zoom.us/j/95363727469?pwd=N3A3OWFSaTlUME9wZzlGajk5VUI3QT09 Passcode: @TP/^*4wg# ALL: Before joining the call: Please send apologies and dial out requests to gnso-secs(a)icann.org<mailto:gnso-secs@icann.org> only Please be sure you have read the ICANN Expected Standards of Behavior<https://www.icann.org/resources/pages/expected-standards-2016-06-28-en> Visit the 29 June Wiki Agenda meeting page: https://community.icann.org/x/VwTpCQ (see left side for other meeting dates) Check your time zone: https://tinyurl.com/5k3u34hf ONLY for Members & Alternates: * Please join via the above Zoom Webinar link and staff will promote you to Panelist * Alternate replacement confirmations – In order to keep track of alternate replacements, use the google form<https://docs.google.com/forms/d/e/1FAIpQLScXP3-H595xH4EFgaR3ydOr-1o9BLAVGUI…> to communicate who the alternate is replacing and for which period. This information will be posted to the Alternate Log-Transfer Policy Review PDP wiki page<https://community.icann.org/x/V4aUCQ>. * Members and alternates replacing members, please select Panelists and Attendees when posting to the chat in order for everyone to see and to be captured afterwards. * Alternates (not replacing a member): Please rename your line in Zoom by adding THREE Zs “zzz” before your name, and in parentheses, (your affiliation - alternate), after your name. To rename in Zoom, hover over your name and click ‘rename’. * Alternates (not replacing a member) are not allowed to engage in the chat or use any of the other zoom room functionalities such as raising hands or agreeing/disagreeing. ONLY for Observers: * Observers will have ability to view member chat and information shared in the zoom webinar room. Observers will not be able to use chat or raise hands. For Audio only: One tap mobile: US: +19294362866,,95363727469#,,,,*7490739013# or +13017158592,,95363727469#,,,,*7490739013# Telephone: Dial (for higher quality, dial a number based on your current location): US: +1 929 436 2866 or +1 301 715 8592 or +1 312 626 6799 or +1 669 900 6833 or +1 253 215 8782 or +1 346 248 7799 or 888 788 0099 (Toll Free) or 877 853 5247 (Toll Free) Webinar ID: 953 6372 7469 Passcode: 7490739013 International numbers available: https://icann.zoom.us/u/acdLFXPLp6

1 0