the difference between a PDP and GAC Advice...
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>
Becky 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 Regards Kavouss 2016-02-01 22:48 GMT+01:00 Burr, Becky <Becky.Burr@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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Kavouss, with respect, Jorge asked me a question and I am providing an answer. As previously indicated, I am also supportive of your 60% proposal, although I do not believe that will fully resolve very serious concerns that appear very likely at this point to result in the GNSO objecting to various recommendations (1, 10, 11). 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> From: Kavouss Arasteh <kavouss.arasteh@gmail.com<mailto:kavouss.arasteh@gmail.com>> Date: Monday, February 1, 2016 at 5:11 PM To: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>> Cc: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] the difference between a PDP and GAC Advice... Becky 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 Regards Kavouss 2016-02-01 22:48 GMT+01:00 Burr, Becky <Becky.Burr@neustar.biz<mailto:Becky.Burr@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<tel:%2B1.202.533.2932> Mobile:+1.202.352.6367<tel:%2B1.202.352.6367>/neustar.biz<http://www.neustar.biz> _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=KyzJ2YRQSlyTRtRfbIUxv1_GF8I-3NdORO-qh1WsWVw&s=aQ-lI6xEGkq1kLe1Y0PuYUMFb2ang6OjQcgdzB6RU0g&e=>
Dear Becky There are 7 SOs(ACs . We can not kill ourselves to satisfy GNSO There is no way that one single entity / community be satisfied on the expense of other entity/Community dissatisfaction. If GAC be encouraged to agree reluctantly to ST18 that is fantastic even with 60% which is one vote below 66% . I do not see difference. I always admire your ability and in-depth knowledge but we are Under time constains We have worked very hard for 14 Months I spent 10-14 days every dax on this CCWG I wish to have a result that either everybody is equally happy or equally unhappy That is my principle throughout my life. I am not admitted to any bar but I am not stupid either Regards Kavouss , 2016-02-01 23:40 GMT+01:00 Burr, Becky <Becky.Burr@neustar.biz>:
Kavouss, with respect, Jorge asked me a question and I am providing an answer. As previously indicated, I am also supportive of your 60% proposal, although I do not believe that will fully resolve very serious concerns that appear very likely at this point to result in the GNSO objecting to various recommendations (1, 10, 11).
*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>
From: Kavouss Arasteh <kavouss.arasteh@gmail.com> Date: Monday, February 1, 2016 at 5:11 PM To: Becky Burr <becky.burr@neustar.biz> Cc: Accountability Community <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] the difference between a PDP and GAC Advice...
Becky 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 Regards Kavouss
2016-02-01 22:48 GMT+01:00 Burr, Becky <Becky.Burr@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@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...>
Dear Kavouss – you are free to reject the proposal, so is everyone else on the list. Jorge asked a question, I provided my answer. 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> From: Kavouss Arasteh <kavouss.arasteh@gmail.com<mailto:kavouss.arasteh@gmail.com>> Date: Monday, February 1, 2016 at 5:51 PM To: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>> Cc: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] the difference between a PDP and GAC Advice... Dear Becky There are 7 SOs(ACs . We can not kill ourselves to satisfy GNSO There is no way that one single entity / community be satisfied on the expense of other entity/Community dissatisfaction. If GAC be encouraged to agree reluctantly to ST18 that is fantastic even with 60% which is one vote below 66% . I do not see difference. I always admire your ability and in-depth knowledge but we are Under time constains We have worked very hard for 14 Months I spent 10-14 days every dax on this CCWG I wish to have a result that either everybody is equally happy or equally unhappy That is my principle throughout my life. I am not admitted to any bar but I am not stupid either Regards Kavouss , 2016-02-01 23:40 GMT+01:00 Burr, Becky <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>>: Kavouss, with respect, Jorge asked me a question and I am providing an answer. As previously indicated, I am also supportive of your 60% proposal, although I do not believe that will fully resolve very serious concerns that appear very likely at this point to result in the GNSO objecting to various recommendations (1, 10, 11). J. Beckwith Burr Neustar, Inc./Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office:+1.202.533.2932<tel:%2B1.202.533.2932> Mobile:+1.202.352.6367<tel:%2B1.202.352.6367>/neustar.biz<http://www.neustar.biz> From: Kavouss Arasteh <kavouss.arasteh@gmail.com<mailto:kavouss.arasteh@gmail.com>> Date: Monday, February 1, 2016 at 5:11 PM To: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>> Cc: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] the difference between a PDP and GAC Advice... Becky 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 Regards Kavouss 2016-02-01 22:48 GMT+01:00 Burr, Becky <Becky.Burr@neustar.biz<mailto:Becky.Burr@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<tel:%2B1.202.533.2932> Mobile:+1.202.352.6367<tel:%2B1.202.352.6367>/neustar.biz<http://www.neustar.biz> _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=KyzJ2YRQSlyTRtRfbIUxv1_GF8I-3NdORO-qh1WsWVw&s=aQ-lI6xEGkq1kLe1Y0PuYUMFb2ang6OjQcgdzB6RU0g&e=>
Dear Becky You are kind to try, but I think it is to no avail. Keith explained it to Jorge; you've explained it to him; Mike explained it to him; I have as well, though less ably than you. Jorge is just trying to avoid the developing consensus in favor of your proposal (which includes other members of the GAC apparently) by raising false equivalence claims. It's an ineffective tactic that does nothing more than demonstrate the weakness of his position. He wants an enhanced GAC role - your proposal threatens his success in that endeavor. Paul Paul Rosenzweig <mailto:paul.rosenzweigesq@redbranchconsulting.com> paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 VOIP: +1 (202) 738-1739 Skype: paul.rosenzweig1066 <http://www.redbranchconsulting.com/index.php?option=com_content&view=articl e&id=19&Itemid=9> Link to my PGP Key <http://www.rsaconference.com/events/us16?utm_source=signature&utm_medium=em ail&utm_campaign=speakers-us2016> From: Burr, Becky [mailto:Becky.Burr@neustar.biz] Sent: Monday, February 1, 2016 4:49 PM To: Accountability Community <accountability-cross-community@icann.org> Subject: [CCWG-ACCT] the difference between a PDP and GAC Advice... 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 / <http://www.neustar.biz> neustar.biz
Dear Paul thanks for knowing my mind so well - it is always astonishing how well you are able to do that... Jokes aside - I feel Becky gave a good explanation, which -as Finn said- might be a good ground for compromise, something some of us really work for quite hard... best Jorge Von meinem iPhone gesendet Am 01.02.2016 um 23:54 schrieb Paul Rosenzweig <paul.rosenzweig@redbranchconsulting.com<mailto:paul.rosenzweig@redbranchconsulting.com>>: Dear Becky You are kind to try, but I think it is to no avail. Keith explained it to Jorge; you’ve explained it to him; Mike explained it to him; I have as well, though less ably than you. Jorge is just trying to avoid the developing consensus in favor of your proposal (which includes other members of the GAC apparently) by raising false equivalence claims. It’s an ineffective tactic that does nothing more than demonstrate the weakness of his position. He wants an enhanced GAC role – your proposal threatens his success in that endeavor. Paul Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com<mailto:paul.rosenzweigesq@redbranchconsulting.com> O: +1 (202) 547-0660 M: +1 (202) 329-9650 VOIP: +1 (202) 738-1739 Skype: paul.rosenzweig1066 Link to my PGP Key<http://www.redbranchconsulting.com/index.php?option=com_content&view=article...> <image001.png><http://www.rsaconference.com/events/us16?utm_source=signature&utm_medium=ema...> From: Burr, Becky [mailto:Becky.Burr@neustar.biz] Sent: Monday, February 1, 2016 4:49 PM To: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: [CCWG-ACCT] the difference between a PDP and GAC Advice... 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@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
Don't you know I'm a mind reader??? Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 VOIP: +1 (202) 738-1739 Skype: paul.rosenzweig1066 Link to my PGP Key -----Original Message----- From: Jorge.Cancio@bakom.admin.ch [mailto:Jorge.Cancio@bakom.admin.ch] Sent: Monday, February 1, 2016 5:57 PM To: paul.rosenzweig@redbranchconsulting.com Cc: Becky.Burr@neustar.biz; accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] the difference between a PDP and GAC Advice... Dear Paul thanks for knowing my mind so well - it is always astonishing how well you are able to do that... Jokes aside - I feel Becky gave a good explanation, which -as Finn said- might be a good ground for compromise, something some of us really work for quite hard... best Jorge Von meinem iPhone gesendet Am 01.02.2016 um 23:54 schrieb Paul Rosenzweig <paul.rosenzweig@redbranchconsulting.com<mailto:paul.rosenzweig@redbranchcon sulting.com>>: Dear Becky You are kind to try, but I think it is to no avail. Keith explained it to Jorge; you've explained it to him; Mike explained it to him; I have as well, though less ably than you. Jorge is just trying to avoid the developing consensus in favor of your proposal (which includes other members of the GAC apparently) by raising false equivalence claims. It's an ineffective tactic that does nothing more than demonstrate the weakness of his position. He wants an enhanced GAC role - your proposal threatens his success in that endeavor. Paul Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com<mailto:paul.rosenzweigesq@redbranchc onsulting.com> O: +1 (202) 547-0660 M: +1 (202) 329-9650 VOIP: +1 (202) 738-1739 Skype: paul.rosenzweig1066 Link to my PGP Key<http://www.redbranchconsulting.com/index.php?option=com_content&view=art icle&id=19&Itemid=9> <image001.png><http://www.rsaconference.com/events/us16?utm_source=signature &utm_medium=email&utm_campaign=speakers-us2016> From: Burr, Becky [mailto:Becky.Burr@neustar.biz] Sent: Monday, February 1, 2016 4:49 PM To: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-commun ity@icann.org>> Subject: [CCWG-ACCT] the difference between a PDP and GAC Advice... 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@icann.org<mailto:Accountability-Cross-Communi ty@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community
hi, On 01-Feb-16 16:48, Burr, Becky wrote:
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.
Yet the GNSO can decide to do a PDP anyway despite being told that the item is out of scope. Just takes a higher threshold vote. While I agree that the processes by which each of the ACSO makes its recommendations and forms its advice are different, I do not think it makes sense to compare them. They are all part of the fabric of ICANN and all developed in their own bottom-up manner. I still believe that parity of difference among the ACSO is an critical principle that should influence what we do in the name of accountability. avri --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
participants (5)
-
Avri Doria -
Burr, Becky -
Jorge.Cancio＠bakom.admin.ch -
Kavouss Arasteh -
Paul Rosenzweig