[gnso-rds-pdp-wg] Backgrounder on Process Framework

Tue Mar 8 20:09:11 UTC 2016

Dear Lisa:
I have been worrying this WHOIS matter for some time and truly appreciate
why a guiding structured framework for action is necessary.  The ALAC so
very long ago adjudged and advised that we must begin with the "Is this
required and why" questions before anything else. And that was the approach
that the EWG took in its deliberation.

What you have produced here deserves to be stored in document form as a
primer on the WG wiki. It touched every base with due consideration.  Just
wished it could be reproduced in multimedia fashion with a 'Where We Are'
arrow that gets updated in due course.

Best,
-Carlton

==============================
Carlton A Samuels
Mobile: 876-818-1799
*Strategy, Planning, Governance, Assessment & Turnaround*
=============================

On Tue, Mar 8, 2016 at 6:18 AM, Lisa Phifer <lisa at corecom.com> wrote:

> Dear all –
>
>
>
> As requested during the WG’s last call, below is an overview of the
> process framework (
> https://community.icann.org/display/gTLDRDS/Process+Framework) reflected
> in the PDP WG charter. The WG will have an opportunity to ask questions
> about this framework during Wednesday’s F2F meeting during which we hope
> some of the members of the Process Framework WG who were involved in
> developing this framework will be present.
>
>
>
> *Origin:* The charter reflects both the Board’s motion initiating this
> PDP and a process framework developed by members of the GNSO Council and
> ICANN Board after the EWG delivered its Final Report. The framework was
> created to help the GNSO Council structure this complex PDP to overcome
> challenges repeatedly encountered by past efforts at comprehensive WHOIS
> policy reform.
>
>
>
> *Inputs:* The framework starts with a pre-PDP WG step to gather inputs
> needed to inform the WG’s deliberations. Existing inputs identified as key
> by the Board/GNSO group include the EWG report and member statements, WHOIS
> RT report, GAC WHOIS principles, 2013 RAA registration data specifications,
> ICANN legal analysis of data protection laws, IETF RFCs, and more. The
> Issue Report gathered further inputs, including SAC055, Article 29 WP
> letters, and recent WHOIS-related PDP and implementation reports. The
> GNSO/Board group considered developing additional inputs on cost, legal,
> and risk impact analysis prior to WG launch but concluded that these must
> be developed after the WG agrees on possible requirements and policies to
> be analyzed.
>
>
>
> *Structured Approach**:* As SAC055 observed, members of the ICANN
> community have been going after WHOIS policy reform from different starting
> points but repeatedly failing to reach consensus because (in large part)
> they did not agree upon the purpose. Accordingly, the Board’s motion to
> launch this PDP explicitly tasked the WG with redefining the purpose of
> collecting, maintaining and providing access to gTLD registration data.
>
>
>
> The GNSO/Board group broke this Board request into 11 inter-dependent
> questions in the framework, peeling back this complex issue to the core
> question of purpose as a pre-requisite for developing new consensus
> policies about access, data, privacy, and accuracy. The 11 questions were
> examined and sequenced by the GNSO/Board group to reflect
> inter-dependencies, depicted in the framework using the letters A-H,
> grouping, and color coding.
>
>
>
> For example, the framework suggests developing consensus policies for
> compliance with data protection laws. However, those policies depend upon
> the actual data to be collected, maintained, and accessed. Data policies in
> turn depend upon who will use that data and for what purposes. As a result,
> the framework sequences policies regarding permissible users and purposes
> (phase 2 group B) before data element and access policies (phase 2 group
> C), with privacy policies (phase 2 group D) to follow. If a next-generation
> RDS is to be developed, these fundamental policies must also be accompanied
> by cross-cutting policies addressing crucial questions such as management
> and allocation of costs (phase 2 group F).
>
>
>
> *Phasing and Iteration:* Given the complexity of this issue, the
> Board/GNSO group adopted a phased approach based on product lifecycle
> management. Establishing requirements prior to design or implementation
> tends to result in more effective, less costly products, while iterative
> refinement allows for alternative designs to be proposed, evaluated, and
> then further optimized.
>
>
>
> This thinking led the GNSO/Board group to structure the PDP into three
> phases: requirements, policy development, and implementation/coexistence
> guidance. In this framework, Phase 1 establishes requirements that apply to
> any registration directory system, based on all inputs gathered prior to WG
> launch and early community outreach. Phases 2 and 3 draft and iteratively
> refine policies and guidance, based on Phase 1 requirements. For example,
> proposed policies for access (phase 2 group B) might be iteratively refined
> to reflect a proposed over-arching data protection policy (phase 2 group
> D), or to reduce associated costs (phase 2 group F) or risks (phase 2 group
> G) identified through impact analysis.
>
>
>
> The framework notes opportunities for parallel subteam efforts during
> phases 2 and 3, if the WG chooses, given sufficient resources. However, it
> suggests that the WG consider all questions at once, meeting as a single
> group, throughout phase 1, to help build shared understanding and consensus
> on what the community requires from a registration directory service – be
> that today’s WHOIS or a new replacement system. The GNSO/Board group felt
> the WG needed to converge on consensus requirements before breaking out
> detailed policy development work into subteams.
>
>
>
> *Decision Points**: *Finally, to help avoid endless iteration, the
> framework recommends close oversight by the GNSO Council to ensure
> continuing alignment with phase 1 requirements during phases 2 and 3. It
> also includes explicit decision points for the GNSO Council to evaluate the
> WG’s recommendations, level of consensus, and public comments, assessing
> progress made against defined criteria before adopting the WG’s
> recommendations.
>
>
>
> Ultimately, it falls to the GNSO Council to establish any such criteria.
> However, the framework includes an initial list that might be evaluated by
> the GNSO Council at each decision point to ensure sustained and sufficient
> progress on all 11 questions to avoid misalignment or gaps. For example,
> criteria might ensure that cost, legal, and risk impacts have been
> adequately addressed, or ensure that appropriate expert or community
> outreach has occurred.
>
>
>
> In addition to this summary, please refer directly to the process
> framework:
>
> https://community.icann.org/display/gTLDRDS/Process+Framework
>
>
>
> Members of the GNSO/board group have been invited to attend to answer any
> questions you may have about the framework, as input to the PDP WG’s
> deliberation on its work plan and how to best organize the tasks that lie
> ahead for phase 1. Please feel free to share any questions you may have in
> advance of the meeting.
>
>
>
> _______________________________________________
> gnso-rds-pdp-wg mailing list
> gnso-rds-pdp-wg at icann.org
> https://mm.icann.org/mailman/listinfo/gnso-rds-pdp-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/gnso-rds-pdp-wg/attachments/20160308/7b0d3a00/attachment.html>