- Gnso-rdrs-sc - lists.icann.org

Meeting Invitation | RDRS Standing Committee | Monday, 29 July 2024
by Devan Reed July 15, 2024

July 15, 2024

Dear all, The next RDRS Standing Committee call is scheduled for Monday, 29 July 2024 at 17:30 UTC for 60 minutes. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 Audio only option: Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acS1yc2A1 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acS1yc2A1__;!!PtGJab4!9A…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send apologies 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://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Wiki agenda page: https://community.icann.org/x/EoC0F * Check your time zone: https://tinyurl.com/3xhcxcbw ONLY for Members & Alternates * Please join via the above Zoom Webinar link and staff will promote you to panelist. * Please select “ Everyone” when posting to the chat for everyone to see your chat and so it’s captured in the recording. 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, Devan Policy Team Supporting the GNSO

1 0

15 MINUTES REMINDER | Meeting Invitation | RDRS Standing Committee | Monday, 15 July 2024
by Devan Reed July 15, 2024

July 15, 2024

Dear all, The next RDRS Standing Committee call is scheduled for Monday, 15 July 2024 at 17:30 UTC for 60 minutes. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 Audio only option: Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acS1yc2A1 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acS1yc2A1__;!!PtGJab4!9A…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send apologies 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://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Wiki agenda page: https://community.icann.org/x/EIC0F * Check your time zone: https://tinyurl.com/346mt63r [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/346mt63r__;!!PtGJab4!4aXjVWA…> ONLY for Members & Alternates * Please join via the above Zoom Webinar link and staff will promote you to panelist. * Please select “ Everyone” when posting to the chat for everyone to see your chat and so it’s captured in the recording. 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 Policy Team Supporting the GNSO

1 0

Re: The June RDRS Usage Metrics report is published.
by Lisa Carter July 15, 2024

July 15, 2024

Hi All, The RDRS Usage Metrics Report covering 1-30 June has been published to the RDRS page. https://www.icann.org/en/system/files/files/rdrs-usage-metrics-15jul24-en.p… Thanks. Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN

1 0

Proposed agenda - RDRS Standing Committee Meeting - Monday, 15 July @ 17:30 UTC
by ICANN Policy Calendar July 12, 2024

July 12, 2024

Dear RDRS Standing Committee Members, Below, please find the proposed agenda for the next meeting of the Standing Committee on Monday, 15 July at 17:30 UTC. Best regards, Feodora and Caitlin -- Proposed Agenda RDRS Standing Committee Meeting Monday, 15 July 2024 at 17:30 UTC 1. Welcome 2. Impressions Document Review & Prioritization 3. Preview of updated Metric 10 & Metric 8 4. AOB

1 0

REMINDER | Meeting Invitation | RDRS Standing Committee | Monday, 15 July 2024
by Terri Agnew July 12, 2024

July 12, 2024

Dear all, The next RDRS Standing Committee call is scheduled for Monday, 15 July 2024 at 17:30 UTC for 60 minutes. To join - Zoom Information: Main Zoom Webinar link: https://icann.zoom.us/j/92181477886?pwd=TlJHTU5EY1d3bUxLV2s3UStPS2MxZz09 <https://urldefense.com/v3/__https:/icann.zoom.us/j/92181477886?pwd=TlJHTU5E…> Passcode: Z@S07?t=v5 Audio only option: Webinar ID: 921 8147 7886 Passcode: 3121016458 International numbers available: https://icann.zoom.us/u/acS1yc2A1 <https://urldefense.com/v3/__https:/icann.zoom.us/u/acS1yc2A1__;!!PtGJab4!9A…> Members, alternates, and observers all have different access and participation directions, please read below! ALL: Before joining the call * Please send apologies 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://urldefense.com/v3/__https:/www.icann.org/resources/pages/expected-s…> * Wiki agenda page: https://community.icann.org/x/EIC0F * Check your time zone: https://tinyurl.com/346mt63r [tinyurl.com]<https://urldefense.com/v3/__https:/tinyurl.com/346mt63r__;!!PtGJab4!4aXjVWA…> ONLY for Members & Alternates * Please join via the above Zoom Webinar link and staff will promote you to panelist. * Please select “ Everyone” when posting to the chat for everyone to see your chat and so it’s captured in the recording. 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 Policy Team Supporting the GNSO

1 0

Introduction to the New Impression Document Management System
by Feodora Hamza July 11, 2024

July 11, 2024

Dear Members of the Standing Committee, I am writing to inform you about the new Impression Document Management<https://docs.google.com/spreadsheets/d/1XFK-RCT5Nv-KcNgX4eQunkUKgSI35Yc_nUZ…> system that many of you might have already encountered. This new system is designed to streamline our document management processe and improve overall efficiency. The document includes three distinct tabs for input: 1. Requesters: as done in previous impressions document 2. Registrars: as done in previous impressions document 3. Further Considerations: this tab is for general feedback or lessons learnt to be considered for successor system Please be aware that there are some important notes highlighted in red within the document. These notes provide relevant instructions and considerations that you should review while making changes in the document. Additionally, you will notice that certain columns are locked from editing. These columns are: · LoE · Notes on LoE · SC agreed Priority Ranking · SC consensus · Status LoE, Notes on LoE and Status columns will be determined and managed by the ICANN support staff. The other mentioned columns will be edited by ICANN support staff but agreed on during the SC meetings, where the group has the chance to discuss and agree on the way forward on each change request. There will be dedicated time during each SC meeting to go through the Impressions Document. We understand these changes might create some limitations for SC members to edit the Impressions Document, but these columns will remain locked to maintain the structure and reliability of the information being recorded as discussed with the SC chair. Once a change request has been completed it will also lock the whole row. Please note that even though some columns are restricted, everyone who has access to the document can add new change requests to the document in the empty rows provided. Should you have questions: * On document issues (formatting, access, etc.) please contact: feodora.hamza(a)icann.org<mailto:feodora.hamza@icann.org> * On LoE, LoE comments or Status of change requests please contact: lisa.carter(a)icann.org<mailto:lisa.carter@icann.org> We believe this new system will greatly enhance how we process change requests and we look forward to your cooperation in utilizing it effectively. Thank you for your support. Kind regards, Feodora Hamza Policy Development Support Manager (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +32 496 30 24 15 Email: feodora.hamza(a)icann.org<mailto:feodora.hamza@icann.org> Website: www.icann.org<http://www.icann.org>

3 3

2024-07-01 RDRS Standing Committee - Meeting #11
by Feodora Hamza July 2, 2024

July 2, 2024

Dear RDRS Standing Committee, Please find below the main discussion points and action items from yesterday`s meeting. The next meeting is scheduled for Monday, 15 July at 17:30 UTC. Kind regards, Feodora and Caitlin 2024-07-01 RDRS Standing Committee - Meeting #11<https://community.icann.org/pages/viewpage.action?pageId=347373582> AI: SC Chair to remove word “policy” from letter to GNSO Council. AI: SC to discuss and agree what additional metrics to be added. AI: SC members that proposed new change requests during the call (and any other change requests) to add them in the impressions document.<https://docs.google.com/spreadsheets/d/1XFK-RCT5Nv-KcNgX4eQunkUKgSI35Yc_nUZ…> AI: ICANN will have tech team provide an updated LOE one the impressions document is updated with the new details from Gabriel. AI: ICANN Org and SC to consider Gabriels request. AI: Gabriel to include change request into the impressions document.<https://docs.google.com/spreadsheets/d/1XFK-RCT5Nv-KcNgX4eQunkUKgSI35Yc_nUZ…> 1. Welcome * SC discussed the letter from RDRS SC Chair to GNSO Council from 25 June 2024. * SC Chair emphasized that the letter's aim is to remove aspects that are not purely managing the RDRS pilot and clarify with the GNSO council. * The overall aim is to see what recommendation the SC can make to the GNSO Council in 18 months time. AI: SC Chair to remove word “policy” from letter to GNSO Council. · SC members asked about the reasoning of the letter and what is the best case scenario outcome that is intended? · SC Chair explained that at this stage there was no additional policy work needed. However, the letter to GNSO Council should encourage Council to invite all SG to expand and continue discussion on RDRS and its implications in different fora beyond the SC. · SC discussed how to measure the success of RDRS? How to assess if the product is working? · SC members said that current RDRS does not bring added value to the requestor community. · SC chair emphasized that the SC does not have time to cover these “political” aspects of RDRS and this is out of scope for SC and the letter aims to encourage the creation of channels outside the SC for that discussion. · The idea is to create another – bigger – group to discuss the “political” dimensions of RDRS and any potential successor system. · SC Chair pointed out that this system, this simple system was fairly easy to design, just as a ticketing system as a transporter of information from requester to responders. But we're finding ourselves now, not being able to assess the efficiency of it closely enough beyond the fact that it just passes, passes the parcel, passes the question from one to the next. · SC members suggested that RDRS is not providing any added value than the situation that existed after GDPR but before the RDRS system. · SC members from LEA explained that their agency uses centralops.net for whois queries and their usage number indicates 15000 queries in 90 days. The system provides similar services as RDRS does but has more user awareness. RDRS, however, is lacking user awareness beyond the community. 2. RDRS Usage Metrics Report · Standing Committee feedback/questions on recent Metrics Usage Report<https://www.icann.org/en/system/files/files/rdrs-usage-metrics-17jun24-en.p…> · Metric 5 number of requests is down from 255 in March to 156 in May. · Metric 6.1, 6.2 seems to be increasing slightly for non participating Rrs, but on decreasing for participating. · Law enforcement and IP holders continue to be the top request categories. · Metric 10 - Domain not supported is the the highest metric. · Metric 8 enhancement request won't be included in the next report, but it will come probably the report after. · ccTlds account for about 8% of overall lookups. Right now we have about 1,087 ccTld queries out of 12,985 lookups since launch. AI: SC to discuss and agree what additional metrics to be added. · The Cctld addition to Metric 10 won't be in the July report. AI: SC members that proposed new change requests during the call (and any other change requests) to add them in the impressions document.<https://docs.google.com/spreadsheets/d/1XFK-RCT5Nv-KcNgX4eQunkUKgSI35Yc_nUZ…> · Discuss and agree on the additional metrics to add to the monthly reports 3. Impressions Document Management 4. AOB · Second round of RDRS enhancements released on 25 June · Requestor Survey · Improving response rate · Additional questions on user experience after submit page in RDRS * Gabriel informed SC that their constituency is working on an API for RDRS as the change request proposed to ICANN Org was considered a high level of effort. AI: ICANN will have tech team provide an updated LOE one the impressions document is updated with the new details from Gabriel. * Gabriel asked the SC/ICANN Org for two things: * 1. a test domain that they can query to make sure that the connection is actually connecting successfully without tainting the data. * 2. an email address/ contact that they can use to send the occasional technical question to. AI: ICANN Org and SC to consider Gabriels request. AI: Gabriel to include change request into the impressions document.<https://docs.google.com/spreadsheets/d/1XFK-RCT5Nv-KcNgX4eQunkUKgSI35Yc_nUZ…> Feodora Hamza Policy Development Support Manager (GNSO) Internet Corporation for Assigned Names and Numbers (ICANN) Mobile: +32 496 30 24 15 Email: feodora.hamza(a)icann.org<mailto:feodora.hamza@icann.org> Website: www.icann.org<http://www.icann.org>

1 0

Re: [Ext] RE: Link to RDRS in RDDS Lookup
by Lisa Carter July 2, 2024

July 2, 2024

Hi Gabriel & Sebastian, To add to what you have both discussed below, ICANN is currently looking into including some additional language and a link to RDRS in the following location on the results page for the domain lookup (see screenshot below). If you can please add your suggestions for the ICANN Lookup Tool (from the email below) to the Impressions Document, the request can be tracked and its progress documented. Thanks. Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Gabriel Andrews <gfandrews(a)fbi.gov> Date: Tuesday, June 18, 2024 at 9:32 AM To: "Sebastien(a)registry.godaddy" <Sebastien(a)registry.godaddy>, Lisa Carter <lisa.carter(a)icann.org>, "gnso-rdrs-sc(a)icann.org" <gnso-rdrs-sc(a)icann.org> Subject: [Ext] RE: Link to RDRS in RDDS Lookup Appreciate your thoughts on this Sebastien. Especially as you check in with your team to explore whether/how notification can be done “in the data”. For what it’s worth, I think your instinct to “go for the lookup box” is exactly consistent with user behavior. If I may expand on my thinking: the link to RDRS is most useful when it is a) presented alongside the notification that data has been redacted, and b) when it is agnostic of the query tool being used (meaning it will be seen regardless of whether the requestor is using godaddy.com/whois vs lookup.icann.org vs centralops.net vs domaintools vs command line etc). Any mechanism capable of satisfying those two principles would be welcome, but the only one I can think of is via having the RDDS (WHOIS/RDAP) data itself carrying the link to RDRS (i.e., presented “in the data”). As to why I view it important to be tool agnostic: it’s my understanding there are potentially thousands of WHOIS/RDAP lookup tools. Maybe more. Despite our familiarity as ICANN insiders with https://lookup.icann.org [lookup.icann.org] , I’d be surprised if it broke the top10 most commonly used in the wild. In LE circles, I knew a lot of case agents/analysts used centralops.net [centralops.net] , and so I had separately asked their admins to link to RDRS in their outputs; they were responsive and swift - but again, it only helps those who happen to use centralops… and does nothing for the other 10 or 100 or 1000 ways of doing the RDDS query. I happen to think centralops put their notification in as good a place as possible for users of their tool (after the user goes for the lookup box, as you can see below), but… a) it’s still not directly alongside the “REDACTED FOR PRIVACY” notification, meaning its still possible to be missed, and b) the challenge of how to reach the users of the other thousand ways of doing a WHOIS/RDAP query remain. Hence why I am so very grateful to you for exploring with your GoDaddy team whether/how awareness/promotion of RDRS can be put “in the Data”, to ensure that with the very same breath that the user is told that the data is redacted they are also told where they can go to request it. More along the lines of ~ With gratitude, G PS – This goes a bit in the weeds, but to expand upon a concern Sarah Wyld had voiced, in the RDAP response profile, there is a “MUST” in 2.7.4.3 which reads: … which carries an obligation for more text than I could fit into a single legible slide. If I interpret the policy correctly (inviting ICANN staff to tell me otherwise) the actual text output would have to include such text at minimum, but could include more (per IV.1.1.1) …and thus could read as: “REDACTED FOR PRIVACY Some of the data in this object has been removed. If you have lawful need of this data, visit rdrs.icann.org” Welcoming corrections to my understanding if I’m off base on this. From: Sebastien--- via Gnso-rdrs-sc <gnso-rdrs-sc(a)icann.org> Sent: Tuesday, June 18, 2024 2:00 AM To: Lisa Carter <lisa.carter(a)icann.org>; gnso-rdrs-sc(a)icann.org Subject: [EXTERNAL EMAIL] - [Gnso-rdrs-sc] Link to RDRS in RDDS Lookup Dear Team, After a number of requests to include RDRS information in the our Registration Data Lookup Tools, including in the latest GAC Communiqué - IV. Issues of Importance to the GAC - 6. Registration Data Request Service (RDRS), I have had a look at what I believe we do and could do better. On the ICANN site https://lookup.icann.org/en [lookup.icann.org] The information appears prominently on the landing page (second paragraph), but I suspect may be missed by people not specifically looking for it, because 1/ users will tend to go for the Lookup box before reading anything else, and 2/ because of the “Nonpublic registration data” title. Specifically looking for it, I managed to miss it on my first review of the page, try a random lookup to look for it on the response page, and find it only coming back to the landing page – I might not be the sharpest amongst us. Can I suggest? For the title of the paragraph to also contain Registration Data Request Service and RDRS - these are the terms we use in all our communications. Nonpublic registration data isn’t. The repeat the block at the bottom of the response page. It is at the point of not finding the sought data that RDRS will come most relevant. I am happy to add this to the new Impressions Document if there is any traction. ------------ As promised I am also engaging with GoDaddy Registrar and Registry to see if/how we could add the relevant at the bottom of our RDDS responses. Kindly, Sebastien Ducos GoDaddy Registry | Senior Client Services Manager +33612284445 France & Australia sebastien(a)registry.godaddy

2 2

Re: [Ext] RE: Email thread for discussing voluntary inclusion of ccTLDs
by Lisa Carter July 2, 2024

July 2, 2024

Hi Gabriel, Please find my comments to your questions below in red. Thanks Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Gabriel Andrews <gfandrews(a)fbi.gov> Date: Thursday, June 6, 2024 at 11:18 AM To: "gnso-rdrs-sc(a)icann.org" <gnso-rdrs-sc(a)icann.org>, Lisa Carter <lisa.carter(a)icann.org> Subject: [Ext] RE: Email thread for discussing voluntary inclusion of ccTLDs To continue the conversation: @ Lisa: Per your note that “all RDDS requirements for ccTLDs are Unstandardized/Unenforceable”, I think I might be missing your point, and hope to clarify ~ i. Speaking to “Unenforceable”, we seem to be in consensus that all RDRS participation is strictly voluntary, and that any ccTLD participation would also be voluntary. While participation in RDRS is voluntary, RDRS does rely on other contractual obligations for gTLD registries such as the availability and supported format of their WHOIS service (and RDAP in the future), obligations that do not exist for ccTLDs. ii. As for “Unstandardized”, is this to suggest that the lack of standardization is preventing ICANN from determining whether/not a ccTLD request is associated with a participating registrar? It was my understanding that the initial lookup done at the start of a RDRS request is always capable to determining the registrar, regardless of whether it’s gTLD or ccTLD. Is that incorrect? Similar to the above response, for RDRS to determine a domain name’s sponsoring registrar based on the registry operator’s WHOIS service, the service must be compliant with the relevant policy and contractual requirements which are not applicable to ccTLD registry operators, and define the location and supported formats of the WHOIS service. Additionally, determining the sponsoring registrar of a domain name is done using identifiers that are applicable only to ICANN-accredited registrars, which may not be the case for domain names in ccTLDs. iii. What LOE would it be to run the initial domain query as you already are, but only “error out for ccTLD” reasons if the query does not successfully identify a participating registrar? We are still assessing the level of effort (LOE), but we would likely require additional analysis to agree on the desired behavior and to consider new scenarios. That being said, based on a preliminary discussion with the team and considering the reasons outlined above, the likely LOE has been estimated to be 'very high' as indicated in the Impressions Document. @ all: Having heard from a small # of ccTLD operators a desire to participate in RDRS, i. Would voluntary ccTLD participation in RDRS help provide us lessons that might be factored into consideration of whether/how ccTLD voluntary mechanisms might be employed in a SSAD/ successor systems? /ps - added below an edit to the initial email, w the critical clarification “ccTLD” From: Andrews, Gabriel F. (STB) (FBI) Sent: Thursday, June 6, 2024 10:51 AM To: gnso-rdrs-sc(a)icann.org Subject: Email thread for discussing voluntary inclusion of ccTLDs Hi all – Noting the desire to “clean up” the impressions document, I hoped to shift from a margin comment conversation to an email conversation for the specific issue of whether/not RDRS can pass requests to participating registrars regardless of whether/not the domain is a ccTLD. Below are pasted the original feedback topic, and the subsequent margin comments. I will next respond to my own email (this) to continue the discussion, but wanted to make a clean break before adding anything new. Cheers, G Gabriel Andrews 11:33 AM May 22 Pinned for further discussion. Existing RDS/WHOIS queries provide this information a non-zero % of time - is this intended to say technical staff can't guarantee to have the info 100% of the time? Clarity sought. Anonymous 8:38 AM May 30 In other words: what other info does ICANN tech staff think is needed in order to route the request to the registrar as is done in gTLD contexts? Anonymous 8:39 AM May 30 Additionally: PSWG is hearing from some ccTLD operators their desire to voluntarily participate in RDRS, which may assist in solving any challenges. Lisa Carter 9:03 AM Today Just an FYI that RDDS requirements for ccTLDs are Unstandardized/Unenforceable as there is no contract for ccTLDs with ICANN.

2 5

Re: Revising API Feedback: (via requestors shouldering more of the lift for RDRS API burden)
by Lisa Carter July 1, 2024

July 1, 2024

Thanks Gabriel for updated item 7 to include the additional information. I will check with our technical team about providing an updated LOE for this request. Best, Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Gabriel Andrews via Gnso-rdrs-sc <gnso-rdrs-sc(a)icann.org> Reply-To: Gabriel Andrews <gfandrews(a)fbi.gov> Date: Monday, July 1, 2024 at 12:01 PM To: "gnso-rdrs-sc(a)icann.org" <gnso-rdrs-sc(a)icann.org> Cc: "Sebastien(a)registry.godaddy" <Sebastien(a)registry.godaddy> Subject: [Gnso-rdrs-sc] Re: Revising API Feedback: (via requestors shouldering more of the lift for RDRS API burden) This request has now been updated in Item 7 in the revised impressions document [docs.google.com] Per the call, committee wanted to know the level of effort for creation of a “test domain” that can be used without influencing the RDRS data collection. Committee was seen as not needing to approve creation of technical PoC email address to respond to RDRS technical questions; no objections to ICANN staff taking this action were raised. G From: Andrews, Gabriel F. (STB) (FBI) Sent: Friday, June 28, 2024 11:05 AM To: gnso-rdrs-sc(a)icann.org Cc: Sebastien(a)registry.godaddy Subject: Revising API Feedback: (via requestors shouldering more of the lift for RDRS API burden) Hi Standing Committee Team, Sebastien: Would you kindly add to the agenda for the next call the discussion topic “API: Revised request to reduce ICANN staff burden / LOE” Having spoken with technical staff on my end, I sense an opportunity to shoulder some of the burden of the “API” request we’d previously assigned a high LoE to. This is taking the tack suggested by Steve Crocker to standardize connections from our end, rather than asking ICANN staff to create new API specific to the RDRS. If we can do this successfully, it might also help inform some important parallel work on issues pertaining to LE identity validation. There would still be an “ask” of ICANN staff, but a much reduced one: We’d want a “test domain” we could use to query to test connections without tainting RDRS data collection. We’d want a little help understanding ICANN’s existing API structure > meaning asking ICANN to designating a technical point of contact (email address) that requestor group engineers could send technical q’s to if needed. I’m hopeful this could shortcut an otherwise high level of effort ask, and remove a good deal of the burden for it from ICANN shoulders. I seek SC concurrence to bless ICANN staff to take actions 1 & 2 above. -Gabriel PS – Q for clarity: do we know if requestors receive an email from ICANN whenever the “status” of their request changes? I’m told by the engineers this could be relevant (and preferred).

1 0