November 2015 - Accountability-Cross-Community

Comments on the third draft proposal
by George Sadowsky Nov. 13, 2015

Nov. 13, 2015

Those of us in Joao Pessoa are fully aware of the utter ridiculousness of this deadline, and I trust that it will be rescinded in favor of something more reasonable. Note that there is no way that I, or for that matter most everyone else, can read this carefully in the next two hours with everything that is going on here. I learned about this deadline by accident, with only two hours to the deadline. Soon after I found a quiet place to start reading the document, the convention center crew arrived and started to disassemble the room around me, including the chair and table that I was using. Other members of the ICANN Board and staff are so occupied with other activities that they may not even know about the deadline. As personal comments, I suggest the following: 1. The final text of the mission statement is uncertain. In order to contribute to the success of both the transition and the post-transition activities of ICANN, it has to satisfy multiple masters, and it is unclear to me that we are near convergence on what that text should be. I have no concrete suggestions to make, but I know that serious work is underway. 2. There still seems to be some serious disagreement regarding a number of items as to what should be put in WS1 and WS2 respectively. 3. I agree with Bruce Tonkin that the Board is likely to approach items in WS2 in a manner similar to our approach to items in WS1. However, IMHO the content of WS2 cannot be open ended and, inter alia, satisfy the requirement for simplicity and completeness that has been repeatedly mentioned by NTIA, as well as other objections to such open endedness and the presumption of automatic acceptance. [The second room that I found in which to work is now being disassembled from under me] 4. I note that the number of ACs and SOs required to dismiss the entire Board has remained at four in spite of comments suggesting that this may incompatible with the "one objection is not sufficient" "principle" depending upon the GAC's decision to enter or not enter a council. I support this decision to make no change in this threshold. Time has run out. I suggest that the inclusiveness and legitimacy of this step in the accountability process is jeopardized, if not completely destroyed, unless a new and more realistic deadline is set for comments on the third draft of this new document. George

3 4

Re: [CCWG-ACCT] CCWG - Draft Update document for CCWG call
by Alan Greenberg Nov. 13, 2015

Nov. 13, 2015

I was part of the breakout session that made this recommendation. It was a reaction to the comments that ICANN is a closed community and that we are not open to input from "outsiders". There did not seem to be any harm, and did have some benefits in allowing anyone to initiate the process which then needed to be ratified by the AC/SO involved. Clearly if an AC/SO is flooded with such requests, there would be a problem, but that (correctly or not) was not envissioned. Alan At 13/11/2015 01:25 PM, Greg Shatan wrote: >It does not limit who can start that petition. As such, Justin >Bieber could start a petition

1 0

Re: [CCWG-ACCT] Implications of bottom-up "policy" requirement
by Alan Greenberg Nov. 13, 2015

Nov. 13, 2015

No, they should. But we need to be careful that our existing contracts are not destroyed. What is deemed to be a "policy" can be very wide and the majority of our current contracts were not created by consensus policy (nor can they ever be under the terms of Spec 1/4). Alan At 13/11/2015 01:27 PM, Seun Ojedeji wrote: >".... and, when they alter existing contracts >must be developed through a bottom-up, >consensus-based multistakeholder process." > >Does the above imply that other policies that >does not alter existing contracts should/may not >go through MS process? I hope that's not what is intended > >Regards > >Sent from my Asus Zenfone2 >Kindly excuse brevity and typos. >On 13 Nov 2015 19:12, "Alan Greenberg" ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca> wrote: >On review, the change is not quite that simple, >partly because in the current version, the first bullet does not make sense. >removing the extraneous punctuation for just the >first bullet we have: "In this role, with >respect to domain names, ICANNâs Mission is to >coordinate the development and implementation of >policies for which uniform or coordinated >resolution is reasonably necessary to facilitate >the openness, interoperability, resilience, >security and/or stability of the DNS" >I do not think that "uniform and coordinated >resolution of policies" makes sense. I think it >was meant to say that the policies allow uniform >and coordinated resolution of names, not the policies them selves. >Perhaps the following works. >In this role, with respect to domain names, >ICANNâs Mission is to coordinate the >development and implementation of policies which >allow the necessary uniform or coordinated >resolution to facilitate the openness, >interoperability, resilience, security and/or >stability of the DNS. Such policies must be >designed to ensure the stable and secure >operation of the Internetâs unique names >systems and, when they alter existing contracts >must be developed through a bottom-up, >consensus-based multistakeholder process. >Alan > > > > > > > > > > > >At 13/11/2015 12:13 PM, Alan Greenberg wrote: >Good question. Let me look at the original version again. Alan >At 13/11/2015 10:48 AM, David Post wrote: >At 09:45 AM 11/13/2015, Alan Greenberg wrote: >I would like to propose a solution to this problem. >The current proposal is that policies (without >being specific) be developed by a bottom-up MS process. >I suggest that we replace "policy' by "Consensus >Policy". This is a term already used in the >Bylaws and is applicable to both the Registry and Registrar contracts. >If, as my original scenario envisions, that such >a policy is struck down, then it may be >re-crafted (or not!) using the established By-Law mandated processes. > > >Alan >Can you clarify what you mean when you propose >replacing "policy" with "Consensus >Policy"? Just substituting the words "Consensus >Policy" for "policy" in the proposal language looks like this: > >"ICANN's Mission is to coordinate the >development and implementation of Consensus >Policies: . For which uniform or coordinated >resolution is reasonably necessary to facilitate >the openness, interoperability, resilience, >security and/or stability: . That are developed >through a bottom-up, consensus-based >multistakeholder process and designed to ensure >the stable and secure operation of the Internet's unique names system." > >Is that what you're proposing? >David > > >At 12/11/2015 04:38 PM, Burr, Becky wrote: >But why isnÂ¡Â¯t the answer that it is a part of a non-policy provision of a >commercial contract entered into in furtherance of ICANNÂ¡Â¯s mission? > > >J. Beckwith Burr >Neustar, Inc. / Deputy >General Counsel & Chief Privacy Officer >1775 Pennsylvania Avenue NW, Washington D.C. 20006 >Office: ><tel:%2B1.202.533.2932>+1.202.533.2932 Mobile: ><tel:%2B1.202.352.6367>+1.202.352.6367 / <http://neustar.biz>neustar.biz ><http://www.neustar.biz> > > > >On 11/12/15, 1:23 PM, "Alan Greenberg" ><<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca> wrote: > >Of course contracts are not policies. But > >contracts contain provisions based on policies. > >Stress tests 29 and 30 explicitly makes reference > >to an IRP challenge could asserting that a > >contract provision was not developed by consensus. > > > >If the mission statement addition said that > >Consensus Policy must be developed by a bottom-up > >MS process, that would be fine. But it simply > >says "policies", an undefined and rather vague term. > > > >Alan > > > >At 12/11/2015 03:29 PM, Burr, Becky wrote: > >>With all due respect - contracts are NOT policies. Contracts reflect > >>policies, and they contain limits on what ICANN can impose unilaterally > >>on > >>contracted parties. But contracts with registries and registrars contain > >>lots of mutually agreed commercial terms and conditions that are NOT > >>policy. That is why ICANN must be able to enter into and enforce > >>contracts Â©Ã¸in furtherance of its mission" > >> > >> > >>J. Beckwith Burr > >>Neustar, Inc. / Deputymply says "policies" > >>General Counsel & Chief Privacy Officer > >>1775 Pennsylvania Avenue NW, Washington D.C. 20006 > >>Office: > <tel:%2B1.202.533.2932>+1.202.533.2932 Mobile: > <tel:%2B1.202.352.6367>+1.202.352.6367 / <http://neustar.biz>neustar.biz > >><http://www.neustar.biz> > >> > >> > >> > >> > >>On 11/12/15, 9:51 AM, "Alan Greenberg" > <<mailto:alan.greenberg@mcgill.ca>alan.greenberg(a)mcgill.ca> wrote: > >> > >> >David, there are several issues here. > >> > > >> >PICs were not developed through a bottom-up process, although they > >> >were subject to comment processes at various times. > >> > > >> >However, PICs are documented in Spec 11 of the registry > >> >agreements. Spec 1 is the explicit list of what topics can be the > >> >subject of a GNSO PDP, and for whatever reason (you can attribute it > >> >to incompetence or conspiracy), PIC are not in the list. > >> > > >> >My worry is that PICs, or virtually any part of a contract might be > >> >able to be struck down by and IRP because they were not developed in > >> >a bottom-up MS process, but there is no way to use the bottom-up MS > >> >process to replace them. > >> > > >> >Alan > >> > > >> >At 12/11/2015 10:26 AM, David Post wrote: > >> >>Alan - I'm not clear what you mean when you say that > >> >> > >> >>>>AG:- some issues which could reasonably considered "policy", such > >> >>>>as PICs in registry agreements, according to the Registry > >> >>>>agreement Spec 1, are NOT SUBJECT to Consensus Policy"? > >> >> > >> >>Do you mean that the insertion of the PICs in Spec 1 was not > >> >>developed by a consensus process ( I would agree )? Or that under > >> >>the current language of the proposal, the insertion of the PICs is > >> >>the kind of action that ICANN would be permitted to take without it > >> >>being subject to the consensus process (I don't think I agree )? > >> >> > >> >>David > >> >> > >> >> > >> >>At 07:54 AM 11/12/2015, Alan Greenberg wrote: > >> >> > >> >>>I am increasingly becoming uneasy with the implications of several > >> >>>of our proposed changes/powers. I would be happy to be convinced > >> >>>that I am missing something and there is no need to be concerned. > >> >>> > >> >>>The particular interaction that I am thinking of is: > >> >>> > >> >>>- the new requirement that "policies" be developed through a > >> >>>bottom-up multistakeholder process; > >> >>> > >> >>>- the fact that we never really define "policy" and therefore what > >> >>>is a policy is subject to interpretation; > >> >>> > >> >>>- we have contracts which are made up of a combination of > >> >>>historical language, negotiated terms, Consensus Policy and yes, > >> >>>terms which at some point in time may have been included through > >> >>>more arcane processes; > >> >>> > >> >>>- some issues which could reasonably considered "policy", such as > >> >>>PICs in registry agreements, according to the Registry agreement > >> >>>Spec 1, are NOT SUBJECT to Consensus Policy; > >> >>> > >> >>>- most contractual provisions are also outside of the limited > >> >>>subjects in Spec 1 (Registry) / Spec 4 (Registrar); > >> >>> > >> >>>- The IRP which can judge something to be outside of ICANN's mission; > >> >>> > >> >>>When you put these together, we have the situation that an IRP > >> >>>could judge that some contractual provision is "policy", was not > >> >>>developed through a bottom-up MS process, and therefore violates > >> >>>the Bylaws. Yet such terms are not eligible for a bottom-up MS > >> >>>process, or predate such processes. > >> >>> > >> >>>I find this EXTREMELY problematic. > >> >>> > >> >>>Alan > >> >>> > >> >>>_______________________________________________ > >> >>>Accountability-Cross-Community mailing list > >> >>><mailto:Accountability-Cross-Community@ica > nn.org>Accountability-Cross-Community(a)icann.org > >> > >>>>>https://urldefense.proofpoint.com/v2/url ?u=https-3A__mm.icann.org_mail > >>>>>ma > >> > >>>>>n_listinfo_accountability-2Dcross-2Dcomm unity&d=CwICAg&c=MOptNlVtIETeD > >>>>>AL > >> > >>>>>C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdY ahOP8WDDkMr4k&m=He0ZyGdJIDc7wz > >>>>>sd > >> > >>>>>IRdFvJnAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7 l0jaMecsuB8Y11DrNFSMO6Xc4C4cNB > >>>>>TJ > >> >>>8&e= > >> >> > >> >>******************************* > >> >>David G Post - Senior Fellow, Open Technology Institute/New America > >> >>Foundation > >> >>blog (Volokh Conspiracy) > >> > >>>><https://urldefense.proofpoint.com/v2/url>ht > tps://urldefense.proofpoint.com/v2/url? u=http-3A__www.washingtonpost. > >>>>co > >> > >>>>m_people_david-2Dpost&d=CwICAg&c=MOptNlVt IETeDALC_lULrw&r=62cJFOifzm6X_ > >>>>GR > >> > >>>>laq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJID c7wzsdIRdFvJnAm7THjsagVk801BeQ > >>>>4h > >> >>E&s=Du760LWuQaX9-Rtg6INi7M4U1UdOwceKgmo_8WTqEXo&e= > >> >>book (Jefferson's Moose) > >> > >>>><https://urldefense.proofpoint.com/v2/url>ht > tps://urldefense.proofpoint.com/v2/url? u=http-3A__tinyurl.com_c327w2n > >>>>&d > >> > >>>>=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFO ifzm6X_GRlaq8Mo8TjDmrxdYahOP8W > >>>>DD > >> > >>>>kMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagV k801BeQ4hE&s=KGa9_YOIKx24ypUgg > >>>>xm > >> >>2sdw-N8-55AfqtvPzjbBsU_s&e= > >> >>music > >> > >>>><https://urldefense.proofpoint.com/v2/url>ht > tps://urldefense.proofpoint.com/v2/url? u=http-3A__tinyurl.com_davidpo > >>>>st > >> > >>>>music&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r =62cJFOifzm6X_GRlaq8Mo8TjDmrxd > >>>>Ya > >> > >>>>hOP8WDDkMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7 THjsagVk801BeQ4hE&s=k3sxcCisSp > >>>>zv > >> >>xkzLursRJem4WqQn3W-AAl8g9Du1glw&e= publications > >> >>etc. > >> > >>>><https://urldefense.proofpoint.com/v2/url>ht > tps://urldefense.proofpoint.com/v2/url? > u=<http://http-3A__www.davidpost.com>http-3A__www.davidpost.com&d > >>>>=C > >> > >>>>wICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOif zm6X_GRlaq8Mo8TjDmrxdYahOP8WDD > >>>>kM > >> > >>>>r4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk8 01BeQ4hE&s=swRN-B4OyZhrqkSq2N3 > >>>>Zm > >> >>gJTXXeioI4XPsyNyxfuSZM&e= > >> >>******************************* > >> > > >> >_______________________________________________ > >> >Accountability-Cross-Community mailing list > >> ><mailto:Accountability-Cross-Community@icann > .org>Accountability-Cross-Community(a)icann.org > >> > >>>https://urldefense.proofpoint.com/v2/url?u =https-3A__mm.icann.org_mailma > >>>n_ > >> > >>>listinfo_accountability-2Dcross-2Dcommunit y&d=CwICAg&c=MOptNlVtIETeDALC_ > >>>lU > >> > >>>Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=He0ZyGdJIDc7wzsdIRdF > >>>vJ > >> >nAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7l0jaMecsuB8Y11DrNFSMO6Xc4C4cNBTJ8&e= > > > > >******************************* >David G Post - Senior Fellow, Open Technology >Institute/New America Foundation >blog (Volokh Conspiracy) ><http://www.washingtonpost.com/people/david-post>http://www.washingtonpost.com/people/david-post > >book (Jefferson's >Moose) <http://tinyurl.com/c327w2n>http://tinyurl.com/c327w2n >music ><http://tinyurl.com/davidpostmusic>http://tinyurl.com/davidpostmusic >publications etc. <http://www.davidpost.com>http://www.davidpost.com >******************************* > > >_______________________________________________ >Accountability-Cross-Community mailing list ><mailto:Accountability-Cross-Community@icann.org>Accountability-Cross-Community(a)icann.org > >https://mm.icann.org/mailman/listinfo/accountability-cross-community

1 0

Re: [CCWG-ACCT] Implications of bottom-up "policy" requirement
by Alan Greenberg Nov. 13, 2015

Nov. 13, 2015

On review, the change is not quite that simple, partly because in the current version, the first bullet does not make sense. removing the extraneous punctuation for just the first bullet we have: "In this role, with respect to domain names, ICANNs Mission is to coordinate the development and implementation of policies for which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS" I do not think that "uniform and coordinated resolution of policies" makes sense. I think it was meant to say that the policies allow uniform and coordinated resolution of names, not the policies them selves. Perhaps the following works. In this role, with respect to domain names, ICANNs Mission is to coordinate the development and implementation of policies which allow the necessary uniform or coordinated resolution to facilitate the openness, interoperability, resilience, security and/or stability of the DNS. Such policies must be designed to ensure the stable and secure operation of the Internets unique names systems and, when they alter existing contracts must be developed through a bottom-up, consensus-based multistakeholder process. Alan At 13/11/2015 12:13 PM, Alan Greenberg wrote: >Good question. Let me look at the original version again. Alan > >At 13/11/2015 10:48 AM, David Post wrote: >>At 09:45 AM 11/13/2015, Alan Greenberg wrote: >>>I would like to propose a solution to this problem. >>> >>>The current proposal is that policies (without >>>being specific) be developed by a bottom-up MS process. >>> >>>I suggest that we replace "policy' by >>>"Consensus Policy". This is a term already >>>used in the Bylaws and is applicable to both >>>the Registry and Registrar contracts. >>> >>>If, as my original scenario envisions, that >>>such a policy is struck down, then it may be >>>re-crafted (or not!) using the established By-Law mandated processes. >> >>Alan >> >>Can you clarify what you mean when you propose >>replacing "policy" with "Consensus >>Policy"? Just substituting the words >>"Consensus Policy" for "policy" in the proposal language looks like this: >> >> >>"ICANN's Mission is to coordinate the >>development and implementation of Consensus >>Policies: . For which uniform or coordinated >>resolution is reasonably necessary to >>facilitate the openness, interoperability, >>resilience, security and/or stability: . That >>are developed through a bottom-up, >>consensus-based multistakeholder process and >>designed to ensure the stable and secure >>operation of the Internet's unique names system." >> >>Is that what you're proposing? >> >>David >> >> >>>At 12/11/2015 04:38 PM, Burr, Becky wrote: >>>>But why isn¡¯t the answer that it is a part of a non-policy provision of a >>>>commercial contract entered into in furtherance of ICANN¡¯s mission? >>>> >>>> >>>>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 11/12/15, 1:23 PM, "Alan Greenberg" <alan.greenberg(a)mcgill.ca> wrote: >>>> >>>> >Of course contracts are not policies. But >>>> >contracts contain provisions based on policies. >>>> >Stress tests 29 and 30 explicitly makes reference >>>> >to an IRP challenge could asserting that a >>>> >contract provision was not developed by consensus. >>>> > >>>> >If the mission statement addition said that >>>> >Consensus Policy must be developed by a bottom-up >>>> >MS process, that would be fine. But it simply >>>> >says "policies", an undefined and rather vague term. >>>> > >>>> >Alan >>>> > >>>> >At 12/11/2015 03:29 PM, Burr, Becky wrote: >>>> >>With all due respect - contracts are NOT policies. Contracts reflect >>>> >>policies, and they contain limits on what ICANN can impose unilaterally >>>> >>on >>>> >>contracted parties. But contracts with >>>> registries and registrars contain >>>> >>lots of mutually agreed commercial terms and conditions that are NOT >>>> >>policy. That is why ICANN must be able to enter into and enforce >>>> >>contracts ©øin furtherance of its mission" >>>> >> >>>> >> >>>> >>J. Beckwith Burr >>>> >>Neustar, Inc. / Deputymply says "policies" >>>> >>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 11/12/15, 9:51 AM, "Alan Greenberg" <alan.greenberg(a)mcgill.ca> wrote: >>>> >> >>>> >> >David, there are several issues here. >>>> >> > >>>> >> >PICs were not developed through a bottom-up process, although they >>>> >> >were subject to comment processes at various times. >>>> >> > >>>> >> >However, PICs are documented in Spec 11 of the registry >>>> >> >agreements. Spec 1 is the explicit list of what topics can be the >>>> >> >subject of a GNSO PDP, and for whatever reason (you can attribute it >>>> >> >to incompetence or conspiracy), PIC are not in the list. >>>> >> > >>>> >> >My worry is that PICs, or virtually any part of a contract might be >>>> >> >able to be struck down by and IRP because they were not developed in >>>> >> >a bottom-up MS process, but there is no way to use the bottom-up MS >>>> >> >process to replace them. >>>> >> > >>>> >> >Alan >>>> >> > >>>> >> >At 12/11/2015 10:26 AM, David Post wrote: >>>> >> >>Alan - I'm not clear what you mean when you say that >>>> >> >> >>>> >> >>>>AG:- some issues which could reasonably considered "policy", such >>>> >> >>>>as PICs in registry agreements, according to the Registry >>>> >> >>>>agreement Spec 1, are NOT SUBJECT to Consensus Policy"? >>>> >> >> >>>> >> >>Do you mean that the insertion of the PICs in Spec 1 was not >>>> >> >>developed by a consensus process ( I would agree )? Or that under >>>> >> >>the current language of the proposal, the insertion of the PICs is >>>> >> >>the kind of action that ICANN would be permitted to take without it >>>> >> >>being subject to the consensus process (I don't think I agree )? >>>> >> >> >>>> >> >>David >>>> >> >> >>>> >> >> >>>> >> >>At 07:54 AM 11/12/2015, Alan Greenberg wrote: >>>> >> >> >>>> >> >>>I am increasingly becoming uneasy with the implications of several >>>> >> >>>of our proposed changes/powers. I would be happy to be convinced >>>> >> >>>that I am missing something and there is no need to be concerned. >>>> >> >>> >>>> >> >>>The particular interaction that I am thinking of is: >>>> >> >>> >>>> >> >>>- the new requirement that "policies" be developed through a >>>> >> >>>bottom-up multistakeholder process; >>>> >> >>> >>>> >> >>>- the fact that we never really define "policy" and therefore what >>>> >> >>>is a policy is subject to interpretation; >>>> >> >>> >>>> >> >>>- we have contracts which are made up of a combination of >>>> >> >>>historical language, negotiated terms, Consensus Policy and yes, >>>> >> >>>terms which at some point in time may have been included through >>>> >> >>>more arcane processes; >>>> >> >>> >>>> >> >>>- some issues which could reasonably considered "policy", such as >>>> >> >>>PICs in registry agreements, according to the Registry agreement >>>> >> >>>Spec 1, are NOT SUBJECT to Consensus Policy; >>>> >> >>> >>>> >> >>>- most contractual provisions are also outside of the limited >>>> >> >>>subjects in Spec 1 (Registry) / Spec 4 (Registrar); >>>> >> >>> >>>> >> >>>- The IRP which can judge something to >>>> be outside of ICANN's mission; >>>> >> >>> >>>> >> >>>When you put these together, we have the situation that an IRP >>>> >> >>>could judge that some contractual provision is "policy", was not >>>> >> >>>developed through a bottom-up MS process, and therefore violates >>>> >> >>>the Bylaws. Yet such terms are not eligible for a bottom-up MS >>>> >> >>>process, or predate such processes. >>>> >> >>> >>>> >> >>>I find this EXTREMELY problematic. >>>> >> >>> >>>> >> >>>Alan >>>> >> >>> >>>> >> >>>_______________________________________________ >>>> >> >>>Accountability-Cross-Community mailing list >>>> >> >>>Accountability-Cross-Community(a)icann.org >>>> >> >>>> >>>>>https://urldefense.proofpoint.com/v2/url >>>> ?u=https-3A__mm.icann.org_mail >>>> >>>>>ma >>>> >> >>>> >>>>>n_listinfo_accountability-2Dcross-2Dcomm >>>> unity&d=CwICAg&c=MOptNlVtIETeD >>>> >>>>>AL >>>> >> >>>> >>>>>C_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdY >>>> ahOP8WDDkMr4k&m=He0ZyGdJIDc7wz >>>> >>>>>sd >>>> >> >>>> >>>>>IRdFvJnAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7 >>>> l0jaMecsuB8Y11DrNFSMO6Xc4C4cNB >>>> >>>>>TJ >>>> >> >>>8&e= >>>> >> >> >>>> >> >>******************************* >>>> >> >>David G Post - Senior Fellow, Open Technology Institute/New America >>>> >> >>Foundation >>>> >> >>blog (Volokh Conspiracy) >>>> >> >>>> >>>>https://urldefense.proofpoint.com/v2/url? >>>> u=http-3A__www.washingtonpost. >>>> >>>>co >>>> >> >>>> >>>>m_people_david-2Dpost&d=CwICAg&c=MOptNlVt >>>> IETeDALC_lULrw&r=62cJFOifzm6X_ >>>> >>>>GR >>>> >> >>>> >>>>laq8Mo8TjDmrxdYahOP8WDDkMr4k&m=He0ZyGdJID >>>> c7wzsdIRdFvJnAm7THjsagVk801BeQ >>>> >>>>4h >>>> >> >>E&s=Du760LWuQaX9-Rtg6INi7M4U1UdOwceKgmo_8WTqEXo&e= >>>> >> >>book (Jefferson's Moose) >>>> >> >>>> >>>>https://urldefense.proofpoint.com/v2/url? >>>> u=http-3A__tinyurl.com_c327w2n >>>> >>>>&d >>>> >> >>>> >>>>=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFO >>>> ifzm6X_GRlaq8Mo8TjDmrxdYahOP8W >>>> >>>>DD >>>> >> >>>> >>>>kMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagV >>>> k801BeQ4hE&s=KGa9_YOIKx24ypUgg >>>> >>>>xm >>>> >> >>2sdw-N8-55AfqtvPzjbBsU_s&e= >>>> >> >>music >>>> >> >>>> >>>>https://urldefense.proofpoint.com/v2/url? >>>> u=http-3A__tinyurl.com_davidpo >>>> >>>>st >>>> >> >>>> >>>>music&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r >>>> =62cJFOifzm6X_GRlaq8Mo8TjDmrxd >>>> >>>>Ya >>>> >> >>>> >>>>hOP8WDDkMr4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7 >>>> THjsagVk801BeQ4hE&s=k3sxcCisSp >>>> >>>>zv >>>> >> >>xkzLursRJem4WqQn3W-AAl8g9Du1glw&e= publications >>>> >> >>etc. >>>> >> >>>> >>>>https://urldefense.proofpoint.com/v2/url? >>>> u=http-3A__www.davidpost.com&d >>>> >>>>=C >>>> >> >>>> >>>>wICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOif >>>> zm6X_GRlaq8Mo8TjDmrxdYahOP8WDD >>>> >>>>kM >>>> >> >>>> >>>>r4k&m=He0ZyGdJIDc7wzsdIRdFvJnAm7THjsagVk8 >>>> 01BeQ4hE&s=swRN-B4OyZhrqkSq2N3 >>>> >>>>Zm >>>> >> >>gJTXXeioI4XPsyNyxfuSZM&e= >>>> >> >>******************************* >>>> >> > >>>> >> >_______________________________________________ >>>> >> >Accountability-Cross-Community mailing list >>>> >> >Accountability-Cross-Community(a)icann.org >>>> >> >>>> >>>https://urldefense.proofpoint.com/v2/url?u >>>> =https-3A__mm.icann.org_mailma >>>> >>>n_ >>>> >> >>>> >>>listinfo_accountability-2Dcross-2Dcommunit >>>> y&d=CwICAg&c=MOptNlVtIETeDALC_ >>>> >>>lU >>>> >> >>>> >>>Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W >>>> DDkMr4k&m=He0ZyGdJIDc7wzsdIRdF >>>> >>>vJ >>>> >> >nAm7THjsagVk801BeQ4hE&s=HtbFOYAAV7l0jaMecsuB8Y11DrNFSMO6Xc4C4cNBTJ8&e= >>>> > >> >>******************************* >>David G Post - Senior Fellow, Open Technology >>Institute/New America Foundation >>blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post >>book (Jefferson's Moose) http://tinyurl.com/c327w2n >>music http://tinyurl.com/davidpostmusic >>publications etc. http://www.davidpost.com >>*******************************

2 1

Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract
by David Post Nov. 13, 2015

Nov. 13, 2015

At 04:42 PM 11/11/2015, Mueller, Milton L wrote: >Thank you David for clarifying your position, which is that you do >NOT support deleting both statements and DO want to keep a clear >affirmative restriction in place. You have proposed to modify the >wording of the restriction in the following manner: > >DP: "Without limiting the foregoing absolute prohibition, ICANN >shall not regulate the content carried or provided by services that >use the Internet's unique identifiers." >Doesn't that do the job? > >MM: Possibly. It depends on whether regulating content also means >regulating the type or nature of the service provided. If content >was interpreted broadly I could accept this formulation Milton - I don't think we're that far apart in this, and I don't want to beat a dead horse - but just to clarify my own position. It's not quite correct to say I do NOT support deleting both statements - I do. If it were entirely up to me, I would delete both the "contract" language and the "regulation" language. But it's not entirely up to me, of course - and, obviously, many others feel strongly, with you and Paul, that some sort of "clear affirmative restriction" specifying what ICANN CANNOT do needs to be put in place. I'm saying I don't object to that, though it's not the direction I would go. If there is going to be some affirmative restriction language,it needs to be clear and unambiguous - otherwise, it is likely to do more harm than good, in my opinion; because it will have to be somehow reconciled with the Mission statement, it has the potential to muddy up interpretation of the Mission statement itself. My problem with the "regulation clause" language is primarily with the formulation that "ICANN shall not regulate services that use the Internet's unique identifiers," because it seems to me that, under a perfectly reasonable reading of that language, that is exactly what ICANN does do - it promulgates and enforces rules for registries and registrars, who provide "services that use the Internet's unique identifiers." I don't know how we would expect someone (the IRP) to understand what it is we're trying to get at, with that language, and it will just lead to all sorts of interpretive mischief. Which leaves the prohibition against "regulating the content carried or provided by services that use the Internet's unique identifiers." You write: >MM: Possibly. It depends on whether regulating content also means >regulating the type or nature of the service provided. If content >was interpreted broadly I could accept this formulation The problem, though, is that we have to decide to accept or reject the formulation before we know how it's going to be interpreted. I'm not sure I know how you would want to make "content" as broad as you would like it to be. David ******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com *******************************

11 28

Stress Test 18: bylaw amendment suggestion
by Pedro Ivo Ferraz da Silva Nov. 13, 2015

Nov. 13, 2015

Dear CCWG colleagues, As you are aware, in Dublin the GAC has provided a consensus input with regards to the bylaw amendments derived from ST18. The GAC input was the following: "The discussions on Stress Test 18 have helped the GAC to have a better understanding of the different views on the issue. In assessing the different rationales presented so far related to Stress Test 18, the GAC considered: * The need that each and every Advisory Committee ensures that the advice provided is clear and reflects the consensus view of the Committee; * The need that each and every Advisory Committee should preserve its own autonomy in its definition of consensus; * The value the Board attributes to receiving consensus advice; * The recommendation of the BGRI WG, as reiterated by the ATRT2, to set the threshold for the ICANN Board to reject GAC advice to a 2/3 majority voting, consistent with the threshold established for rejection of ccNSO and GNSO PDP recommendations. In view of the above, having considered concerns expressed by various parties, the GAC agreed to further work on the issue of Stress Test 18, and to submit any further input to the CCWG taking into account the timelines of the CCWG. GAC Members will continue to work within the CCWG to finalise the proposal for enhancing ICANN accountability." With the aim of addressing the input given by the GAC in its ICANN 54 communiqué and the original concerns expressed by the ST18 proponents, I present for your consideration the following alternative amendments (underlined) in ICANN bylaws. ARTICLE XI: ADVISORY COMMITTEES Section 1. GENERAL “The Board may create one or more Advisory Committees in addition to those set forth in this Article. Advisory Committee membership may consist of Directors only, Directors and non-directors, or non-directors only, and may also include non-voting or alternate members. Advisory Committees shall have no legal authority to act for ICANN, but shall report their findings and recommendations to the Board. Where the ICANN Board is obliged to pay due deference to advice from Advisory Committees and where that advice, if not followed, requires finding mutually agreed solutions for implementation of that advice, the Advisory Committee will make every effort to ensure that the advice provided is clear and reflects the consensus view of the committee. In this context, each Advisory Committee has the right to determine its particular definition of consensus.” ARTICLE XI: ADVISORY COMMITTEES Section 2. SPECIFIC ADVISORY COMMITTEES Item 1.j “The advice of the Governmental Advisory Committee on public policy matters shall be duly taken into account, both in the formulation and adoption of policies. In the event that the ICANN Board determines to take an action that is not consistent with the Governmental Advisory Committee advice, it shall so inform the Committee and state the reasons why it decided not to follow that advice. Any GAC Advice approved by a GAC consensus may only be rejected by a vote of more than two-thirds (2/3) of the Board. The Governmental Advisory Committee and the ICANN Board will then try, in good faith and in a timely and efficient manner, to find a mutually acceptable solution.” Kind regards, Pedro Ivo Ferraz da Silva Divisão da Sociedade da Informação Ministério das Relações Exteriores T: +55 61 2030-6609

22 62

Re: [CCWG-ACCT] Stress test 18 - Follow-up call #67
by Roelof Meijer Nov. 13, 2015

Nov. 13, 2015

I would like to be on the group Best, Roelof Meijer From: <accountability-cross-community-bounces(a)icann.org<mailto:accountability-cross-community-bounces@icann.org>> on behalf of Mathieu Weill <mathieu.weill(a)afnic.fr<mailto:mathieu.weill@afnic.fr>> Date: vrijdag 13 november 2015 12:01 To: "accountability-cross-community(a)icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community(a)icann.org<mailto:accountability-cross-community@icann.org>> Subject: [CCWG-ACCT] Stress test 18 - Follow-up call #67 Dear all, As indicated on call #67 today, we are forming a subgroup tasked with assessing the state of play and the various options on Stress Test 18 language, so that the CCWG can decide how to proceed in the third CCWG-Accountability Work Stream 1 proposal. It is expected that this subgroup will need to produce outcome for CCWG-ACCT consideration in a very timely fashion. A call to kick off discussions will be held next week, exact date to be disclosed soon. The call will be recorded and transcribed. Please note that a mailing-list will also be set up. We invite you to express your interest to join the group by sending a notification to acct-staff(a)icann.org<mailto:acct-staff@icann.org> preferably by today - end of business day. Thank you Best regards Mathieu, Thomas, León

1 0

Re: [CCWG-ACCT] 17 UTC deadline for final edits
by avri doria Nov. 13, 2015

Nov. 13, 2015

I support keeping the current language. Our normal practice is that until there is a new consensus the old consensus stands. Alternatively +1 avri Sent from a T-Mobile 4G LTE Device <div>-------- Original message --------</div><div>From: Malcolm Hutty <malcolm(a)linx.net> </div><div>Date:11/13/2015 1:28 PM (GMT-03:00) </div><div>To: Alice Jansen <alice.jansen(a)icann.org> </div><div>Cc: acct-staff(a)icann.org, accountability-cross-community(a)icann.org </div><div>Subject: Re: [CCWG-ACCT] 17 UTC deadline for final edits </div><div> </div> On 13 Nov 2015, at 11:40, Alice Jansen <alice.jansen(a)icann.org> wrote: As announced on your call #67, this is to kindly remind you that final edits on the attached draft Formal Update (circulated on 12 November) are needed by 17:00 UTC today. As indicated on the call, no line edits will be taken into account. Co-Chairs are asking for content related comments. Per the note below, any format, font and proofreading issues are being addressed by a professional writer. Thank you, Dear Alice, I just wanted to check you'd received the message copied below and understood it as responsive to this call, Kind Regards, Malcolm On 12/11/2015 23:04, Bernard Turcotte wrote: All, As per Mathieu's email of earlier today please find the draft Proposal Update document which will be discussed at the next CCWG meeting. There has been a major, unacceptable change between the last revision of this document and this one. Concerning the Mission, the previous revision said, on page 30 The CCWG-Accountability recommends clarifying ICANN’s Mission and Core Values to: * Reinforce the scope of ICANN’s organizational activities related to the Domain Name System (DNS) - ICANN is not to regulate services that use the Internet's unique identifiers, or the content that such services carry or provide. - ICANN is to have the ability to enforce agreements with contracted parties (entities that have signed agreements with ICANN in relation to top level domain names) That fairly reflected the decision recommendation from the previous draft, at least at the level of detail that appears in this document. The new revision just released removes those statements, and in their place says merely "The CCWG-Accountability is yet to reach consensus on the proposed language that is intended to address contract enforcement and regulation." (page 21) That is not correct. The existing recommendation from our previous draft Report remains intact until replaced. There has been nothing remotely like a consensus to remove it. Please revert to the previous statement. Based on Greg's most recent e-mail, of just a couple of hours ago, I think there are grounds for optimism that there WILL be a broadly based consensus to replace the previous text with his new suggestion. But if that fails, the fall-back is the existing text, not no text at all. The CCWG's existing recommendation remains until we have consensus to change it. It is essential that we follow proper process here, especially on such a crucial issue. Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ London Internet Exchange Ltd Monument Place, 24 Monument Street, London EC3R 8AJ Company Registered in England No. 3137929 Trinity Court, Trinity Street, Peterborough PE1 1DA

3 2

Re: [CCWG-ACCT] Implications of bottom-up "policy" requirement
by David Post Nov. 13, 2015

Nov. 13, 2015

Alan - I'm not clear what you mean when you say that >>AG:- some issues which could reasonably considered "policy", such >>as PICs in registry agreements, according to the Registry agreement >>Spec 1, are NOT SUBJECT to Consensus Policy"? Do you mean that the insertion of the PICs in Spec 1 was not developed by a consensus process ( I would agree )? Or that under the current language of the proposal, the insertion of the PICs is the kind of action that ICANN would be permitted to take without it being subject to the consensus process (I don't think I agree )? David At 07:54 AM 11/12/2015, Alan Greenberg wrote: >I am increasingly becoming uneasy with the implications of several >of our proposed changes/powers. I would be happy to be convinced >that I am missing something and there is no need to be concerned. > >The particular interaction that I am thinking of is: > >- the new requirement that "policies" be developed through a >bottom-up multistakeholder process; > >- the fact that we never really define "policy" and therefore what >is a policy is subject to interpretation; > >- we have contracts which are made up of a combination of historical >language, negotiated terms, Consensus Policy and yes, terms which at >some point in time may have been included through more arcane processes; > >- some issues which could reasonably considered "policy", such as >PICs in registry agreements, according to the Registry agreement >Spec 1, are NOT SUBJECT to Consensus Policy; > >- most contractual provisions are also outside of the limited >subjects in Spec 1 (Registry) / Spec 4 (Registrar); > >- The IRP which can judge something to be outside of ICANN's mission; > >When you put these together, we have the situation that an IRP could >judge that some contractual provision is "policy", was not developed >through a bottom-up MS process, and therefore violates the Bylaws. >Yet such terms are not eligible for a bottom-up MS process, or >predate such processes. > >I find this EXTREMELY problematic. > >Alan > >_______________________________________________ >Accountability-Cross-Community mailing list >Accountability-Cross-Community(a)icann.org >https://mm.icann.org/mailman/listinfo/accountability-cross-community ******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com *******************************

4 8

17 UTC deadline for final edits
by Alice Jansen Nov. 13, 2015

Nov. 13, 2015

Dear all, As announced on your call #67, this is to kindly remind you that final edits on the attached draft Formal Update (circulated on 12 November) are needed by 17:00 UTC today. As indicated on the call, no line edits will be taken into account. Co-Chairs are asking for content related comments. Per the note below, any format, font and proofreading issues are being addressed by a professional writer. Thank you, Best regards Alice From: Bernard Turcotte <turcotte.bernard(a)gmail.com<mailto:turcotte.bernard@gmail.com>> Date: Friday, November 13, 2015 12:04 AM To: "accountability-cross-community(a)icann.org<mailto:accountability-cross-community@icann.org>" <accountability-cross-community(a)icann.org<mailto:accountability-cross-community@icann.org>> Subject: CCWG - Draft Update document for CCWG call All, As per Mathieu's email of earlier today please find the draft Proposal Update document which will be discussed at the next CCWG meeting. The document is going to professional formatting as we speak - so any issues of layout, fonts etc. will be addressed by a specialist. This document also represents a consideration of all the comments received with respect to the previous version - not that all of these were accepted, but a majority were taken on. We apologize for the lateness of the document, but as you will notice we have put significant efforts into recasting this per the comments. Bernard Turcotte ICANN Staff Support for the CCWG for the CCWG Co-chairs.

15 15