[Gnso-epdp-team] On the subject of ICANN's Bylaws...

Thu Aug 15 08:59:52 UTC 2019

To quickly respond to Greg's point,  I think we are way beyond the point of
understanding the spirit of the requests.  As previously noted we would not
be sitting at this table if we did not all patently understand the "why";
our point remains that even the most worthy of reasons may fall foul of an
inadequate form, explanation or justification . The law has set out the
principles and we must devise policy that respects that law - need I also
remind, we did not write the law,  we, (and for clarity the WE here is the
contracted parties and not the 3rd party requester) are the ones that must
follow it here in the first instance.  All the good intentions in the world
will not remedy illegality in our policy.

To echo the sentiment of the CPH letter sent on Tuesday, and noting Janis
has indicated that he hopes that the Zero Version report shall start that
path, I will reiterated that we need to create policy that is aimed at
expecting and glean the type of information required in a request, and not
merely provide 'standard' request formats based on 'Case Study 1 through *∞* .
Every request received will be unique - the policy/ process on how to deal
with each unique request - is what we should be trying to standardize.

Therefore to answer Mark's question as to what concrete steps I'm talking
about , using our 'use case' discussion and indeed my own reasoning when
reviewing them,I have thrown together a *really rough draft *of the process
which, when we cut through the concept of justifying angles, and actually
critically identify the process necessary in a 6(1)f situation - This was
merely an exercise of taking the process we are going through in our heads
in our deliberations, and writing it down for posterity. So I have tried to
focus on the process elements, which I go through in assessing the
individual "case study" - we need to take a step back to viewing a case
study (singular) as raw material to see what process steps we take to treat
that material, and come up with an answer - either 1)release 2)request more
info or 3)decline.

I hope it helps!

Alan

PS : to be clear this is my document not a RYSG or CPH doc

[image: Donuts Inc.] <http://donuts.domains>
Alan Woods
Senior Compliance & Policy Manager, Donuts Inc.
------------------------------
The Victorians,
15-18 Earlsfort Terrace
Dublin 2, County Dublin
Ireland

<https://www.facebook.com/donutstlds>   <https://twitter.com/DonutsInc>
<https://www.linkedin.com/company/donuts-inc>

Please NOTE: This electronic message, including any attachments, may
include privileged, confidential and/or inside information owned by Donuts
Inc. . Any distribution or use of this communication by anyone other than
the intended recipient(s) is strictly prohibited and may be unlawful.  If
you are not the intended recipient, please notify the sender by replying to
this message and then delete it from your system. Thank you.

On Mon, Aug 12, 2019 at 5:44 PM Mark Svancarek (CELA) <marksv at microsoft.com>
wrote:

> *Alan*, your advice seems reasonable, but I am not sure I am
> understanding what you are suggesting in actual practice.
>
>
>
> Regarding:
>
>
>
> “The past 2 use cases we have considered, although we appreciate the work
> that was undertaken to present to us in such detail, both requests were
> ultimately based on the same process of a 6(1)f. Our task must be to
> see-past the window dressing and consider the similarities and
> commonalities of the underlying process involved; this is after all, our
> goal. We seem to have slipped back into scrambling to getting our
> ‘interests’ and our ‘claims’ on the record for fear they somehow will not
> be accepted from consideration; we would again like to assert, that in the
> interests of time and resources, that the team should be prioritizing
> review of contrasting use cases, ones that require differing approaches, to
> further anticipate the breadth of the policy required, and not merely
> rehashing the same process from a different angle. “
>
> What should we have done differently, and how would you propose to handle
> it going forward?  Some specificity would be helpful.
>
>
>
>
>
> *From:* Gnso-epdp-team <gnso-epdp-team-bounces at icann.org> *On Behalf Of *Alan
> Woods
> *Sent:* Monday, August 12, 2019 1:37 AM
> *To:* James M. Bladel <jbladel at godaddy.com>
> *Cc:* gnso-epdp-team at icann.org
> *Subject:* Re: [Gnso-epdp-team] On the subject of ICANN's Bylaws...
>
>
>
> Dear Colleagues,
>
> The RYSG would like to support and thank James for his excellent response.
> We appreciate especially the reminder that the context in our discussions
> is key and we must resist, however how inadvertently, layering our own
> interpretations on top of settled, and defined concepts. Needless to say we
> support his reasoning wholeheartedly.
>
> We would further like to note 2 things. We do believe that this creep of
> the legal vs natural discussion back into our agenda, as was already very
> well responded to by Volker earlier today, is tending to be again, a large
> distraction to our focus on other legitimate use cases that help establish
> the process – At this point, and noting the calls for speed and structure
> from all quarters, we would kindly request that the discussion on legal vs.
> natural should only occur as part of the priority 2 discussions, as has
> been agreed to by the group.
>
> Secondly, we must also remind the group, that the point of these uses
> cases is not so that we can create a cookie cutter responses in specific
> cases, e.g. the security researcher or even in the case of the consumer.
> The past 2 use cases we have considered, although we appreciate the work
> that was undertaken to present to us in such detail, both requests were
> ultimately based on the same process of a 6(1)f. Our task must be to
> see-past the window dressing and consider the similarities and
> commonalities of the underlying process involved; this is after all, our
> goal. We seem to have slipped back into scrambling to getting our
> ‘interests’ and our ‘claims’ on the record for fear they somehow will not
> be accepted from consideration; we would again like to assert, that in the
> interests of time and resources, that the team should be prioritizing
> review of contrasting use cases, ones that require differing approaches, to
> further anticipate the breadth of the policy required, and not merely
> rehashing the same process from a different angle.
>
> Kind regards,
>
> Alan Woods
>
>
>
>
>
> [image: Donuts Inc.]
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdonuts.domains&data=02%7C01%7Cmarksv%40microsoft.com%7Cadd40309eb834ff2ca2608d71f005605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637011958626402591&sdata=bY7w%2FsK2UTPFQYEf2iLx2yVF6w2VW7UM4JnXpMUYezQ%3D&reserved=0>
>
> *Alan Woods*
>
> Senior Compliance & Policy Manager, Donuts Inc.
> ------------------------------
>
> The Victorians,
>
> 15-18 Earlsfort Terrace
> Dublin 2, County Dublin
> Ireland
>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.facebook.com%2Fdonutstlds&data=02%7C01%7Cmarksv%40microsoft.com%7Cadd40309eb834ff2ca2608d71f005605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637011958626412589&sdata=1qqNBMIJ9kfZu5W0Q5bULL4eYSq2bPU0L77ALelzLko%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftwitter.com%2FDonutsInc&data=02%7C01%7Cmarksv%40microsoft.com%7Cadd40309eb834ff2ca2608d71f005605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637011958626412589&sdata=jKxFPqYxGiMNXl7sVJiVRgtTMjSXTAi3L3AKQkBp%2FAQ%3D&reserved=0>
>
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fdonuts-inc&data=02%7C01%7Cmarksv%40microsoft.com%7Cadd40309eb834ff2ca2608d71f005605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637011958626422583&sdata=JG3A0eEfTx9xg4Ci6vh96pss%2BO3fwEbZkKJrJ5V4paY%3D&reserved=0>
>
>
>
> Please NOTE: This electronic message, including any attachments, may
> include privileged, confidential and/or inside information owned by Donuts
> Inc. . Any distribution or use of this communication by anyone other than
> the intended recipient(s) is strictly prohibited and may be unlawful.  If
> you are not the intended recipient, please notify the sender by replying to
> this message and then delete it from your system. Thank you.
>
>
>
>
>
> On Fri, Aug 9, 2019 at 4:47 PM James M. Bladel <jbladel at godaddy.com>
> wrote:
>
> Good morning, Colleagues-
>
>
>
> During yesterday’s call, a few folks mentioned that ICANN’s Bylaws contain
> commitments to uphold “Competition” and “Consumer Choice/Consumer Trust”.
> These references to the Bylaws were offered in support of the proposed Use
> Case that RDS data should be a primary resource for consumers who are
> seeking to verify the operator of a website, or check the reputation of
> business, or to dispute a commercial transaction.
>
>
>
> For clarity, it’s worth noting that the predominant context for
> “competition” in ICANN’s Bylaws is specific to the domain name industry,
> esp. Registries and Registrars.  And this makes sense, given that the
> industry prior to ICANN had no concept of “competition” or “consumer
> choice”; all domain transactions were handled by a single provider.
>
>
>
> Additionally, mentions of “consumer protection”, “consumer choice”, and
> “consumer trust” within the Bylaws are contained within Section 4.6(d),
> which outlines the “Periodic Reviews”, and are an element of the 2012 New
> gTLD program.  These sections were ported to the Bylaws from the
> Affirmation of Commitments, and were drafted when many feared that new
> gTLDs would confuse consumers and undermine trust/confidence in the DNS.
>
>
>
> Taken together, it’s not correct to conclude that WHOIS/RDS data is
> intended to replace or preempt more widely recognized alternative tools for
> online consumers, like:
>
>    - SSL certificates, verified by Certificate Authorities (CA) and
>    supported by all modern browsers
>    - Trust certificates (issued by organizations like the Better Business
>    Bureau, Trustwave, McAffee, SiteLock, and card processors like
>    Visa/Mastercard)
>    - Reputation/review services like Google ratings, Yelp, and Facebook
>    or Amazon reviews, and
>    - The “About Us” or “Contact Us” or “Customer Support” links on
>    merchant websites, which are omnipresent for legitimate businesses and
>    required by law in many areas.
>
>
>
> But if this is still a point of divergence among the EPDP members, then
> perhaps we could consult ICANN Legal about the extent of their
> “Competition” and “Consumer Trust” mandate, and whether they believe ICANN
> is on the hook for the integrity & consumer satisfaction for all commercial
> activity taking place anywhere on the Internet.
>
>
>
> J.
>
>
>
> -------------
>
> *James Bladel*
>
> *GoDaddy*
>
>
>
>
>
> _______________________________________________
> Gnso-epdp-team mailing list
> Gnso-epdp-team at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-epdp-team
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.org%2Fmailman%2Flistinfo%2Fgnso-epdp-team&data=02%7C01%7Cmarksv%40microsoft.com%7Cadd40309eb834ff2ca2608d71f005605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637011958626422583&sdata=LIFN7siwYgQk9b%2BzyXyZQ47JNufocJIwcFY7abQKzmg%3D&reserved=0>
> _______________________________________________
> 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Fpolicy&data=02%7C01%7Cmarksv%40microsoft.com%7Cadd40309eb834ff2ca2608d71f005605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637011958626432576&sdata=DF%2BLEtnb323utQ1fT9nL6eVFYZ9gAdRphzScNzkSGMI%3D&reserved=0>)
> and the website Terms of Service (https://www.icann.org/privacy/tos
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.icann.org%2Fprivacy%2Ftos&data=02%7C01%7Cmarksv%40microsoft.com%7Cadd40309eb834ff2ca2608d71f005605%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637011958626432576&sdata=SJzL5d3AZF76VC1DGldlAuCC2ZWBQ9acpxWIjun3%2BNA%3D&reserved=0>).
> 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: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190815/1b9a655f/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6(1)f process steps  (very rough draft).pdf
Type: application/pdf
Size: 107729 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/gnso-epdp-team/attachments/20190815/1b9a655f/61fprocessstepsveryroughdraft-0001.pdf>