[council] ePDP

Thu May 24 18:48:41 UTC 2018

Hi Keith,

It appears to me that all policy is within the picket fence so will be
interesting to see a document with your view point on what the RySG views
as outside the picket fence.

Considering, that this is a new process to all I think we will be learning
as we go.

Best,

Susan

On Wed, May 23, 2018 at 9:46 PM, Drazek, Keith <kdrazek at verisign.com> wrote:

> And, as a GNSO PDP, it must respect the picket fence. Not all issues in
> the Temporary Specification are eligible for a PDP. This is going to be one
> of the important scoping questions for the Council’s attention.
>
>
>
> Regards,
>
> Keith
>
>
>
> *From:* council <council-bounces at gnso.icann.org> *On Behalf Of *Michele
> Neylon - Blacknight
> *Sent:* Thursday, May 24, 2018 12:35 AM
> *To:* Darcy Southwell <darcy.southwell at endurance.com>; Rubens Kuhl <
> rubensk at nic.br>; Susan Kawaguchi <susankpolicy at gmail.com>
> *Cc:* GNSO Council List <council at gnso.icann.org>
> *Subject:* [EXTERNAL] Re: [council] ePDP
>
>
>
> Also we need to remember that the ePDP needs to focus on the temporary
> spec NOT on “fixing” whois. To that end it needs to be focussed on the
> various policies etc., that are impacted by the temporary spec and are now
> out of sync.
>
>
>
> Regards
>
>
> Michele
>
>
>
> --
>
> Mr Michele Neylon
>
> Blacknight Solutions
>
> Hosting, Colocation & Domains
>
> https://www.blacknight.com
>
> https://blacknight.blog /
>
> http://ceo.hosting/
>
> Intl. +353 (0) 59  9183072
>
> Direct Dial: +353 (0)59 9183090
>
> -------------------------------
>
> Blacknight Internet Solutions Ltd, Unit 12A,Barrowside Business Park,Sleaty
>
> Road,Graiguecullen,Carlow, R93 X265
>
> ,Ireland  Company No.: 370845
>
>
>
> *From: *council <council-bounces at gnso.icann.org> on behalf of Darcy
> Southwell <darcy.southwell at endurance.com>
> *Date: *Thursday 24 May 2018 at 02:21
> *To: *Rubens Kuhl <rubensk at nic.br>, Susan Kawaguchi <
> susankpolicy at gmail.com>
> *Cc: *GNSO Council List <council at gnso.icann.org>
> *Subject: *Re: [council] ePDP
>
>
>
> Agree with Rubens that no one SO/AC is more important than another.
>
>
>
> Is Susan’s suggestion 5-6 per SO/AC or SG/C?   I’m confused.
>
>
>
> *From: *council <council-bounces at gnso.icann.org> on behalf of Rubens Kuhl
> <rubensk at nic.br>
> *Date: *Wednesday, May 23, 2018 at 9:16 PM
> *To: *Susan Kawaguchi <susankpolicy at gmail.com>
> *Cc: *GNSO Council List <council at gnso.icann.org>
> *Subject: *Re: [council] ePDP
>
>
>
> Susan,
>
>
>
> Responses inline.
>
>
>
>
>
> On 23 May 2018, at 21:26, Susan Kawaguchi <susankpolicy at gmail.com> wrote:
>
>
>
> Hello All,
>
>
>
> I have given the potential ePDP much thought over the last two days.
>
>
>
> To effectively do this work at the speed that it will require we need to
> focus the ePDP.  As you all know this is a tremendous amount of work.
>
>
>
> We need to address the following:
>
>
>
> Including at the very least the GAC and SSAC in this ePDP will be
> critical.
>
>
>
> While this is still a GNSO ePDP, the fact that we will likely not run an
> open WG means that we should invite ACs, but I don't see why some ACs would
> be critical and others would not.
>
>
>
>
>
> The members of the team should be limited to 5-6 members of each SG/AC.
>
>
>
> I'm more inclined to a lesser number of members per SG, and even less from
> ACs, perhaps one each per AC.
>
>
>
>
>
>
>
> Each member must agree to accept the fast paced extensive work load,
> participating on calls, subgroups and drafting when necessary.
>
>
>
> And to be willing to come to common grounds... which is the only way for
> this effort to not fail like all others before them have.
>
>
>
>
>
>
>
> Understand that their work is representational of the community they are
> affiliated with and will receive endorsement to express views.
>
>
>
> I'm not sure of that; while I understand that idea, and this is how
> Council representation works for 3 of the 4 GNSO SGs, I'm afraid it could
> be not practical and hamper productivity, but I'm not ready yet to offer an
> alternative.
>
>
>
>
>
>
>
> Create a leadership team with extensive knowledge and time to focus on
> this work.
>
>
>
> Select a Chair that will have the time and skills to effectively manage
> the ePDP.
>
>
>
> Yeap.
>
>
>
>
>
> Include a Board member for oversight and check ins on the team.
>
>
>
> I believe Board liaison(s) would be helpful in not causing a delay by
> drafting a policy Board wouldn't be able to accept, but I wouldn't call
> them members.
>
>
>
>
>
> This ePDP should focus on the critical needs identified in the Annex of
> the Temporary Spec. first as these issues are of critical importance.
> (copied below for ease of reference)
>
>
>
>
>
> But if the main topics are not dealt with by the ePDP, temp spec will
> expire and lose effect... so I would rather see the opposite: taking first
> the items already included in the spec, bake all the uncontroversial ones
> into policy and begin implementation of them ASAP. Only after that first
> report, deal with controversial and further community action ones. Having
> parallel PDP/IRT teams also seem to be needed to achieve the ambitious
> timeframe imposed by the temp spec framework.
>
>
>
>
>
>
>
> Rubens
>
>
>
>
>
>
>
> Annex: Important Issues for Further Community Action
>
> The purpose of this Annex is to set forth implementation issues raised
> during the course of development of this Temporary Specification for which
> the ICANN Board encourages the community to continue discussing so that
> they may be resolved as quickly as possible after the effective date of the
> Temporary Specification. This Annex does not create new or modified
> requirements for Registrar or Registry Operator, nor is it intended to
> direct the scope of the Policy Development Process, which will be initiated
> as a result of the Board’s adoption of thisTemporary Specification.
>
>    1. Pursuant to Section 4.4, continuing community work to develop an
>    accreditation and access model that complies with GDPR, while recognizing
>    the need to obtain additional guidance from Article 29 Working
>    Party/European Data Protection Board.
>    2. Addressing the feasibility of requiring unique contacts to have a
>    uniform anonymized email address across domain name registrations at a
>    given Registrar, while ensuring security/stability and meeting the
>    requirements of Section 2.5.1 of Appendix A.
>    3. Developing methods to provide potential URS and UDRP complainants
>    with sufficient access to Registration Data to support good-faith filings
>    of complaints.
>    4. Consistent process for continued access to Registration Data,
>    including non- public data, for users with a legitimate purpose, until the
>    time when a final accreditation and access mechanism is fully operational,
>    on a mandatory basis for all contracted parties.
>    5. Distinguishing between legal and natural persons to allow for
>    public access to the Registration Data of legal persons, which are not in
>    the remit of the GDPR.
>    6. Limitations in terms of query volume envisaged under an
>    accreditation program balanced against realistic investigatory
>    cross-referencing needs.
>    7. Confidentiality of queries for Registration Data by law enforcement
>    authorities.
>
> Looking forward to discussing further tonight.
>
> Susan Kawaguchi
>
> BC Councilor.
>
>
>
>
>
>
>
> _______________________________________________
> council mailing list
> council at gnso.icann.org
> https://mm.icann.org/mailman/listinfo/council
>
>
>
> _______________________________________________ council mailing list
> council at gnso.icann.org https://mm.icann.org/mailman/listinfo/council
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/council/attachments/20180524/b10aa096/attachment-0001.html>