The call will take place on Monday, 03 April 2023 at 17:30 UTC for 60 minutes.
For other places see: https://tinyurl.com/p8wzj252
2. Data to be included in RDRS Reporting (see page 4 https://gnso.icann.org/sites/default/files/policy/2022/correspondence/ducos-to-gnso-council-07nov22-en.pdf [gnso.icann.org] [gnso.icann.org]). Consider additional suggestions made and question regarding format / platform:
a. Number of Requests by Requestor (may be pseudonymized/anonymized if needed)
b. Denial Rate by Reason Type
c. # of Registrars that have published information about the existence of RDRS on their web-sites and encouraged requestors to submit requests there
d. Is there a preference for format and platform for the published metrics reports?
3. Success criteria for this system which should include analysis of relevant usage data:
a. Consider proposal from Sarah: “The RDRS will gather disclosure request volumes, which will help inform the Board's decision about building the full SSAD. As such, success criteria should be tied to the RDRS’s ability to gather that request volume.
- Is the RDRS available to all possible requestors?
- Is the RDRS available to all interested registrars?
- Can the RDRS be used to submit requests?
- Does the RDRS track request outcomes?
If those are all ‘yes’, then the RDRS should be considered to be successfully gathering registration data disclosure request volumes.”
b. Other suggestions?
4. How to best to promote and secure comprehensive use of the system, both by potential requestors as well as ICANN accredited registrars. (if time allows)
a. Small team to discuss
5. Further consideration of the other topics identified in the addendum that the small team did not consider gating factors but for which it would be interested to have further discussions with ICANN org during the implementation phase to consider if/how some of these aspects could be considered to be added in the current implementation of WDS or a future version (1) API, 2) confidentiality options for LE requests, 3) billing mechanism, 4) review of terms and conditions for requestors as well as participating registrars, 5) requests submitted fall under “reasonable access” & phase 1 requirements; 6) ability for requestor to indicate if they do not agree with information logged by registrar) – (if time allows)
6. Confirm next steps & confirm next meeting (Monday 10 April at 17.30 UTC)
Apologies: Thomas Rickert, John McElwaine
Chat Transcript - located on zoom recording/select the chat tab
Notes/ Action Items
- ICANN org RDRS Project Team to provide the EPDP Phase 2A Small Team with a digestible version of the data model (such as a chart) as soon as possible. Data Model to include a transaction table for transfers to registrars and a table for registrar responses. (Note: due to the upcoming holiday weekend, the Project Team will not be able to provide this is advance of the next meeting.)
- The Small Team will continue discussing success criteria for the RDRS at the next meeting. Accordingly, Small Team Members to review Sarah’s proposal (included below, for reference) and provide additional points/concerns ahead of the call. Small Team members to come prepared to continue the discussion of success criteria at the next meeting on Monday, 10 April at 17:30 UTC.
The RDRS will gather disclosure request volumes, which will help inform the Board's decision about building the full SSAD. As such, success criteria should be tied to the RDRS’s ability to gather that request volume.
Is the RDRS available to all possible requestors?
Is the RDRS available to all interested registrars?
Can the RDRS be used to submit requests?
Does the RDRS track request outcomes?
If those are all ‘yes’, then the RDRS should be considered to be successfully gathering registration data disclosure request volumes.