Responses to Rafael's Questions
I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance. I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority. Rafael’s questions appear in blue italic below, and my answers follow: 1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then? I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority. My previous response to this same question from Jorge follows: 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. 2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice? This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc. 3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)? It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy. Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support. Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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>
Dear Becky According to your responses, as there is standing GAC advice on ccTLDs and new gTLDs, GAC would be excluded from any community decision related to Board decisions to such topics. Probably we may also have advice on IPs. I feel that if we do not return to a sensible discussion, based on your original description of the carve-out, this amounts to GAC exclusion from any community decision making. Something which has no basis in prior agreements, in prior draft reports nor in the feedback from chartering organisations and public comment. best Jorge Von meinem iPhone gesendet Am 05.02.2016 um 19:06 schrieb Burr, Becky <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>>: I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance. I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority. Rafael’s questions appear in blue italic below, and my answers follow: 1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then? I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority. My previous response to this same question from Jorge follows: 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. 2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice? This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc. 3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)? It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy. Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support. Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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
Hi, On Fri, Feb 05, 2016 at 06:29:35PM +0000, Jorge.Cancio@bakom.admin.ch wrote:
Probably we may also have advice on IPs.
Is that "Internet protocols" or "intellectual properties"? I hope it's the latter, since if the board starts trying to interfere with the former (regardless of what the GAC says) we're going to have other problems. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
surely both :D Von meinem iPhone gesendet
Am 05.02.2016 um 19:46 schrieb Andrew Sullivan <ajs@anvilwalrusden.com>:
Hi,
On Fri, Feb 05, 2016 at 06:29:35PM +0000, Jorge.Cancio@bakom.admin.ch wrote: Probably we may also have advice on IPs.
Is that "Internet protocols" or "intellectual properties"? I hope it's the latter, since if the board starts trying to interfere with the former (regardless of what the GAC says) we're going to have other problems.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On Fri, Feb 05, 2016 at 07:03:34PM +0000, Jorge.Cancio@bakom.admin.ch wrote:
surely both :D
I see. Of course, the board is welcome to receive your advice about Internet protocols, but it's not in a position to act on that advice anyway. This is the precise point of fixing the ICANN mission statement so that ICANN doesn't go off on topics that are not in its remit. I hope that any board would immediately understand that and reject the GAC advice. I should think it rather important that the GAC not be in a position to keep insisting the board take action on advice where the GAC is urging the board to do something it should not. So, with this response, you demonstrate precisely why, if the GAC wants the board to have to do certain things when it gets formal advice, te GAC should therefore give up other avenues of participation. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Dear Andrew I guess you have misunderstood. Apologies if I was trying to be humorous. The new community powers and the new IRP, which we all have been developing these last months, establish legal means to appeal and turn down any Board decision inconsistent with ICANN's Mission, including any based on GAC advice. Best Jorge Von meinem iPhone gesendet
Am 05.02.2016 um 20:26 schrieb Andrew Sullivan <ajs@anvilwalrusden.com>:
On Fri, Feb 05, 2016 at 07:03:34PM +0000, Jorge.Cancio@bakom.admin.ch wrote: surely both :D
I see.
Of course, the board is welcome to receive your advice about Internet protocols, but it's not in a position to act on that advice anyway. This is the precise point of fixing the ICANN mission statement so that ICANN doesn't go off on topics that are not in its remit. I hope that any board would immediately understand that and reject the GAC advice.
I should think it rather important that the GAC not be in a position to keep insisting the board take action on advice where the GAC is urging the board to do something it should not. So, with this response, you demonstrate precisely why, if the GAC wants the board to have to do certain things when it gets formal advice, te GAC should therefore give up other avenues of participation.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Andrew, I wish to point out that several individuals, myself included, have offered advice on v4 and v6 allocation policy issues, and as constitutent regional allocation institutions chose to incorporate an NRO and memorandize their relationship with the Board through the ASO, it is, in theory, and practice, possible for the Board to take, or relay, an interest in the routing and addressing infrastructures. Similarly, were the naming infrastructure to be of incidental interest to one or more members of the ASO, no structural barriers exist to preclude members of the ASO from articulating (a better choice of words than "interfere", in my opinion) that interest. Assuming that "IP" might mean protocol parameters, please accept this small reminder that getting GOST into the suite of mechanisms which might sign a zone was an issue that concerned GNSO, ccNSO, and GAC members. Eric Brunner-Williams Eugene, Oregon
Probably we may also have advice on IPs.
Is that "Internet protocols" or "intellectual properties"? I hope it's the latter, since if the board starts trying to interfere with the former (regardless of what the GAC says) we're going to have other problems.
Very much +1. Well said Becky. P 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: Friday, February 5, 2016 1:03 PM To: Accountability Community <accountability-cross-community@icann.org> Subject: [CCWG-ACCT] Responses to Rafael's Questions I am going to attempt to respond to Rafael's questions, below. This is a long post, so apologies in advance. I'd like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC's ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board's implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board's action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority. Rafael's questions appear in blue italic below, and my answers follow: 1. We have previously discussed it, but we still fail to understand why this "carve-out" is only applicable to the GAC. If this measure is foreseen to avoid the "two-bites-at-the-apple" situation, for instance the GNSO is as well in a position of being "judge and part" when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a "mutually agreeable procedure to TRY to find a solution", it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then? I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board's obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way - it can involve any topic with "public policy" implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority. My previous response to this same question from Jorge follows: 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. 2. If this "carve-out" were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to "Board decisions" to "implement GAC advice". But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this "carve-out" mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a "carve-out" is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice? This seems fairly straightforward. The GAC keeps a "scorecard" regarding the Board's handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en. pdf. To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board's implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc. 3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a "no formal objection rule" (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)? It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy. Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN's Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board's implementation action - e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support. Let me repeat again what I said at the outset - nothing prevents the GAC from "intervening" through debate, discussion, persuasion, advice or any other non-decisional role. 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
+ 1 Thanks Becky. It really is time to agree this and move on. On 05/02/2016 10:34, Paul Rosenzweig wrote:
Information Security Program Charter
Very much +1. Well said Becky.
P
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...>
<http://www.rsaconference.com/events/us16?utm_source=signature&utm_medium=ema...>
*From:*Burr, Becky [mailto:Becky.Burr@neustar.biz] *Sent:* Friday, February 5, 2016 1:03 PM *To:* Accountability Community <accountability-cross-community@icann.org> *Subject:* [CCWG-ACCT] Responses to Rafael's Questions
Iam going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a /decision-maker/ in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in /blue italic/below, and my answers follow:
/1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?/
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. *The GAC is singled out because it, and it alone, has this authority.*
*My previous response to this same question from Jorge follows:*
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.
/2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?/
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
/3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?/
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role.
*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
-- Matthew Shears | Director, Global Internet Policy & Human Rights Project Center for Democracy & Technology | cdt.org E: mshears@cdt.org | T: +44.771.247.2987 CDT's Annual Dinner, Tech Prom, is April 6, 2016. Don't miss out - register at cdt.org/annual-dinner. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Yes thank you Becky for this. From: <accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org>> on behalf of Matthew Shears <mshears@cdt.org<mailto:mshears@cdt.org>> Date: Friday 5 February 2016 at 7:04 p.m. To: Paul Rosenzweig <paul.rosenzweig@redbranchconsulting.com<mailto:paul.rosenzweig@redbranchconsulting.com>>, "'Burr, Becky'" <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>>, 'Accountability Community' <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions + 1 Thanks Becky. It really is time to agree this and move on. On 05/02/2016 10:34, Paul Rosenzweig wrote: Very much +1. Well said Becky. P Paul Rosenzweig <mailto:paul.rosenzweigesq@redbranchconsulting.com>paul.rosenzweig@redbranchconsulting.com<mailto: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<http://www.redbranchconsulting.com/index.php?option=com_content&view=article...> [cid:part3.05010202.03030004@cdt.org]<http://www.rsaconference.com/events/us16?utm_source=signature&utm_medium=ema...> From: Burr, Becky [mailto:Becky.Burr@neustar.biz] Sent: Friday, February 5, 2016 1:03 PM To: Accountability Community <accountability-cross-community@icann.org><mailto:accountability-cross-community@icann.org> Subject: [CCWG-ACCT] Responses to Rafael's Questions I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance. I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority. Rafael’s questions appear in blue italic below, and my answers follow: 1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then? I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority. My previous response to this same question from Jorge follows: 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. 2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice? This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, <https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en....> https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc. 3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)? It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy. Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support. Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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 -- Matthew Shears | Director, Global Internet Policy & Human Rights Project Center for Democracy & Technology | cdt.org E: mshears@cdt.org<mailto:mshears@cdt.org> | T: +44.771.247.2987 CDT's Annual Dinner, Tech Prom, is April 6, 2016. Don't miss out - register at cdt.org/annual-dinner. ________________________________ [Avast logo]<https://www.avast.com/antivirus> This email has been checked for viruses by Avast antivirus software. www.avast.com<https://www.avast.com/antivirus>
Thank you Becky for putting the proposals in the proper context!! To the colleagues from Spain and Switzerland I beg to take a step back, look at the whole picture and try to think as comprehensibly as Becky has just done. Best regards Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 5 Feb 2016, at 10:03, Burr, Becky wrote:
I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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
Dear Carlos We are trying to have a discussion on substance, I feel, and I'm not seeing any argument addressing the concern that this "carve out" may be overbroad. As I said before, as there is standing GAC advice on ccTLDs and new gTLDs, GAC would be excluded from any community decision related to Board decisions on such topics, which leaves little room for GAC participation for the GAC in the community mechanism. I feel that if we do not return to a sensible discussion, based on Becky's original description of the carve-out, this amounts to GAC exclusion from any community decision making. Something which has no basis in prior agreements, in prior draft reports nor in the feedback from chartering organisations and public comment. best Jorge Von meinem iPhone gesendet
Am 05.02.2016 um 20:13 schrieb Carlos Raúl Gutiérrez G. <crg@isoc-cr.org>:
Thank you Becky for putting the proposals in the proper context!!
To the colleagues from Spain and Switzerland I beg to take a step back, look at the whole picture and try to think as comprehensibly as Becky has just done.
Best regards
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg
On 5 Feb 2016, at 10:03, Burr, Becky wrote:
I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear Jorge, let me repeat my previous (before transition) points concerning the issues on the table, as the reason for asking for a wider framework for this discussion: * a clear difference between SOs and ACs remain. While the transition discussion is focused on some kind of equal rights for all SO and AC for specific accountabiliyt purposes, I still see big differences between all of them, internally and externally. So I don’t think that the tactic to play a GNSO vs. , while easy to explain to your principals, is a particularly productive one in the CCWG. ** we are coming out of a fresh experience of GAC advice to the Board in terms of a few new gTLDs that may come back to us, even under the new Accountability rules (.africa, .amazon, .wine, etc.). So lets not forget that whatever is being discussed may come back to us in the form of new responsibilities/liabilities from the previous round. *** lets not forget the the NTIA assumption is that the USG will step back vis a vis the community, but not to create more powers to Governments altogether. So it may not be smart to fight for pyrric objectives. So lets cool down and take a fresh approach. Best regards Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 5 Feb 2016, at 11:20, Jorge.Cancio@bakom.admin.ch wrote:
Dear Carlos
We are trying to have a discussion on substance, I feel, and I'm not seeing any argument addressing the concern that this "carve out" may be overbroad.
As I said before, as there is standing GAC advice on ccTLDs and new gTLDs, GAC would be excluded from any community decision related to Board decisions on such topics, which leaves little room for GAC participation for the GAC in the community mechanism.
I feel that if we do not return to a sensible discussion, based on Becky's original description of the carve-out, this amounts to GAC exclusion from any community decision making.
Something which has no basis in prior agreements, in prior draft reports nor in the feedback from chartering organisations and public comment.
best
Jorge
Von meinem iPhone gesendet
Am 05.02.2016 um 20:13 schrieb Carlos Raúl Gutiérrez G. <crg@isoc-cr.org>:
Thank you Becky for putting the proposals in the proper context!!
To the colleagues from Spain and Switzerland I beg to take a step back, look at the whole picture and try to think as comprehensibly as Becky has just done.
Best regards
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg
On 5 Feb 2016, at 10:03, Burr, Becky wrote:
I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear Carlos Thanks for these points, but ee should not get personal. We have come s long way in the ccwg and we have established and settled clear principles of equal participation within the accountability framework. And now we are having a specific discussion on the carve-out proposed by Becky, to which we are saying that it is overbroad and should be circumscribed to its original remit (at least how we understood it). Let's have a rational and cool debate on these specifics. regards Jorge Von meinem iPhone gesendet
Am 05.02.2016 um 20:33 schrieb Carlos Raúl Gutiérrez G. <crg@isoc-cr.org>:
Dear Jorge,
let me repeat my previous (before transition) points concerning the issues on the table, as the reason for asking for a wider framework for this discussion:
* a clear difference between SOs and ACs remain. While the transition discussion is focused on some kind of equal rights for all SO and AC for specific accountabiliyt purposes, I still see big differences between all of them, internally and externally. So I don’t think that the tactic to play a GNSO vs. , while easy to explain to your principals, is a particularly productive one in the CCWG. ** we are coming out of a fresh experience of GAC advice to the Board in terms of a few new gTLDs that may come back to us, even under the new Accountability rules (.africa, .amazon, .wine, etc.). So lets not forget that whatever is being discussed may come back to us in the form of new responsibilities/liabilities from the previous round. *** lets not forget the the NTIA assumption is that the USG will step back vis a vis the community, but not to create more powers to Governments altogether. So it may not be smart to fight for pyrric objectives.
So lets cool down and take a fresh approach.
Best regards
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg
On 5 Feb 2016, at 11:20, Jorge.Cancio@bakom.admin.ch wrote:
Dear Carlos
We are trying to have a discussion on substance, I feel, and I'm not seeing any argument addressing the concern that this "carve out" may be overbroad.
As I said before, as there is standing GAC advice on ccTLDs and new gTLDs, GAC would be excluded from any community decision related to Board decisions on such topics, which leaves little room for GAC participation for the GAC in the community mechanism.
I feel that if we do not return to a sensible discussion, based on Becky's original description of the carve-out, this amounts to GAC exclusion from any community decision making.
Something which has no basis in prior agreements, in prior draft reports nor in the feedback from chartering organisations and public comment.
best
Jorge
Von meinem iPhone gesendet
Am 05.02.2016 um 20:13 schrieb Carlos Raúl Gutiérrez G. <crg@isoc-cr.org>:
Thank you Becky for putting the proposals in the proper context!!
To the colleagues from Spain and Switzerland I beg to take a step back, look at the whole picture and try to think as comprehensibly as Becky has just done.
Best regards
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg
On 5 Feb 2016, at 10:03, Burr, Becky wrote:
I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Thank you Jorge! We really have to (re)focus and discuss in a more constructive way. Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 5 Feb 2016, at 11:40, Jorge.Cancio@bakom.admin.ch wrote:
Dear Carlos
Thanks for these points, but ee should not get personal.
We have come s long way in the ccwg and we have established and settled clear principles of equal participation within the accountability framework.
And now we are having a specific discussion on the carve-out proposed by Becky, to which we are saying that it is overbroad and should be circumscribed to its original remit (at least how we understood it).
Let's have a rational and cool debate on these specifics.
regards
Jorge
Von meinem iPhone gesendet
Am 05.02.2016 um 20:33 schrieb Carlos Raúl Gutiérrez G. <crg@isoc-cr.org>:
Dear Jorge,
let me repeat my previous (before transition) points concerning the issues on the table, as the reason for asking for a wider framework for this discussion:
* a clear difference between SOs and ACs remain. While the transition discussion is focused on some kind of equal rights for all SO and AC for specific accountabiliyt purposes, I still see big differences between all of them, internally and externally. So I don’t think that the tactic to play a GNSO vs. , while easy to explain to your principals, is a particularly productive one in the CCWG. ** we are coming out of a fresh experience of GAC advice to the Board in terms of a few new gTLDs that may come back to us, even under the new Accountability rules (.africa, .amazon, .wine, etc.). So lets not forget that whatever is being discussed may come back to us in the form of new responsibilities/liabilities from the previous round. *** lets not forget the the NTIA assumption is that the USG will step back vis a vis the community, but not to create more powers to Governments altogether. So it may not be smart to fight for pyrric objectives.
So lets cool down and take a fresh approach.
Best regards
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg
On 5 Feb 2016, at 11:20, Jorge.Cancio@bakom.admin.ch wrote:
Dear Carlos
We are trying to have a discussion on substance, I feel, and I'm not seeing any argument addressing the concern that this "carve out" may be overbroad.
As I said before, as there is standing GAC advice on ccTLDs and new gTLDs, GAC would be excluded from any community decision related to Board decisions on such topics, which leaves little room for GAC participation for the GAC in the community mechanism.
I feel that if we do not return to a sensible discussion, based on Becky's original description of the carve-out, this amounts to GAC exclusion from any community decision making.
Something which has no basis in prior agreements, in prior draft reports nor in the feedback from chartering organisations and public comment.
best
Jorge
Von meinem iPhone gesendet
Am 05.02.2016 um 20:13 schrieb Carlos Raúl Gutiérrez G. <crg@isoc-cr.org>:
Thank you Becky for putting the proposals in the proper context!!
To the colleagues from Spain and Switzerland I beg to take a step back, look at the whole picture and try to think as comprehensibly as Becky has just done.
Best regards
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg
On 5 Feb 2016, at 10:03, Burr, Becky wrote:
I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
+1 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: Carlos Raúl Gutiérrez G. [mailto:crg@isoc-cr.org] Sent: Friday, February 5, 2016 2:33 PM To: Jorge.Cancio@bakom.admin.ch Cc: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions Dear Jorge, let me repeat my previous (before transition) points concerning the issues on the table, as the reason for asking for a wider framework for this discussion: * a clear difference between SOs and ACs remain. While the transition discussion is focused on some kind of equal rights for all SO and AC for specific accountabiliyt purposes, I still see big differences between all of them, internally and externally. So I don’t think that the tactic to play a GNSO vs. , while easy to explain to your principals, is a particularly productive one in the CCWG. ** we are coming out of a fresh experience of GAC advice to the Board in terms of a few new gTLDs that may come back to us, even under the new Accountability rules (.africa, .amazon, .wine, etc.). So lets not forget that whatever is being discussed may come back to us in the form of new responsibilities/liabilities from the previous round. *** lets not forget the the NTIA assumption is that the USG will step back vis a vis the community, but not to create more powers to Governments altogether. So it may not be smart to fight for pyrric objectives. So lets cool down and take a fresh approach. Best regards Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 5 Feb 2016, at 11:20, Jorge.Cancio@bakom.admin.ch wrote:
Dear Carlos
We are trying to have a discussion on substance, I feel, and I'm not seeing any argument addressing the concern that this "carve out" may be overbroad.
As I said before, as there is standing GAC advice on ccTLDs and new gTLDs, GAC would be excluded from any community decision related to Board decisions on such topics, which leaves little room for GAC participation for the GAC in the community mechanism.
I feel that if we do not return to a sensible discussion, based on Becky's original description of the carve-out, this amounts to GAC exclusion from any community decision making.
Something which has no basis in prior agreements, in prior draft reports nor in the feedback from chartering organisations and public comment.
best
Jorge
Von meinem iPhone gesendet
Am 05.02.2016 um 20:13 schrieb Carlos Raúl Gutiérrez G. <crg@isoc-cr.org>:
Thank you Becky for putting the proposals in the proper context!!
To the colleagues from Spain and Switzerland I beg to take a step back, look at the whole picture and try to think as comprehensibly as Becky has just done.
Best regards
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg
On 5 Feb 2016, at 10:03, Burr, Becky wrote:
I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I¹ve answered this question several times, but will try once more. 1. This is not over broad - GAC Advice is uniquely privileged compared to other input, including PDPs and GNSO Guidance. The community must be empowered to challenge the Board¹s implementation of that Advice, and giving the GAC a decisional role in blocking such a challenge (whether that is through blocking a bylaw, bringing an IRP, etc.) addresses the two bites at the apple structural problem. The same principle applies whether the challenge is through an IRP or through a vote to reject a proposed Bylaw. There is, on the other hand, no principled basis for limiting this carve out to an IRP. 2. If you want a sensible discussion, stop claiming that this carve out would ³exclude" the GAC from community decisions on ³topics² such as ccTLDs and gTLDs and/or ³community decision making." There is a register of GAC Advice. There is a comprehensive report of GAC Advice on new gTLDs and the Board¹s response. https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en .pdf. It seems quite specific to me, and clearly does not begin to cover the waterfront of new gTLD ³topics.² The GAC is the master of its own Advice, and the generality or specificity of such Advice is in the GAC¹s exclusive control. And in any case, as someone on the list has already pointed out, it is up to the GAC to decide whether it wants to issue formal Advice on a particular topic, whether it would prefer to issue a compilation of member views (as it has in the past and which does not constitute Advice) or whether it wants to do something else entirely and thus preserve your role as a decision-maker. The bottom line is that the GAC should not be able to force the Board to the negotiating table on a specific issue and then participate AS A DECISION MAKER in the exercise of a community power challenging the Board¹s implementation of the output of negotiations on that specific issue. 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> On 2/5/16, 2:20 PM, "Jorge.Cancio@bakom.admin.ch" <Jorge.Cancio@bakom.admin.ch> wrote:
Dear Carlos
We are trying to have a discussion on substance, I feel, and I'm not seeing any argument addressing the concern that this "carve out" may be overbroad.
As I said before, as there is standing GAC advice on ccTLDs and new gTLDs, GAC would be excluded from any community decision related to Board decisions on such topics, which leaves little room for GAC participation for the GAC in the community mechanism.
I feel that if we do not return to a sensible discussion, based on Becky's original description of the carve-out, this amounts to GAC exclusion from any community decision making.
Something which has no basis in prior agreements, in prior draft reports nor in the feedback from chartering organisations and public comment.
best
Jorge
Von meinem iPhone gesendet
Am 05.02.2016 um 20:13 schrieb Carlos Raúl Gutiérrez G. <crg@isoc-cr.org>:
Thank you Becky for putting the proposals in the proper context!!
To the colleagues from Spain and Switzerland I beg to take a step back, look at the whole picture and try to think as comprehensibly as Becky has just done.
Best regards
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg
On 5 Feb 2016, at 10:03, Burr, Becky wrote:
I am going to attempt to respond to Rafael¹s questions, below. This is a long post, so apologies in advance.
I¹d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC¹s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board¹s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board¹s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael¹s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this ³carve-out² is only applicable to the GAC. If this measure is foreseen to avoid the ³two-bites-at-the-apple² situation, for instance the GNSO is as well in a position of being ³judge and part² when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a ³mutually agreeable procedure to TRY to find a solution², it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board¹s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way it can involve any topic with ³public policy² implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this ³carve-out² were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to ³Board decisions² to ³implement GAC advice². But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this ³carve-out² mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a ³carve-out² is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a ³scorecard² regarding the Board¹s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_sy stem_files_files_gac-2Dadvice-2Dscorecard-2D07oct15-2Den.pdf&d=CwIF-g&c= MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=5 3DhjQJu-5O6JWZRNEqAvNc_wI9v8wc_YVD59jOx7Hw&s=nBCkwh8XFdEYa1MK-03LlqhwRJM gfNIRYKfrLDW_Eng&e= . To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board¹s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a ³no formal objection rule² (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN¹s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board¹s implementation action e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset nothing prevents the GAC from ³intervening² through debate, discussion, persuasion, advice or any other non-decisional role. 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://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma n_listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDAL C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=53DhjQJu-5O6JWZR NEqAvNc_wI9v8wc_YVD59jOx7Hw&s=2BElAF8EiJd-Fi1rzJXaj4rX7UEhIKC6nr2uGDSmPw 4&e=
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman _listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDALC_ lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=53DhjQJu-5O6JWZRNEq AvNc_wI9v8wc_YVD59jOx7Hw&s=2BElAF8EiJd-Fi1rzJXaj4rX7UEhIKC6nr2uGDSmPw4&e=
Dear Carlos, Colleagues from Spain and Switzerland are not alone and several members of the GAC share the same concerns as they have expressed in this list and which Argentina also shares. So could you be so kind to clarify your comment "To the colleagues from Spain and Switzerland I beg to take a step back". Regards Olga 2016-02-05 16:10 GMT-03:00 Carlos Raúl Gutiérrez G. <crg@isoc-cr.org>:
Thank you Becky for putting the proposals in the proper context!!
To the colleagues from Spain and Switzerland I beg to take a step back, look at the whole picture and try to think as comprehensibly as Becky has just done.
Best regards
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg
On 5 Feb 2016, at 10:03, Burr, Becky wrote:
I am going to attempt to respond to Rafael’s questions, below. This is a
long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
As per the normal rules of engagement it would be very useful to know when the colleagues are speaking in their personal member of the CCWG role. This mornings reaction to Becky great summary where treated with what I consider disrespect to her great work. Many people present today in the NCPH shared this impression. I do mind when the explicit rules of engagement you can read everytime you open Adobe Connect are not followed. Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 5 Feb 2016, at 12:00, Olga Cavalli wrote:
Dear Carlos,
Colleagues from Spain and Switzerland are not alone and several members of the GAC share the same concerns as they have expressed in this list and which Argentina also shares.
So could you be so kind to clarify your comment "To the colleagues from Spain and Switzerland I beg to take a step back".
Regards Olga
2016-02-05 16:10 GMT-03:00 Carlos Raúl Gutiérrez G. <crg@isoc-cr.org>:
Thank you Becky for putting the proposals in the proper context!!
To the colleagues from Spain and Switzerland I beg to take a step back, look at the whole picture and try to think as comprehensibly as Becky has just done.
Best regards
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg
On 5 Feb 2016, at 10:03, Burr, Becky wrote:
I am going to attempt to respond to Rafael’s questions, below. This is a
long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
And then there were four …. 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=article...> Link to my PGP Key <http://www.rsaconference.com/events/us16?utm_source=signature&utm_medium=ema...> From: Olga Cavalli [mailto:olgacavalli@gmail.com] Sent: Friday, February 5, 2016 3:01 PM To: Carlos Raúl Gutiérrez G. <crg@isoc-cr.org> Cc: Accountability Community <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions Dear Carlos, Colleagues from Spain and Switzerland are not alone and several members of the GAC share the same concerns as they have expressed in this list and which Argentina also shares. So could you be so kind to clarify your comment "To the colleagues from Spain and Switzerland I beg to take a step back". Regards Olga 2016-02-05 16:10 GMT-03:00 Carlos Raúl Gutiérrez G. <crg@isoc-cr.org <mailto:crg@isoc-cr.org> >: Thank you Becky for putting the proposals in the proper context!! To the colleagues from Spain and Switzerland I beg to take a step back, look at the whole picture and try to think as comprehensibly as Becky has just done. Best regards Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg On 5 Feb 2016, at 10:03, Burr, Becky wrote: I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance. I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority. Rafael’s questions appear in blue italic below, and my answers follow: 1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then? I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority. My previous response to this same question from Jorge follows: 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. 2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice? This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc. 3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)? It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy. Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support. Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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://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 _______________________________________________ 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
Dear Co-Chairs Dear Beckie Deal All, We have noted relatively extensive exchange of e-mails among colleagues during the last one and half day ; after our devoted call on Recs. 1 and 11 . Views are sometime so strong that potentially may give rise to something that none of us expect. As merely a CCWG participant ( all of my interventions and message have been in that capacity only) I WARN ourselves that: 1. We SHALL NOT escalate the issue to end with VOTING, an element that I personally AGINST that. 2. We m shall not ignore views of GAC nor that of GNSO at all 3. There are difficulties raised by some GAC members mostly in regard with carve-out concept. 4.Some GAC Member could consider the initial proposal of Beckie, even if Beckie stated that her initial and subsequent proposal are exactly the same but that view is not shared, at least , by some GAC members. 5. The show of hand on the Devoted call was not a VOTE at all on the substance of the matter but rather whether the participants were ready to take the proposed compromised text to their constituencies. 6. We need to hear the responses of those constituencies ,probably and hopefully on Monday’s call 7. Beckie as the author of her creative solution is sincerely asked or perhaps urged to review her initial and revised proposal again 8.Should we make the text of Beckie compromise better to be acceptable ,so far so good. 9.Should that failed WITHOUT GOPING TO VOTE, we need to look at other possibilities .There are other ways to proceed but let us stop at this stage and encourage ebvery body to pronounce his or her views on the matter. 10. No matter what option would taken NO VOTING AT ALL- Regards 2016-02-05 23:05 GMT+01:00 Paul Rosenzweig < paul.rosenzweig@redbranchconsulting.com>:
And then there were four ….
Paul Rosenzweig
paul.rosenzweig@redbranchconsulting.com <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...>
<http://www.rsaconference.com/events/us16?utm_source=signature&utm_medium=ema...>
*From:* Olga Cavalli [mailto:olgacavalli@gmail.com] *Sent:* Friday, February 5, 2016 3:01 PM *To:* Carlos Raúl Gutiérrez G. <crg@isoc-cr.org> *Cc:* Accountability Community <accountability-cross-community@icann.org> *Subject:* Re: [CCWG-ACCT] Responses to Rafael's Questions
Dear Carlos,
Colleagues from Spain and Switzerland are not alone and several members of the GAC share the same concerns as they have expressed in this list and which Argentina also shares.
So could you be so kind to clarify your comment "To the colleagues from Spain and Switzerland I beg to take a step back".
Regards
Olga
2016-02-05 16:10 GMT-03:00 Carlos Raúl Gutiérrez G. <crg@isoc-cr.org>:
Thank you Becky for putting the proposals in the proper context!!
To the colleagues from Spain and Switzerland I beg to take a step back, look at the whole picture and try to think as comprehensibly as Becky has just done.
Best regards
Carlos Raúl Gutiérrez +506 8837 7176 Skype: carlos.raulg
On 5 Feb 2016, at 10:03, Burr, Becky wrote:
I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear Becky After other work commitments I'm now catching up on the e-mail traffic and so apologise if I'm not quite in step with everybody else engaged in this thread but I want to say how much I appreciate your comprehensive and very lucid e-mail. It is extremely helpful for the GAC representatives who are endeavouring to help CCWG colleagues resolve the current gap in positions on Rec 11. The emphasis on recognising the wider advisory role of the GAC within the community framework is particularly helpful I think. Much for all of us to consider over the weekend but hope it is enjoyable for everyone nonetheless - we all need a breather I think! Kind regards Mark Mark Carvell United Kingdom Representative on the GovernmentalSdvisory Committee of ICANN Global Internet Governance Policy Department for Culture, Media and Sport mark.carvell@culture.gov.uk tel +44 (0) 20 7211 6062 On 5 February 2016 at 18:03, Burr, Becky <Becky.Burr@neustar.biz> wrote:
I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a *decision-maker* in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in *blue italic* below, and my answers follow:
*1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?*
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. *The GAC is singled out because it, and it alone, has this authority.*
*My previous response to this same question from Jorge follows:*
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.
*2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?*
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
*3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?*
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role.
*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
Thank you Becky for kindly answering my questions, much appreciated. I hope to get back to you with further comments as I proceed with internal consultations. I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC. For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects. Best Rafael Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance. I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority. Rafael’s questions appear in blue italic below, and my answers follow: 1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then? I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority. My previous response to this same question from Jorge follows: 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. 2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice? This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc. 3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)? It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy. Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support. Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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>
Dear Becky, Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is “unique” in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision. I kindly ask for clarification on the “uniqueness” of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a “discussion” with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3. In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss “in good faith and in a timely and efficient manner, to find a mutually acceptable solution“. In conclusion, for the very same reason, namely avoid the “two bites at the apple” situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established. Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described. Best Rafael ________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions Thank you Becky for kindly answering my questions, much appreciated. I hope to get back to you with further comments as I proceed with internal consultations. I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC. For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects. Best Rafael Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance. I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority. Rafael’s questions appear in blue italic below, and my answers follow: 1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then? I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority. My previous response to this same question from Jorge follows: 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. 2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice? This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc. 3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)? It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy. Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support. Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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>
Dear Becky, Argentina shares the same concerns expressed by Rafael. Best regards Olga Enviado desde mi iPad
El 6 feb 2016, a las 7:29 a.m., Perez Galindo, Rafael <RPEREZGA@minetur.es> escribió:
Dear Becky,
Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is “unique” in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision.
I kindly ask for clarification on the “uniqueness” of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a “discussion” with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3.
In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss “in good faith and in a timely and efficient manner, to find a mutually acceptable solution“.
In conclusion, for the very same reason, namely avoid the “two bites at the apple” situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established.
Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described.
Best Rafael
________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
Thank you Becky for kindly answering my questions, much appreciated.
I hope to get back to you with further comments as I proceed with internal consultations.
I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC.
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
Best Rafael
Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions
I am going to attempt to respond to Rafael’s questions, below. This is a long post, so apologies in advance.
I’d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC’s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board’s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board’s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael’s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this “carve-out” is only applicable to the GAC. If this measure is foreseen to avoid the “two-bites-at-the-apple” situation, for instance the GNSO is as well in a position of being “judge and part” when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a “mutually agreeable procedure to TRY to find a solution”, it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board’s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way – it can involve any topic with “public policy” implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this “carve-out” were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to “Board decisions” to “implement GAC advice”. But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this “carve-out” mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a “carve-out” is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a “scorecard” regarding the Board’s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-en..... To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board’s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a “no formal objection rule” (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN’s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board’s implementation action – e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset – nothing prevents the GAC from “intervening” through debate, discussion, persuasion, advice or any other non-decisional role. 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
Given the very different roles & natures of SO¹s versus ACs, this comparison of voting thresholds doesn¹t make sense. J. On 2/6/16, 4:29 , "accountability-cross-community-bounces@icann.org on behalf of Perez Galindo, Rafael" <accountability-cross-community-bounces@icann.org on behalf of RPEREZGA@minetur.es> wrote:
Dear Becky,
Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is ³unique² in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision.
I kindly ask for clarification on the ³uniqueness² of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a ³discussion² with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3.
In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss ³in good faith and in a timely and efficient manner, to find a mutually acceptable solution³.
In conclusion, for the very same reason, namely avoid the ³two bites at the apple² situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established.
Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described.
Best Rafael
________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
Thank you Becky for kindly answering my questions, much appreciated.
I hope to get back to you with further comments as I proceed with internal consultations.
I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC.
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
Best Rafael
Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions
I am going to attempt to respond to Rafael¹s questions, below. This is a long post, so apologies in advance.
I¹d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC¹s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board¹s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board¹s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael¹s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this ³carve-out² is only applicable to the GAC. If this measure is foreseen to avoid the ³two-bites-at-the-apple² situation, for instance the GNSO is as well in a position of being ³judge and part² when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a ³mutually agreeable procedure to TRY to find a solution², it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board¹s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way it can involve any topic with ³public policy² implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this ³carve-out² were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to ³Board decisions² to ³implement GAC advice². But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this ³carve-out² mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a ³carve-out² is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a ³scorecard² regarding the Board¹s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-e n.pdf. To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board¹s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a ³no formal objection rule² (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN¹s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board¹s implementation action e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset nothing prevents the GAC from ³intervening² through debate, discussion, persuasion, advice or any other non-decisional role. 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
Of course it doesn't. . As I have said he is being deliberately obtuse. -- Paul Rosenzweig Sent from myMail app for Android Saturday, 06 February 2016, 00:47PM -05:00 from "James M. Bladel" < jbladel@godaddy.com> :
Given the very different roles & natures of SO¹s versus ACs, this comparison of voting thresholds doesn¹t make sense.
J.
On 2/6/16, 4:29 , " accountability-cross-community-bounces@icann.org on behalf of Perez Galindo, Rafael" < accountability-cross-community-bounces@icann.org on behalf of RPEREZGA@minetur.es > wrote:
Dear Becky,
Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is ³unique² in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision.
I kindly ask for clarification on the ³uniqueness² of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a ³discussion² with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3.
In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss ³in good faith and in a timely and efficient manner, to find a mutually acceptable solution³.
In conclusion, for the very same reason, namely avoid the ³two bites at the apple² situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established.
Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described.
Best Rafael
________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
Thank you Becky for kindly answering my questions, much appreciated.
I hope to get back to you with further comments as I proceed with internal consultations.
I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC.
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
Best Rafael
Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions
I am going to attempt to respond to Rafael¹s questions, below. This is a long post, so apologies in advance.
I¹d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC¹s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board¹s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board¹s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael¹s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this ³carve-out² is only applicable to the GAC. If this measure is foreseen to avoid the ³two-bites-at-the-apple² situation, for instance the GNSO is as well in a position of being ³judge and part² when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a ³mutually agreeable procedure to TRY to find a solution², it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board¹s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way it can involve any topic with ³public policy² implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this ³carve-out² were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to ³Board decisions² to ³implement GAC advice². But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this ³carve-out² mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a ³carve-out² is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a ³scorecard² regarding the Board¹s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-e n.pdf. To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board¹s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a ³no formal objection rule² (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN¹s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board¹s implementation action e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset nothing prevents the GAC from ³intervening² through debate, discussion, persuasion, advice or any other non-decisional role. 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
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear Co-Chairs Dear Beckie Dear Steve DelBianco It is difficult to follow the arguments expressed by James In the ST18 reference is made to the privilege that BYLAWS provided to GAC obliging the Board to get into negotiation with GAC, if its ADVICE IS REJECTED to be enganged in negotiation/ discussion with GAC to try to find in a good faith a satisfactory solution….. But this privilege also forseen for GNSO and ccNSO too as Rafael indicated The privilege or DOUBBLE BITE TO apple by GAC, AS A SINGLE OUT AC may not be relevant I think the comments / question raised by Rafael should be properly and legally answered. That is why I suggest that this issue be given to our Legal Council/ Lawyers to be legally interpreted in a formal MEMORANDUM WHICH SHOULD BE RECODRED IN THE CCWG documentations. We need to convince Rafael and GNSO that how the apple should be divided between the two. This is to be discussed in detail on Monday devoted call. CCWG does not work only for GNSO or ccNSO but for the entire community. If resolution of this issue is not resolved satisfactorily so as both parties be equally happy or equally unhappy then the entire process would be failed since this is a fundamental issue which must be properly addressed and resolved . We must provide convincing reply to Rafael, Jorge and other GAC member so commented . However, this is not an issue to be resolved by VOTING I hereby declare that VOTING does not resolve the matter and thus SHOULD NOT BE USED. We must to find a workable solution.by which a legal language in line with the objectives and spirit of Bylaws and Multistakeholder approach is drafted and used in these Recs. Regards 2016-02-06 18:47 GMT+01:00 James M. Bladel <jbladel@godaddy.com>:
Given the very different roles & natures of SO¹s versus ACs, this comparison of voting thresholds doesn¹t make sense.
J.
On 2/6/16, 4:29 , "accountability-cross-community-bounces@icann.org on behalf of Perez Galindo, Rafael" <accountability-cross-community-bounces@icann.org on behalf of RPEREZGA@minetur.es> wrote:
Dear Becky,
Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is ³unique² in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision.
I kindly ask for clarification on the ³uniqueness² of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a ³discussion² with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3.
In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss ³in good faith and in a timely and efficient manner, to find a mutually acceptable solution³.
In conclusion, for the very same reason, namely avoid the ³two bites at the apple² situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established.
Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described.
Best Rafael
________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
Thank you Becky for kindly answering my questions, much appreciated.
I hope to get back to you with further comments as I proceed with internal consultations.
I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC.
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
Best Rafael
Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions
I am going to attempt to respond to Rafael¹s questions, below. This is a long post, so apologies in advance.
I¹d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC¹s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board¹s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board¹s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael¹s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this ³carve-out² is only applicable to the GAC. If this measure is foreseen to avoid the ³two-bites-at-the-apple² situation, for instance the GNSO is as well in a position of being ³judge and part² when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a ³mutually agreeable procedure to TRY to find a solution², it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board¹s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way it can involve any topic with ³public policy² implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this ³carve-out² were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to ³Board decisions² to ³implement GAC advice². But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this ³carve-out² mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a ³carve-out² is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a ³scorecard² regarding the Board¹s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example,
https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-e
n.pdf. To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board¹s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a ³no formal objection rule² (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN¹s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board¹s implementation action e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset nothing prevents the GAC from ³intervening² through debate, discussion, persuasion, advice or any other non-decisional role. 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
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear all Perhaps we shall remind ourselves that every SO and every AC has a legitimate role within the development of policies and their implementation within ICANN. And all these roles are different but equally necessary, in their specific form, for the develpment of such policies and their implementation. Some develop policies and others give advice, all according to the existing rules of ICANN, which lay out its specific model of multistakeholder collaboration. Our work here in the ccwg has not been, and is not, according to our charter, to change this model. We have been tasked, as I have been understanding our work, to develop new accountability measures, primarily directed to establish means for the community to check the workings of ICANN as an organization. And in this new community empowerment framework we have agreed from the beginning that all SO/AC willing to participate should be treated equally - that they should have an equal footing. Any compromise we may find during these last days must be consistent with this principle, supported repeatedly in public comment periods. Best Jorge Von meinem iPhone gesendet
Am 06.02.2016 um 19:06 schrieb James M. Bladel <jbladel@godaddy.com>:
Given the very different roles & natures of SO¹s versus ACs, this comparison of voting thresholds doesn¹t make sense.
J.
On 2/6/16, 4:29 , "accountability-cross-community-bounces@icann.org on behalf of Perez Galindo, Rafael" <accountability-cross-community-bounces@icann.org on behalf of RPEREZGA@minetur.es> wrote:
Dear Becky,
Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is ³unique² in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision.
I kindly ask for clarification on the ³uniqueness² of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a ³discussion² with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3.
In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss ³in good faith and in a timely and efficient manner, to find a mutually acceptable solution³.
In conclusion, for the very same reason, namely avoid the ³two bites at the apple² situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established.
Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described.
Best Rafael
________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
Thank you Becky for kindly answering my questions, much appreciated.
I hope to get back to you with further comments as I proceed with internal consultations.
I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC.
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
Best Rafael
Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions
I am going to attempt to respond to Rafael¹s questions, below. This is a long post, so apologies in advance.
I¹d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC¹s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board¹s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board¹s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael¹s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this ³carve-out² is only applicable to the GAC. If this measure is foreseen to avoid the ³two-bites-at-the-apple² situation, for instance the GNSO is as well in a position of being ³judge and part² when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a ³mutually agreeable procedure to TRY to find a solution², it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board¹s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way it can involve any topic with ³public policy² implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this ³carve-out² were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to ³Board decisions² to ³implement GAC advice². But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this ³carve-out² mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a ³carve-out² is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a ³scorecard² regarding the Board¹s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15-e n.pdf. To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board¹s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a ³no formal objection rule² (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN¹s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board¹s implementation action e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset nothing prevents the GAC from ³intervening² through debate, discussion, persuasion, advice or any other non-decisional role. 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
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Dear Jorge - It is indeed correct to note that all SOs and ACs have legitimate, yet different roles, within ICANN. The function of the SOs is to develop consensus policies, but they are limited in scope (GNSO-gTLDs, ccNSO-ccTLDs, etc.). The integrity of the bottom-up process obligates the Board to give significant weight to their in-scope recommendations, hence the 2/3rds threshold to reject. The scope of an AC is less limited (GAC-“public policy”), and can advise the Board directly on any issue, including the policy recommendations of the SOs or other ACs. There is not an equivalent among the SOs (e.g., the GNSO would not, for example, demand “equal footing” with the ccNSO on ccTLD consensus policy development). The fact that the GAC is asking for its advice to be treated with equivalence to as those organizations defined by the bylaws as responsible for developing policy is a significant re-write of the ICANN model. It dilutes the meaningful contributions of SOs, and (ultimately) converts every issues into a dialogue between the Board and GAC/Governments. Farewell, multi-stakeholders... I agree with Andrew: we seem to be moving further apart on this with each day, and our time is very short. I’m much less optimistic of the Becky/Kavouss compromise, compared to where I was on Thursday. But we need to make a decision to move forward with the Third Draft (which will likely fail the GNSO) or adopt the Becky/Kavouss compromise and take our chances with the GAC. Thanks— J. On 2/6/16, 12:39 , "Jorge.Cancio@bakom.admin.ch" <Jorge.Cancio@bakom.admin.ch> wrote:
Dear all
Perhaps we shall remind ourselves that every SO and every AC has a legitimate role within the development of policies and their implementation within ICANN.
And all these roles are different but equally necessary, in their specific form, for the develpment of such policies and their implementation.
Some develop policies and others give advice, all according to the existing rules of ICANN, which lay out its specific model of multistakeholder collaboration.
Our work here in the ccwg has not been, and is not, according to our charter, to change this model.
We have been tasked, as I have been understanding our work, to develop new accountability measures, primarily directed to establish means for the community to check the workings of ICANN as an organization.
And in this new community empowerment framework we have agreed from the beginning that all SO/AC willing to participate should be treated equally - that they should have an equal footing.
Any compromise we may find during these last days must be consistent with this principle, supported repeatedly in public comment periods.
Best
Jorge
Von meinem iPhone gesendet
Am 06.02.2016 um 19:06 schrieb James M. Bladel <jbladel@godaddy.com>:
Given the very different roles & natures of SO¹s versus ACs, this comparison of voting thresholds doesn¹t make sense.
J.
On 2/6/16, 4:29 , "accountability-cross-community-bounces@icann.org on behalf of Perez Galindo, Rafael" <accountability-cross-community-bounces@icann.org on behalf of RPEREZGA@minetur.es> wrote:
Dear Becky,
Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is ³unique² in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision.
I kindly ask for clarification on the ³uniqueness² of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a ³discussion² with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3.
In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss ³in good faith and in a timely and efficient manner, to find a mutually acceptable solution³.
In conclusion, for the very same reason, namely avoid the ³two bites at the apple² situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established.
Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described.
Best Rafael
________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
Thank you Becky for kindly answering my questions, much appreciated.
I hope to get back to you with further comments as I proceed with internal consultations.
I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC.
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
Best Rafael
Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions
I am going to attempt to respond to Rafael¹s questions, below. This is a long post, so apologies in advance.
I¹d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC¹s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board¹s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board¹s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael¹s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this ³carve-out² is only applicable to the GAC. If this measure is foreseen to avoid the ³two-bites-at-the-apple² situation, for instance the GNSO is as well in a position of being ³judge and part² when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a ³mutually agreeable procedure to TRY to find a solution², it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board¹s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way it can involve any topic with ³public policy² implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this ³carve-out² were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to ³Board decisions² to ³implement GAC advice². But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this ³carve-out² mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a ³carve-out² is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a ³scorecard² regarding the Board¹s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example,
https://www.icann.org/en/system/files/files/gac-advice-scorecard-07oct15 -e n.pdf. To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board¹s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a ³no formal objection rule² (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN¹s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board¹s implementation action e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset nothing prevents the GAC from ³intervening² through debate, discussion, persuasion, advice or any other non-decisional role. 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
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
James, I want to point out that the existance and stability of the roles you note has not been unchanged over time -- we began with a PSO Bylaws entity which we no longer have, replaced (poorly, in my opinion) by a technical liaison function, and real confusion over membership, improved (somewhat, again in my opinion) by an At-Large Bylaws entity. I also want to point out that there are issues for which the gNSO and the ccNSO are not, as you seem to suggest, independent, but for which the policy interests of each coincide, e.g., our i18n/l10n choice of mechanism and of local implementation. We have struggled over the years with the problem that the GAC, and also ALAC, have no structural means of participating in policy development (in any of the SOs), and so are constrained to react to policy proposals. Respectfully I suggest that nothing we are considering here "dilutes the meaningful contributions of SOs, and (ultimately) converts every issues into a dialogue between the Board and GAC/Governments". Eric Brunner-Williams Eugene, Oregon
I just want to reach to this and note that ALAC and At-Large members are very active in the GNSO policy development processes on equal footing with GNSO members. SO unless I am missing something I don’t think that this is reflective of the current realities for the GNSO policy processes. -James On 06/02/2016, 7:37 p.m., "accountability-cross-community-bounces@icann.org on behalf of Eric (Maule) Brunner-Williams" <accountability-cross-community-bounces@icann.org on behalf of ebw@abenaki.wabanaki.net> wrote:
We have struggled over the years with the problem that the GAC, and also ALAC, have no structural means of participating in policy development (in any of the SOs), and so are constrained to react to policy proposals.
James, As I've not participated directly in GNSO processes recently, it is quite possible my representation is historic rather than contemporary. This still leaves at least one other AC which may not be "very active in the GNSO policy development processes on equal footing with GNSO members", for which my representation may be contemporary rather than historic. Eric Brunner-Williams Eugene, Oregon
I just want to reach to this and note that ALAC and At-Large members are very active in the GNSO policy development processes on equal footing with GNSO members. SO unless I am missing something I don?t think that this is reflective of the current realities for the GNSO policy processes.
FWIW I don't know what gives you that impression but yes no doubt about the activeness of ALAC (AtLarge) but I think adding "equal footing" to it may be too optimistic. That said, I don't think this is where to resolve that (if there is anything to resolve) Cheers! On 6 Feb 2016 9:02 p.m., "James Gannon" <james@cyberinvasion.net> wrote:
I just want to reach to this and note that ALAC and At-Large members are very active in the GNSO policy development processes on equal footing with GNSO members. SO unless I am missing something I don’t think that this is reflective of the current realities for the GNSO policy processes.
-James
On 06/02/2016, 7:37 p.m., " accountability-cross-community-bounces@icann.org on behalf of Eric (Maule) Brunner-Williams" < accountability-cross-community-bounces@icann.org on behalf of ebw@abenaki.wabanaki.net> wrote:
We have struggled over the years with the problem that the GAC, and also ALAC, have no structural means of participating in policy development (in any of the SOs), and so are constrained to react to policy proposals.
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
ALAC and At-large members of GNSO PDPs are given exactly the same rights during the working group and the final determination of consensus as members of the WG affiliated with the GNSO… Im not sure of any differentiation in the current working methods of GNSO PDPs. And for the record and for Eric’s info GAC members in particular the PSWG members are also active in a similar manner. But I agree with Seun here is not the place for this discussion given the current pressing matter we have before us. -James From: Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> Date: Saturday 6 February 2016 at 8:19 p.m. To: James Gannon <james@cyberinvasion.net<mailto:james@cyberinvasion.net>> Cc: "James M. Bladel" <jbladel@godaddy.com<mailto:jbladel@godaddy.com>>, "accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>>, "Eric (Maule) Brunner-Williams" <ebw@abenaki.wabanaki.net<mailto:ebw@abenaki.wabanaki.net>> Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions FWIW I don't know what gives you that impression but yes no doubt about the activeness of ALAC (AtLarge) but I think adding "equal footing" to it may be too optimistic. That said, I don't think this is where to resolve that (if there is anything to resolve) Cheers! On 6 Feb 2016 9:02 p.m., "James Gannon" <james@cyberinvasion.net<mailto:james@cyberinvasion.net>> wrote: I just want to reach to this and note that ALAC and At-Large members are very active in the GNSO policy development processes on equal footing with GNSO members. SO unless I am missing something I don’t think that this is reflective of the current realities for the GNSO policy processes. -James On 06/02/2016, 7:37 p.m., "accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> on behalf of Eric (Maule) Brunner-Williams" <accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> on behalf of ebw@abenaki.wabanaki.net<mailto:ebw@abenaki.wabanaki.net>> wrote:
We have struggled over the years with the problem that the GAC, and also ALAC, have no structural means of participating in policy development (in any of the SOs), and so are constrained to react to policy proposals.
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
James,
ALAC and At-large members of GNSO PDPs are given exactly the same rights during the working group and the final determination of consensus as members of the WG affiliated with the GNSO? Im not sure of any differentiation in the current working methods of GNSO PDPs.
I recall there being quite a bit of work by the voting members of the GNSO Council before a working group is chartered, as well as restrictions on the choice of chair and Council liaison.
And for the record and for Eric?s info GAC members in particular the PSWG members are also active in a similar manner.
I'm relieved that in my absence problems correct themselves.
But I agree with Seun here is not the place for this discussion given the current pressing matter we have before us.
True, but you did offer your view that "... It converts every issues into a dialogue between the Board and GAC/Governments." This is a pretty serious claim. Rather than restate, slightly less grandly, the import of GAC advice, your supporting arguement appears to be everyone is meaningfully inside the GNSO policy tent. If true, I'm surprised. Eric Brunner-Williams Eugene, Oregon
Rafael, with all due respect I have explained in great detail why a PDP and GAC Advice cannot be compared. Here is my explanation again: ********************** 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> On 2/6/16, 1:39 PM, "Jorge.Cancio@bakom.admin.ch" <Jorge.Cancio@bakom.admin.ch> wrote:
Dear all
Perhaps we shall remind ourselves that every SO and every AC has a legitimate role within the development of policies and their implementation within ICANN.
And all these roles are different but equally necessary, in their specific form, for the develpment of such policies and their implementation.
Some develop policies and others give advice, all according to the existing rules of ICANN, which lay out its specific model of multistakeholder collaboration.
Our work here in the ccwg has not been, and is not, according to our charter, to change this model.
We have been tasked, as I have been understanding our work, to develop new accountability measures, primarily directed to establish means for the community to check the workings of ICANN as an organization.
And in this new community empowerment framework we have agreed from the beginning that all SO/AC willing to participate should be treated equally - that they should have an equal footing.
Any compromise we may find during these last days must be consistent with this principle, supported repeatedly in public comment periods.
Best
Jorge
Von meinem iPhone gesendet
Am 06.02.2016 um 19:06 schrieb James M. Bladel <jbladel@godaddy.com>:
Given the very different roles & natures of SO¹s versus ACs, this comparison of voting thresholds doesn¹t make sense.
J.
On 2/6/16, 4:29 , "accountability-cross-community-bounces@icann.org on behalf of Perez Galindo, Rafael" <accountability-cross-community-bounces@icann.org on behalf of RPEREZGA@minetur.es> wrote:
Dear Becky,
Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is ³unique² in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision.
I kindly ask for clarification on the ³uniqueness² of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a ³discussion² with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3.
In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss ³in good faith and in a timely and efficient manner, to find a mutually acceptable solution³.
In conclusion, for the very same reason, namely avoid the ³two bites at the apple² situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established.
Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described.
Best Rafael
________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
Thank you Becky for kindly answering my questions, much appreciated.
I hope to get back to you with further comments as I proceed with internal consultations.
I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC.
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
Best Rafael
Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions
I am going to attempt to respond to Rafael¹s questions, below. This is a long post, so apologies in advance.
I¹d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC¹s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board¹s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board¹s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael¹s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this ³carve-out² is only applicable to the GAC. If this measure is foreseen to avoid the ³two-bites-at-the-apple² situation, for instance the GNSO is as well in a position of being ³judge and part² when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a ³mutually agreeable procedure to TRY to find a solution², it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board¹s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way it can involve any topic with ³public policy² implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this ³carve-out² were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to ³Board decisions² to ³implement GAC advice². But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this ³carve-out² mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a ³carve-out² is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a ³scorecard² regarding the Board¹s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example,
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_sy stem_files_files_gac-2Dadvice-2Dscorecard-2D07oct15-2De&d=CwIF-g&c=MOptN lVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn 5PbwQ801bKyEaf_KkbWRX6C6Ri6uiICMe-nIA&s=LkCxNJyFaoVIBzQ9JqTXU_fxmDE1Z366 mOozgyGbT28&e= n.pdf. To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board¹s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a ³no formal objection rule² (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN¹s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board¹s implementation action e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset nothing prevents the GAC from ³intervening² through debate, discussion, persuasion, advice or any other non-decisional role. 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://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma n_listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDAL C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bK yEaf_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUV E&e=
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman _listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDALC_ lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bKyEa f_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUVE&e=
I think it is worth considering the extent to which providing GAC with decisional authority over ICANN’s governance violates ICANN’s Articles of Organization and Bylaws, which require it to operate in an accountable and transparent way. This was certainly a significant issue in the last summer's .africa IRP ruling, where the panel found that GAC breached its obligations to act transparently and equitably in accordance with ICANN’s Articles and Bylaws. The panel found that as a constituent body of ICANN, the GAC (and the board) had a legal obligation to act transparently and equitably, and they did not, creating a breach of ICANN’s Articles and Bylaws. What we are doing here is providing this particular constituent body of ICANN, which has no transparency requirements nor track record of transparency with equal decisional authority in Rec 1 and greater decisional authority in Rec 11 than those constituent parts of ICANN which are required to act transparently, such as the GNSO. This is another fundamental flaw in the proposal. Similarly, there is nothing that requires GAC to be “bottom-up” in its membership. Democratic and non-democratic governments are welcome in the GAC without distinction. Perhaps that was fine when GAC was purely advisory, but now that it will be provided decisional authority on so-called “equal footing” with those constituent parts of ICANN that are required to be operated in a bottom-up and democratic manner, it becomes a significant problem and major adjustment in the fundamental model of Internet governance, which itself becomes less democratic of a model. GAC has not even been able to agree that it wants this major shift in its role and the change to the multi-stakeholderism governance model that comes with it. If it can’t do that, those the parts of Recs 1 & 11 that enhance GAC’s power need to go. Otherwise ICANN risks violating its own Articles and Bylaws by significantly empowering the part of it, which is not required to be transparent, accountable, or bottom-up as mandated by these legal instruments. Robin
On Feb 6, 2016, at 3:03 PM, Burr, Becky <Becky.Burr@neustar.biz> wrote:
Rafael, with all due respect I have explained in great detail why a PDP and GAC Advice cannot be compared. Here is my explanation again: **********************
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>
On 2/6/16, 1:39 PM, "Jorge.Cancio@bakom.admin.ch" <Jorge.Cancio@bakom.admin.ch> wrote:
Dear all
Perhaps we shall remind ourselves that every SO and every AC has a legitimate role within the development of policies and their implementation within ICANN.
And all these roles are different but equally necessary, in their specific form, for the develpment of such policies and their implementation.
Some develop policies and others give advice, all according to the existing rules of ICANN, which lay out its specific model of multistakeholder collaboration.
Our work here in the ccwg has not been, and is not, according to our charter, to change this model.
We have been tasked, as I have been understanding our work, to develop new accountability measures, primarily directed to establish means for the community to check the workings of ICANN as an organization.
And in this new community empowerment framework we have agreed from the beginning that all SO/AC willing to participate should be treated equally - that they should have an equal footing.
Any compromise we may find during these last days must be consistent with this principle, supported repeatedly in public comment periods.
Best
Jorge
Von meinem iPhone gesendet
Am 06.02.2016 um 19:06 schrieb James M. Bladel <jbladel@godaddy.com>:
Given the very different roles & natures of SO¹s versus ACs, this comparison of voting thresholds doesn¹t make sense.
J.
On 2/6/16, 4:29 , "accountability-cross-community-bounces@icann.org on behalf of Perez Galindo, Rafael" <accountability-cross-community-bounces@icann.org on behalf of RPEREZGA@minetur.es> wrote:
Dear Becky,
Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is ³unique² in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision.
I kindly ask for clarification on the ³uniqueness² of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a ³discussion² with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3.
In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss ³in good faith and in a timely and efficient manner, to find a mutually acceptable solution³.
In conclusion, for the very same reason, namely avoid the ³two bites at the apple² situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established.
Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described.
Best Rafael
________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
Thank you Becky for kindly answering my questions, much appreciated.
I hope to get back to you with further comments as I proceed with internal consultations.
I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC.
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
Best Rafael
Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions
I am going to attempt to respond to Rafael¹s questions, below. This is a long post, so apologies in advance.
I¹d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC¹s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board¹s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board¹s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael¹s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this ³carve-out² is only applicable to the GAC. If this measure is foreseen to avoid the ³two-bites-at-the-apple² situation, for instance the GNSO is as well in a position of being ³judge and part² when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a ³mutually agreeable procedure to TRY to find a solution², it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board¹s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way it can involve any topic with ³public policy² implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this ³carve-out² were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to ³Board decisions² to ³implement GAC advice². But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this ³carve-out² mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a ³carve-out² is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a ³scorecard² regarding the Board¹s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example,
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_sy stem_files_files_gac-2Dadvice-2Dscorecard-2D07oct15-2De&d=CwIF-g&c=MOptN lVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn 5PbwQ801bKyEaf_KkbWRX6C6Ri6uiICMe-nIA&s=LkCxNJyFaoVIBzQ9JqTXU_fxmDE1Z366 mOozgyGbT28&e= n.pdf. To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board¹s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a ³no formal objection rule² (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN¹s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board¹s implementation action e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset nothing prevents the GAC from ³intervening² through debate, discussion, persuasion, advice or any other non-decisional role. 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://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma n_listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDAL C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bK yEaf_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUV E&e=
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman _listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDALC_ lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bKyEa f_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUVE&e=
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I fully agree. GAC is an AC, not an SO, but receives deference to consensus advice. It obviously wants more influence. But that is not an accountability measure that must be in place before the transition can take. it does have however have to potential to break the Arasteh/Burr Compromise and the Consensus that we seem to have for it. It strikes me as the classic tactic from Negotiation 101: "Always ask for more" :-)-O -- Sent from Dr Lisse's iPad mini 4
On 7 Feb 2016, at 01:30, Robin Gross <robin@ipjustice.org> wrote:
I think it is worth considering the extent to which providing GAC with decisional authority over ICANN’s governance violates ICANN’s Articles of Organization and Bylaws, which require it to operate in an accountable and transparent way.
This was certainly a significant issue in the last summer's .africa IRP ruling, where the panel found that GAC breached its obligations to act transparently and equitably in accordance with ICANN’s Articles and Bylaws. The panel found that as a constituent body of ICANN, the GAC (and the board) had a legal obligation to act transparently and equitably, and they did not, creating a breach of ICANN’s Articles and Bylaws.
What we are doing here is providing this particular constituent body of ICANN, which has no transparency requirements nor track record of transparency with equal decisional authority in Rec 1 and greater decisional authority in Rec 11 than those constituent parts of ICANN which are required to act transparently, such as the GNSO. This is another fundamental flaw in the proposal.
Similarly, there is nothing that requires GAC to be “bottom-up” in its membership. Democratic and non-democratic governments are welcome in the GAC without distinction. Perhaps that was fine when GAC was purely advisory, but now that it will be provided decisional authority on so-called “equal footing” with those constituent parts of ICANN that are required to be operated in a bottom-up and democratic manner, it becomes a significant problem and major adjustment in the fundamental model of Internet governance, which itself becomes less democratic of a model.
GAC has not even been able to agree that it wants this major shift in its role and the change to the multi-stakeholderism governance model that comes with it. If it can’t do that, those the parts of Recs 1 & 11 that enhance GAC’s power need to go. Otherwise ICANN risks violating its own Articles and Bylaws by significantly empowering the part of it, which is not required to be transparent, accountable, or bottom-up as mandated by these legal instruments.
Robin
On Feb 6, 2016, at 3:03 PM, Burr, Becky <Becky.Burr@neustar.biz> wrote:
Rafael, with all due respect I have explained in great detail why a PDP and GAC Advice cannot be compared. Here is my explanation again: **********************
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>
On 2/6/16, 1:39 PM, "Jorge.Cancio@bakom.admin.ch" <Jorge.Cancio@bakom.admin.ch> wrote:
Dear all
Perhaps we shall remind ourselves that every SO and every AC has a legitimate role within the development of policies and their implementation within ICANN.
And all these roles are different but equally necessary, in their specific form, for the develpment of such policies and their implementation.
Some develop policies and others give advice, all according to the existing rules of ICANN, which lay out its specific model of multistakeholder collaboration.
Our work here in the ccwg has not been, and is not, according to our charter, to change this model.
We have been tasked, as I have been understanding our work, to develop new accountability measures, primarily directed to establish means for the community to check the workings of ICANN as an organization.
And in this new community empowerment framework we have agreed from the beginning that all SO/AC willing to participate should be treated equally - that they should have an equal footing.
Any compromise we may find during these last days must be consistent with this principle, supported repeatedly in public comment periods.
Best
Jorge
Von meinem iPhone gesendet
Am 06.02.2016 um 19:06 schrieb James M. Bladel <jbladel@godaddy.com>:
Given the very different roles & natures of SO¹s versus ACs, this comparison of voting thresholds doesn¹t make sense.
J.
On 2/6/16, 4:29 , "accountability-cross-community-bounces@icann.org on behalf of Perez Galindo, Rafael" <accountability-cross-community-bounces@icann.org on behalf of RPEREZGA@minetur.es> wrote:
Dear Becky,
Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is ³unique² in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision.
I kindly ask for clarification on the ³uniqueness² of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a ³discussion² with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3.
In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss ³in good faith and in a timely and efficient manner, to find a mutually acceptable solution³.
In conclusion, for the very same reason, namely avoid the ³two bites at the apple² situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established.
Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described.
Best Rafael
________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
Thank you Becky for kindly answering my questions, much appreciated.
I hope to get back to you with further comments as I proceed with internal consultations.
I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC.
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
Best Rafael
Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions
I am going to attempt to respond to Rafael¹s questions, below. This is a long post, so apologies in advance.
I¹d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC¹s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board¹s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board¹s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael¹s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this ³carve-out² is only applicable to the GAC. If this measure is foreseen to avoid the ³two-bites-at-the-apple² situation, for instance the GNSO is as well in a position of being ³judge and part² when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a ³mutually agreeable procedure to TRY to find a solution², it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board¹s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way it can involve any topic with ³public policy² implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this ³carve-out² were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to ³Board decisions² to ³implement GAC advice². But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this ³carve-out² mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a ³carve-out² is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a ³scorecard² regarding the Board¹s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example,
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_sy stem_files_files_gac-2Dadvice-2Dscorecard-2D07oct15-2De&d=CwIF-g&c=MOptN lVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn 5PbwQ801bKyEaf_KkbWRX6C6Ri6uiICMe-nIA&s=LkCxNJyFaoVIBzQ9JqTXU_fxmDE1Z366 mOozgyGbT28&e= n.pdf. To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board¹s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a ³no formal objection rule² (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN¹s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board¹s implementation action e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset nothing prevents the GAC from ³intervening² through debate, discussion, persuasion, advice or any other non-decisional role. 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://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma n_listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDAL C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bK yEaf_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUV E&e=
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman _listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDALC_ lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bKyEa f_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUVE&e=
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I agree too, with the friendly amendment that it isn’t the “GAC” that is using the tactic, but merely a small minority of vocal GAC members who hope we will mistake their opposition for GAC opposition … 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=article...> Link to my PGP Key <http://www.rsaconference.com/events/us16?utm_source=signature&utm_medium=ema...> From: Dr Eberhard W Lisse [mailto:epilisse@gmail.com] Sent: Sunday, February 7, 2016 12:23 AM To: CCWG Accountability <accountability-cross-community@icann.org> Cc: Lisse Eberhard <directors@omadhina.NET> Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions I fully agree. GAC is an AC, not an SO, but receives deference to consensus advice. It obviously wants more influence. But that is not an accountability measure that must be in place before the transition can take. it does have however have to potential to break the Arasteh/Burr Compromise and the Consensus that we seem to have for it. It strikes me as the classic tactic from Negotiation 101: "Always ask for more" :-)-O -- Sent from Dr Lisse's iPad mini 4 On 7 Feb 2016, at 01:30, Robin Gross <robin@ipjustice.org <mailto:robin@ipjustice.org> > wrote: I think it is worth considering the extent to which providing GAC with decisional authority over ICANN’s governance violates ICANN’s Articles of Organization and Bylaws, which require it to operate in an accountable and transparent way. This was certainly a significant issue in the last summer's .africa IRP ruling, where the panel found that GAC breached its obligations to act transparently and equitably in accordance with ICANN’s Articles and Bylaws. The panel found that as a constituent body of ICANN, the GAC (and the board) had a legal obligation to act transparently and equitably, and they did not, creating a breach of ICANN’s Articles and Bylaws. What we are doing here is providing this particular constituent body of ICANN, which has no transparency requirements nor track record of transparency with equal decisional authority in Rec 1 and greater decisional authority in Rec 11 than those constituent parts of ICANN which are required to act transparently, such as the GNSO. This is another fundamental flaw in the proposal. Similarly, there is nothing that requires GAC to be “bottom-up” in its membership. Democratic and non-democratic governments are welcome in the GAC without distinction. Perhaps that was fine when GAC was purely advisory, but now that it will be provided decisional authority on so-called “equal footing” with those constituent parts of ICANN that are required to be operated in a bottom-up and democratic manner, it becomes a significant problem and major adjustment in the fundamental model of Internet governance, which itself becomes less democratic of a model. GAC has not even been able to agree that it wants this major shift in its role and the change to the multi-stakeholderism governance model that comes with it. If it can’t do that, those the parts of Recs 1 & 11 that enhance GAC’s power need to go. Otherwise ICANN risks violating its own Articles and Bylaws by significantly empowering the part of it, which is not required to be transparent, accountable, or bottom-up as mandated by these legal instruments. Robin On Feb 6, 2016, at 3:03 PM, Burr, Becky <Becky.Burr@neustar.biz <mailto:Becky.Burr@neustar.biz> > wrote: Rafael, with all due respect I have explained in great detail why a PDP and GAC Advice cannot be compared. Here is my explanation again: ********************** 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://neustar.biz> <http://www.neustar.biz> On 2/6/16, 1:39 PM, "Jorge.Cancio@bakom.admin.ch <mailto:Jorge.Cancio@bakom.admin.ch> " <Jorge.Cancio@bakom.admin.ch <mailto:Jorge.Cancio@bakom.admin.ch> > wrote: Dear all Perhaps we shall remind ourselves that every SO and every AC has a legitimate role within the development of policies and their implementation within ICANN. And all these roles are different but equally necessary, in their specific form, for the develpment of such policies and their implementation. Some develop policies and others give advice, all according to the existing rules of ICANN, which lay out its specific model of multistakeholder collaboration. Our work here in the ccwg has not been, and is not, according to our charter, to change this model. We have been tasked, as I have been understanding our work, to develop new accountability measures, primarily directed to establish means for the community to check the workings of ICANN as an organization. And in this new community empowerment framework we have agreed from the beginning that all SO/AC willing to participate should be treated equally - that they should have an equal footing. Any compromise we may find during these last days must be consistent with this principle, supported repeatedly in public comment periods. Best Jorge Von meinem iPhone gesendet Am 06.02.2016 um 19:06 schrieb James M. Bladel <jbladel@godaddy.com <mailto:jbladel@godaddy.com> >: Given the very different roles & natures of SO¹s versus ACs, this comparison of voting thresholds doesn¹t make sense. J. On 2/6/16, 4:29 , "accountability-cross-community-bounces@icann.org <mailto:accountability-cross-community-bounces@icann.org> on behalf of Perez Galindo, Rafael" <accountability-cross-community-bounces@icann.org <mailto:accountability-cross-community-bounces@icann.org> on behalf of RPEREZGA@minetur.es <mailto:RPEREZGA@minetur.es> > wrote: Dear Becky, Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is ³unique² in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision. I kindly ask for clarification on the ³uniqueness² of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a ³discussion² with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3. In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss ³in good faith and in a timely and efficient manner, to find a mutually acceptable solution³. In conclusion, for the very same reason, namely avoid the ³two bites at the apple² situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established. Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described. Best Rafael ________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions Thank you Becky for kindly answering my questions, much appreciated. I hope to get back to you with further comments as I proceed with internal consultations. I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC. For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects. Best Rafael Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions I am going to attempt to respond to Rafael¹s questions, below. This is a long post, so apologies in advance. I¹d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC¹s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board¹s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board¹s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority. Rafael¹s questions appear in blue italic below, and my answers follow: 1. We have previously discussed it, but we still fail to understand why this ³carve-out² is only applicable to the GAC. If this measure is foreseen to avoid the ³two-bites-at-the-apple² situation, for instance the GNSO is as well in a position of being ³judge and part² when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a ³mutually agreeable procedure to TRY to find a solution², it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then? I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board¹s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way it can involve any topic with ³public policy² implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority. My previous response to this same question from Jorge follows: 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. 2. If this ³carve-out² were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to ³Board decisions² to ³implement GAC advice². But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this ³carve-out² mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a ³carve-out² is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice? This seems fairly straightforward. The GAC keeps a ³scorecard² regarding the Board¹s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example, https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_sy stem_files_files_gac-2Dadvice-2Dscorecard-2D07oct15-2De&d=CwIF-g&c=MOptN lVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn 5PbwQ801bKyEaf_KkbWRX6C6Ri6uiICMe-nIA&s=LkCxNJyFaoVIBzQ9JqTXU_fxmDE1Z366 mOozgyGbT28&e= n.pdf. To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board¹s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc. 3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a ³no formal objection rule² (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)? It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy. Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN¹s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board¹s implementation action e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support. Let me repeat again what I said at the outset nothing prevents the GAC from ³intervening² through debate, discussion, persuasion, advice or any other non-decisional role. 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://neustar.biz> <http://www.neustar.biz> _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma n_listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDAL C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bK yEaf_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUV E&e= _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org> https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman _listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDALC_ lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bKyEa f_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUVE&e= _______________________________________________ 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 _______________________________________________ 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
The amendment is accepted :-)-O el On 2016-02-07 15:27 , Paul Rosenzweig wrote:
I agree too, with the friendly amendment that it isn’t the “GAC” that is using the tactic, but merely a small minority of vocal GAC members who hope we will mistake their opposition for GAC opposition …
Paul [...]
*From:*Dr Eberhard W Lisse [mailto:epilisse@gmail.com] *Sent:* Sunday, February 7, 2016 12:23 AM *To:* CCWG Accountability <accountability-cross-community@icann.org> *Cc:* Lisse Eberhard <directors@omadhina.NET> *Subject:* Re: [CCWG-ACCT] Responses to Rafael's Questions
I fully agree.
GAC is an AC, not an SO, but receives deference to consensus advice.
It obviously wants more influence. But that is not an accountability measure that must be in place before the transition can take.
it does have however have to potential to break the Arasteh/Burr Compromise and the Consensus that we seem to have for it.
It strikes me as the classic tactic from Negotiation 101: "Always ask for more" :-)-O
--
Sent from Dr Lisse's iPad mini 4
On 7 Feb 2016, at 01:30, Robin Gross <robin@ipjustice.org <mailto:robin@ipjustice.org>> wrote:
I think it is worth considering the extent to which providing GAC with decisional authority over ICANN’s governance violates ICANN’s Articles of Organization and Bylaws, which require it to operate in an accountable and transparent way.
This was certainly a significant issue in the last summer's .africa IRP ruling, where the panel found that GAC breached its obligations to act transparently and equitably in accordance with ICANN’s Articles and Bylaws. The panel found that as a constituent body of ICANN, the GAC (and the board) had a legal obligation to act transparently and equitably, and they did not, creating a breach of ICANN’s Articles and Bylaws.
What we are doing here is providing this particular constituent body of ICANN, which has no transparency requirements nor track record of transparency with equal decisional authority in Rec 1 and greater decisional authority in Rec 11 than those constituent parts of ICANN which are required to act transparently, such as the GNSO. This is another fundamental flaw in the proposal.
Similarly, there is nothing that requires GAC to be “bottom-up” in its membership. Democratic and non-democratic governments are welcome in the GAC without distinction. Perhaps that was fine when GAC was purely advisory, but now that it will be provided decisional authority on so-called “equal footing” with those constituent parts of ICANN that are required to be operated in a bottom-up and democratic manner, it becomes a significant problem and major adjustment in the fundamental model of Internet governance, which itself becomes less democratic of a model.
GAC has not even been able to agree that it */wants/* this major shift in its role and the change to the multi-stakeholderism governance model that comes with it. If it can’t do that, those the parts of Recs 1 & 11 that enhance GAC’s power need to go. Otherwise ICANN risks violating its own Articles and Bylaws by significantly empowering the part of it, which is not required to be transparent, accountable, or bottom-up as mandated by these legal instruments.
Robin
On Feb 6, 2016, at 3:03 PM, Burr, Becky <Becky.Burr@neustar.biz <mailto:Becky.Burr@neustar.biz>> wrote:
Rafael, with all due respect I have explained in great detail why a PDP and GAC Advice cannot be compared. Here is my explanation again: **********************
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://neustar.biz> <http://www.neustar.biz>
On 2/6/16, 1:39 PM, "Jorge.Cancio@bakom.admin.ch <mailto:Jorge.Cancio@bakom.admin.ch>" <Jorge.Cancio@bakom.admin.ch <mailto:Jorge.Cancio@bakom.admin.ch>> wrote:
Dear all
Perhaps we shall remind ourselves that every SO and every AC has a legitimate role within the development of policies and their implementation within ICANN.
And all these roles are different but equally necessary, in their specific form, for the develpment of such policies and their implementation.
Some develop policies and others give advice, all according to the existing rules of ICANN, which lay out its specific model of multistakeholder collaboration.
Our work here in the ccwg has not been, and is not, according to our charter, to change this model.
We have been tasked, as I have been understanding our work, to develop new accountability measures, primarily directed to establish means for the community to check the workings of ICANN as an organization.
And in this new community empowerment framework we have agreed from the beginning that all SO/AC willing to participate should be treated equally - that they should have an equal footing.
Any compromise we may find during these last days must be consistent with this principle, supported repeatedly in public comment periods.
Best
Jorge
Von meinem iPhone gesendet
Am 06.02.2016 um 19:06 schrieb James M. Bladel <jbladel@godaddy.com <mailto:jbladel@godaddy.com>>:
Given the very different roles & natures of SO¹s versus ACs, this comparison of voting thresholds doesn¹t make sense.
J.
On 2/6/16, 4:29 , "accountability-cross-community-bounces@icann.org <mailto:accountability-cross-community-bounces@icann.org> on behalf of Perez Galindo, Rafael" <accountability-cross-community-bounces@icann.org <mailto:accountability-cross-community-bounces@icann.org> on behalf of RPEREZGA@minetur.es <mailto:RPEREZGA@minetur.es>> wrote:
Dear Becky,
Your proposal establishes that there are situations where the GAC would be excluded from participating in specific considerations, since it is ³unique² in its capacity to compel the Board to negociate, even if at the end the Board is free to make their decision.
I kindly ask for clarification on the ³uniqueness² of the GAC, since ICANN Bylaws Annex A Section 9 on GNSO PDP process establish that the board needs a 2/3 majority to go against the GNSO recommendation approved by supermajority AND that the Board shall engage in a ³discussion² with the Council (letters c and d), that could end up again with another voting from the Board to reject the new GNSO recommendation by 2/3.
In the same vein, as regards Annex B and the ccNSO PDP, the Board and the Council shall discuss ³in good faith and in a timely and efficient manner, to find a mutually acceptable solution³.
In conclusion, for the very same reason, namely avoid the ³two bites at the apple² situation, it could be argued that if the GAC should be singled out to be carved out, the terms for carving out other SO/ACs should as well be established.
Looking forward to hearing others' views, and apologies in advance if I have misunderstood the processes above described.
Best Rafael
________________________________________ From: Perez Galindo, Rafael Sent: 05 February 2016 22:31 To: Burr, Becky; Accountability Community Subject: Re: [CCWG-ACCT] Responses to Rafael's Questions
Thank you Becky for kindly answering my questions, much appreciated.
I hope to get back to you with further comments as I proceed with internal consultations.
I only would like to draw your attention now to the fact that your proposal, in its broad scope now clearly defined (and apologies here if some of us understood that you were referring to a limited scope), is essentially different from the discussions on ST 18 that we all have been having during the last year. This addition to the package is not related to percentages nor thresholds anymore, nor how the Board may react to GAC advice (remember this and only this was the reason why Steve del Bianco put forward ST 18!!) , but goes far beyond, as it actually regulates the access of the GAC to the EC.
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
Best Rafael
Sent from a mobile device. Please excuse any typos. -------- Original message -------- From: "Burr, Becky" Date:05/02/2016 19:04 (GMT+01:00) To: Accountability Community Subject: [CCWG-ACCT] Responses to Rafael's Questions
I am going to attempt to respond to Rafael¹s questions, below. This is a long post, so apologies in advance.
I¹d like to start out by saying that my proposal does not in any way prevent the GAC from participating in any community discussion whatsoever, or from continuing to provide advice on public policy matters whenever and however it chooses. Rather, the compromise would limit the GAC¹s ability to participate as a decision-maker in the very limited situation in which the community takes exception to the Board¹s implementation of GAC Advice and a community discussion is initiated to explore use of a community power to challenge the Board¹s action. Even in those limited situations where the carve out would apply, the GAC is still able to participate in discussion, to engage in advocacy, to persuade, to issue more advice, etc. The only impact is that at the end of the day the GAC would not count towards the thresholds necessary to block or support exercise of the relevant power. So please, do not say that anyone is trying to silence the GAC or to in any way limit its current authority.
Rafael¹s questions appear in blue italic below, and my answers follow:
1. We have previously discussed it, but we still fail to understand why this ³carve-out² is only applicable to the GAC. If this measure is foreseen to avoid the ³two-bites-at-the-apple² situation, for instance the GNSO is as well in a position of being ³judge and part² when it comes to decisions of the Board based on a PDP. In these cases, the GNSO is part (has proposed a policy and the Board has accepted it) and judge (through its participation in the EC, it can participate through its vote in the rejecting of the challenge to this policy). This situation is unfair to the rest of SO/ACs. What are the reasons for such a privilege? In this vein, although the GAC has a ³mutually agreeable procedure to TRY to find a solution², it CANNOT force the Board to act according to its advice, therefore a Board decision based on GAC Advice is as free as a Board decision based on GNSO or CCNSO PDP or GNSO Guidance (all three with a 2/3 threshold for rejection by ICANN Board). Why is the GAC singled out then?
I have previously explained this, as have others on the calls and in the chat. My previous response follows. The fact is that the Board¹s obligation to work to try to find a mutually agreeable solution before rejecting GAC Advice gives the GAC both a formidable and unique power to stop a process in its tracks and compel the Board to negotiate. The fact that in the end a mutually acceptable solution may not be found does not change the nature of that power. And GAC advice is not constrained in any material way it can involve any topic with ³public policy² implications, and it can be issued at any time before, during, or after a policy development process has concluded, and indeed midway during implementation of such policy. No other SO or AC has that authority. The GAC is singled out because it, and it alone, has this authority.
My previous response to this same question from Jorge follows:
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.
2. If this ³carve-out² were to be accepted, how would the exclusion of the GAC from a community decision-making process be triggered? Who would decide on such things? Who would control the legality of such a decision? The carve-out refers generically to ³Board decisions² to ³implement GAC advice². But we need to bear in mind that Board decisions very often rely on many different inputs for any decision (a PDP, advice from advisory committees, including the GAC, legal advice, etc.), and rarely only stem exclusively from GAC advice. Would this ³carve-out² mean that where there is a Board decision based on such multiple sources, only one of them being a GAC advice, the GAC would be excluded from any community power related to such a Board decision? How do we make sure that if such a ³carve-out² is accepted it has not these effects, and ONLY applies when the Board acts based ONLY on GAC advice?
This seems fairly straightforward. The GAC keeps a ³scorecard² regarding the Board¹s handling of GAC Advice. GAC Advice is listed and tracked. ICANN tracks its responses formally. See, for example,
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_en_sy stem_files_files_gac-2Dadvice-2Dscorecard-2D07oct15-2De&d=CwIF-g&c=MOptN lVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn 5PbwQ801bKyEaf_KkbWRX6C6Ri6uiICMe-nIA&s=LkCxNJyFaoVIBzQ9JqTXU_fxmDE1Z366 mOozgyGbT28&e= n.pdf. To the extent that other organizations have provided similar advice, they have not had the opportunity to compel the Board to the negotiation table with respect to that advice. In such cases, they could still participate in the decision making process in an effort to block exercise of a community power challenging the Board¹s implementation of GAC Advice if, for example, they happened to agree with that Advice and/or thought the way the Board implemented that Advice was appropriate, etc.
3. What happens if a Board decision is based on GAC advice which in turn is based on international law, relevant national law and/or important reasons of public policy? We should remember that under Rec11 GAC will be obliged to act under a ³no formal objection rule² (full consensus). Should the community be able to overturn such a Board decision without giving the possibility to the GAC to intervene in such a process (based on a GAC consensus)?
It is not the case now, nor has it ever been the case that the position of the GAC will prevail simply because it asserts that its views are mandated by international law, relevant national law, and/or important reasons of public policy.
Now, and in the future, the Board must make this call in the first instance, subject to applicable law and in light of ICANN¹s Mission, Commitments & Core Values. If enough of the community thinks the Board got it wrong, it has the right to challenge the Board¹s implementation action e.g., by rejecting a proposed Bylaws change, by bringing an IRP, or ultimately, by recalling the Board. Throughout this, the Board, the GAC, SOs, other ACs, etc. will have the opportunity to make their respective cases. The thresholds for the exercise of community powers have been deliberately set to require broad support.
Let me repeat again what I said at the outset nothing prevents the GAC from ³intervening² through debate, discussion, persuasion, advice or any other non-decisional role. 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://neustar.biz><http://www.neustar.biz> _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailma n_listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDAL C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bK yEaf_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUV E&e=
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <mailto:Accountability-Cross-Community@icann.org>
https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman _listinfo_accountability-2Dcross-2Dcommunity&d=CwIF-g&c=MOptNlVtIETeDALC_ lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=CSDCBn5PbwQ801bKyEa f_KkbWRX6C6Ri6uiICMe-nIA&s=RAYjW5JTG_cSQEiQvVVyKvzyUbLW4LDMxNQOcqNJUVE&e=
_______________________________________________ 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
_______________________________________________ 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
-- Dr. Eberhard W. Lisse 4-5 St Annes Walk, Alderney <directors@omadhina.net> Guernsey, GY9 3JZ Omadhina Internet Services Ltd British Channel Islands
Hi, On Fri, Feb 05, 2016 at 09:31:03PM +0000, Perez Galindo, Rafael wrote:
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
I agree it should be carefully analysed and contemplated, but that analysis and contemplation should take place before the next call not dedicated to Rec. 11 (my calendar seems to think that's Tuesday). The CCWG needs to come to a close and ship something -- even a report out that there's no solution would be better than more delay. There is simply no more time to dither. The transition (or its failure) is waiting on this CCWG's output. The operational communities need to know what their next available range(s) of action will be. Moreover, if the GAC really cannot accept this proposed compromise, it seems at least to me that the hope of any compromise ever being reached is roughly zero. Therefore, the CCWG members should vote on something and move on. I vastly prefer consensus, but in the community where I usually work we would have declared this consensus rough some time ago and closed the discussion. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Dear Andrew, I fully understand your frustration as I am aware that Parameter and Number commnuities which have provided their reponse to transition to ICG more about 13 month agoare anxiously waitng for the CCWG.- tHIER PATIENCE HAS LIMIT. tHE PROCESS IS too SLOW But let us try to find a convincing responce to Rafael and Jorge Regards Kavouss 2016-02-06 19:53 GMT+01:00 Andrew Sullivan <ajs@anvilwalrusden.com>:
Hi,
On Fri, Feb 05, 2016 at 09:31:03PM +0000, Perez Galindo, Rafael wrote:
For that reason, I believe it should be very carefully analyzed and
assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
I agree it should be carefully analysed and contemplated, but that analysis and contemplation should take place before the next call not dedicated to Rec. 11 (my calendar seems to think that's Tuesday).
The CCWG needs to come to a close and ship something -- even a report out that there's no solution would be better than more delay. There is simply no more time to dither. The transition (or its failure) is waiting on this CCWG's output. The operational communities need to know what their next available range(s) of action will be.
Moreover, if the GAC really cannot accept this proposed compromise, it seems at least to me that the hope of any compromise ever being reached is roughly zero. Therefore, the CCWG members should vote on something and move on. I vastly prefer consensus, but in the community where I usually work we would have declared this consensus rough some time ago and closed the discussion.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I have to agree with Andrew on this, this is a topic we can debate for weeks on end. We need to move forward. -jg On 06/02/2016, 6:53 p.m., "accountability-cross-community-bounces@icann.org on behalf of Andrew Sullivan" <accountability-cross-community-bounces@icann.org on behalf of ajs@anvilwalrusden.com> wrote:
Hi,
On Fri, Feb 05, 2016 at 09:31:03PM +0000, Perez Galindo, Rafael wrote:
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
I agree it should be carefully analysed and contemplated, but that analysis and contemplation should take place before the next call not dedicated to Rec. 11 (my calendar seems to think that's Tuesday).
The CCWG needs to come to a close and ship something -- even a report out that there's no solution would be better than more delay. There is simply no more time to dither. The transition (or its failure) is waiting on this CCWG's output. The operational communities need to know what their next available range(s) of action will be.
Moreover, if the GAC really cannot accept this proposed compromise, it seems at least to me that the hope of any compromise ever being reached is roughly zero. Therefore, the CCWG members should vote on something and move on. I vastly prefer consensus, but in the community where I usually work we would have declared this consensus rough some time ago and closed the discussion.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
All, As I have respectfully noted several times, and will reiterate again...the GAC as a whole has taken no position on Rec-1 and Rec-11 and is highly unlikely to do so. There simply is not consensus within the GAC on these issues. The Arasteh/Burr proposal is as close as we're likely to get to a compromise that will not be rejected by any Chartering Org and will be acceptable to NTIA and Congress. This is it. It's time to finalize this work and deliver a proposal to the Chartering Organizations so we can meet the Marrakech deadline for approval. Regards, Keith Sent from my iPhone
On Feb 6, 2016, at 2:17 PM, James Gannon <james@cyberinvasion.net> wrote:
I have to agree with Andrew on this, this is a topic we can debate for weeks on end. We need to move forward.
-jg
On 06/02/2016, 6:53 p.m., "accountability-cross-community-bounces@icann.org on behalf of Andrew Sullivan" <accountability-cross-community-bounces@icann.org on behalf of ajs@anvilwalrusden.com> wrote:
Hi,
On Fri, Feb 05, 2016 at 09:31:03PM +0000, Perez Galindo, Rafael wrote:
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
I agree it should be carefully analysed and contemplated, but that analysis and contemplation should take place before the next call not dedicated to Rec. 11 (my calendar seems to think that's Tuesday).
The CCWG needs to come to a close and ship something -- even a report out that there's no solution would be better than more delay. There is simply no more time to dither. The transition (or its failure) is waiting on this CCWG's output. The operational communities need to know what their next available range(s) of action will be.
Moreover, if the GAC really cannot accept this proposed compromise, it seems at least to me that the hope of any compromise ever being reached is roughly zero. Therefore, the CCWG members should vote on something and move on. I vastly prefer consensus, but in the community where I usually work we would have declared this consensus rough some time ago and closed the discussion.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Agree Keith. ________________________________ Brett Schaefer Jay Kingham Senior Research Fellow in International Regulatory Affairs Margaret Thatcher Center for Freedom Davis Institute for National Security and Foreign Policy The Heritage Foundation 214 Massachusetts Avenue, NE Washington, DC 20002 202-608-6097 heritage.org<http://heritage.org/> __________ On Feb 6, 2016, at 2:56 PM, Drazek, Keith <kdrazek@verisign.com<mailto:kdrazek@verisign.com>> wrote: All, As I have respectfully noted several times, and will reiterate again...the GAC as a whole has taken no position on Rec-1 and Rec-11 and is highly unlikely to do so. There simply is not consensus within the GAC on these issues. The Arasteh/Burr proposal is as close as we're likely to get to a compromise that will not be rejected by any Chartering Org and will be acceptable to NTIA and Congress. This is it. It's time to finalize this work and deliver a proposal to the Chartering Organizations so we can meet the Marrakech deadline for approval. Regards, Keith Sent from my iPhone
On Feb 6, 2016, at 2:17 PM, James Gannon <james@cyberinvasion.net<mailto:james@cyberinvasion.net>> wrote:
I have to agree with Andrew on this, this is a topic we can debate for weeks on end. We need to move forward.
-jg
On 06/02/2016, 6:53 p.m., "accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> on behalf of Andrew Sullivan" <accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> on behalf of ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com>> wrote:
Hi,
On Fri, Feb 05, 2016 at 09:31:03PM +0000, Perez Galindo, Rafael wrote:
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
I agree it should be carefully analysed and contemplated, but that analysis and contemplation should take place before the next call not dedicated to Rec. 11 (my calendar seems to think that's Tuesday).
The CCWG needs to come to a close and ship something -- even a report out that there's no solution would be better than more delay. There is simply no more time to dither. The transition (or its failure) is waiting on this CCWG's output. The operational communities need to know what their next available range(s) of action will be.
Moreover, if the GAC really cannot accept this proposed compromise, it seems at least to me that the hope of any compromise ever being reached is roughly zero. Therefore, the CCWG members should vote on something and move on. I vastly prefer consensus, but in the community where I usually work we would have declared this consensus rough some time ago and closed the discussion.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com<mailto:ajs@anvilwalrusden.com> _______________________________________________ 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://mm.icann.org/mailman/listinfo/accountability-cross-community>
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://mm.icann.org/mailman/listinfo/accountability-cross-community>
_______________________________________________ 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://mm.icann.org/mailman/listinfo/accountability-cross-community>
Well said Jonathan Zuck President ACT: The App Association On Sat, Feb 6, 2016 at 11:55 AM -0800, "Drazek, Keith" <kdrazek@verisign.com<mailto:kdrazek@verisign.com>> wrote: All, As I have respectfully noted several times, and will reiterate again...the GAC as a whole has taken no position on Rec-1 and Rec-11 and is highly unlikely to do so. There simply is not consensus within the GAC on these issues. The Arasteh/Burr proposal is as close as we're likely to get to a compromise that will not be rejected by any Chartering Org and will be acceptable to NTIA and Congress. This is it. It's time to finalize this work and deliver a proposal to the Chartering Organizations so we can meet the Marrakech deadline for approval. Regards, Keith Sent from my iPhone
On Feb 6, 2016, at 2:17 PM, James Gannon <james@cyberinvasion.net> wrote:
I have to agree with Andrew on this, this is a topic we can debate for weeks on end. We need to move forward.
-jg
On 06/02/2016, 6:53 p.m., "accountability-cross-community-bounces@icann.org on behalf of Andrew Sullivan" <accountability-cross-community-bounces@icann.org on behalf of ajs@anvilwalrusden.com> wrote:
Hi,
On Fri, Feb 05, 2016 at 09:31:03PM +0000, Perez Galindo, Rafael wrote:
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
I agree it should be carefully analysed and contemplated, but that analysis and contemplation should take place before the next call not dedicated to Rec. 11 (my calendar seems to think that's Tuesday).
The CCWG needs to come to a close and ship something -- even a report out that there's no solution would be better than more delay. There is simply no more time to dither. The transition (or its failure) is waiting on this CCWG's output. The operational communities need to know what their next available range(s) of action will be.
Moreover, if the GAC really cannot accept this proposed compromise, it seems at least to me that the hope of any compromise ever being reached is roughly zero. Therefore, the CCWG members should vote on something and move on. I vastly prefer consensus, but in the community where I usually work we would have declared this consensus rough some time ago and closed the discussion.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
+1 Time to wrap this up. On 06/02/2016 14:48, Jonathan Zuck wrote:
Well said
Jonathan Zuck President ACT: The App Association
On Sat, Feb 6, 2016 at 11:55 AM -0800, "Drazek, Keith" <kdrazek@verisign.com <mailto:kdrazek@verisign.com>> wrote:
All,
As I have respectfully noted several times, and will reiterate again...the GAC as a whole has taken no position on Rec-1 and Rec-11 and is highly unlikely to do so. There simply is not consensus within the GAC on these issues. The Arasteh/Burr proposal is as close as we're likely to get to a compromise that will not be rejected by any Chartering Org and will be acceptable to NTIA and Congress. This is it. It's time to finalize this work and deliver a proposal to the Chartering Organizations so we can meet the Marrakech deadline for approval.
Regards, Keith
Sent from my iPhone
On Feb 6, 2016, at 2:17 PM, James Gannon <james@cyberinvasion.net> wrote:
I have to agree with Andrew on this, this is a topic we can debate for weeks on end. We need to move forward.
-jg
On 06/02/2016, 6:53 p.m., "accountability-cross-community-bounces@icann.org on behalf of Andrew Sullivan" <accountability-cross-community-bounces@icann.org on behalf of ajs@anvilwalrusden.com> wrote:
Hi,
On Fri, Feb 05, 2016 at 09:31:03PM +0000, Perez Galindo, Rafael wrote:
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
I agree it should be carefully analysed and contemplated, but that analysis and contemplation should take place before the next call not dedicated to Rec. 11 (my calendar seems to think that's Tuesday).
The CCWG needs to come to a close and ship something -- even a report out that there's no solution would be better than more delay. There is simply no more time to dither. The transition (or its failure) is waiting on this CCWG's output. The operational communities need to know what their next available range(s) of action will be.
Moreover, if the GAC really cannot accept this proposed compromise, it seems at least to me that the hope of any compromise ever being reached is roughly zero. Therefore, the CCWG members should vote on something and move on. I vastly prefer consensus, but in the community where I usually work we would have declared this consensus rough some time ago and closed the discussion.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Matthew Shears | Director, Global Internet Policy & Human Rights Project Center for Democracy & Technology | cdt.org E: mshears@cdt.org | T: +44.771.247.2987 CDT's Annual Dinner, Tech Prom, is April 6, 2016. Don't miss out - register at cdt.org/annual-dinner. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
+ 1. I think Keith's post captures the situation very well. Just to also share that we discussed it in the ASO and we would not be opposed to Kavouss + Becky proposal. Izumi On 2016/02/07 10:10, Matthew Shears wrote:
+1 Time to wrap this up.
On 06/02/2016 14:48, Jonathan Zuck wrote:
Well said
Jonathan Zuck President ACT: The App Association
On Sat, Feb 6, 2016 at 11:55 AM -0800, "Drazek, Keith" <kdrazek@verisign.com <mailto:kdrazek@verisign.com>> wrote:
All,
As I have respectfully noted several times, and will reiterate again...the GAC as a whole has taken no position on Rec-1 and Rec-11 and is highly unlikely to do so. There simply is not consensus within the GAC on these issues. The Arasteh/Burr proposal is as close as we're likely to get to a compromise that will not be rejected by any Chartering Org and will be acceptable to NTIA and Congress. This is it. It's time to finalize this work and deliver a proposal to the Chartering Organizations so we can meet the Marrakech deadline for approval.
Regards, Keith
Sent from my iPhone
On Feb 6, 2016, at 2:17 PM, James Gannon <james@cyberinvasion.net> wrote:
I have to agree with Andrew on this, this is a topic we can debate for weeks on end. We need to move forward.
-jg
On 06/02/2016, 6:53 p.m., "accountability-cross-community-bounces@icann.org on behalf of Andrew Sullivan" <accountability-cross-community-bounces@icann.org on behalf of ajs@anvilwalrusden.com> wrote:
Hi,
On Fri, Feb 05, 2016 at 09:31:03PM +0000, Perez Galindo, Rafael wrote:
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
I agree it should be carefully analysed and contemplated, but that analysis and contemplation should take place before the next call not dedicated to Rec. 11 (my calendar seems to think that's Tuesday).
The CCWG needs to come to a close and ship something -- even a report out that there's no solution would be better than more delay. There is simply no more time to dither. The transition (or its failure) is waiting on this CCWG's output. The operational communities need to know what their next available range(s) of action will be.
Moreover, if the GAC really cannot accept this proposed compromise, it seems at least to me that the hope of any compromise ever being reached is roughly zero. Therefore, the CCWG members should vote on something and move on. I vastly prefer consensus, but in the community where I usually work we would have declared this consensus rough some time ago and closed the discussion.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I disagree, the charter does does not say, ship something, anything, to make the transition happen, it says what accountability measures must happen so that (before) the transition can happen, and which ones can wait until after it has happened. el -- Sent from Dr Lisse's iPad mini 4
On 6 Feb 2016, at 20:53, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
Hi,
On Fri, Feb 05, 2016 at 09:31:03PM +0000, Perez Galindo, Rafael wrote:
For that reason, I believe it should be very carefully analyzed and assessed, from an implementing and legal POV. Such a decision cannot be taken in a rush, without considering its consequences and possible side effects.
I agree it should be carefully analysed and contemplated, but that analysis and contemplation should take place before the next call not dedicated to Rec. 11 (my calendar seems to think that's Tuesday).
The CCWG needs to come to a close and ship something -- even a report out that there's no solution would be better than more delay. There is simply no more time to dither. The transition (or its failure) is waiting on this CCWG's output. The operational communities need to know what their next available range(s) of action will be.
Moreover, if the GAC really cannot accept this proposed compromise, it seems at least to me that the hope of any compromise ever being reached is roughly zero. Therefore, the CCWG members should vote on something and move on. I vastly prefer consensus, but in the community where I usually work we would have declared this consensus rough some time ago and closed the discussion.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On Sun, Feb 07, 2016 at 07:14:09AM +0200, Dr Eberhard W Lisse wrote:
the charter does does not say, ship something, anything, to make the transition happen, it says what accountability measures must happen so that (before) the transition can happen, and which ones can wait until after it has happened.
That's nice. But I would like someone to tell me a plausible story under which this CCWG doesn't ship something such that the transition happens, and yet the desired accountability measures happen. Or, for that matter, where IANA holds together. Let us not delude ourselves into thinking that the rest of the world believes ICANN is a critical institution. The three operational communities -- one of them part of ICANN! -- have all come up with a mechanism in which ICANN and IANA are separated. If the ICANN community cannot find a way to satisfy itself that it has the accountability measures it needs, then the obvious answer is to find some other way to achieve the IANA functions. Having already imagined it, we can certainly reach that outcome. Yet the operational communities all express satisfaction to date with ICANN's performance. I think it'd be a shameful negligence of our duty were we to allow satisfied communities to go seek other options just because we squabble. But I think we should not be sangine that IANA will remain untouched if we should fail to deliver. The community pressures are too great. Something will change. We can be responsible enablers of that change, or we can stand by stupefied while it happens. That is up to us. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Yeah, right, toss all accountability, make it happen. Not. el -- Sent from Dr Lisse's iPad mini 4
On 7 Feb 2016, at 07:45, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Sun, Feb 07, 2016 at 07:14:09AM +0200, Dr Eberhard W Lisse wrote:
the charter does does not say, ship something, anything, to make the transition happen, it says what accountability measures must happen so that (before) the transition can happen, and which ones can wait until after it has happened.
That's nice. But I would like someone to tell me a plausible story under which this CCWG doesn't ship something such that the transition happens, and yet the desired accountability measures happen. Or, for that matter, where IANA holds together.
Let us not delude ourselves into thinking that the rest of the world believes ICANN is a critical institution. The three operational communities -- one of them part of ICANN! -- have all come up with a mechanism in which ICANN and IANA are separated. If the ICANN community cannot find a way to satisfy itself that it has the accountability measures it needs, then the obvious answer is to find some other way to achieve the IANA functions. Having already imagined it, we can certainly reach that outcome. Yet the operational communities all express satisfaction to date with ICANN's performance.
I think it'd be a shameful negligence of our duty were we to allow satisfied communities to go seek other options just because we squabble. But I think we should not be sangine that IANA will remain untouched if we should fail to deliver.
The community pressures are too great. Something will change. We can be responsible enablers of that change, or we can stand by stupefied while it happens. That is up to us.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On Sun, Feb 07, 2016 at 07:59:18AM +0200, Dr Eberhard W Lisse wrote:
Yeah, right, toss all accountability, make it happen.
Not.
Really? What's your leverage? Suppose that this CCWG does not deliver next week, such that there is a report that can be adopted by the chatering organizations no later that Marrakech. In that case, what reason does the board have to adopt even one resolution making any of the proposed changes? If your answer is, "Too much pent up demand," then explain to me how the same demand doesn't lead the rest of the interested world to decide ICANN is too broken to be reformed, and to route around the damage it represents. We are no longer free to fail and be ignored. Either we deliver, or ICANN's internal processes are revealed to be fruitlessly ineffective. Let's not pretend. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
Leverage? Interesting. I was asked to to it right. Implicitly by being appointed to this CCWG Accountability. And I feel it is as legitimate to look out for the smaller ccTLDs' interests as for business' or governments'. If ICANN's processes are effective or not. I know they have never been and are not. But that does not mean the end justifies the means. el -- Sent from Dr Lisse's iPad mini 4
On 7 Feb 2016, at 08:33, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
On Sun, Feb 07, 2016 at 07:59:18AM +0200, Dr Eberhard W Lisse wrote: Yeah, right, toss all accountability, make it happen.
Not.
Really?
What's your leverage? Suppose that this CCWG does not deliver next week, such that there is a report that can be adopted by the chatering organizations no later that Marrakech.
In that case, what reason does the board have to adopt even one resolution making any of the proposed changes?
If your answer is, "Too much pent up demand," then explain to me how the same demand doesn't lead the rest of the interested world to decide ICANN is too broken to be reformed, and to route around the damage it represents.
We are no longer free to fail and be ignored. Either we deliver, or ICANN's internal processes are revealed to be fruitlessly ineffective. Let's not pretend.
Best regards,
A
-- Andrew Sullivan ajs@anvilwalrusden.com _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
There may be some details which may not satisfy everyone's needs 100%, but overall, I see that we are heading towards finalising the proposal which enhances ICANN's accountability than it is today. I think we are very close to completing the proposal. Now is the time to think of a pragmatic way forward to complete it. Izumi On 2016/02/07 16:06, Dr Eberhard W Lisse wrote:
Leverage?
Interesting.
I was asked to to it right. Implicitly by being appointed to this CCWG Accountability.
And I feel it is as legitimate to look out for the smaller ccTLDs' interests as for business' or governments'.
If ICANN's processes are effective or not. I know they have never been and are not.
But that does not mean the end justifies the means.
el
participants (21)
-
Andrew Sullivan -
Burr, Becky -
Carlos Raúl Gutiérrez G. -
Dr Eberhard W Lisse -
Dr Eberhard W Lisse -
Drazek, Keith -
Eric (Maule) Brunner-Williams -
Izumi Okutani -
James Gannon -
James M. Bladel -
Jonathan Zuck -
Jorge.Cancio＠bakom.admin.ch -
Kavouss Arasteh -
Mark Carvell -
Matthew Shears -
Olga Cavalli -
Paul Rosenzweig -
Perez Galindo, Rafael -
Robin Gross -
Schaefer, Brett -
Seun Ojedeji