[GNSO-EPDPP2-SmallTeam] GNSO Report draft - Review deadline COB1 April 2022

Thu Apr 14 13:16:49 UTC 2022

Sarah,

Thanks for responding.  In my view, this is the beginning of a constructive
conversation, not the end.  The question, in my view, is not *whether* to
implement a reverse search capability but *how*.  That is, assume the
capability is provided, how should it be managed?  Who should be allowed to
use it, and under what circumstances?  What forms of audit and
accountability are needed?  Etc.  These questions might seem daunting, but
they're actually quite approachable.  In any case, a decision made within
the GNSO policy development process to just say there will not be any
support for reverse search is, in my view, a significant mistake.

Steve

On Thu, Apr 14, 2022 at 8:56 AM Sarah Wyld <swyld at tucows.com> wrote:

> 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 at tucows.com
>
>
>
>
>
> *From: *Steve Crocker <steve at shinkuro.com>
> *Sent: *April 13, 2022 6:58 PM
> *To: *Anderson, Marc <mcanderson at verisign.com>
> *Cc: *gnso-secs at icann.org; gnso-epdpp2-smallteam at 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 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 at 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 at icann.org>
> On Behalf Of Steve Crocker
> > Sent: Thursday, March 31, 2022 8:39 AM
> > To: Sebastien at registry.godaddy
> > Cc: gnso-secs at icann.org; gnso-epdpp2-smallteam at 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 at registry.godaddy
> <Sebastien at 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
> >
> > +33612284445
> >
> > France & Australia
> >
> > sebastien at registry.godaddy
> >
> >
> >
> > _______________________________________________
> > GNSO-EPDPP2-SmallTeam mailing list
> > GNSO-EPDPP2-SmallTeam at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mm.icann.org/pipermail/gnso-epdpp2-smallteam/attachments/20220414/b2ea2a22/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: BF3519ABBBF549AB86EC21B190B4914D.png
Type: image/png
Size: 15054 bytes
Desc: not available
URL: <https://mm.icann.org/pipermail/gnso-epdpp2-smallteam/attachments/20220414/b2ea2a22/BF3519ABBBF549AB86EC21B190B4914D-0001.png>