Hi,

 

What is the purpose of gathering info on requests and requestors?

 

If it is to understand the patterns in requests so that we can automate the request and response process, I think we‘ve been through enough discussion on that topic in the EPDP to know that we cannot come to agreement on it. So... if an SSAD relies on automation of response as a fundamental feature, is that ever going to be doable in real life? 

 
 
-- 
Sarah Wyld, CIPP/E
 
Policy & Privacy Manager
Pronouns: she/they
 
swyld@tucows.com

 

 

From: Steve Crocker
Sent: March 28, 2022 10:00 AM
To: Sarah Wyld
Cc: Marika Konings; gnso-epdpp2-smallteam@icann.org
Subject: Re: [GNSO-EPDPP2-SmallTeam] Reminder & Proposed Agenda for EPDPPhase2 Small Team meeting with ICANN Org to assess Proof of Conceptproposed Requirements

 

Sarah,

 

Thanks.  I think the common ground here is that we don't have enough information about the requests and the requesters.  The attempt to size the eventual system and determine its cost of operation is premature.  If a system is going to be built and fielded, the focus has to be on gathering info on requests and requesters.  The ticketing system, as described, is not sufficient for this purpose.  Both the requesters and the collectors (registrars, registries, resellers, etc.) also have to participate in analysis of the data.  Sizing the ticketing system is actually the least interesting element of the design.

 

Steve

 

 

On Mon, Mar 28, 2022 at 9:54 AM Sarah Wyld <swyld@tucows.com> wrote:

Thanks for sharing this, Steve. A couple thoughts:

 

> the experimental system will not have the functionality and performance of a real system. It is doubtful any measurement of the use of the proposed system will yield data that will be useful in predicting future use.

 

SW: Yes, agreed – the experimental system would include only a portion of the full SSAD as described in the recs, and so the functionality would not be mirrored and thus it’s a flawed analogue to the full system. I had thought it would still provide useful data, but perhaps not.

 

> it seems extremely likely that it will be possible to define classes of requests associated with defined groups of requesters that all meet the same conditions. Predetermination in those cases would therefore allow automated processing of such requests

 

SW: We have found this not to be the case; requests sent in from the same group (or even the same individual requestor) are sometimes determined to warrant disclosure of the data, but not always, so this necessitates human review of each request. And of course we all would remember the long discussions about automation that occurred in the EPDP, resulting in very narrow use cases, so I’m not sure this is a practical idea.

 

Thanks, 

 
 
-- 
Sarah Wyld, CIPP/E
 
Policy & Privacy Manager
Pronouns: she/they
 
swyld@tucows.com

 

 

From: Steve Crocker
Sent: March 27, 2022 5:01 PM
To: Marika Konings
Cc: gnso-epdpp2-smallteam@icann.org
Subject: Re: [GNSO-EPDPP2-SmallTeam] Reminder & Proposed Agenda for EPDPPhase 2 Small Team meeting with ICANN Org to assess Proof of Conceptproposed Requirements

 

Marika, et al,

 

Attached is a note for inclusion and discussion.  The key points in the note are:

  1. If a system is going to be built and fielded, the appropriate goal is to learn more about the classes of requests and groups of requesters.  This will help determine how to build an effective and efficient system.  It remains premature to expect the system to yield useful data on the volumes of usage.
  2. There was substantial prior work in the Expert Working Group and in the ad hoc RDAP Pilot.  We should be building on that work.

Thanks,

 

Steve

 

 

On Thu, Mar 24, 2022 at 6:35 AM Marika Konings <marika.konings@icann.org> wrote:

Dear All,

 

As a reminder, please provide any further input and/or suggestions you may have on the Proof of Concept Outline & Requirements (see https://docs.google.com/document/d/1m3dANwxKK_q8gk5OTBcANkPk-PkTOCMS/edit?pli=1) by the end of today. The staff support team has made some minor updates in line with yesterday’s meeting (in redline).

 

For Monday’s meeting, hereby the proposed agenda:

 

EPDP Phase 2 Small Team meeting with ICANN org to assess Proof of Concept proposed Requirements – Monday 28 March at 14.00 UTC

 

  1. Welcome
  2. Walk through of Proof of Concept Outline & Expectations with ICANN org
    1. What is the Proof of Concept expected to prove / disprove?
    2. Which aspects of the SSAD recommendations are expected to be part of the proof of concept to provide essential insights?
    3. Q & A – any clarifying questions to better understand the small teams expectations
    4. Initial reactions – e.g. what is likely possible, what may be possible, what is likely impossible
  1. Small team to consider what updates, if any, should be made to Proof of Concept based on discussion under #2
  2. Confirm next steps & next EPDP Phase 2 Small Team meeting (Wednesday 30 March at 14.00 UTC)

 

Best regards,

 

Marika

_______________________________________________
GNSO-EPDPP2-SmallTeam mailing list
GNSO-EPDPP2-SmallTeam@icann.org
https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam

_______________________________________________
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.