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 02 Jul '21

02 Jul '21

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 30 Jun '21

30 Jun '21

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 29 Jun '21

29 Jun '21

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 29 Jun '21

29 Jun '21

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 29 Jun '21

29 Jun '21

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 29 Jun '21

29 Jun '21

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 28 Jun '21

28 Jun '21

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 25 Jun '21

25 Jun '21

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 25 Jun '21

25 Jun '21

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 25 Jun '21

25 Jun '21

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