[CCWG-ACCT] the difference between a PDP and GAC Advice...

Kavouss Arasteh kavouss.arasteh at gmail.com
Mon Feb 1 22:11:11 UTC 2016

I am puzzled about your analysis.
You are rasing a fundamental structural changes or structual analysis that
many may a) disagree and b) require time.
Let me come back to the discussion on the last call
Dispute between 4(5 PERSONS and the rest on 66% or 51% AS SIMPLE AS THAT
tHERE WAS NO pdp development issue at all.
Why you wish to engage all of us in a discussions that may have fundamental
disagreement on the concept.
You may interpret the issue as you mentioned.
GNSO supporting you becuase the GAC advice is tied up to PDP process.
Before your suggestions there was no direct tandem between the two.
Do you know the Board's reactions to your proposal?
Do you know the legal pereople's view on your proposal?
Do you know the reaction of ccNSO on your proposal
Do you know the impact of your proposal on IANA TRANSITION.?
ICG MAY HAVE DIFFERENT VIEW ON THAT due to the fact that ICG must formally
receive the adviose of CWG on the matter
You are proposing structral changes
I am not conmfortable to that proposal
Either 66% or 60% or 51% or no change

2016-02-01 22:48 GMT+01:00 Burr, Becky <Becky.Burr at neustar.biz>:

> Jorge asks why I am drawing a distinction between GAC Advice and the
> output (e.g., a policy developed through a PDP) of a supporting
> organization or this new “GNSO Guidance." The differences between a PDP (or
> Guidance on implementation of a PDP) and GAC Advice are both structural and
> substantive.   In short, the process for issuing GNSO policy and guidance
> has built-in safeguards to prevent Mission creep and promote transparency
> and public consultation.  For many reasons, including some that I consider
> entirely appropriate, that’s not the case with GAC Advice.
> On the one hand, the GAC can give Advice *on any topic* it likes.  Yes,
> technically it must relate to “public policy” - but as we know that is a
> very broad concept.  The GAC can also give that Advice *at any time* it
> likes - before, during, or well after a PDP or even the Board’s acceptance
> of a PDP.     There is no rule that says that GAC Advice must relate to a
> topic within ICANN’s Mission or that such Advice must be consistent with
> ICANN’s Bylaws.  Both the flexibility with respect to topic and timing mean
> that GAC Advice can be disruptive to ongoing policy development and/or
> implementation. And, under Rec. 11 as currently proposed, the Board must
> accept that Advice unless 66% of the Board opposes it.  That’s the case no
> matter what that Advice is and *even if a majority of the Board thinks it
> would violate ICANN’s Bylaws to implement that Advice*.
> A PDP, on the other hand, takes place in a highly structured environment
> that is strictly controlled both by subject matter and sequencing.  Even
> before the PDP really gets off the ground it is subject to review by
> ICANN’s General Counsel as to whether or not it is within ICANN’s Mission.
> That is a critical structural safeguard against scope creep that
> distinguishes a PDP from GAC Advice.
> The PDP process is highly structured, with numerous safeguards that
> protect against scope creep and ensure transparency:
> a. Final Issue Report requested by the Board, the GNSO Council
> ("Council") or Advisory Committee. The issue report must affirmatively
> address the following issues:
>    - The proposed issue raised for consideration;
>    - The identity of the party submitting the request for the Issue
>    Report;
>    - How that party is affected by the issue, if known;
>    - Support for the issue to initiate the PDP, if known;
>    - The opinion of the ICANN General Counsel regarding whether the issue
>    proposed for consideration within the Policy Development Process is
>    properly within the scope of the ICANN's mission, policy process and more
>    specifically the role of the GNSO as set forth in the Bylaws.
>    - The opinion of ICANN Staff as to whether the Council should initiate
>    the PDP on the issue
> b. Formal initiation of the Policy Development Process by the Council;
> c. Formation of a Working Group or other designated work method;
> d. Initial Report produced by a Working Group or other designated work
> method;
> e. Final Report produced by a Working Group, or other designated work
> method, and forwarded to the Council for deliberation;
> f. Council approval of PDP Recommendations contained in the Final Report,
> by the required thresholds;
> g. PDP Recommendations and Final Report shall be forwarded to the Board
> through a Recommendations Report approved by the Council]; and
> h. Board approval of PDP Recommendations.
> The proposal to create “GNSO Guidance” doesn’t change things
> dramatically – as proposed by the Policy and Implementation Working Group,
> because such guidance "would typically involve clarification of, or
> advice on existing gTLD policy recommendations.”
> *J. Beckwith Burr*
> *Neustar, Inc.* / Deputy General Counsel & Chief Privacy Officer
> 1775 Pennsylvania Avenue NW, Washington D.C. 20006
> *Office:* +1.202.533.2932  *Mobile:* +1.202.352.6367 */* *neustar.biz*
> <http://www.neustar.biz>
> _______________________________________________
> Accountability-Cross-Community mailing list
> Accountability-Cross-Community at icann.org
> https://mm.icann.org/mailman/listinfo/accountability-cross-community
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160201/0c2a98e6/attachment.html>

More information about the Accountability-Cross-Community mailing list