One aspect that I did not hear during the discussion is whether reporting of confidential queries needs to be done in real time or can be done some time later. I think the usual reason for requesting confidentiality is to avoid tipping off the registrant that an inquiry from law enforcement is being made. It's my impression that it would be ok to reveal this detail sometime in the future. I suspect there's no simple rule, e.g. "after two weeks" but is instead related to the progress of the investigation. That said, I can imagine imposing a rule that says the requesting agency must release the hold at some point. To maintain some degree of discipline, perhaps it would be reasonable to report the total number of confidential inquiries that have not been released. If the number keeps growing, it might be appropriate for someone with access to the underlying data to work with the requestors to make sure they are not forgetting to remove the hold. Thanks, Steve On Mon, Oct 7, 2024 at 11:03 AM farzaneh badii via Gnso-rdrs-sc < gnso-rdrs-sc@icann.org> wrote:
Thank you Lisa
I just wanted to record the response here:
At NCSG we care about and advocate for: 1)law enforcement location to be transparently disclosed 2) the number of requests received from the law enforcement agency in each country.
These two requests were received well by the SC and reporting on law enforcement requests location is a normal procedure for many tech corporations. Unfortunately how it has been decided to report and display the data defeats the purpose.
In my opinion, the discussion went as follows: NCSG requested that the report include the location of law enforcement requests. Then, other SC members suggested that we also report the location of other types of requests. We agreed to this, but our intention was not for all request types to be aggregated into one bucket with a single report on their location. We specifically argued for the law enforcement request locations to be reported separately, in the interest of transparency. The way it's currently designed defeats that purpose.
What we agreed on was for the report to include the location of each request type separately. We were being collegial in agreeing to include the locations of other request types, but we did not intend for that to result in the law enforcement request locations being lost or lumped together with others. Our goal was always for the location of law enforcement requests to be reported visibly and transparently.
What we envisioned was a simple chart that clearly states:
- X number of requests from Intellectual Property holders came from this country - X number of requests from Law Enforcement came from that country.
In our (NCSG) request document, we included examples of how other tech companies do this. We referenced tables that clearly display this type of information to clarify what we meant for ease of use. [Google doc link <https://docs.google.com/document/d/1Lyj-g5y8JLBSf-dHm81Cf_bFDRBEeZ-KgYYy44at...> ].
Regarding aggregation, it's important to emphasize that confidentiality of law enforcement requests were carefully considered. We had discussions with the Gabreil to ensure that the way we report law enforcement requests does not violate confidentiality, and they agreed with our approach. Other tech companies and organizations report on law enforcement requests, even when there's only one, and they also comply with privacy laws. Privacy policies should not apply to public bodies that should be held accountable to the public.
We need to discuss this further. It is crucial to bring some transparency to the location of law enforcement requests. Transparency is also mentioned in ICANN bylaws.
Best regards Farzaneh
On Thu, Oct 3, 2024 at 6:21 PM Lisa Carter via Gnso-rdrs-sc < gnso-rdrs-sc@icann.org> wrote:
Hello Standing Committee Members,
Attached is a sample/preview of Metric 18 which displays the number of requestors by country (Item #1 in the RDRS SC Workbook <https://docs.google.com/spreadsheets/d/1XFK-RCT5Nv-KcNgX4eQunkUKgSI35Yc_nUZ6...> “Requestors” tab). As a reminder, how ICANN displays Metric 18 and why it is displayed as shown in the attachment was discussed on the Standing Committee call that took place 9 September 2024. You can also reference the explanation in column (J8) ICANN LOE Notes in the RDRS SC Workbook.
We will be discussing this new metric as part of the agenda for our call on Monday, 7 October, so any questions or comments you have can be addressed during the call. Metric 18 will be included in the RDRS Usage Metrics Report published by mid-October.
Best,
Lisa Carter
Sr. Program Manager, Strategic Initiatives
ICANN
[image: signature_3827786603]
_______________________________________________ Gnso-rdrs-sc mailing list -- gnso-rdrs-sc@icann.org To unsubscribe send an email to gnso-rdrs-sc-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
_______________________________________________ Gnso-rdrs-sc mailing list -- gnso-rdrs-sc@icann.org To unsubscribe send an email to gnso-rdrs-sc-leave@icann.org
_______________________________________________ By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.
-- Sent by a Verified [image: Sent by a Verified sender] <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> sender
