GNSO Report draft - Review deadline COB 1 April 2022
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?pl... 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<mailto:sebastien@registry.godaddy>
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?pl...
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
[image: 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.
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 <mailto:Sebastien@registry.godaddy> <Sebastien@registry.godaddy <mailto: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?pl... 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 +33612284445 France & Australia <mailto:sebastien@registry.godaddy> sebastien@registry.godaddy _______________________________________________ GNSO-EPDPP2-SmallTeam mailing list GNSO-EPDPP2-SmallTeam@icann.org <mailto:GNSO-EPDPP2-SmallTeam@icann.org> https://mm.icann.org/mailman/listinfo/gnso-epdpp2-smallteam <https://secure-web.cisco.com/16EwPeCGuDU59mzEufavEyg2KSfRbwD6tuJxHRXP2L7FnBp...> _______________________________________________ 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 <https://secure-web.cisco.com/1GFNlstXTEHBhkPQuf5R1iqqU5lh384VDNAbJXkLDCsu3s6...> ) and the website Terms of Service (https://www.icann.org/privacy/tos <https://secure-web.cisco.com/1vQbhzTRjWW3uaBRjBoi3qhLyr87E828WLNvRyLHnCsm-1F...> ). 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.
Marc, I apologize for not responding sooner. Thanks for forwarding the link to the use cases. My comments about understanding the requests and requesters are written from the point of view of understanding whether the requester is going to be able to get the data or action they feel is necessary. The mapping of their *needs* into the list of officially sanctioned *purposes* is one of the possible disconnects. Use case BC-3 provides a useful example. Here's the relevant wording: *BC-3: Overarching Purpose: Investigate, detect, prevent, and bring civil claims for Abusive Domain namesUse Case: Identify owner of abusive domains and other related domains involved in civil legal claims related to phishing, malware, botnets, and other fraudulent activities* *c) Data elements that may typically be disclosed:* *Registrant name, e-mail, address, phone, postal address* *Technical contact name, email address, phone, postal address* *Other domain names linked to the registrant’s data contact fields* The last line entails a "reverse search." Unpacking this a bit, the typical scenario will include two or more requests. The first request will ask for the registration data associated with a specific domain. A subsequent request will then ask for registrations that share the same registrant or email address. I don't believe reverse search or anything close to it is currently included in the specifications. The effect is to tell the folks who feel the BC-3 use case is important to their work that they can't do their work. Steve On Thu, Mar 31, 2022 at 9:32 AM Anderson, Marc <mcanderson@verisign.com> wrote:
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:
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. The requirement that registrars review every request runs counter to the necessary goal of learning how to automate as much as possible. The history of requests and responses must be available for study in order to learn how to evolve the overall system. 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?pl...
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
+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.
Hi Steve,
. The effect is to tell the folks who feel the BC-3 use case is important to their work that they can't do their work.
I think this is slightly misstating the situation. Instead, I would say that the effect is to tell the folks who feel that BC-3 use case is important that sometimes their desire to use the data does not override the data subject’s right to privacy. Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Steve Crocker Sent: April 13, 2022 6:58 PM To: Anderson, Marc Cc: gnso-secs@icann.org; gnso-epdpp2-smallteam@icann.org Subject: Re: [GNSO-EPDPP2-SmallTeam] GNSO Report draft - Review deadline COB1 April 2022 Marc, I apologize for not responding sooner. Thanks for forwarding the link to the use cases. My comments about understanding the requests and requesters are written from the point of view of understanding whether the requester is going to be able to get the data or action they feel is necessary. The mapping of their needs into the list of officially sanctioned purposes is one of the possible disconnects. Use case BC-3 provides a useful example. Here's the relevant wording: BC-3: Overarching Purpose: Investigate, detect, prevent, and bring civil claims for Abusive Domain names Use Case: Identify owner of abusive domains and other related domains involved in civil legal claims related to phishing, malware, botnets, and other fraudulent activities c) Data elements that may typically be disclosed: Registrant name, e-mail, address, phone, postal address Technical contact name, email address, phone, postal address Other domain names linked to the registrant’s data contact fields The last line entails a "reverse search." Unpacking this a bit, the typical scenario will include two or more requests. The first request will ask for the registration data associated with a specific domain. A subsequent request will then ask for registrations that share the same registrant or email address. I don't believe reverse search or anything close to it is currently included in the specifications. The effect is to tell the folks who feel the BC-3 use case is important to their work that they can't do their work. Steve On Thu, Mar 31, 2022 at 9:32 AM Anderson, Marc <mcanderson@verisign.com> wrote:
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:
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. The requirement that registrars review every request runs counter to the necessary goal of learning how to automate as much as possible. The history of requests and responses must be available for study in order to learn how to evolve the overall system. 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?pl...
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
+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.
Hi Steve,
. The effect is to tell the folks who feel the BC-3 use case is important to their work that they can't do their work.
I think this is slightly misstating the situation. Instead, I would say that the effect is to tell the folks who feel that BC-3 use case is important that sometimes their desire to use the data does not override the data subject’s right to privacy. Thanks, -- Sarah Wyld, CIPP/E Policy & Privacy Manager Pronouns: she/they swyld@tucows.com From: Steve Crocker Sent: April 13, 2022 6:58 PM To: Anderson, Marc Cc: gnso-secs@icann.org; gnso-epdpp2-smallteam@icann.org Subject: Re: [GNSO-EPDPP2-SmallTeam] GNSO Report draft - Review deadline COB1 April 2022 Marc, I apologize for not responding sooner. Thanks for forwarding the link to the use cases. My comments about understanding the requests and requesters are written from the point of view of understanding whether the requester is going to be able to get the data or action they feel is necessary. The mapping of their needs into the list of officially sanctioned purposes is one of the possible disconnects. Use case BC-3 provides a useful example. Here's the relevant wording: BC-3: Overarching Purpose: Investigate, detect, prevent, and bring civil claims for Abusive Domain names Use Case: Identify owner of abusive domains and other related domains involved in civil legal claims related to phishing, malware, botnets, and other fraudulent activities c) Data elements that may typically be disclosed: Registrant name, e-mail, address, phone, postal address Technical contact name, email address, phone, postal address Other domain names linked to the registrant’s data contact fields The last line entails a "reverse search." Unpacking this a bit, the typical scenario will include two or more requests. The first request will ask for the registration data associated with a specific domain. A subsequent request will then ask for registrations that share the same registrant or email address. I don't believe reverse search or anything close to it is currently included in the specifications. The effect is to tell the folks who feel the BC-3 use case is important to their work that they can't do their work. Steve On Thu, Mar 31, 2022 at 9:32 AM Anderson, Marc <mcanderson@verisign.com> wrote:
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:
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. The requirement that registrars review every request runs counter to the necessary goal of learning how to automate as much as possible. The history of requests and responses must be available for study in order to learn how to evolve the overall system. 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?pl...
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
+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.
Just listened to Council discussion of our small team report today. What I heard argues for our Small Team to hold at least one more meeting: 1. councilors heard that PoC will assess request volumes, which would help in determining costs of an eventual SSAD (p.6 item 5 in our attached report: "SSAD PoC should run for period of time to gather representative picture of request volume..." But as noted in a footnote of our report, I believe we will have low request volume for a Ticketing System that does not improve upon today’s experience of delayed responses and non-disclosures. Low volume experience will undermine our contention that we need to improve upon the status quo. 2. Heard some discussion of the attached InfoNetworks proposal for an “SSAD Pilot that addresses the actual goal for the SSAD development process and demonstrates its viability (p.7)”. Our small team could assess that option. Moreover, another part of the InfoNetworks paper deserves our consideration: InfoNetworks is helping DotMusic to seek “action guidance” from Cyprus DPA, based upon a detailed reference implementation and privacy impact assessment. We should examine that Cyprus experience as an option for seeking SSAD guidance from the EDPB. I would like to understand the time and cost of developing the minimum documentation and reference implementation required for Org to seek EDPB guidance. Sincerely, Steve DelBianco ICANN Business Constituency -- President & CEO, NetChoice +1-703-615-6206
SteveDB, Thanks and I concur. The ultimate touchstone is whether the requesters are being served. The rights of the registrants, the cost and efficiency of the overall system, and the risks to the registrars, et al are all essential considerations and form a set of constraints, but within these constraints it is also essential to focus on what the requesters need and to ensure any proposed system will actually meed their needs. Steve C On Thu, Apr 14, 2022 at 10:20 AM Steve DelBianco <sdelbianco@netchoice.org> wrote:
Just listened to Council discussion of our small team report today.
What I heard argues for our Small Team to hold at least one more meeting:
1. councilors heard that PoC will assess request volumes, which would help in determining costs of an eventual SSAD (p.6 item 5 in our attached report: "SSAD PoC should run for period of time to gather representative picture of request volume..."
But as noted in a footnote of our report, I believe we will have low request volume for a Ticketing System that does not improve upon today’s experience of delayed responses and non-disclosures. Low volume experience will undermine our contention that we need to improve upon the status quo.
2. Heard some discussion of the attached InfoNetworks proposal for an “SSAD Pilot that addresses the actual goal for the SSAD development process and demonstrates its viability (p.7)”. Our small team could assess that option.
Moreover, another part of the InfoNetworks paper deserves our consideration: InfoNetworks is helping DotMusic to seek “action guidance” from Cyprus DPA, based upon a detailed reference implementation and privacy impact assessment.
We should examine that Cyprus experience as an option for seeking SSAD guidance from the EDPB. I would like to understand the time and cost of developing the minimum documentation and reference implementation required for Org to seek EDPB guidance.
Sincerely,
Steve DelBianco
ICANN Business Constituency
--
President & CEO, NetChoice
+1-703-615-6206
_______________________________________________ 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.
Hi Steve, Sorry for the late response, I was keen on better understanding our timelines before scheduling further meetings. I shared my views regarding that in my previous email today. While we organize for the ODP team to conduct its scoping work, I am more than happy to organize further discussions with the Small Team to discuss these topics and any other the team may see fit. The easiest is probably for Staff to circulate a Doodle Poll to find a time block that works for all. In the same vein: I do not want to change the representative model of this team, but as it is taking more time than initially anticipated, I think it is fair to offer any member the opportunity to step down and designate someone to replace them. Kindly, Sebastien Ducos GoDaddy Registry | Senior Client Services Manager [signature_1674226866] +33612284445 France & Australia sebastien@registry.godaddy<mailto:sebastien@registry.godaddy> From: GNSO-EPDPP2-SmallTeam <gnso-epdpp2-smallteam-bounces@icann.org> on behalf of Steve DelBianco <sdelbianco@netchoice.org> Date: Thursday, 14 April 2022 at 4:23 pm To: gnso-epdpp2-smallteam@icann.org <gnso-epdpp2-smallteam@icann.org> Cc: gnso-secs@icann.org <gnso-secs@icann.org> Subject: [GNSO-EPDPP2-SmallTeam] next steps You don't often get email from sdelbianco@netchoice.org. Learn why this is important<http://aka.ms/LearnAboutSenderIdentification> Caution: This email is from an external sender. Please do not click links or open attachments unless you recognize the sender and know the content is safe. Forward suspicious emails to isitbad@. Just listened to Council discussion of our small team report today. What I heard argues for our Small Team to hold at least one more meeting: 1. councilors heard that PoC will assess request volumes, which would help in determining costs of an eventual SSAD (p.6 item 5 in our attached report: "SSAD PoC should run for period of time to gather representative picture of request volume..." But as noted in a footnote of our report, I believe we will have low request volume for a Ticketing System that does not improve upon today’s experience of delayed responses and non-disclosures. Low volume experience will undermine our contention that we need to improve upon the status quo. 2. Heard some discussion of the attached InfoNetworks proposal for an “SSAD Pilot that addresses the actual goal for the SSAD development process and demonstrates its viability (p.7)”. Our small team could assess that option. Moreover, another part of the InfoNetworks paper deserves our consideration: InfoNetworks is helping DotMusic to seek “action guidance” from Cyprus DPA, based upon a detailed reference implementation and privacy impact assessment. We should examine that Cyprus experience as an option for seeking SSAD guidance from the EDPB. I would like to understand the time and cost of developing the minimum documentation and reference implementation required for Org to seek EDPB guidance. Sincerely, Steve DelBianco ICANN Business Constituency -- President & CEO, NetChoice +1-703-615-6206
participants (5)
-
Anderson, Marc -
Sarah Wyld -
Sebastien＠registry.godaddy -
Steve Crocker -
Steve DelBianco