Steve,

 

You’ve mentioned this a couple times now, and I must admit I’m a little confused by your statements about needing to understand requests and requestors.  I think its pretty well understood and was discussed at length during the working group deliberations.   Recommendation 7 from the final report deals with requestor purposes and provides a non-exhaustive list.  This was derived from extensive discussions the working group had around use cases.  Those use case discussions were captured by staff and documented on the wiki page:  https://community.icann.org/display/EOTSFGRD/d.+Use+Cases  They weren’t included in the final report, but they are linked to in section 2.2 under EPDP team approach.  Perhaps that will be helpful.

 

On the duration/interval, I think a check in every 6 months for a maximum of 2 years seems like a reasonable approach.  >From your feedback, you seem to think that is to long.  Do you have a different duration/interval in mind?

 

Best,

Marc

 

 

 

From: GNSO-EPDPP2-SmallTeam <gnso-epdpp2-smallteam-bounces@icann.org> On Behalf Of Steve Crocker
Sent: Thursday, March 31, 2022 8:39 AM
To: Sebastien@registry.godaddy
Cc: gnso-secs@icann.org; gnso-epdpp2-smallteam@icann.org
Subject: [EXTERNAL] Re: [GNSO-EPDPP2-SmallTeam] GNSO Report draft - Review deadline COB 1 April 2022

 

Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 

Sebastian, et al,

 

Thanks.  I've added my comments.  The main points are:

  1. The overarching statement that "[t]he most important data gap in the ODA is the unknown volume of use for the SSAD" is completely wrong.  Rather, what's missing is what knowledge of what the requesters need and how to move toward a streamlined system that meets their needs without putting the contracted parties or ICANN at risk.
  2. The requirement that registrars review every request runs counter to the necessary goal of learning how to automate as much as possible.
  3. The history of requests and responses must be available for study in order to learn how to evolve the overall system.
  4. A two year test with six month intervals is not consistent with "A proof of concept ... is expected to be relatively easy and inexpensive to set up and implement."

Thanks,

 

Steve

 

 

On Thu, Mar 31, 2022 at 6:47 AM Sebastien@registry.godaddy <Sebastien@registry.godaddy> wrote:

Hello Team,

 

As discussed on our call yesterday, we edited the report prepared for the GNSO, in line with our latest discussions.

Please find it here https://docs.google.com/document/d/1m3dANwxKK_q8gk5OTBcANkPk-PkTOCMS/edit?pli=1

 

We kindly ask you to review and comment it by COB tomorrow, Friday 1 April, for us to meet our Council submission deadline on Monday.
We currently have a call scheduled for Monday should we need clarifications on your inputs. We may cancel this call if the report is clear and agreed by tomorrow.

 

Please note that we have left the idiom ‘proof of concept’ in the document because we used it in our previous verbal reports. I did note that the small team had requested to give it a proper name and referenced “Simplified Request System” as suggested by Sarah in the chat. I know Ticketing System has often been used, but I see this as a generic term for the type of tools we foresee using, rather than a specific name for this tool.

With your approval, going forward we will use Simplified Request System in our communications.

 

Looking forward to your comments on the Google doc.

 

Kindly,

 

 

Sebastien Ducos

GoDaddy Registry | Senior Client Services Manager

signature_2929969775

+33612284445

France & Australia

sebastien@registry.godaddy

 

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