Re: [Ext] RE: Link to RDRS in RDDS Lookup
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@fbi.gov> Date: Tuesday, June 18, 2024 at 9:32 AM To: "Sebastien@registry.godaddy" <Sebastien@registry.godaddy>, Lisa Carter <lisa.carter@icann.org>, "gnso-rdrs-sc@icann.org" <gnso-rdrs-sc@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@icann.org> Sent: Tuesday, June 18, 2024 2:00 AM To: Lisa Carter <lisa.carter@icann.org>; gnso-rdrs-sc@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@registry.godaddy
Thank you Lisa – on this point, I don’t object to ICANN’s proposed injection of text/link to RDRS, and have added it to track in the feedback document as you suggest. I will note, however, that the primary ask is *not* that the RDRS link to be included in the tool, but for it to be included in the RDDS data, and for ICANN to work with the contracted parties to determine how this might best be accomplished not only in RDRS contexts, but in SSAD contexts as well. There are thousands of such tools – but only one standard for returned RDAP data. By putting the link in the tool, you might reach a small % of RDAP users. By putting the link in the data, you reach them all. From: Lisa Carter <lisa.carter@icann.org> Sent: Thursday, June 27, 2024 2:09 PM To: Andrews, Gabriel F. (STB) (FBI) <gfandrews@fbi.gov>; Sebastien@registry.godaddy; gnso-rdrs-sc@icann.org Subject: [EXTERNAL EMAIL] - Re: [Ext] RE: Link to RDRS in RDDS Lookup 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. [cid:image001.png@01DAC942.A9B44880] Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN [signature_3554201727] From: Gabriel Andrews <gfandrews@fbi.gov<mailto:gfandrews@fbi.gov>> Date: Tuesday, June 18, 2024 at 9:32 AM To: "Sebastien@registry.godaddy<mailto:Sebastien@registry.godaddy>" <Sebastien@registry.godaddy<mailto:Sebastien@registry.godaddy>>, Lisa Carter <lisa.carter@icann.org<mailto:lisa.carter@icann.org>>, "gnso-rdrs-sc@icann.org<mailto:gnso-rdrs-sc@icann.org>" <gnso-rdrs-sc@icann.org<mailto:gnso-rdrs-sc@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]<https://urldefense.com/v3/__https:/lookup.icann.org/__;!!PtGJab4!7Wp7ptuQxEn...> , 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]<https://urldefense.com/v3/__https:/centralops.net/co/__;!!PtGJab4!7Wp7ptuQxE...> , 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. [cid:image003.png@01DAC942.A9B44880] 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 ~ [cid:image004.png@01DAC942.A9B44880] 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<https://www.icann.org/en/system/files/files/rdap-response-profile-15feb19-en...>, there is a “MUST” in 2.7.4.3 which reads: [cid:image005.jpg@01DAC942.A9B44880] … 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) [cid:image006.jpg@01DAC942.A9B44880] …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@icann.org<mailto:gnso-rdrs-sc@icann.org>> Sent: Tuesday, June 18, 2024 2:00 AM To: Lisa Carter <lisa.carter@icann.org<mailto:lisa.carter@icann.org>>; gnso-rdrs-sc@icann.org<mailto:gnso-rdrs-sc@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]<https://urldefense.com/v3/__https:/lookup.icann.org/en__;!!PtGJab4!7Wp7ptuQx...> [cid:image007.png@01DAC942.A9B44880] 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? 1. 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. 2. 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 [signature_2522542029] +33612284445 France & Australia sebastien@registry.godaddy<mailto:sebastien@registry.godaddy>
Hi Gabriel, Thank you for clarifying your ask to include a link to RDRS in the RDDS/RDAP response and for ICANN’s assistance in determining how to best accomplish this goal with respect to both RDRS and SSAD. In order to satisfy the two goals you mention below, the mechanism for implementing this type of request is through policy development. For example, the Additional Registration Data Directory Services (RDDS) Information Policy, updated on 21 February 2024, reflects the changes required to implement the Registration Data Policy. The Policy requires contracted parties to include a notice in the RDDS protocol output with a link to information that help’s users better identify a registration’s sponsoring registrar when inquiring about WHOIS inaccuracies. Similarly, information and links to the RDRS could be added in the RDDS/RDAP output through the GNSO policy development process. Best, Lisa Carter Sr. Program Manager, Strategic Initiatives ICANN From: Gabriel Andrews <gfandrews@fbi.gov> Date: Friday, June 28, 2024 at 10:27 AM To: Lisa Carter <lisa.carter@icann.org>, "Sebastien@registry.godaddy" <Sebastien@registry.godaddy>, "gnso-rdrs-sc@icann.org" <gnso-rdrs-sc@icann.org> Subject: RE: [Ext] RE: Link to RDRS in RDDS Lookup Thank you Lisa – on this point, I don’t object to ICANN’s proposed injection of text/link to RDRS, and have added it to track in the feedback document as you suggest. I will note, however, that the primary ask is *not* that the RDRS link to be included in the tool, but for it to be included in the RDDS data, and for ICANN to work with the contracted parties to determine how this might best be accomplished not only in RDRS contexts, but in SSAD contexts as well. There are thousands of such tools – but only one standard for returned RDAP data. By putting the link in the tool, you might reach a small % of RDAP users. By putting the link in the data, you reach them all. From: Lisa Carter <lisa.carter@icann.org> Sent: Thursday, June 27, 2024 2:09 PM To: Andrews, Gabriel F. (STB) (FBI) <gfandrews@fbi.gov>; Sebastien@registry.godaddy; gnso-rdrs-sc@icann.org Subject: [EXTERNAL EMAIL] - Re: [Ext] RE: Link to RDRS in RDDS Lookup 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@fbi.gov> Date: Tuesday, June 18, 2024 at 9:32 AM To: "Sebastien@registry.godaddy" <Sebastien@registry.godaddy>, Lisa Carter <lisa.carter@icann.org>, "gnso-rdrs-sc@icann.org" <gnso-rdrs-sc@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@icann.org> Sent: Tuesday, June 18, 2024 2:00 AM To: Lisa Carter <lisa.carter@icann.org>; gnso-rdrs-sc@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@registry.godaddy
participants (2)
-
Gabriel Andrews -
Lisa Carter