Jorge: Can you please clarify what the implications are of this: The GAC further expects that changes to ICANN's mission and core values should not constrain the Board from accepting and implementing GAC advice. In MM: Do you mean to imply that there should be no limits of ICANN's mission?

IMHO, the GAC is not bound by ICANN’s Mission and Core Values. It can issue any Advice it likes. But ICANN can only implement GAC Advice in a manner that is consistent with ICANN’s Mission and Core Values. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz> From: <Schaefer>, Brett <Brett.Schaefer@heritage.org<mailto:Brett.Schaefer@heritage.org>> Date: Thursday, January 7, 2016 at 10:48 AM To: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>>, "Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>" <Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Cc: "acct-staff@icann.org<mailto:acct-staff@icann.org>" <acct-staff@icann.org<mailto:acct-staff@icann.org>> Subject: RE: Deck for Meeting #75 Mission Statement discussion Or, perhaps, that GAC advice should not be bound by ICANN’s mission and core values? ________________________________ BrettSchaefer 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org_&d=CwMGaQ&c...> From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Thursday, January 07, 2016 10:22 AM To: Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion Jorge: Can you please clarify what the implications are of this: The GAC further expects that changes to ICANN’s mission and core values should not constrain the Board from accepting and implementing GAC advice. In MM: Do you mean to imply that there should be no limits of ICANN’s mission?

But what if the Board cannot muster a 2/3 vote against GAC advice that goes beyond ICANN’s Mission and Core Values? Then we have the equivalent of a Constitutional crisis, with the GAC in a position as a member of the empowered community to object to accountability escalation attempts related to the situation. Philip S. Corwin, Founding Principal Virtualaw LLC 1155 F Street, NW Suite 1050 Washington, DC 20004 202-559-8597/Direct 202-559-8750/Fax 202-255-6172/cell Twitter: @VlawDC "Luck is the residue of design" -- Branch Rickey From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Schaefer, Brett Sent: Thursday, January 07, 2016 11:08 AM To: Burr, Becky; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch; accountability-cross-community@icann.org Cc: acct-staff@icann.org Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion Yes, that should be clear. ________________________________ 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/> From: Burr, Becky [mailto:Becky.Burr@neustar.biz] Sent: Thursday, January 07, 2016 11:06 AM To: Schaefer, Brett; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: Deck for Meeting #75 Mission Statement discussion Importance: High IMHO, the GAC is not bound by ICANN’s Mission and Core Values. It can issue any Advice it likes. But ICANN can only implement GAC Advice in a manner that is consistent with ICANN’s Mission and Core Values. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz> From: <Schaefer>, Brett <Brett.Schaefer@heritage.org<mailto:Brett.Schaefer@heritage.org>> Date: Thursday, January 7, 2016 at 10:48 AM To: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>>, "Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>" <Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Cc: "acct-staff@icann.org<mailto:acct-staff@icann.org>" <acct-staff@icann.org<mailto:acct-staff@icann.org>> Subject: RE: Deck for Meeting #75 Mission Statement discussion Or, perhaps, that GAC advice should not be bound by ICANN’s mission and core values? ________________________________ BrettSchaefer 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org_&d=CwMGaQ&c...> From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Thursday, January 07, 2016 10:22 AM To: Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion Jorge: Can you please clarify what the implications are of this: The GAC further expects that changes to ICANN’s mission and core values should not constrain the Board from accepting and implementing GAC advice. In MM: Do you mean to imply that there should be no limits of ICANN’s mission? ________________________________ No virus found in this message. Checked by AVG - www.avg.com<http://www.avg.com> Version: 2016.0.7227 / Virus Database: 4489/11316 - Release Date: 01/03/16

On 7 Jan 2016 5:32 PM, "Schaefer, Brett" <Brett.Schaefer@heritage.org> wrote:

Even then, the Board must try in good faith to find a compromise solution. This potentially could include GAC advice that goes beyond or is contrary to ICANN’s scope and mission.

SO: This is correct and such possibility is applicable in any decision of the board, irrespective of whether it's GAC advice or not. No?

The bylaw should clarify that Board-approved GAC advice, even if adopted by consensus, is subject to IRP appeal.”

SO: Is there a section of the current proposal that makes board's decision on GAC advice immune to community powers? (with IRP being an escalation path). I will like to see reference to that specific part as I have not seen such yet. The community powers is based on board's action/inaction so I don't understand what clarification is required when no exceptions (in this context) were made in the first place. Regards

This is also why we recommend restricting GAC participation in the

Empowered Community to an advisory role as long as it retains this power.

________________________________ 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

From: Phil Corwin [mailto:psc@vlaw-dc.com] Sent: Thursday, January 07, 2016 11:12 AM To: Schaefer, Brett; Burr, Becky; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch; accountability-cross-community@icann.org Cc: acct-staff@icann.org

Subject: RE: Deck for Meeting #75 Mission Statement discussion

But what if the Board cannot muster a 2/3 vote against GAC advice that goes beyond ICANN’s Mission and Core Values?

Then we have the equivalent of a Constitutional crisis, with the GAC in a position as a member of the empowered community to object to accountability escalation attempts related to the situation.

Philip S. Corwin, Founding Principal

Virtualaw LLC

1155 F Street, NW

Suite 1050

Washington, DC 20004

202-559-8597/Direct

202-559-8750/Fax

202-255-6172/cell

Twitter: @VlawDC

"Luck is the residue of design" -- Branch Rickey

From: accountability-cross-community-bounces@icann.org [mailto: accountability-cross-community-bounces@icann.org] On Behalf Of Schaefer, Brett Sent: Thursday, January 07, 2016 11:08 AM To: Burr, Becky; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch; accountability-cross-community@icann.org Cc: acct-staff@icann.org Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

Yes, that should be clear.

________________________________

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

From: Burr, Becky [mailto:Becky.Burr@neustar.biz] Sent: Thursday, January 07, 2016 11:06 AM To: Schaefer, Brett; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch; accountability-cross-community@icann.org Cc: acct-staff@icann.org Subject: Re: Deck for Meeting #75 Mission Statement discussion Importance: High

IMHO, the GAC is not bound by ICANN’s Mission and Core Values. It can issue any Advice it likes. But ICANN can only implement GAC Advice in a manner that is consistent with ICANN’s Mission and Core Values.

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

From: <Schaefer>, Brett <Brett.Schaefer@heritage.org> Date: Thursday, January 7, 2016 at 10:48 AM To: "Mueller, Milton L" <milton@gatech.edu>, "Jorge.Cancio@bakom.admin.ch" <Jorge.Cancio@bakom.admin.ch>, Becky Burr <becky.burr@neustar.biz>, Accountability Community <accountability-cross-community@icann.org> Cc: "acct-staff@icann.org" <acct-staff@icann.org> Subject: RE: Deck for Meeting #75 Mission Statement discussion

Or, perhaps, that GAC advice should not be bound by ICANN’s mission and core values?

________________________________

BrettSchaefer 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

From: accountability-cross-community-bounces@icann.org [mailto: accountability-cross-community-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Thursday, January 07, 2016 10:22 AM To: Jorge.Cancio@bakom.admin.ch; Becky.Burr@neustar.biz; accountability-cross-community@icann.org Cc: acct-staff@icann.org Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

Jorge:

Can you please clarify what the implications are of this:

The GAC further expects that changes to ICANN’s mission and core values should

not constrain the Board from accepting and implementing GAC advice. In

MM: Do you mean to imply that there should be no limits of ICANN’s mission?

________________________________

No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.7227 / Virus Database: 4489/11316 - Release Date: 01/03/16

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

GAC ADVICE is not subject to challenge through the IRP. Anything the ICANN does (or fails to do) - including the Board's implementation of GAC Advice - that violates the Bylaws can be challenged through an IRP. This represents no change from the current situation of the IRP. But we have spent many cycles on this, and GAC Advice itself is not subject to IRP challenge. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz> From: <Schaefer>, Brett <Brett.Schaefer@heritage.org<mailto:Brett.Schaefer@heritage.org>> Date: Thursday, January 7, 2016 at 12:44 PM To: Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> Cc: Milton L Mueller <milton@gatech.edu<mailto:milton@gatech.edu>>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, "Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>" <Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>>, Phil Corwin <psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>> Subject: RE: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion Seun, Yes, I think it should be made explicit that GAC advice approved by the Board is subject to IRP challenge and would be bound by the Mission and Scope – just like other Board decisions. The GAC advisory relationship with the Board is rather unique and I think it merits clarification. I would hope that that would not be controversial. Best, Brett From: Seun Ojedeji [mailto:seun.ojedeji@gmail.com] Sent: Thursday, January 07, 2016 12:35 PM To: Schaefer, Brett Cc: Milton L Mueller; Burr, Becky; Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>; Phil Corwin Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion On 7 Jan 2016 5:32 PM, "Schaefer, Brett" <Brett.Schaefer@heritage.org<mailto:Brett.Schaefer@heritage.org>> wrote:

Even then, the Board must try in good faith to find a compromise solution. This potentially could include GAC advice that goes beyond or is contrary to ICANN’s scope and mission.

SO: This is correct and such possibility is applicable in any decision of the board, irrespective of whether it's GAC advice or not. No?

The bylaw should clarify that Board-approved GAC advice, even if adopted by consensus, is subject to IRP appeal.”

SO: Is there a section of the current proposal that makes board's decision on GAC advice immune to community powers? (with IRP being an escalation path). I will like to see reference to that specific part as I have not seen such yet. The community powers is based on board's action/inaction so I don't understand what clarification is required when no exceptions (in this context) were made in the first place. Regards

This is also why we recommend restricting GAC participation in the Empowered Community to an advisory role as long as it retains this power.

________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org&d=CwMGaQ&c=...>

From: Phil Corwin [mailto:psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>] Sent: Thursday, January 07, 2016 11:12 AM To: Schaefer, Brett; Burr, Becky; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org>

Subject: RE: Deck for Meeting #75 Mission Statement discussion

But what if the Board cannot muster a 2/3 vote against GAC advice that goes beyond ICANN’s Mission and Core Values?

Then we have the equivalent of a Constitutional crisis, with the GAC in a position as a member of the empowered community to object to accountability escalation attempts related to the situation.

Philip S. Corwin, Founding Principal

Virtualaw LLC

1155 F Street, NW

Suite 1050

Washington, DC 20004

202-559-8597/Direct

202-559-8750/Fax

202-255-6172/cell

Twitter: @VlawDC

"Luck is the residue of design" -- Branch Rickey

From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org>] On Behalf Of Schaefer, Brett Sent: Thursday, January 07, 2016 11:08 AM To: Burr, Becky; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

Yes, that should be clear.

________________________________

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org&d=CwMGaQ&c=...>

From: Burr, Becky [mailto:Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>] Sent: Thursday, January 07, 2016 11:06 AM To: Schaefer, Brett; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: Deck for Meeting #75 Mission Statement discussion Importance: High

IMHO, the GAC is not bound by ICANN’s Mission and Core Values. It can issue any Advice it likes. But ICANN can only implement GAC Advice in a manner that is consistent with ICANN’s Mission and Core Values.

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>

From: <Schaefer>, Brett <Brett.Schaefer@heritage.org<mailto:Brett.Schaefer@heritage.org>> Date: Thursday, January 7, 2016 at 10:48 AM To: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>>, "Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>" <Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Cc: "acct-staff@icann.org<mailto:acct-staff@icann.org>" <acct-staff@icann.org<mailto:acct-staff@icann.org>> Subject: RE: Deck for Meeting #75 Mission Statement discussion

Or, perhaps, that GAC advice should not be bound by ICANN’s mission and core values?

________________________________

BrettSchaefer 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org&d=CwMGaQ&c=...>

From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org>] On Behalf Of Mueller, Milton L Sent: Thursday, January 07, 2016 10:22 AM To: Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

Jorge:

Can you please clarify what the implications are of this:

The GAC further expects that changes to ICANN’s mission and core values should

not constrain the Board from accepting and implementing GAC advice. In

MM: Do you mean to imply that there should be no limits of ICANN’s mission?

________________________________

No virus found in this message. Checked by AVG - www.avg.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.avg.com&d=CwMGaQ&c=M...> Version: 2016.0.7227 / Virus Database: 4489/11316 - Release Date: 01/03/16

________________________________ BrettSchaefer 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org_&d=CwMGaQ&c...> _______________________________________________

Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=6YBF-nubtnoONd3CAN-DerTuzBQOw6aUpUSeK5HsCqY&s=jI5WagSOi1fVOHUGCc7aSm8iLeUDrccKL2Y8ObtgqzE&e=>

that was also my understanding Jorge Von meinem iPhone gesendet Am 07.01.2016 um 18:45 schrieb Burr, Becky <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>>: Some comments inline in BLUE J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz> From: Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> Date: Thursday, January 7, 2016 at 12:34 PM To: "Schaefer, Brett" <Brett.Schaefer@heritage.org<mailto:Brett.Schaefer@heritage.org>> Cc: Milton L Mueller <milton@gatech.edu<mailto:milton@gatech.edu>>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, "Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>" <Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>>, Phil Corwin <psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion On 7 Jan 2016 5:32 PM, "Schaefer, Brett" <Brett.Schaefer@heritage.org<mailto:Brett.Schaefer@heritage.org>> wrote:

Even then, the Board must try in good faith to find a compromise solution. This potentially could include GAC advice that goes beyond or is contrary to ICANN’s scope and mission.

SO: This is correct and such possibility is applicable in any decision of the board, irrespective of whether it's GAC advice or not. No?

The bylaw should clarify that Board-approved GAC advice, even if adopted by consensus, is subject to IRP appeal.” ALL BOARD ACTION AND INACTION IN VIOLATION OF THE BYLAWS CAN BE CHALLENGED THROUGH AN IRP BY COMMUNITY OR SOMEONE MATERIALLY AFFECTED. FULL STOP. NO CLARIFICATION IS NEEDED. THIS IS NOT THE SAME AS CHALLENGING GAC ADVICE – YOU CANNOT DO THAT THROUGH AN IRP. BUT YOU CAN CHALLENGE THE BOARD’S IMPLEMENTATION IF THAT IMPLEMENTATION CAUSES ICANN TO EXCEED ITS MISSION. THAT’S THE CASE RIGHT NOW. THERE IS NO CHANGE.

SO: Is there a section of the current proposal that makes board's decision on GAC advice immune to community powers? (with IRP being an escalation path). I will like to see reference to that specific part as I have not seen such yet. The community powers is based on board's action/inaction so I don't understand what clarification is required when no exceptions (in this context) were made in the first place. Regards

This is also why we recommend restricting GAC participation in the Empowered Community to an advisory role as long as it retains this power.

________________________________ 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org&d=CwMFaQ&c=...>

From: Phil Corwin [mailto:psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>] Sent: Thursday, January 07, 2016 11:12 AM To: Schaefer, Brett; Burr, Becky; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org>

Subject: RE: Deck for Meeting #75 Mission Statement discussion

But what if the Board cannot muster a 2/3 vote against GAC advice that goes beyond ICANN’s Mission and Core Values?

Then we have the equivalent of a Constitutional crisis, with the GAC in a position as a member of the empowered community to object to accountability escalation attempts related to the situation.

Philip S. Corwin, Founding Principal

Virtualaw LLC

1155 F Street, NW

Suite 1050

Washington, DC 20004

202-559-8597/Direct

202-559-8750/Fax

202-255-6172/cell

Twitter: @VlawDC

"Luck is the residue of design" -- Branch Rickey

From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org>] On Behalf Of Schaefer, Brett Sent: Thursday, January 07, 2016 11:08 AM To: Burr, Becky; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

Yes, that should be clear.

________________________________

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<https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org&d=CwMFaQ&c=...>

From: Burr, Becky [mailto:Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>] Sent: Thursday, January 07, 2016 11:06 AM To: Schaefer, Brett; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: Deck for Meeting #75 Mission Statement discussion Importance: High

IMHO, the GAC is not bound by ICANN’s Mission and Core Values. It can issue any Advice it likes. But ICANN can only implement GAC Advice in a manner that is consistent with ICANN’s Mission and Core Values.

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>

From: <Schaefer>, Brett <Brett.Schaefer@heritage.org<mailto:Brett.Schaefer@heritage.org>> Date: Thursday, January 7, 2016 at 10:48 AM To: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>>, "Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>" <Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Cc: "acct-staff@icann.org<mailto:acct-staff@icann.org>" <acct-staff@icann.org<mailto:acct-staff@icann.org>> Subject: RE: Deck for Meeting #75 Mission Statement discussion

Or, perhaps, that GAC advice should not be bound by ICANN’s mission and core values?

________________________________

BrettSchaefer 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org&d=CwMFaQ&c=...>

From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org>] On Behalf Of Mueller, Milton L Sent: Thursday, January 07, 2016 10:22 AM To: Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

Jorge:

Can you please clarify what the implications are of this:

The GAC further expects that changes to ICANN’s mission and core values should

not constrain the Board from accepting and implementing GAC advice. In

MM: Do you mean to imply that there should be no limits of ICANN’s mission?

________________________________

No virus found in this message. Checked by AVG - www.avg.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.avg.com&d=CwMFaQ&c=M...> Version: 2016.0.7227 / Virus Database: 4489/11316 - Release Date: 01/03/16

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=XWhy9T7r3e6BdgGM3y97gOAm67EP8WgBOpd_HGhQw6E&s=uPeSRarW6Gs_pPN34Cw8M6dRURR6I0Adu9VoH_xE7_M&e=>

Yes, but it raises an important question. If the GAC has authority to issue Advice that the Board must follow unless 2/3 of the Board reject, should the GAC ALSO get to decide whether the sole designator can challenge ICANN’s implementation of Advice in a manner that violates the Bylaws? J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz> From: "Megan.Richards@ec.europa.eu<mailto:Megan.Richards@ec.europa.eu>" <Megan.Richards@ec.europa.eu<mailto:Megan.Richards@ec.europa.eu>> Date: Thursday, January 7, 2016 at 11:33 AM To: "psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>" <psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>> Cc: "Brett.Schaefer@heritage.org<mailto:Brett.Schaefer@heritage.org>" <Brett.Schaefer@heritage.org<mailto:Brett.Schaefer@heritage.org>>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, "milton@gatech.edu<mailto:milton@gatech.edu>" <milton@gatech.edu<mailto:milton@gatech.edu>>, "Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>" <Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>>, "acct-staff@icann.org<mailto:acct-staff@icann.org>" <acct-staff@icann.org<mailto:acct-staff@icann.org>> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion Sounds like a board ready to "violate" ICANN mission and core values. Were those not criteria for measures to be taken by the sole designator ? Sent from my iPad On 07 Jan 2016, at 17:17, Phil Corwin <psc@vlaw-dc.com<mailto:psc@vlaw-dc.com>> wrote: But what if the Board cannot muster a 2/3 vote against GAC advice that goes beyond ICANN’s Mission and Core Values? Then we have the equivalent of a Constitutional crisis, with the GAC in a position as a member of the empowered community to object to accountability escalation attempts related to the situation. Philip S. Corwin, Founding Principal Virtualaw LLC 1155 F Street, NW Suite 1050 Washington, DC 20004 202-559-8597/Direct 202-559-8750/Fax 202-255-6172/cell Twitter: @VlawDC "Luck is the residue of design" -- Branch Rickey From:accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Schaefer, Brett Sent: Thursday, January 07, 2016 11:08 AM To: Burr, Becky; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion Yes, that should be clear. ________________________________ BrettSchaefer 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org_&d=CwMF-g&c...> From: Burr, Becky [mailto:Becky.Burr@neustar.biz] Sent: Thursday, January 07, 2016 11:06 AM To: Schaefer, Brett; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: Deck for Meeting #75 Mission Statement discussion Importance: High IMHO, the GAC is not bound by ICANN’s Mission and Core Values. It can issue any Advice it likes. But ICANN can only implement GAC Advice in a manner that is consistent with ICANN’s Mission and Core Values. J. Beckwith Burr Neustar, Inc./Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office:+1.202.533.2932 Mobile:+1.202.352.6367 /neustar.biz<http://www.neustar.biz> From: <Schaefer>, Brett <Brett.Schaefer@heritage.org<mailto:Brett.Schaefer@heritage.org>> Date: Thursday, January 7, 2016 at 10:48 AM To: "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>>, "Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>" <Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Cc: "acct-staff@icann.org<mailto:acct-staff@icann.org>" <acct-staff@icann.org<mailto:acct-staff@icann.org>> Subject: RE: Deck for Meeting #75 Mission Statement discussion Or, perhaps, that GAC advice should not be bound by ICANN’s mission and core values? ________________________________ BrettSchaefer 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__heritage.org_&d=CwMGaQ&c...> From:accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Thursday, January 07, 2016 10:22 AM To: Jorge.Cancio@bakom.admin.ch<mailto:Jorge.Cancio@bakom.admin.ch>; Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>; accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org> Cc: acct-staff@icann.org<mailto:acct-staff@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion Jorge: Can you please clarify what the implications are of this: The GAC further expects that changes to ICANN’s mission and core values should not constrain the Board from accepting and implementing GAC advice. In MM: Do you mean to imply that there should be no limits of ICANN’s mission? ________________________________ No virus found in this message. Checked by AVG - www.avg.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.avg.com&d=CwMF-g&c=M...> Version: 2016.0.7227 / Virus Database: 4489/11316 - Release Date: 01/03/16 _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=dMcLenQ8YiWJfPt4Srs6__d0ei0TUk2pYRAy-riLTEA&s=52C_QgBMosfwcrscFShMkE6veIVkXFY_n02NMEFsbrQ&e=>

On 7 Jan 2016 6:01 PM, "Burr, Becky" <Becky.Burr@neustar.biz> wrote:

Yes, but it raises an important question. If the GAC has authority to

issue Advice that the Board must follow unless 2/3 of the Board reject, should the GAC ALSO get to decide whether the sole designator can challenge ICANN’s implementation of Advice in a manner that violates the Bylaws?

SO: In this situation and according to the escalation process and threshold, I would expect that GAC would not get passed the petition stage unless there is indeed sense in their petition that convinces other "voting" SO/AC. No? One extreme issue that I foresee(which has nothing to do with GAC) is a situation where the threshold required to exercise a community power is achieved, even though what is requested of the board by the community would in itself violate one or more sections of the bylaw. This is why I believe some exceptions (such as ICANN relationship with numbers as IFO) for exercising community powers were made, if there are other scenarios like that then it should be clearly exempted from wrath of the community powers. Regards

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

From: "Megan.Richards@ec.europa.eu" <Megan.Richards@ec.europa.eu> Date: Thursday, January 7, 2016 at 11:33 AM To: "psc@vlaw-dc.com" <psc@vlaw-dc.com> Cc: "Brett.Schaefer@heritage.org" <Brett.Schaefer@heritage.org>, Becky Burr <becky.burr@neustar.biz>, "milton@gatech.edu" <milton@gatech.edu>, " Jorge.Cancio@bakom.admin.ch" <Jorge.Cancio@bakom.admin.ch>, Accountability Community <accountability-cross-community@icann.org>, "acct-staff@icann.org" <acct-staff@icann.org>

Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

Sounds like a board ready to "violate" ICANN mission and core values. Were those not criteria for measures to be taken by the sole designator ?

Sent from my iPad

On 07 Jan 2016, at 17:17, Phil Corwin <psc@vlaw-dc.com> wrote:

...

But what if the Board cannot muster a 2/3 vote against GAC advice that goes beyond ICANN’s Mission and Core Values?

Then we have the equivalent of a Constitutional crisis, with the GAC in a position as a member of the empowered community to object to accountability escalation attempts related to the situation.

Philip S. Corwin, Founding Principal

Virtualaw LLC

1155 F Street, NW

Suite 1050

Washington, DC 20004

202-559-8597/Direct

202-559-8750/Fax

202-255-6172/cell

Twitter: @VlawDC

"Luck is the residue of design" -- Branch Rickey

From:accountability-cross-community-bounces@icann.org [mailto: accountability-cross-community-bounces@icann.org] On Behalf Of Schaefer, Brett Sent: Thursday, January 07, 2016 11:08 AM To: Burr, Becky; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch; accountability-cross-community@icann.org Cc: acct-staff@icann.org Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

Yes, that should be clear.

________________________________

BrettSchaefer

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

From: Burr, Becky [mailto:Becky.Burr@neustar.biz] Sent: Thursday, January 07, 2016 11:06 AM To: Schaefer, Brett; Mueller, Milton L; Jorge.Cancio@bakom.admin.ch; accountability-cross-community@icann.org Cc: acct-staff@icann.org Subject: Re: Deck for Meeting #75 Mission Statement discussion Importance: High

IMHO, the GAC is not bound by ICANN’s Mission and Core Values. It can issue any Advice it likes. But ICANN can only implement GAC Advice in a manner that is consistent with ICANN’s Mission and Core Values.

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

From: <Schaefer>, Brett <Brett.Schaefer@heritage.org> Date: Thursday, January 7, 2016 at 10:48 AM To: "Mueller, Milton L" <milton@gatech.edu>, "Jorge.Cancio@bakom.admin.ch" <Jorge.Cancio@bakom.admin.ch>, Becky Burr <becky.burr@neustar.biz>, Accountability Community <accountability-cross-community@icann.org> Cc: "acct-staff@icann.org" <acct-staff@icann.org> Subject: RE: Deck for Meeting #75 Mission Statement discussion

Or, perhaps, that GAC advice should not be bound by ICANN’s mission and core values?

________________________________

BrettSchaefer 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

From:accountability-cross-community-bounces@icann.org [mailto: accountability-cross-community-bounces@icann.org] On Behalf Of Mueller, Milton L Sent: Thursday, January 07, 2016 10:22 AM To: Jorge.Cancio@bakom.admin.ch; Becky.Burr@neustar.biz; accountability-cross-community@icann.org Cc: acct-staff@icann.org Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

Jorge:

Can you please clarify what the implications are of this:

The GAC further expects that changes to ICANN’s mission and core values should

not constrain the Board from accepting and implementing GAC advice. In

MM: Do you mean to imply that there should be no limits of ICANN’s mission?

________________________________

No virus found in this message. Checked by AVG - www.avg.com Version: 2016.0.7227 / Virus Database: 4489/11316 - Release Date: 01/03/16

_______________________________________________ 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

On 7 Jan 2016, at 16:36, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:

But second, the scenario imagines a case in which there is GAC advice that goes beyond the legal responsibilities of the board members (because of the bylaws) but where fewer than 2/3 of the board is willing to say, "No." This is of course a logical possibility, but it seems to me that at some point we have to admit that board members have power, judgement, and discretion. The empowered community can hold the board to account; but if you're going to have a corporation with a board it's still going to need to be able to act. Presumably, the point of the board member selection process is to try to select people who won't suddenly take leave of their senses and start doing things outside their legal scope.

Andrew, I don't think we need to expect that the Board might "suddenly take leave of their senses" for there to be a need for independent review of whether they have strayed beyond the bounds of the matters on which they are authorised to act. Any entity can err, and accountability means that something can be done to correct that in the (hopefully rare) cases where it does. Indeed, the IRP has found against the Board in previous cases that have occurred. Do you think that Board had taken leave of their senses each time? The trouble with your argument that we can just trust the Board to remain within the Mission when invited by the GAC to stray beyond it, without a mechanism to review their decisions, is that the same argument applies equally to the case of the Board acting inconsistently with the Bylaws in any other way, as it does to the specific case of the Board acting inconsistently with the Mission limitation. Are you really suggesting that there is no need for the IRP at all? After multiple rounds of public comment, with every round overwhelmingly endorsing the same approach, I think this question should really be considered settled: * ICANN must have a limited Mission; * ICANN must only act within the scope of that Mission; * The IRP must be available to provide fair, independent and objective review of claims that ICANN has acted outside that scope, and to provide effective redress when it finds that that has occurred; * The GAC should be able to give whatever advice it thinks fit, but a claim that a particular action was suggested by GAC advice, or even required to implement GAC advice, should not excuse actions that the above would otherwise prohibit. The Mission is intended to be stable, but it is not immutable. If the GAC believes that the above limits prevent ICANN from doing things that ICANN should do, the proper course of action is not to defy these rules or to denude them of effect, but to suggest the ways in which they think ICANN's Mission should be increased, for the consideration of the community. Kind Regards, Malcolm

Yes Jorge, it did and thanks for clarification. But tell me hiow do you want that the matter beaddressed . There are several provision in the ICANN Mission Staement, Nobady has asked that the legal Team ensure that those provisions would be fully implemented. Here is the GAC STATMENT Quote *"The GAC expects that any changes will not reduce the current role of the GAC in providing advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN’s policies and various laws and international agreements or where they may affect public policy issues (as provided in the current ByLaws). This includes issues such as consumer protection, the respect for fundamental rights and freedoms and law enforcement." *Unquote What do you expect from the lawyers to acertain.? How they can acertain ? what is the assurance that whatever they acertain will be im plemented ? Unless you put some text in the BALAWS which must be discussed and agreed by CCWG and put it to public comments there is no legal certainty that the GAC statemnt be implemented . The second statemnet is Quote "*The GAC further expects that changes to ICANN’s mission and core values should not constrain the Board from accepting and implementing GAC advice. In addition, ICANN’s ability to enforce contractual obligations and act upon the public policy advice of the GAC should not be inadvertently impacted."* Unquote The same questions are also appicable I do not see any possible means to further pursue the matter unless some language to that effect be included in the Byélas which must be discussed and agreed by CCWG and put it to public comments Regards Kavouss 2016-01-07 18:54 GMT+01:00 Andrew Sullivan <ajs@anvilwalrusden.com>:

On Thu, Jan 07, 2016 at 05:29:34PM +0000, Malcolm Hutty wrote:

...

The trouble with your argument that we can just trust the Board to remain within the Mission when invited by the GAC to stray beyond it, without a mechanism to review their decisions, is that the same argument applies equally to the case of the Board acting inconsistently with the Bylaws in any other way, as it does to the specific case of the Board acting inconsistently with the Mission limitation.

But I'm not making that argument (hence the tripartite response). But re-reading my message, I certainly didn't make my point clear. All I was trying to say was that, given the empowered community and the new accountability and so on, the case where the board will decide to wander out of its areas of responsibilty seems lower. And then, even if it does, we have the other mechanisms in place.

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’m sorry, Jorge. I read the entire GAC submission … and I still don’t see an answer to Milton’s question. I appreciate that you can’t go beyond what the GAC has said – but your purposeful ambiguity can’t be used at this point. When the GAC says that you expect changes in the mission to “not constrain the Board from accepting and implementing GAC advice” I read that exactly as Milton does – as saying that the GAC thinks that the Board should accept GAC advice even if that advice might take it beyond its mission (either purposefully or inadervtently). For the record, I think that suggestion is extremely dangerous as a matter of practice for the Board and also likely to result in rejection of the IANA transition by the NTIA. I think it is both manifest and self-evident that if GAC advice were to, hypothetically, be that the Board should engage in some activity that was beyond its mission (say capacity building or content censorship) then it would be appropriate and, indeed, mandatory, for the Board to reject that advice, precisely because it was to take action beyond the Mission. 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: Jorge.Cancio@bakom.admin.ch [mailto:Jorge.Cancio@bakom.admin.ch] Sent: Thursday, January 7, 2016 1:57 PM To: kavouss.arasteh@gmail.com Cc: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion Dear Kavouss It wasn’t me who first proposed the question which was decided tob e further refined with the ICANN Legal. I was one of the supporters of that move. And what matters is that the CCWG had decided to move ahead with this. Under that understanding the GAC included the first para I quoted: “The GAC notes that legal advice is being sought by the CCWG to clarify the practical effect of this Recommendation, and believes this is appropriate.” I feel the other elements in the GAC input (which you quote) could serve to formulate an appropriate legal question. Perhaps the co-chairs would be willing to form a small group which, under their guidance, could formulate such a question, after receiving the feedback from ICANN Legal which was agreed to be requested. Regards Jorge Von: Kavouss Arasteh [mailto:kavouss.arasteh@gmail.com] Gesendet: Donnerstag, 7. Januar 2016 19:46 An: Cancio Jorge BAKOM <Jorge.Cancio@bakom.admin.ch <mailto:Jorge.Cancio@bakom.admin.ch> > Cc: accountability-cross-community@icann.org <mailto:accountability-cross-community@icann.org> ; Mathieu Weill <Mathieu.Weill@afnic.fr <mailto:Mathieu.Weill@afnic.fr> >; Thomas Rickert <rickert@anwaelte.de <mailto:rickert@anwaelte.de> >; Schneider Thomas BAKOM <Thomas.Schneider@bakom.admin.ch <mailto:Thomas.Schneider@bakom.admin.ch> >; León Felipe Sánchez Ambía <leonfelipe@sanchez.mx <mailto:leonfelipe@sanchez.mx> >; Burr, Becky <Becky.Burr@neustar.biz <mailto:Becky.Burr@neustar.biz> >; Jordan Carter <jordan@internetnz.net.nz <mailto:jordan@internetnz.net.nz> > Betreff: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion Yes Jorge, it did and thanks for clarification. But tell me hiow do you want that the matter beaddressed . There are several provision in the ICANN Mission Staement, Nobady has asked that the legal Team ensure that those provisions would be fully implemented. Here is the GAC STATMENT Quote "The GAC expects that any changes will not reduce the current role of the GAC in providing advice on the activities of ICANN as they relate to concerns of governments, particularly matters where there may be an interaction between ICANN’s policies and various laws and international agreements or where they may affect public policy issues (as provided in the current ByLaws). This includes issues such as consumer protection, the respect for fundamental rights and freedoms and law enforcement." Unquote What do you expect from the lawyers to acertain.? How they can acertain ? what is the assurance that whatever they acertain will be im plemented ? Unless you put some text in the BALAWS which must be discussed and agreed by CCWG and put it to public comments there is no legal certainty that the GAC statemnt be implemented . The second statemnet is Quote "The GAC further expects that changes to ICANN’s mission and core values should not constrain the Board from accepting and implementing GAC advice. In addition, ICANN’s ability to enforce contractual obligations and act upon the public policy advice of the GAC should not be inadvertently impacted." Unquote The same questions are also appicable I do not see any possible means to further pursue the matter unless some language to that effect be included in the Byélas which must be discussed and agreed by CCWG and put it to public comments Regards Kavouss 2016-01-07 18:54 GMT+01:00 Andrew Sullivan <ajs@anvilwalrusden.com <mailto:ajs@anvilwalrusden.com> >: On Thu, Jan 07, 2016 at 05:29:34PM +0000, Malcolm Hutty wrote:

The trouble with your argument that we can just trust the Board to remain within the Mission when invited by the GAC to stray beyond it, without a mechanism to review their decisions, is that the same argument applies equally to the case of the Board acting inconsistently with the Bylaws in any other way, as it does to the specific case of the Board acting inconsistently with the Mission limitation.

But I'm not making that argument (hence the tripartite response). But re-reading my message, I certainly didn't make my point clear. All I was trying to say was that, given the empowered community and the new accountability and so on, the case where the board will decide to wander out of its areas of responsibilty seems lower. And then, even if it does, we have the other mechanisms in place. 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

On 07-Jan-16 17:44, Paul Rosenzweig wrote:

I think it is both manifest and self-evident that if GAC advice were to, hypothetically, be that the Board should engage in some activity that was beyond its mission(say capacity building or content censorship)

Remarkable to see those two as having the same weight. Is training people on the DNS or DNSEC in the same category as content censorship? avri --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Andrew said it even better than I did.  +1 -- Paul Rosenzweig Sent from myMail app for Android Thursday, 07 January 2016, 06:51PM -05:00 from Andrew Sullivan < ajs@anvilwalrusden.com> :

On Thu, Jan 07, 2016 at 06:21:20PM -0500, Avri Doria wrote:

...

Is training people on the DNS or DNSEC in the same category as content censorship?

Is capacity building in the sense of training people on DNS or DNSSEC really outside ICANN's mission, in the CCWG's proposal? It seems to me that that one could argue it helps the "ensure the stable and secure operation of the Internet's unique identifier systems" realm.

If ICANN decided to get into teaching people how to deploy VoIP using SIP, however, I'd wonder why. Or into web administration, or perhaps (more in line with the analogy) WordPress or Drupal administration. And those things do seem to me to be approximately as relevant to what ICANN is doing as content censorship: I don't think ICANN should do either.

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

Perhaps you should be asking Is floating and sustaining something like the Net Mundial Initiative, whose express purpose is to address public policy issues outside the names and numbers, and technical protocols and coordination, something within ICANN's mandate? (Since this is directly an issue where ICANN steps on governmental toes, in that public policy is traditionally a gov space, this question may be more relevant to the current discussion on GAC advice and board's consequent obligations. Also it is a real, manifest issue and not an abstraction.) parminder On Friday 08 January 2016 05:21 AM, Andrew Sullivan wrote:

On Thu, Jan 07, 2016 at 06:21:20PM -0500, Avri Doria wrote:

...

Is training people on the DNS or DNSEC in the same category as content censorship? Is capacity building in the sense of training people on DNS or DNSSEC really outside ICANN's mission, in the CCWG's proposal? It seems to me that that one could argue it helps the "ensure the stable and secure operation of the Internet's unique identifier systems" realm.

If ICANN decided to get into teaching people how to deploy VoIP using SIP, however, I'd wonder why. Or into web administration, or perhaps (more in line with the analogy) WordPress or Drupal administration. And those things do seem to me to be approximately as relevant to what ICANN is doing as content censorship: I don't think ICANN should do either.

A

National Interest, is not the same as Public Policy and most definitive not as Global Public Interest. It's typically trustbuilding from the Board to use something not defined to get what it wants. As much as that I am critical of the Board's behavior. However, as we haven't seen their final comments to our final proposal, I'll wait and see what they come up with, as I fully agree that we need to get it right rather than getting it done. el -- Sent from Dr Lisse's iPad mini

On 8 Jan 2016, at 10:05, Nigel Roberts <nigel@channelisles.net> wrote:

Indeed, and the GAC themselves reminded ICANN, when the issued GAC Advice acknowledging the adoption of the Framework of Interpretation by the ICANN board, that the national government or public authority remains the relevant body for public policy matters.

Thus it seems that ICANN should NOT be involved in determining what 'the public interest' is, as that is the preserve of governments.

It should however take into account 'the interests of the (global) public'.

The two concepts are NOT coterminous.

...

On 08/01/16 07:12, parminder wrote: Perhaps you should be asking

Is floating and sustaining something like the Net Mundial Initiative, whose express purpose is to address public policy issues outside the names and numbers, and technical protocols and coordination, something within ICANN's mandate?

(Since this is directly an issue where ICANN steps on governmental toes, in that public policy is traditionally a gov space, this question may be more relevant to the current discussion on GAC advice and board's consequent obligations. Also it is a real, manifest issue and not an abstraction.)

parminder

...

On Friday 08 January 2016 05:21 AM, Andrew Sullivan wrote:

...

On Thu, Jan 07, 2016 at 06:21:20PM -0500, Avri Doria wrote: Is training people on the DNS or DNSEC in the same category as content censorship? Is capacity building in the sense of training people on DNS or DNSSEC really outside ICANN's mission, in the CCWG's proposal? It seems to me that that one could argue it helps the "ensure the stable and secure operation of the Internet's unique identifier systems" realm.

If ICANN decided to get into teaching people how to deploy VoIP using SIP, however, I'd wonder why. Or into web administration, or perhaps (more in line with the analogy) WordPress or Drupal administration. And those things do seem to me to be approximately as relevant to what ICANN is doing as content censorship: I don't think ICANN should do either.

A

_______________________________________________ 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

Is floating and sustaining something like the Net Mundial Initiative, whose express purpose is to address public policy issues outside the names and numbers, and technical protocols and coordination, something within ICANN's mandate? My answer: No.

My understanding was that the NetMundial INITIATIVE was where the "stepping out of line" was perceived not NetMundial itself - I can understand that some or many felt that way (this is not a comment either way just an observation so please don't all send me a ton of emails supporting or negating Fadi's participation in the NMI - was just trying to clarify the discussion (hope springs eternal!) -----Original Message----- From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Avri Doria Sent: Friday, January 08, 2016 5:34 PM To: accountability-cross-community@icann.org Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion Hi, Except that ICANN's work and the environment it is done within was indeed part of what was considered by NETmundial. I know that for many, NET mundial was the origin of the objection about ICANN overstepping its mission. I never believed that and believe that it was an important event and within mission for ICANN to have done. I think changing the mission so as to exclude ICANN particpation and suppport for such activities would be a mistake and should not be included as a Transition goal. How about IGF, should ICANN stop its support? Is that a goal? I agree we should maintain ICANN's already restricted mission. This is what we agreed to. We have not agreed to narrowing its scope as far as I understand. avri On 08-Jan-16 11:21, Mueller, Milton L wrote:

Is floating and sustaining something like the Net Mundial Initiative, whose express purpose is to address public policy issues outside the names and numbers, and technical protocols and coordination, something within ICANN's mandate?

My answer: No.

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

On 08-Jan-16 12:25, Burr, Becky wrote:

Wonder if the right way to look at this is to develop some Stress Tests on whether we¹ve changed the test?

I think this might be a good idea. I am sure you are right that there is a difference between some of the things people say will be excluded in the post transition mission and those that actually would be. Perhaps we should test against a set of things that the Board decided were in scope in the past years and see whether they would still be in scope with the rewrite. avri --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

On 8 Jan 2016, at 17:49, Avri Doria <avri@acm.org> wrote:

Perhaps we should test against a set of things that the Board decided were in scope in the past years and see whether they would still be in scope with the rewrite.

Do you believe that the definition of whether something is in scope is whether the Board previously considered it in scope?

Agree - that is what policy people and lawyers are supposed to do when proposing an amendment to an existing regulation. Regards Jorge -----Ursprüngliche Nachricht----- Von: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] Im Auftrag von Avri Doria Gesendet: Samstag, 9. Januar 2016 17:16 Cc: accountability-cross-community@icann.org Betreff: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion On 09-Jan-16 08:31, Malcolm Hutty wrote:

...

On 8 Jan 2016, at 17:49, Avri Doria <avri@acm.org> wrote:

Perhaps we should test against a set of things that the Board decided were in scope in the past years and see whether they would still be in scope with the rewrite. Do you believe that the definition of whether something is in scope is whether the Board previously considered it in scope?

It is the history of interpreting the mission that we have to work with, so seem to me that it has to be at the base of any discrimination we need to do. Really does not matter if you or I agree that it was in-scope or not. A Board advised by a talented and risk adverse legal team made those interpretations. We can perhaps eliminate issues they decided on that ended up in the courts or that NTIA spoke out against for scope, if any, from the set of issues under test. In doing the stress test the point is not the decision made but whether the issue was in-scope. (Note: I think the Board makes lots of incorrect decisions on in-scope issues, the two are different questions. ) The point is to decide if the revised mission is the same. We should be able to do a substitution test. Do we get the same in-scope value with the revised Mission &c. as we get with the current Bylaws. Our various groups of lawyers, the CCWG as well as ICANN's can advise on whether the substitution of one set of language for another gives the same result. We have a large body of recommendations that the ICANN legal team has made on whether issues were in-scope or not, e.g. whether an issue is in-scope is part of every GNSO PDP. There are probably many issue scope discussions that have been written up in the past that I know nothing about. Most of us may know nothing about them. We may even have documentation on legal reasoning that was done on the scope issue in ICANN's archives. One reason that I think such a test may help settle the issue is that we have no one arguing for changing ICANN's mission, just for clarification. A stress test can check whether we have succeeded in doing that. Without that we have no facts on which to decide that the current Bylaws Mission and the proposed Mission &c. are indeed the same from a legal scope point of view. avri --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

Becky,

is it consistent with and reasonably necessary to ensure the stability and security of the DNS?

If stability and security (let us address the "of what" separately) exhaust the requirements, then past actions, e.g., "shared access" to some existing registries and the associated namespaces (circa 1999), and "new gTLDs" and the associated namespaces (circa 2001, 2005, and 2013), all of which served to increase the number of actors with {read,write,modify} access to the data which supports the DNS, were not necessary. I'm indirectly revisiting my prior point that the pattern of behavior of the early adopters, from Kleinrock's published works -- which incorporates work that lead to the High Performance Computing Act of 1991, and so the behavior of the USG, and later early adopters, to ICANN under its latest Board, and its latest contract with the USG, has been to provide access to subsequent adopters.

From this pattern of behavior, for which similar work in the UK academic community, and elsewhere, existed contemporaniously, which I trust we're not now deciding is outside the mission and/or scope of the Corporation, we can infer the existance of a public interest, held by several governments and research academic institutions, in extending access to the benefits of this particular stable mechanism of associating referants and resources -- an interest apparently shared by a sufficiently large body of end users of this system to make the attributive adjective "global" not nonsensical.

I suggest that the word "accessibility" or some cognate be added to the usual mantra of "security and stability", so we not shut the door on those who would like to use this system. Thank you for your patience reading this. Obviously, as there was public comment opposed to the Applicant Support Working Group's initial and final recommendations, prepared in response to a prior Board's call to form a cross community working group to consider how to assist 2013-round new gTLD applicants meeting some diversity goal, it is not impossible that its author(s) now argue that efforts to improve the accessibility of benefits made possible by the ongoing function of the Corporation fall outside the mission and/or scope of the Corporation. That the initial implementation of the ASWG's recommendations did not identify any applicant for "support" merely showed that the attempt to articulate a public interes must be improved upon, not proof that no public interest existed, as another CCWG-ACCT contributor observed. Eric Brunner-Williams Eugene, Oregon

(cc:s trimmed, since I don't think I have permission to post to all those places and anyway I don't know why it'd be relevant.) On Fri, Jan 08, 2016 at 10:16:03AM +0100, Dr Eberhard W Lisse wrote:

As the chair of the TechWg I am really wondering what we are talking about here.

We are talking about the different _kinds_ of "capacity building", and comparing and contrasting with content censorship, because of a remark someone (I forget who) made up-thread. The point is to understand the consequence of a limited mission and to understand whether the text we have before us conforms with our intuitions about what the mission actually is. (I normally hate arguments from intuitions, but that's what we're doing here so we might as well know it.)

So outreach would also be content censorship, perhaps?

I don't think that is even suggested by anything I wrote, but apparently I was not plain enough. Let me try to be clearer:

Smaller TLDs (cc and g) need all the help they can get, and it most definitively is within mission.

Well, first, is _any_ help within mission? Should ICANN (for instance) help small TLDs develop human resources policy? Should ICANN help small TLDs understand office leasing requirements? How about tax rules in the TLD's jurisdiction? Should ICANN give direct funding to small TLDs that are in financial trouble? Or every (small? define "small"?) TLD? At the very least, I think reasonable people could disagree about any of those cases. Perhaps you could say where you'd draw the line. But second, it seems self-evident to me (and not contrary to the text we have) that building technical capacity to perform the technical function of a TLD registry is indeed good to do, and something that ICANN can contribute to "ensure the stable and secure operation of the Internet's unique identifier systems as described below." I think the board's comments suggest they worry that the (elided) description in the CCWG draft 3 is too restrictive and wouldn't allow the sort of capacity building that (you and I agree) is currently correctly done as (say) part of Tech Day. What do you think the draft 3 mission text entails? Do you think the board is right to be worried? I shoudl say that this works for controls on delegations as well. For instance, the ICANN policy that restricts registration of (say) red-cross.TLD or [a-z][a-z].TLD is in fact an imposition of rules from one zone (the root zone) into another delegated zone (the TLD). The operator of TLD is not ICANN, and it makes its own policies, yet ICANN imposes some of those policies as a condition of delegating TLD. One might argue that one wishes history had gone differently, but this is the regime we have and it appears to be one we can mostly live with. What would be overreach, however, is for ICANN to try to impose such restrictions all the way down the tree. Indeed, we already have lots of things that are not consistent with ICANN policies for the DNS, but that are used regularly in other parts of the DNS. IDNs that do not use IDNA are quite common in lots of places. Domain names with spaces in them are used for DNS-based service discovery. "Underscore labels" (a label starting with _) are used as the technical mechanism to identify SRV records and for various anti-spam measures like DKIM and DMARC. These sorts of policies should not be heritable, and I think we want mission text that makes this clear. I believe the board's suggestion would be a step backwards in this area (as I indicated yesterday). Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com

Hi, When I red it, I read it to mean that in changing the mission text, we should not change the mission so much, by so-called clarification, as to rule issues that are not out of scope today to be out of scope tomorrow. avri On 07-Jan-16 10:22, Mueller, Milton L wrote:

Jorge:

Can you please clarify what the implications are of this:

The GAC further expects that changes to ICANN’s mission and core values should

not constrain the Board from accepting and implementing GAC advice. In

MM: Do you mean to imply that there should be no limits of ICANN’s mission?

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

On 07/01/2016 18:58, Andrew Sullivan wrote:

On "including the allocation and assignment of names in the root zone as a result of those policies," I don't object to the inclusion. But the board's overall proposed language is troubling:

In this role, ICANN’s scope includes the coordination of the development and implementation of domain name policies (including the allocation and assignment of names in the root zone as a result of those policies.)

First, the move to "includes" is in effect an unbounded scope, because it does not state where the end of the inclusion lies. But more troubling, this says, "development and implementation of domain name policies," as though ICANN has responsibility for domain names other than the root zone. It never has, it does not today, it should not, and it must not.

The DNS is a system of distributed authority: the SOA record, which marks a zone cut, is so named because it stands for "Start of Authority". ICANN has no more business telling me what to do in anvilwalrusden.com or crankycanuck.ca than I have business in telling them how to run icann.org. ICANN can make policies about under what conditions it will delegate from the root zone, and for those policies to have teeth it can of course say that if the delegated zone does not conform with a policy the delegation will be removed (although that has interesting stability implications). It can also make policies about any other zone for which it is the authority (such as icann.org). But it cannot make policies for domain names in general. This is a consequence of the DNS architecture.

Thank you for this technical explanation. Would the following work instead? In this role, ICANN’s shall coordinate the development and implementation of domain name policies for the root zone (including the allocation and assignment of names in the root zone as a result of those policies.) -- 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

I agree with Paul and Malcolm regarding so-called ‘voluntary’ commitments. We can limit the pressure on ICANN to expand its mission by not creating a loophole in the accountability structures that allows mission creep. And I agree that the limiting principle is a key foundation for our work. Robin

On Jan 14, 2016, at 9:03 AM, Paul Rosenzweig <paul.rosenzweig@redbranchconsulting.com> wrote:

I share Malcolm's view of voluntary commitments. Leaving aside what may have gone before, allowing the parties to an agreement to contract around binding limitations on their action would, effectively, nullify the Mission-limitation principle that is at the core of the accountability structure we are building. I can live with grandfathering in prior mistakes in this regard, if I have to, but it is essential that the line be drawn for future actions in stone, not sand.

Cheers Paul

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: Malcolm Hutty [mailto:malcolm@linx.net] Sent: Thursday, January 14, 2016 2:14 AM To: Burr, Becky <Becky.Burr@neustar.biz>; Accountability Community <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

On 06/01/2016 19:03, Burr, Becky wrote:

...

Is attached in DRAFT FORM. Anything missing or wrong should be attributed to incompetence rather than conspiracy. I am still working on questions in 1 section. I will also shortly resend a variety of previously circulated resource documents.

Becky,

The slide deck you actually presented at meeting 75 contains three propositions that were not contained in this draft deck you copied to the list. I believe you described these in your oral presentation as "strawman propositions for discussion". I am writing to react to those propositions.

"Proposition: The GAC may provide Advice on any matter it sees fit; ICANN must duly consider such Advice in accordance with the Bylaws, and if it decides to follow such Advice, must do so in a manner consistent with ICANN's Bylaws, including its Mission Statement."

I agree with this proposition.

"Proposition: ICANN's agreements with contracted parties may reflect: (a) bottom-up, consensus-based, multistakeholder policies on issues for which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and (b) other provisions in service of that Mission."

I also agree with this proposition.

The third propostion you introduce with a question:

"To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission, e.g., to serve a specific community, pro-actively address a public policy concern?

If "voluntary" commitments may exceed the scope of ICANN's Mission, how do you ensure that such commitments are truly voluntary?

Proposition: Individually negotiated commitments will be deemed to be voluntary. Existing RA and RAA language (including standard PICs) are "grandfathered" (as defined in Notes). Going forward, a mechanism should be available to permit contracted parties to enter into agreements without waiving the right to challenge (collectively) a contract provision on the grounds that (a) it exceeds ICANN's Mission and (b) was extracted by ICANN on an other than voluntary basis."

I do not agree with this proposition, because I think the question you pose to which it is offered as an answer is mistaken.

My reasoning is as follows:

Let us set aside the question of how to determine whether a particular provision of a contract between ICANN and a Registry was arrived at through "voluntary" means. Let us also set aside the vexed question of whether the concept of a "voluntary commitment" is even meaningful in a negotiation between an entity that has a critical input for its core business and an entity that is the monopoly supplier of that critical input.

Let us consider instead: why do we care whether terms in Registry contracts are "voluntary commitments"?

To put it another way, what is the wrong with ICANN imposing unwanted terms on Registries?

It seems to me that the very notion of "voluntary commitment" must be intended as a meaning of protecting Registries from unreasonable impositions by ICANN. However the fear of ICANN making unreasonable impositions on Registries is not the only or main reason why we want to limit ICANN to acting within its Mission, so addressing the Mission limitation through some definition of what constitutes a "voluntary commitment" misses the point.

Limiting ICANN to its Mission is there to protect the entire community, not just Registries. Concerning the so-called "regulatory prohibition", that prohibition is intended primarily to protect the interests of end-user registrants, not those of Registries. We should be just as concerned if ICANN tries to exceed its Mission as a result of a conspiracy between it and the Registries as we should if ICANN does so as a result of some other motivation and then tries to impose requirements on Registries without their approval.

Accordingly, I am afraid I cannot agree with either your third proposition or the assumption on which it rests.

In your question you ask "To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission".

The answer to this is that contracted parties are not bound by ICANN's bylaws, and so they are entirely free to enter into any contractual relations they wish. However, ICANN is bound by its bylaws, and so is not free to be the counterparty to a contract the purpose of which exceeds or is in contradiction with the Mission or other bylaws requirement.

Incidentally, I would point out that there is nothing unique about the Mission limitation. If we were to adopt the view that ICANN is free enter into an agreement with Registries for purposes beyond the Mission merely because the Registries were eager for it to do so, by the same token ICANN could then also disregard any other provision of the Bylaws that sought to constrain how ICANN acts provided that Registries "voluntary" agreed to that. That cannot be acceptable to anyone, surely.

Kind Regards,

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

_______________________________________________ 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

On 14/01/2016 18:01, CW Mail wrote:

Well, in that case, ICANN will have to abstain - permanently - from delegating any TLDs with ambitions to provide services to the regulated sectors, world-wide.

What a bizarre suggestion! Many entities provide services to companies in heavily regulated sectors, without taking it on themselves to enforce the regulations that pertain in of that sector themselves. -- 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

Hi, While I agree with the principle that commitments need to be voluntary and the coercion is reason for contract nullification, I also think it is a matter of law to define coercion. I would also argue that the PICs, the example under discussion, were not a matter of coercion, certainly not in any criminal sense. Not everyone made such commitments and those did go forward. On those commitments that were imposed after the policy and initial contract had been set and then changed for the so-called regulated industries, while I deplore the fact that those were set without proper ICANN process and would consider it a process error, I do not believe that this was coercion. For better or worse, this sort of back and forth of requirements is a normal part of contract negotiation. The applicants could have refused and fought it. They made a business decision that for financial reasons made sense to them and then decided whether to fight or sign. I also do not agree that PICs necessarily constitute mission creep, whatever that might actually mean - Yet Another Undefined Term (YAUT) and something that is in the eye of the beholder, or a possible future IRP. On PICS, I think the problem is a process error and one that could, in the future, be challenged based on the Articles change on requiring bottom-up multistakeholder process based decisions. Something like this could become a IRP action in a possible future, assuming we succeed in this accountability process. avri On 15-Jan-16 09:16, Matthew Shears wrote:

+ 1 Paul, Malcolm, Robin

On 14/01/2016 17:35, Robin Gross wrote:

...

I agree with Paul and Malcolm regarding so-called ‘voluntary’ commitments. We can limit the pressure on ICANN to expand its mission by not creating a loophole in the accountability structures that allows mission creep. And I agree that the limiting principle is a key foundation for our work.

Robin

...

On Jan 14, 2016, at 9:03 AM, Paul Rosenzweig <paul.rosenzweig@redbranchconsulting.com> wrote:

I share Malcolm's view of voluntary commitments. Leaving aside what may have gone before, allowing the parties to an agreement to contract around binding limitations on their action would, effectively, nullify the Mission-limitation principle that is at the core of the accountability structure we are building. I can live with grandfathering in prior mistakes in this regard, if I have to, but it is essential that the line be drawn for future actions in stone, not sand.

Cheers Paul

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: Malcolm Hutty [mailto:malcolm@linx.net] Sent: Thursday, January 14, 2016 2:14 AM To: Burr, Becky <Becky.Burr@neustar.biz>; Accountability Community <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

On 06/01/2016 19:03, Burr, Becky wrote:

...

Is attached in DRAFT FORM. Anything missing or wrong should be attributed to incompetence rather than conspiracy. I am still working on questions in 1 section. I will also shortly resend a variety of previously circulated resource documents. Becky,

The slide deck you actually presented at meeting 75 contains three propositions that were not contained in this draft deck you copied to the list. I believe you described these in your oral presentation as "strawman propositions for discussion". I am writing to react to those propositions.

"Proposition: The GAC may provide Advice on any matter it sees fit; ICANN must duly consider such Advice in accordance with the Bylaws, and if it decides to follow such Advice, must do so in a manner consistent with ICANN's Bylaws, including its Mission Statement."

I agree with this proposition.

"Proposition: ICANN's agreements with contracted parties may reflect: (a) bottom-up, consensus-based, multistakeholder policies on issues for which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and (b) other provisions in service of that Mission."

I also agree with this proposition.

The third propostion you introduce with a question:

"To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission, e.g., to serve a specific community, pro-actively address a public policy concern?

If "voluntary" commitments may exceed the scope of ICANN's Mission, how do you ensure that such commitments are truly voluntary?

Proposition: Individually negotiated commitments will be deemed to be voluntary. Existing RA and RAA language (including standard PICs) are "grandfathered" (as defined in Notes). Going forward, a mechanism should be available to permit contracted parties to enter into agreements without waiving the right to challenge (collectively) a contract provision on the grounds that (a) it exceeds ICANN's Mission and (b) was extracted by ICANN on an other than voluntary basis."

I do not agree with this proposition, because I think the question you pose to which it is offered as an answer is mistaken.

My reasoning is as follows:

Let us set aside the question of how to determine whether a particular provision of a contract between ICANN and a Registry was arrived at through "voluntary" means. Let us also set aside the vexed question of whether the concept of a "voluntary commitment" is even meaningful in a negotiation between an entity that has a critical input for its core business and an entity that is the monopoly supplier of that critical input.

Let us consider instead: why do we care whether terms in Registry contracts are "voluntary commitments"?

To put it another way, what is the wrong with ICANN imposing unwanted terms on Registries?

It seems to me that the very notion of "voluntary commitment" must be intended as a meaning of protecting Registries from unreasonable impositions by ICANN. However the fear of ICANN making unreasonable impositions on Registries is not the only or main reason why we want to limit ICANN to acting within its Mission, so addressing the Mission limitation through some definition of what constitutes a "voluntary commitment" misses the point.

Limiting ICANN to its Mission is there to protect the entire community, not just Registries. Concerning the so-called "regulatory prohibition", that prohibition is intended primarily to protect the interests of end-user registrants, not those of Registries. We should be just as concerned if ICANN tries to exceed its Mission as a result of a conspiracy between it and the Registries as we should if ICANN does so as a result of some other motivation and then tries to impose requirements on Registries without their approval.

Accordingly, I am afraid I cannot agree with either your third proposition or the assumption on which it rests.

In your question you ask "To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission".

The answer to this is that contracted parties are not bound by ICANN's bylaws, and so they are entirely free to enter into any contractual relations they wish. However, ICANN is bound by its bylaws, and so is not free to be the counterparty to a contract the purpose of which exceeds or is in contradiction with the Mission or other bylaws requirement.

Incidentally, I would point out that there is nothing unique about the Mission limitation. If we were to adopt the view that ICANN is free enter into an agreement with Registries for purposes beyond the Mission merely because the Registries were eager for it to do so, by the same token ICANN could then also disregard any other provision of the Bylaws that sought to constrain how ICANN acts provided that Registries "voluntary" agreed to that. That cannot be acceptable to anyone, surely.

Kind Regards,

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

_______________________________________________ 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

--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

Is it possible to analyze these problems by asking first whether ICANN has imposed these requirements (for e.g. a stakeholder council) on the applicant as a condition of entry into the root or, instead, it's a voluntary commitment undertaken by the applicant for its own purposes (e.g. to get the support of global environmental organizations, to get external funding, or what have you). If it were the former, then I think I do have a problem with ICANN's enforcement of the provision absent some demonstration both that it is reasonably necessary for the stability/security/interoperability of the DNS (which I wouldn't think it is, on the face of it from your hypothetical) and that it is otherwise within the confines of the mission. On the other hand, to the extent that the applicant made some voluntary undertaking that was not viewed by ICANN as a condition of its entry into the root, I have less of a problem in saying that ICANN can take steps to enforce the contractual promises made to it by third parties. I know it's a fuzzy line - maybe too fuzzy to be workable. But I do think that it might be the line that we've been struggling to define throughout this discussion. David At 12:59 PM 1/14/2016, Burr, Becky wrote:

I understand these concerns. Let me try to make my concerns concrete, particularly in the context community applications for new gTLDs, which may contain provisions that are a condition of community support but not strictly within ICANN¹s wheelhouse.

Say, for example, that a community .eco application included provisions, for example, requiring registrants to disclose certain information about their environmental practices, and assume for the moment, that the requirement was the result of input from an advisory group consisting of global environmental organizations and a condition of the support of those groups. (I believe that these suppositions are factual but it really doesn¹t matter.) Suppose, also, that the application includes an obligation to maintain and support a stakeholder¹s council consisting of representatives from global environmental organizations. Another example, suppose .bank requires registrants to demonstrate a certain regulatory status, and imposed that requirement to gain the support of financial institutions?

All of those commitments, by virtue of their inclusion in the application, are enforceable by ICANN. But say that the applicant decides to abandon the disclosure requirement and disbands the stakeholder council. Are either of those commitments reasonably necessary to facilitate openness, interoperability, resilience, security and/or stability of the DNS? Is ICANN¹s contractual authority to enforce those commitments ³in service² of ICANN¹s stability and security Mission?

We could say that the community preference for new gTLDs is the result of bottom-up, multistakeholder policy development and that contractual enforcement is ³in service² of that policy. But I don¹t know if that actually resolves the need to be reasonably necessary to facilitate stability, security, etc.

Thoughts??

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 1/14/16, 12:03 PM, "Paul Rosenzweig" <paul.rosenzweig@redbranchconsulting.com> wrote:

...

I share Malcolm's view of voluntary commitments. Leaving aside what may have gone before, allowing the parties to an agreement to contract around binding limitations on their action would, effectively, nullify the Mission-limitation principle that is at the core of the accountability structure we are building. I can live with grandfathering in prior mistakes in this regard, if I have to, but it is essential that the line be drawn for future actions in stone, not sand.

Cheers Paul

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: Malcolm Hutty [mailto:malcolm@linx.net] Sent: Thursday, January 14, 2016 2:14 AM To: Burr, Becky <Becky.Burr@neustar.biz>; Accountability Community <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

On 06/01/2016 19:03, Burr, Becky wrote:

...

Is attached in DRAFT FORM. Anything missing or wrong should be attributed to incompetence rather than conspiracy. I am still working on questions in 1 section. I will also shortly resend a variety of previously circulated resource documents.

Becky,

The slide deck you actually presented at meeting 75 contains three propositions that were not contained in this draft deck you copied to the list. I believe you described these in your oral presentation as "strawman propositions for discussion". I am writing to react to those propositions.

"Proposition: The GAC may provide Advice on any matter it sees fit; ICANN must duly consider such Advice in accordance with the Bylaws, and if it decides to follow such Advice, must do so in a manner consistent with ICANN's Bylaws, including its Mission Statement."

I agree with this proposition.

"Proposition: ICANN's agreements with contracted parties may reflect: (a) bottom-up, consensus-based, multistakeholder policies on issues for which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and (b) other provisions in service of that Mission."

I also agree with this proposition.

The third propostion you introduce with a question:

"To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission, e.g., to serve a specific community, pro-actively address a public policy concern?

If "voluntary" commitments may exceed the scope of ICANN's Mission, how do you ensure that such commitments are truly voluntary?

Proposition: Individually negotiated commitments will be deemed to be voluntary. Existing RA and RAA language (including standard PICs) are "grandfathered" (as defined in Notes). Going forward, a mechanism should be available to permit contracted parties to enter into agreements without waiving the right to challenge (collectively) a contract provision on the grounds that (a) it exceeds ICANN's Mission and (b) was extracted by ICANN on an other than voluntary basis."

I do not agree with this proposition, because I think the question you pose to which it is offered as an answer is mistaken.

My reasoning is as follows:

Let us set aside the question of how to determine whether a particular provision of a contract between ICANN and a Registry was arrived at through "voluntary" means. Let us also set aside the vexed question of whether the concept of a "voluntary commitment" is even meaningful in a negotiation between an entity that has a critical input for its core business and an entity that is the monopoly supplier of that critical input.

Let us consider instead: why do we care whether terms in Registry contracts are "voluntary commitments"?

To put it another way, what is the wrong with ICANN imposing unwanted terms on Registries?

It seems to me that the very notion of "voluntary commitment" must be intended as a meaning of protecting Registries from unreasonable impositions by ICANN. However the fear of ICANN making unreasonable impositions on Registries is not the only or main reason why we want to limit ICANN to acting within its Mission, so addressing the Mission limitation through some definition of what constitutes a "voluntary commitment" misses the point.

Limiting ICANN to its Mission is there to protect the entire community, not just Registries. Concerning the so-called "regulatory prohibition", that prohibition is intended primarily to protect the interests of end-user registrants, not those of Registries. We should be just as concerned if ICANN tries to exceed its Mission as a result of a conspiracy between it and the Registries as we should if ICANN does so as a result of some other motivation and then tries to impose requirements on Registries without their approval.

Accordingly, I am afraid I cannot agree with either your third proposition or the assumption on which it rests.

In your question you ask "To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission".

The answer to this is that contracted parties are not bound by ICANN's bylaws, and so they are entirely free to enter into any contractual relations they wish. However, ICANN is bound by its bylaws, and so is not free to be the counterparty to a contract the purpose of which exceeds or is in contradiction with the Mission or other bylaws requirement.

Incidentally, I would point out that there is nothing unique about the Mission limitation. If we were to adopt the view that ICANN is free enter into an agreement with Registries for purposes beyond the Mission merely because the Registries were eager for it to do so, by the same token ICANN could then also disregard any other provision of the Bylaws that sought to constrain how ICANN acts provided that Registries "voluntary" agreed to that. That cannot be acceptable to anyone, surely.

Kind Regards,

Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net _&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=S1JiVUQAqGB5VlxgFKlZdI4Kacb3MT5lpljmR0QprN0&s=EG_60KARwEuCkyZejW CL5HMy7C5FuGO58n8IlpW3_qE&e=

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

_______________________________________________ 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=CwICAg&c=MOptNlVtIETeDALC_lU Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=S1JiVUQAqGB5VlxgFKlZdI 4Kacb3MT5lpljmR0QprN0&s=a2j-IrQbQI8nnG8lowtub4eUpDPs20QHQrk9PfOuYak&e=

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@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 *******************************

Hmm. Well. I feel compelled to defend the right to apply for and operate a “meaningless" TLD. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz> From: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Date: Friday, January 15, 2016 at 3:56 PM To: David Post <david.g.post@gmail.com<mailto:david.g.post@gmail.com>> Cc: Becky Burr <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] Deck for Meeting #75 Mission Statement discussion David, I thinks this is a good point, actually. There are complexities, fuzzinesses and variables to be sure. And we may draw the (fuzzy) line in different places. But even common agreement on what is on the "right" side of the line would be a start. At some point, we also get to some fairly philosophical policy questions -- what should it mean to operate a TLD? Should it be largely meaningless to have one TLD vs. another? Or should many TLDs be very meaningful? Should a TLD registry operator promise that their TLD have a certain meaning (security, our registrants are real banks and not phishing scams, you should feel safe here)? When should ICANN resolve contention sets based on who made the better promises? Should all applicants have to keep all their promises when the TLD is "live" -- or are some applicants or some promises different than others? Meaningless TLDs would be kind of a disaster, since the new gTLD marketplace is predicated on differentiation, and on making a ready connection between the string and the meaning. We actually did pretty well on the gTLD side with largely meaningless TLDs for a long time (e.g., how many network vs. non-network registrations are there in .net?), while most ccTLDs had at least some degree of meaningfulness. Imagine a new gTLD program predicated on meaningless strings -- all Londoners should want .blatz, while the horse-loving community is going to love .splooshle. Not too compelling. Indeed if meaningless strings were cool, there probably would be no domain names -- we'd just have IP addresses.... Greg On Thu, Jan 14, 2016 at 1:51 PM, David Post <david.g.post@gmail.com<mailto:david.g.post@gmail.com>> wrote: Is it possible to analyze these problems by asking first whether ICANN has imposed these requirements (for e.g. a stakeholder council) on the applicant as a condition of entry into the root or, instead, it's a voluntary commitment undertaken by the applicant for its own purposes (e.g. to get the support of global environmental organizations, to get external funding, or what have you). If it were the former, then I think I do have a problem with ICANN's enforcement of the provision absent some demonstration both that it is reasonably necessary for the stability/security/interoperability of the DNS (which I wouldn't think it is, on the face of it from your hypothetical) and that it is otherwise within the confines of the mission. On the other hand, to the extent that the applicant made some voluntary undertaking that was not viewed by ICANN as a condition of its entry into the root, I have less of a problem in saying that ICANN can take steps to enforce the contractual promises made to it by third parties. I know it's a fuzzy line - maybe too fuzzy to be workable. But I do think that it might be the line that we've been struggling to define throughout this discussion. David At 12:59 PM 1/14/2016, Burr, Becky wrote: I understand these concerns. Let me try to make my concerns concrete, particularly in the context community applications for new gTLDs, which may contain provisions that are a condition of community support but not strictly within ICANN¹s wheelhouse. Say, for example, that a community .eco application included provisions, for example, requiring registrants to disclose certain information about their environmental practices, and assume for the moment, that the requirement was the result of input from an advisory group consisting of global environmental organizations and a condition of the support of those groups. (I believe that these suppositions are factual but it really doesn¹t matter.) Suppose, also, that the application includes an obligation to maintain and support a stakeholder¹s council consisting of representatives from global environmental organizations. Another example, suppose .bank requires registrants to demonstrate a certain regulatory status, and imposed that requirement to gain the support of financial institutions? All of those commitments, by virtue of their inclusion in the application, are enforceable by ICANN. But say that the applicant decides to abandon the disclosure requirement and disbands the stakeholder council. Are either of those commitments reasonably necessary to facilitate openness, interoperability, resilience, security and/or stability of the DNS? Is ICANN¹s contractual authority to enforce those commitments ³in service² of ICANN¹s stability and security Mission? We could say that the community preference for new gTLDs is the result of bottom-up, multistakeholder policy development and that contractual enforcement is ³in service² of that policy. But I don¹t know if that actually resolves the need to be reasonably necessary to facilitate stability, security, etc. Thoughts?? J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932<tel:%2B1.202.533.2932> Mobile: +1.202.352.6367<tel:%2B1.202.352.6367> / neustar.biz<http://neustar.biz> <http://www.neustar.biz> On 1/14/16, 12:03 PM, "Paul Rosenzweig" <paul.rosenzweig@redbranchconsulting.com<mailto:paul.rosenzweig@redbranchconsulting.com>> wrote:

I share Malcolm's view of voluntary commitments. Leaving aside what may have gone before, allowing the parties to an agreement to contract around binding limitations on their action would, effectively, nullify the Mission-limitation principle that is at the core of the accountability structure we are building. I can live with grandfathering in prior mistakes in this regard, if I have to, but it is essential that the line be drawn for future actions in stone, not sand.

Cheers Paul

Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com<mailto:paul.rosenzweig@redbranchconsulting.com> O: +1 (202) 547-0660<tel:%2B1%20%28202%29%20547-0660> M: +1 (202) 329-9650<tel:%2B1%20%28202%29%20329-9650> VOIP: +1 (202) 738-1739<tel:%2B1%20%28202%29%20738-1739> Skype: paul.rosenzweig1066 Link to my PGP Key

-----Original Message----- From: Malcolm Hutty [mailto:malcolm@linx.net<mailto:malcolm@linx.net>] Sent: Thursday, January 14, 2016 2:14 AM To: 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] Deck for Meeting #75 Mission Statement discussion

On 06/01/2016 19:03, Burr, Becky wrote:

...

Is attached in DRAFT FORM. Anything missing or wrong should be attributed to incompetence rather than conspiracy. I am still working on questions in 1 section. I will also shortly resend a variety of previously circulated resource documents.

Becky,

The slide deck you actually presented at meeting 75 contains three propositions that were not contained in this draft deck you copied to the list. I believe you described these in your oral presentation as "strawman propositions for discussion". I am writing to react to those propositions.

"Proposition: The GAC may provide Advice on any matter it sees fit; ICANN must duly consider such Advice in accordance with the Bylaws, and if it decides to follow such Advice, must do so in a manner consistent with ICANN's Bylaws, including its Mission Statement."

I agree with this proposition.

"Proposition: ICANN's agreements with contracted parties may reflect: (a) bottom-up, consensus-based, multistakeholder policies on issues for which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and (b) other provisions in service of that Mission."

I also agree with this proposition.

The third propostion you introduce with a question:

"To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission, e.g., to serve a specific community, pro-actively address a public policy concern?

If "voluntary" commitments may exceed the scope of ICANN's Mission, how do you ensure that such commitments are truly voluntary?

Proposition: Individually negotiated commitments will be deemed to be voluntary. Existing RA and RAA language (including standard PICs) are "grandfathered" (as defined in Notes). Going forward, a mechanism should be available to permit contracted parties to enter into agreements without waiving the right to challenge (collectively) a contract provision on the grounds that (a) it exceeds ICANN's Mission and (b) was extracted by ICANN on an other than voluntary basis."

I do not agree with this proposition, because I think the question you pose to which it is offered as an answer is mistaken.

My reasoning is as follows:

Let us set aside the question of how to determine whether a particular provision of a contract between ICANN and a Registry was arrived at through "voluntary" means. Let us also set aside the vexed question of whether the concept of a "voluntary commitment" is even meaningful in a negotiation between an entity that has a critical input for its core business and an entity that is the monopoly supplier of that critical input.

Let us consider instead: why do we care whether terms in Registry contracts are "voluntary commitments"?

To put it another way, what is the wrong with ICANN imposing unwanted terms on Registries?

It seems to me that the very notion of "voluntary commitment" must be intended as a meaning of protecting Registries from unreasonable impositions by ICANN. However the fear of ICANN making unreasonable impositions on Registries is not the only or main reason why we want to limit ICANN to acting within its Mission, so addressing the Mission limitation through some definition of what constitutes a "voluntary commitment" misses the point.

Limiting ICANN to its Mission is there to protect the entire community, not just Registries. Concerning the so-called "regulatory prohibition", that prohibition is intended primarily to protect the interests of end-user registrants, not those of Registries. We should be just as concerned if ICANN tries to exceed its Mission as a result of a conspiracy between it and the Registries as we should if ICANN does so as a result of some other motivation and then tries to impose requirements on Registries without their approval.

Accordingly, I am afraid I cannot agree with either your third proposition or the assumption on which it rests.

In your question you ask "To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission".

The answer to this is that contracted parties are not bound by ICANN's bylaws, and so they are entirely free to enter into any contractual relations they wish. However, ICANN is bound by its bylaws, and so is not free to be the counterparty to a contract the purpose of which exceeds or is in contradiction with the Mission or other bylaws requirement.

Incidentally, I would point out that there is nothing unique about the Mission limitation. If we were to adopt the view that ICANN is free enter into an agreement with Registries for purposes beyond the Mission merely because the Registries were eager for it to do so, by the same token ICANN could then also disregard any other provision of the Bylaws that sought to constrain how ICANN acts provided that Registries "voluntary" agreed to that. That cannot be acceptable to anyone, surely.

Kind Regards,

Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523<tel:%2B44%2020%207645%203523> Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net _&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=S1JiVUQAqGB5VlxgFKlZdI4Kacb3MT5lpljmR0QprN0&s=EG_60KARwEuCkyZejW CL5HMy7C5FuGO58n8IlpW3_qE&e=

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

_______________________________________________ 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=CwICAg&c=MOptNlVtIETeDALC_lU Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=S1JiVUQAqGB5VlxgFKlZdI 4Kacb3MT5lpljmR0QprN0&s=a2j-IrQbQI8nnG8lowtub4eUpDPs20QHQrk9PfOuYak&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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=is6eCPhWlDOLWHO04Lu1jzkdeZJZcUdMbFKPM1H4SFc&e=> ******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.washingtonpost.com_people_david-2Dpost&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=s-XZ_7FTxSAX_3b0e7i2NMjTksq1FZYVaBl6daxii3M&e=> book (Jefferson's Moose) http://tinyurl.com/c327w2n<https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_c327w2n&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=yUIiHI_AXX2f05ciq9Iu1iECfVfQGSRho6NyphGdpLw&e=> music http://tinyurl.com/davidpostmusic<https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_davidpostmusic&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=H2MJlMVtmrLGjZ5Ediad8L-Ocrtn_O1Exk5U7NMgw3s&e=> publications etc. http://www.davidpost.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.davidpost.com&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=1uyD8PvH5k98f_Hst4gBl62K_pOL3Z8QPZb4NFREI9A&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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_accountability-2Dcross-2Dcommunity&d=CwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=X78WIcBHzgYjpH4XJRJEQJFTZHGa7lahlvtUFIMtbZQ&s=is6eCPhWlDOLWHO04Lu1jzkdeZJZcUdMbFKPM1H4SFc&e=>

I think David's point was a bit different and more nuanced than that, as he said that "to the extent that the applicant made some voluntary undertaking that was not viewed by ICANN as a condition of its entry into the root, I have less of a problem in saying that ICANN can take steps to enforce the contractual promises made to it by third parties." There are plenty of registries that promised nothing beyond technical competence and that's fine, but there are many others who promised more (geos, communities, restricted TLDs, etc.). I agree that there is a value to a .bank TLD that is operated in secure manner and that verifies its registrants, etc. If the operator obligates themselves in their registry agreement to operate the TLD in that manner, that should then be enforceable by ICANN. Expecting registrants to enforce that status is unrealistic -- but if you want to enrich my brethren in the class action bar, that might be a good way to do it. As for meaningless strings -- I support that right, too. If a registry operator thinks they can make money that way, more power to them. Of course, it won't stay meaningless forever -- it will likely acquire a meaning over time if it is distinguished in any way (low prices, all malware, kids use it). As any trademark lawyer will tell you, the strongest kind of mark is a "fanciful" (i.e., made-up) mark, so it might be a shrewd move to start with a heretofore meaningless string and breathe meaning into it as the operator sees fit sees fit. Greg On Fri, Jan 15, 2016 at 5:23 PM, Paul Rosenzweig < paul.rosenzweig@redbranchconsulting.com> wrote:

It isn’t whether the strings are meaningful or meaningless is it? In the end David’s point (with which I think I agree) is that enforcing that meaning is not ICANN’s job because it isn’t related to the security and stability of the system. I take Becky’s point that there is value in having meaning and also that sometimes the only way to make that value real is by enforcing standards for use of the meaningful string. We can all agree that it is better for banks to be in .bank than it is for sports teams, or fraudsters. But that’s a requirement that is external to the stability of the network and I tend to think it is a bad thing for ICANN to take that obligation on. The obligation (e.g. to run a domain that gives out .bank strings only to people who meet a certain regulatory status) runs to the people who create and rely on that status … not to ICANN, I think

Paul

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:* Greg Shatan [mailto:gregshatanipc@gmail.com] *Sent:* Friday, January 15, 2016 3:57 PM *To:* David Post <david.g.post@gmail.com> *Cc:* Accountability Community <accountability-cross-community@icann.org>

*Subject:* Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

David,

I thinks this is a good point, actually. There are complexities, fuzzinesses and variables to be sure. And we may draw the (fuzzy) line in different places. But even common agreement on what is on the "right" side of the line would be a start.

At some point, we also get to some fairly philosophical policy questions -- what should it mean to operate a TLD? Should it be largely meaningless to have one TLD vs. another? Or should many TLDs be very meaningful? Should a TLD registry operator promise that their TLD have a certain meaning (security, our registrants are real banks and not phishing scams, you should feel safe here)? When should ICANN resolve contention sets based on who made the better promises? Should all applicants have to keep all their promises when the TLD is "live" -- or are some applicants or some promises different than others?

Meaningless TLDs would be kind of a disaster, since the new gTLD marketplace is predicated on differentiation, and on making a ready connection between the string and the meaning. We actually did pretty well on the gTLD side with largely meaningless TLDs for a long time (e.g., how many network vs. non-network registrations are there in .net?), while most ccTLDs had at least some degree of meaningfulness. Imagine a new gTLD program predicated on meaningless strings -- all Londoners should want .blatz, while the horse-loving community is going to love .splooshle. Not too compelling. Indeed if meaningless strings were cool, there probably would be no domain names -- we'd just have IP addresses....

Greg

On Thu, Jan 14, 2016 at 1:51 PM, David Post <david.g.post@gmail.com> wrote:

Is it possible to analyze these problems by asking first whether ICANN has imposed these requirements (for e.g. a stakeholder council) on the applicant as a condition of entry into the root or, instead, it's a voluntary commitment undertaken by the applicant for its own purposes (e.g. to get the support of global environmental organizations, to get external funding, or what have you).

If it were the former, then I think I do have a problem with ICANN's enforcement of the provision absent some demonstration both that it is reasonably necessary for the stability/security/interoperability of the DNS (which I wouldn't think it is, on the face of it from your hypothetical) and that it is otherwise within the confines of the mission. On the other hand, to the extent that the applicant made some voluntary undertaking that was not viewed by ICANN as a condition of its entry into the root, I have less of a problem in saying that ICANN can take steps to enforce the contractual promises made to it by third parties.

I know it's a fuzzy line - maybe too fuzzy to be workable. But I do think that it might be the line that we've been struggling to define throughout this discussion. David

At 12:59 PM 1/14/2016, Burr, Becky wrote:

I understand these concerns. Let me try to make my concerns concrete, particularly in the context community applications for new gTLDs, which may contain provisions that are a condition of community support but not strictly within ICANN¹s wheelhouse.

Say, for example, that a community .eco application included provisions, for example, requiring registrants to disclose certain information about their environmental practices, and assume for the moment, that the requirement was the result of input from an advisory group consisting of global environmental organizations and a condition of the support of those groups. (I believe that these suppositions are factual but it really doesn¹t matter.) Suppose, also, that the application includes an obligation to maintain and support a stakeholder¹s council consisting of representatives from global environmental organizations. Another example, suppose .bank requires registrants to demonstrate a certain regulatory status, and imposed that requirement to gain the support of financial institutions?

All of those commitments, by virtue of their inclusion in the application, are enforceable by ICANN. But say that the applicant decides to abandon the disclosure requirement and disbands the stakeholder council. Are either of those commitments reasonably necessary to facilitate openness, interoperability, resilience, security and/or stability of the DNS? Is ICANN¹s contractual authority to enforce those commitments ³in service² of ICANN¹s stability and security Mission?

We could say that the community preference for new gTLDs is the result of bottom-up, multistakeholder policy development and that contractual enforcement is ³in service² of that policy. But I don¹t know if that actually resolves the need to be reasonably necessary to facilitate stability, security, etc.

Thoughts??

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 1/14/16, 12:03 PM, "Paul Rosenzweig" <paul.rosenzweig@redbranchconsulting.com> wrote:

...

I share Malcolm's view of voluntary commitments. Leaving aside what may have gone before, allowing the parties to an agreement to contract around binding limitations on their action would, effectively, nullify the Mission-limitation principle that is at the core of the accountability structure we are building. I can live with grandfathering in prior mistakes in this regard, if I have to, but it is essential that the line be drawn for future actions in stone, not sand.

Cheers Paul

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: Malcolm Hutty [mailto:malcolm@linx.net] Sent: Thursday, January 14, 2016 2:14 AM To: Burr, Becky <Becky.Burr@neustar.biz>; Accountability Community <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

On 06/01/2016 19:03, Burr, Becky wrote:

...

Is attached in DRAFT FORM. Anything missing or wrong should be attributed to incompetence rather than conspiracy. I am still working on questions in 1 section. I will also shortly resend a variety of previously circulated resource documents.

Becky,

The slide deck you actually presented at meeting 75 contains three propositions that were not contained in this draft deck you copied to the list. I believe you described these in your oral presentation as "strawman propositions for discussion". I am writing to react to those propositions.

"Proposition: The GAC may provide Advice on any matter it sees fit; ICANN must duly consider such Advice in accordance with the Bylaws, and if it decides to follow such Advice, must do so in a manner consistent with ICANN's Bylaws, including its Mission Statement."

I agree with this proposition.

"Proposition: ICANN's agreements with contracted parties may reflect: (a) bottom-up, consensus-based, multistakeholder policies on issues for which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and (b) other provisions in service of that Mission."

I also agree with this proposition.

The third propostion you introduce with a question:

"To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission, e.g., to serve a specific community, pro-actively address a public policy concern?

If "voluntary" commitments may exceed the scope of ICANN's Mission, how do you ensure that such commitments are truly voluntary?

Proposition: Individually negotiated commitments will be deemed to be voluntary. Existing RA and RAA language (including standard PICs) are "grandfathered" (as defined in Notes). Going forward, a mechanism should be available to permit contracted parties to enter into agreements without waiving the right to challenge (collectively) a contract provision on the grounds that (a) it exceeds ICANN's Mission and (b) was extracted by ICANN on an other than voluntary basis."

I do not agree with this proposition, because I think the question you pose to which it is offered as an answer is mistaken.

My reasoning is as follows:

Let us set aside the question of how to determine whether a particular provision of a contract between ICANN and a Registry was arrived at through "voluntary" means. Let us also set aside the vexed question of whether the concept of a "voluntary commitment" is even meaningful in a negotiation between an entity that has a critical input for its core business and an entity that is the monopoly supplier of that critical input.

Let us consider instead: why do we care whether terms in Registry contracts are "voluntary commitments"?

To put it another way, what is the wrong with ICANN imposing unwanted terms on Registries?

It seems to me that the very notion of "voluntary commitment" must be intended as a meaning of protecting Registries from unreasonable impositions by ICANN. However the fear of ICANN making unreasonable impositions on Registries is not the only or main reason why we want to limit ICANN to acting within its Mission, so addressing the Mission limitation through some definition of what constitutes a "voluntary commitment" misses the point.

Limiting ICANN to its Mission is there to protect the entire community, not just Registries. Concerning the so-called "regulatory prohibition", that prohibition is intended primarily to protect the interests of end-user registrants, not those of Registries. We should be just as concerned if ICANN tries to exceed its Mission as a result of a conspiracy between it and the Registries as we should if ICANN does so as a result of some other motivation and then tries to impose requirements on Registries without their approval.

Accordingly, I am afraid I cannot agree with either your third proposition or the assumption on which it rests.

In your question you ask "To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission".

The answer to this is that contracted parties are not bound by ICANN's bylaws, and so they are entirely free to enter into any contractual relations they wish. However, ICANN is bound by its bylaws, and so is not free to be the counterparty to a contract the purpose of which exceeds or is in contradiction with the Mission or other bylaws requirement.

Incidentally, I would point out that there is nothing unique about the Mission limitation. If we were to adopt the view that ICANN is free enter into an agreement with Registries for purposes beyond the Mission merely because the Registries were eager for it to do so, by the same token ICANN could then also disregard any other provision of the Bylaws that sought to constrain how ICANN acts provided that Registries "voluntary" agreed to that. That cannot be acceptable to anyone, surely.

Kind Regards,

Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange |

https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net

...

_&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=S1JiVUQAqGB5VlxgFKlZdI4Kacb3MT5lpljmR0QprN0&s=EG_60KARwEuCkyZejW CL5HMy7C5FuGO58n8IlpW3_qE&e=

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

_______________________________________________ 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=CwICAg&c=MOptNlVtIETeDALC_lU Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=S1JiVUQAqGB5VlxgFKlZdI 4Kacb3MT5lpljmR0QprN0&s=a2j-IrQbQI8nnG8lowtub4eUpDPs20QHQrk9PfOuYak&e=

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@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 *******************************

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

Becky, Our notes crossed paths.

All of those commitments, by virtue of their inclusion in the application, are enforceable by ICANN. But say that the applicant decides to abandon the disclosure requirement and disbands the stakeholder council.

Lets change one part of the hypo, the applicant (subsequent to approval) decides to abandon a different requirement -- the one that requires the executive staff not to be completely comprised of crooks. The vetting of the applicant executive management serves one or more of the goals of openness, interoperability, resilience, security and/or stability of the DNS. Which commitments, made within the contract, are unnecessary to enforce, and which are necessary to enforce? Eric Brunner-Williams Eugene, Oregon

Just for the record, I am a strong supporter of community TLDs and therefore think these kinds of commitments should be enforceable 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 1/14/16, 3:59 PM, "Jonathan Zuck" <JZuck@actonline.org> wrote:

This all makes sense but going forward it will require enormous changes to how community proposals and those which overcome GAC objections are handled. As we head into the CCT review (regardless of where consumer trust ends up in the bylaws) it’s not hard to imagine that adherence to PICs will be a part of the consumer trust calculation.

On 1/14/16, 12:59 PM, "accountability-cross-community-bounces@icann.org on behalf of Burr, Becky" <accountability-cross-community-bounces@icann.org on behalf of Becky.Burr@neustar.biz> wrote:

...

I understand these concerns. Let me try to make my concerns concrete,

...

particularly in the context community applications for new gTLDs, which

...

may contain provisions that are a condition of community support but not

...

strictly within ICANN¹s wheelhouse.

...

...

Say, for example, that a community .eco application included provisions,

...

for example, requiring registrants to disclose certain information about

...

their environmental practices, and assume for the moment, that the

...

requirement was the result of input from an advisory group consisting of

...

global environmental organizations and a condition of the support of those

...

groups. (I believe that these suppositions are factual but it really

...

doesn¹t matter.) Suppose, also, that the application includes an

...

obligation to maintain and support a stakeholder¹s council consisting of

...

representatives from global environmental organizations. Another example,

...

suppose .bank requires registrants to demonstrate a certain regulatory

...

status, and imposed that requirement to gain the support of financial

...

institutions?

...

...

All of those commitments, by virtue of their inclusion in the application,

...

are enforceable by ICANN. But say that the applicant decides to abandon

...

the disclosure requirement and disbands the stakeholder council. Are

...

either of those commitments reasonably necessary to facilitate openness,

...

interoperability, resilience, security and/or stability of the DNS? Is

...

ICANN¹s contractual authority to enforce those commitments ³in service² of

...

ICANN¹s stability and security Mission?

...

...

We could say that the community preference for new gTLDs is the result of

...

bottom-up, multistakeholder policy development and that contractual

...

enforcement is ³in service² of that policy. But I don¹t know if that

...

actually resolves the need to be reasonably necessary to facilitate

...

stability, security, etc.

...

...

Thoughts??

...

...

...

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 1/14/16, 12:03 PM, "Paul Rosenzweig"

...

<paul.rosenzweig@redbranchconsulting.com> wrote:

...

...

...

I share Malcolm's view of voluntary commitments. Leaving aside what may

...

...

have gone before, allowing the parties to an agreement to contract around

...

...

binding limitations on their action would, effectively, nullify the

...

...

Mission-limitation principle that is at the core of the accountability

...

...

structure we are building. I can live with grandfathering in prior

...

...

mistakes

...

...

in this regard, if I have to, but it is essential that the line be drawn

...

...

for

...

...

future actions in stone, not sand.

...

...

...

...

Cheers

...

...

Paul

...

...

...

...

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: Malcolm Hutty [mailto:malcolm@linx.net]

...

...

Sent: Thursday, January 14, 2016 2:14 AM

...

...

To: Burr, Becky <Becky.Burr@neustar.biz>; Accountability Community

...

...

<accountability-cross-community@icann.org>

...

...

Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

...

...

...

...

...

...

...

...

On 06/01/2016 19:03, Burr, Becky wrote:

...

...

...

...

...

...

Is attached in DRAFT FORM. Anything missing or wrong should be

...

...

...

attributed to incompetence rather than conspiracy. I am still working

...

...

...

on questions in 1 section. I will also shortly resend a variety of

...

...

...

previously circulated resource documents.

...

...

...

...

Becky,

...

...

...

...

The slide deck you actually presented at meeting 75 contains three

...

...

propositions that were not contained in this draft deck you copied to the

...

...

list. I believe you described these in your oral presentation as "strawman

...

...

propositions for discussion". I am writing to react to those propositions.

...

...

...

...

...

...

"Proposition: The GAC may provide Advice on any matter it sees fit; ICANN

...

...

must duly consider such Advice in accordance with the Bylaws, and if it

...

...

decides to follow such Advice, must do so in a manner consistent with

...

...

ICANN's Bylaws, including its Mission Statement."

...

...

...

...

I agree with this proposition.

...

...

...

...

"Proposition: ICANN's agreements with contracted parties may reflect:

...

...

(a) bottom-up, consensus-based, multistakeholder policies on issues for

...

...

which uniform or coordinated resolution is reasonably necessary to

...

...

facilitate the openness, interoperability, resilience, security and/or

...

...

stability of the DNS; and (b) other provisions in service of that

...

...

Mission."

...

...

...

...

I also agree with this proposition.

...

...

...

...

...

...

The third propostion you introduce with a question:

...

...

...

...

"To what extent should contracted parties be free to propose or

...

...

voluntarily

...

...

accept (and obligated to comply with) contract provisions that exceed the

...

...

scope of ICANN's Mission, e.g., to serve a specific community,

...

...

pro-actively

...

...

address a public policy concern?

...

...

...

...

If "voluntary" commitments may exceed the scope of ICANN's Mission, how do

...

...

you ensure that such commitments are truly voluntary?

...

...

...

...

Proposition: Individually negotiated commitments will be deemed to be

...

...

voluntary. Existing RA and RAA language (including standard PICs) are

...

...

"grandfathered" (as defined in Notes). Going forward, a mechanism should

...

...

be

...

...

available to permit contracted parties to enter into agreements without

...

...

waiving the right to challenge (collectively) a contract provision on the

...

...

grounds that (a) it exceeds ICANN's Mission and (b) was extracted by ICANN

...

...

on an other than voluntary basis."

...

...

...

...

I do not agree with this proposition, because I think the question you

...

...

pose

...

...

to which it is offered as an answer is mistaken.

...

...

...

...

...

...

My reasoning is as follows:

...

...

...

...

Let us set aside the question of how to determine whether a particular

...

...

provision of a contract between ICANN and a Registry was arrived at

...

...

through

...

...

"voluntary" means. Let us also set aside the vexed question of whether the

...

...

concept of a "voluntary commitment" is even meaningful in a negotiation

...

...

between an entity that has a critical input for its core business and an

...

...

entity that is the monopoly supplier of that critical input.

...

...

...

...

Let us consider instead: why do we care whether terms in Registry

...

...

contracts

...

...

are "voluntary commitments"?

...

...

...

...

To put it another way, what is the wrong with ICANN imposing unwanted

...

...

terms

...

...

on Registries?

...

...

...

...

It seems to me that the very notion of "voluntary commitment" must be

...

...

intended as a meaning of protecting Registries from unreasonable

...

...

impositions

...

...

by ICANN. However the fear of ICANN making unreasonable impositions on

...

...

Registries is not the only or main reason why we want to limit ICANN to

...

...

acting within its Mission, so addressing the Mission limitation through

...

...

some

...

...

definition of what constitutes a "voluntary commitment" misses the point.

...

...

...

...

Limiting ICANN to its Mission is there to protect the entire community,

...

...

not

...

...

just Registries. Concerning the so-called "regulatory prohibition", that

...

...

prohibition is intended primarily to protect the interests of end-user

...

...

registrants, not those of Registries. We should be just as concerned if

...

...

ICANN tries to exceed its Mission as a result of a conspiracy between it

...

...

and

...

...

the Registries as we should if ICANN does so as a result of some other

...

...

motivation and then tries to impose requirements on Registries without

...

...

their

...

...

approval.

...

...

...

...

Accordingly, I am afraid I cannot agree with either your third proposition

...

...

or the assumption on which it rests.

...

...

...

...

In your question you ask "To what extent should contracted parties be free

...

...

to propose or voluntarily accept (and obligated to comply with) contract

...

...

provisions that exceed the scope of ICANN's Mission".

...

...

...

...

The answer to this is that contracted parties are not bound by ICANN's

...

...

bylaws, and so they are entirely free to enter into any contractual

...

...

relations they wish. However, ICANN is bound by its bylaws, and so is not

...

...

free to be the counterparty to a contract the purpose of which exceeds or

...

...

is

...

...

in contradiction with the Mission or other bylaws requirement.

...

...

...

...

Incidentally, I would point out that there is nothing unique about the

...

...

Mission limitation. If we were to adopt the view that ICANN is free enter

...

...

into an agreement with Registries for purposes beyond the Mission merely

...

...

because the Registries were eager for it to do so, by the same token ICANN

...

...

could then also disregard any other provision of the Bylaws that sought to

...

...

constrain how ICANN acts provided that Registries "voluntary" agreed to

...

...

that. That cannot be acceptable to anyone, surely.

...

...

...

...

Kind Regards,

...

...

...

...

Malcolm.

...

...

--

...

...

Malcolm Hutty | tel: +44 20 7645 3523

...

...

Head of Public Affairs | Read the LINX Public Affairs blog London

...

...

Internet Exchange |

...

...

https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.n et

...

...

_&d=CwICAg&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP 8W

...

...

DDkMr4k&m=S1JiVUQAqGB5VlxgFKlZdI4Kacb3MT5lpljmR0QprN0&s=EG_60KARwEuCkyZe jW

...

...

CL5HMy7C5FuGO58n8IlpW3_qE&e=

...

...

...

...

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

...

...

...

...

...

...

_______________________________________________

...

...

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=CwICAg&c=MOptNlVtIETeDALC_ lU

...

...

Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=S1JiVUQAqGB5VlxgFKlZ dI

...

...

4Kacb3MT5lpljmR0QprN0&s=a2j-IrQbQI8nnG8lowtub4eUpDPs20QHQrk9PfOuYak&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=CwIGaQ&c=MOptNlVtIETeDALC_ lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=5fp4l6_dpYabbqXJ5jI rneBaxcVshtWf2gPMv57CWQs&s=JDV_2OsfBpBzpvyOseePZwja8Hv4jP7-PUuBgt04DMU&e=

So if an applicant includes obligations in the application, it is ok for ICANN to enforce those commitments? What¹s the principle - freedom of contract? But if GAC, ALAC, or someone else urges ICANN to pick one applicant over another, anyone can challenge that [what? The urging, the selection, something else?]? You¹re disqualified if GAC endorses your application? 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 1/17/16, 2:58 PM, "Mueller, Milton L" <milton@gatech.edu> wrote:

...

-----Original Message-----

Just for the record, I am a strong supporter of community TLDs and therefore think these kinds of commitments should be enforceable

J. Beckwith Burr

Becky, this is a non sequitur.

The issue is not whether there can be or should be community TLDs, but whether the wider community that makes policy within ICANN, such as GNSO, ALAC or GAC, can impose enforceable commitments on proposed community TLDs as a condition of their acceptance. If the original proposer of the community TLD wants to bind themselves to do something (e.g., require all registrants to wear purple hats) I don't care. If GAC, GNSO, or ALAC conspire to get ICANN to reject a community TLD applicant because it doesn't require its registrants to wear purple hats, ICANN is straying from its mission.

Furthermore, if ICANN has two similar competing applicants for the same TLD string, and GAC, ALAC, GNSO or whoever urges ICANN to choose applicant A over applicant B because A promises to force all its registrants to wear purple hats, then that should be challengeable via IRP as exceeding ICANN's mission.

Do we agree on that much?

Dr. Milton L Mueller Professor, School of Public Policy Georgia Institute of Technology

Internet Governance Project

Not surprised by your answer Malcolm, trying to understand Milton’s previous post 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 1/18/16, 5:48 AM, "Malcolm Hutty" <malcolm@linx.net> wrote:

On 18/01/2016 01:54, Burr, Becky wrote:

...

So if an applicant includes obligations in the application, it is ok for ICANN to enforce those commitments?

Not for purposes inconsistent with ICANN's Mission, no.

It shouldn't be surprising that ICANN cannot escape the limits of its Bylaws simply by placing something inconsistent with them into a contract. If a Registry placed something in its application that would, if agreed, cause ICANN to act inconsistently with law that was applicable to ICANN, you wouldn't expect the contract to override applicable law. Nor should it override the governance of ICANN.

...

What¹s the principle - freedom of contract?

No.

The Registry's freedom of contract is not limited, subject to applicable law. But ICANN's is freedom of contract is additionally limited by the Bylaws.

-- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net _&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=-geSIHTWRl6DCSrH-kyHuqevO9FzKqljo-59nELlt3A&s=vhJ8-CLGiqVKgZB3af xAt1BCHnhYaoy3W9jEZ3EKJhM&e=

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

On 19/01/2016 03:32, Greg Shatan wrote:

​If (in your view) ICANN ca​nnot enforce obligations that an applicant includes in its application, who can enforce those obligations?

Greg, By calling them "obligations" you presuppose the correctness of your own position that ICANN should enforce them. Let us call them what they are: "statements concerning how the applicant intends to operate the Registry". Are all such statements obligations? Clearly not: the contract does not govern every aspect of registry operation; plenty of decisions are left to the commercial policy of the applicant, which it is free to alter over time.

If no one can enforce these obligations, then how can they even be called obligations?

They should not be. Please stop doing so.

What keeps applicants from pulling a "bait-and-switch," stating a series of "obligations" in their application, only to drop them after the application is approved.

The notion of "bait and switch" implies that there is a bait. In my view, ICANN should not regard as bait a promise to engage in an enterprise that ICANN has no legitimate right to pursue. Indeed, it would make sense in the next round to amend the applicant guidebook / application form in a way that strongly discourages applicants from offering up promises that ICANN ought to disregard.

Frankly, I think it is entirely within ICANN's mission to enforce obligations set out in applications.

Again, there you go pre-supposing the validity of your claim. Merely because something is written into an application doesn't make it something that ICANN must go along with. (If it does, I'll be submitting an application containing an "obligation" on me to receive a regular income from ICANN!). For something to be an obligation, it must be something that becomes part of the contract. ICANN should not be willing to write into its contracts objectives that it has no right nor interest to pursue. As part of its Mission to implement policies for which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS, ICANN may indeed enter into and enforce contracts to achieve those ends. It may not, however, enter into and enforce contracts entirely unconnected with those ends, or designed to pursue ends in conflict with its Mission and Bylaws.

It shouldn't be surprising that ICANN cannot escape the limits of its Bylaws simply by placing something inconsistent with them into a contract.

​However, this is not what Becky postulated. She postulated obligations ​placed in the agreement by the registry operator, not obligations placed in the agreement by ICANN.

There is no difference. A contract is an agreement. It is a joint enterprise, with both sides jointly engaged in the purpose of the contract (albeit, often with different tasks to undertake in pursuit of that enterprise). If the contract says "We will censor all mention of llamas from any web sites run on domains within this domain", then both the Registry and ICANN are engaged in the enterprise of suppressing mention of llamas. That it is the Registry's task in pursuit of this enterprise to send notices to registrants instructing them to remove articles mentioning llamas, and ICANN's task to consider whether the Registry has been sufficiently dilligent and effective at suppressing talk of llamas, are mere points of detail. In their respective roles, both ICANN and the Registry are llama-suppressors.

If a Registry placed something in its application that would, if agreed, cause ICANN to act inconsistently with law that was applicable to ICANN, you wouldn't expect the contract to override applicable law. Nor should it override the governance of ICANN.

​This answer only muddies the waters. We seem to have shifted somehow from potential obligations placed on the applicant to potential obligations placed on ICANN in the application that would then become part of the RA. I'm not sure where that shift came from.

There is no shift. The contract is a joint enterprise. Consider the following illustrative example. Suppose that an applicant said that they would operate their domain on a not-for-profit basis, and that any surplus accumulated in excess of operating requirements and a prudent reserve equivalent to n months operating income would be returned to registrants in the form of a regularly-awarded lottery prize. Running lotteries is, I believe, an activity that the State of California reserves to itself. Do you not think the California authorities might have something to say about ICANN procuring the creation and operation of lotteries that they consider illegal? Do you not think that were ICANN to seek to compel this registry to carry out its "obligation" to run a lottery, they would look at ICANN as a joint conspirator?

I'm not sure what "real world" examples of this there would be -- where a registry puts new obligations on ICANN. I think this is so rare as to be essentially not worth considering.

In that case you may wish to consult the IPC submission on this subject, which argues that it should be an obligation upon ICANN to enforce every provision of every contract.

Of course, if an application did require ICANN to break the law, I would expect that application to be rejected or modified, rather than having that obligation placed into an agreement. Indeed, if it were to ever get that far, a contractual provision that violated the law would be void as against public policy (at least under US law).

Wonderful! Now we're getting somewhere. All I am saying is that this should apply, not only in respect of statute law, but also in respect of ICANN's Articles and Bylaws (which are also a form of law, and capable of having legally enforceable consequences). This is perfectly normal and expected. That's why you're having to argue for additional text to disapply it, while those on my side of this argument are satisfied with the default position at law.

> What¹s the principle - freedom of > contract?

No.

The Registry's freedom of contract is not limited, subject to applicable law. But ICANN's is freedom of contract is additionally limited by the Bylaws.

​We are talking about a single contract here -- between a registry operator and ICANN.

No, we're not. The Registry is free to contract with other counter-parties, as it wishes, if they agree to contract with the Registry. The Registry's "freedom of contract" does not imply a right to compel ICANN to contract with it on the terms it offers, just as it does not imply a right to contract with you or me. ICANN ought to refuse to enter into contracts that aim at objectives outside the scope of its Mission (or which are incompatible with other elements of the Bylaws for that matter); the Bylaws ought to compel ICANN to make such refusal. Registries are not bound by the limits of ICANN's Mission, and are free to make contractually enforceable promises to others that choose to accept them. -- 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

Not confusing them Eric, but the issue has pre and post delegation implications. I asked about the disqualification if someone urges ICANN to pick for a reason outside ICANN¹s Mission because I have no idea how the ³challenge² that Milton is proposing could be accomplished. 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 1/18/16, 1:07 PM, "Eric (Maule) Brunner-Williams" <ebw@abenaki.wabanaki.net> wrote:

Becky,

Enforcement (after interpretation and examination of situational applicability) of some rule, e.g., applicant-assumed-obligation, occurs when the applicant has obtained a delegation. Selection amongst two or more applicants, for whatever reasons, and the AGB contained the rules applicable for the 2010 cohort, occurs before delegation.

The phrasing below confuses post-delegation and pre-delegation criteria and enforcements.

...

So if an applicant includes obligations in the application, it is ok for ICANN to enforce those commitments? What?s the principle - freedom of contract? But if GAC, ALAC, or someone else urges ICANN to pick one applicant over another, anyone can challenge that [what? The urging, the selection, something else?]? You?re disqualified if GAC endorses your application?

"freedom of contract" is inconsistent with the responsibilities of the NTIA and its contractors, and incompatible with a transition of a government contract, where pre-existing public interests are retained by the transitional contractor.

Eric Brunner-Williams Eugene, Oregon

-----Original Message----- So if an applicant includes obligations in the application, it is ok for ICANN to enforce those commitments?

Isn't that what you want?

What¹s the principle - freedom of contract?

You tell me what the principle is. It is your position. I am simply saying it is acceptable as long as it is truly a voluntary commitment I think the whole business of enforcing commitments that would be outside of mission if it were not voluntary is problematic, but you say you love it. So you tell me what you think the principle is.

But if GAC, ALAC, or someone else urges ICANN to pick one applicant over another, anyone can challenge that [what? The urging, the selection, something else?]? You¹re disqualified if GAC endorses your application?

This is an uncharacteristically exaggerated and leading question. Really, Becky, we've got enough rhetorical pollution in this discourse you don't need to add to it. Let's go through this step by step. The "urging" obviously cannot be challenged unless it becomes the basis of a decision. GAC shouldn't be endorsing individual applications AT ALL, as you should know, but if it does, it is only a problem if its endorsement is based on the applicant's adoption of commitments imposed on it by others, and the enforcement of which would exceed ICANN's mission. The endorsement of GAC is clearly not a problem if any commitments don't exceed the mission and/or ICANN's board does not approve the application. I hope that's clear now

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 1/17/16, 2:58 PM, "Mueller, Milton L" <milton@gatech.edu> wrote:

...

...

-----Original Message-----

Just for the record, I am a strong supporter of community TLDs and therefore think these kinds of commitments should be enforceable

J. Beckwith Burr

Becky, this is a non sequitur.

The issue is not whether there can be or should be community TLDs, but whether the wider community that makes policy within ICANN, such as GNSO, ALAC or GAC, can impose enforceable commitments on proposed community TLDs as a condition of their acceptance. If the original proposer of the community TLD wants to bind themselves to do something (e.g., require all registrants to wear purple hats) I don't care. If GAC, GNSO, or ALAC conspire to get ICANN to reject a community TLD applicant because it doesn't require its registrants to wear purple hats, ICANN is straying from its mission.

Furthermore, if ICANN has two similar competing applicants for the same TLD string, and GAC, ALAC, GNSO or whoever urges ICANN to choose applicant A over applicant B because A promises to force all its registrants to wear purple hats, then that should be challengeable via IRP as exceeding ICANN's mission.

Do we agree on that much?

Dr. Milton L Mueller Professor, School of Public Policy Georgia Institute of Technology

Internet Governance Project

I think this is a very useful discussion getting to the heart of the matter, so I would really like to encourage others to participate. Question - you say In other words, the idea that ICANN can "enforce" PICs without itself determining the standards that PICs seek to enforce simply doesn't stand up to scrutiny. As soon as ICANN is called on to enforce a PIC against a registry, it must necessarily assert that a particular kind of action is required by the PIC, and distinguish it from the action actually undertaken that the registry asserts to be sufficient. This is the core of regulatory activity. I have no problem whatsoever with ICANN engaging in this kind of regulatory behaviour for matters within its limited Mission, but if we invite ICANN to take this on for an unlimited range of objectives claimed to be in the public interest, we are essentially investing ICANN with a global policing power. Ok, but can ICANN enforce the part of the contract that says you can¹t register in the domain unless you are licensed by an appropriate authority? I understand that having rules for allocating new TLDs is reasonably necessary to ensure the stability and security of the DNS, but I don¹t understand how enforcing that the registry licensing requirement is (in and of itself) UNLESS you say that the delegation (community preference) was made on the basis of that commitment, and enforcing the commitments underlying the delegation decision is an inherent requirement of the policy itself. I¹m grasping for a principle here. 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 1/15/16, 11:22 AM, "Malcolm Hutty" <malcolm@linx.net> wrote:

Becky,

I agree that the existence of community applications has been an important part of the new gTLD process. I don't think the small limitation on the Mission we have agreed in the Third Draft Report would or should prevent ICANN creating new community TLDs in the future.

You give the example of .bank. I don't see anything in the Mission that inhibits ICANN in any way from saying that .bank has been created for the exclusive use of recognised banks, and that the only banks it recognises for this purpose are those with an appropriate banking license under applicable law.

This is quite different from regulating the behaviour of banks. If ICANN went on to say that any bank must report cash transactions over $10,000 to the US treasury, and any bank refused to do this it would take their domains away, then that would be an example of ICANN regulating the behaviour of banks, not of it identifying a particular user community. Though opponents of a limited Mission can try to blur this distinction with cleverly-constructed corner cases, I think this distinction is quite clear enough to be workable and to be objectively employed by an independent reviewer.

Turning to your example of environmental activists, I think it clear that if ICANN sets rules requiring disclosure of certain environmental practices then that is a clear example of behavioural regulation, that I don't think ICANN should be getting into. By contrast, if that registry promised to have a stakeholder council and then disbanded it, I think this would be a case of changing the organisational structure of the registry, no different from disbanding a customer complaints division (and no less objectionable).

In short, I think community TLDs should be allowed for identifiable communities; I don't think this carries any necessary implication that ICANN should get into the business of seeking to regulate the behaviour of the members of those communities (except as justified by reasons that actually are part of ICANN's Mission, of course).

To those who disagree, I would like to point out the inevitable consequences of going down this route.

Some say that the registry should be "made to uphold" these commitments, while still thinking that this doesn't require ICANN to begin creating such behavioural rules itself. I think this profoundly mistaken.

Suppose that a registry, such as for .eco, makes a commitment to enforce certain behaviour by its users, such as the publication of relevant environmental reports. As long as nobody is objecting, the fact that ICANN has contracted with the registry to do this doesn't really have any effect. The only time it matters is when someone complains.

The only way ICANN gets involved is when someone comes to ICANN and says ".eco promised to make their users disclose environmental reports and they're not doing so. Please enforce this requirement on the .eco registry".

What is ICANN supposed to do with this complaint? Proponents of PICS seem to think there is some magical wand that ICANN waives to bring .eco into compliance with its contract. This is nonsense. What actually happens is that ICANN contacts the registry and says "We've had a complaint you're not requiring publication of relevant reports, is this true? Please provide evidence that you are doing as you previously promised.". Most likely, the registry replies that they are in compliance with their commitment. The evidence offered, however, may well be open to differing interpretations: for example, .eco may have placed an extremely narrow definition on what constitutes a "relevant environmental report".

What is ICANN supposed to do next? On the one hand, it has a complainant, who can show that the registry is not doing certain things, and argues that those things are required by the PIC. On the other, it has a registry, which can show it is doing other things, and argues that those things are sufficient to discharge the promise it had previously made in the PIC.

It seems to me that there are really two options for how to proceed:

i) ICANN could be so deferential to the registry interpretation as to accept its position pretty much automatically: so long as the registry didn't simply admit non-compliance, and its claim to compliance wasn't manifestly ridiculous, ICANN could simply stop there. But what is the value in requiring ICANN to "enforce" PICs to such a limited standard? If that's all we're going to do, why not save ourselves a lot of bother (not to mention raising expectations from some stakeholders only to inevitably disappoint)?

ii) Alternatively, ICANN could investigate the case and come to its own view as to whether what the registry has done is sufficient to discharge its contractual obligation. However it can ONLY do that by first forming a view as to what the PIC requires. So in the putative case, ICANN could only enforce a requirement to make reasonable environmental disclosures if it itself determines what it considers constitutes a reasonable environmental disclosure. Likewise it can only enforce a commitment to prevent harassment by setting standards for what constitutes harassment, it can only enforce a commitment take down copyright infringing material by deciding whether particular publications infringe copyright, and it can only enforce a commitment to prevent access to certain web sites by minors by deciding both what age constitutes a minor, and what are acceptable means for identifying them and for excluding them from access.

In other words, the idea that ICANN can "enforce" PICs without itself determining the standards that PICs seek to enforce simply doesn't stand up to scrutiny. As soon as ICANN is called on to enforce a PIC against a registry, it must necessarily assert that a particular kind of action is required by the PIC, and distinguish it from the action actually undertaken that the registry asserts to be sufficient. This is the core of regulatory activity. I have no problem whatsoever with ICANN engaging in this kind of regulatory behaviour for matters within its limited Mission, but if we invite ICANN to take this on for an unlimited range of objectives claimed to be in the public interest, we are essentially investing ICANN with a global policing power.

Some may be happy to see ICANN go down that route. I would not: I think it has neither the capacity nor the legitimacy. But I am also worried by those who have managed to convince themselves that it is possible to enforce PICs for an unlimited range of purposes without itself becoming embroiled in setting the rules for those purposes. Those people are, I believe, simply kidding themselves.

Malcolm.

-- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net _&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=F3FlEVYbysKtCNonZguZbv90urP8qDBk_08KcwSbnzQ&s=ksR3GCVlhY-LMF3l9w mgX_POXp3jz25-xZ5f0KkUo-E&e=

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

I don?t understand how enforcing that the registry licensing requirement is (in and of itself) UNLESS you say that the delegation (community preference) was made on the basis of that commitment, and enforcing the commitments underlying the delegation decision is an inherent requirement of the policy itself. I?m grasping for a principle here.

I think your UNLESS branch is correct. Absent post-delegation enforcement, there is no cost for pre-delegation misrepresentation, and I suggest that were access to the IANA zone file to be misrepresentation-cost-free that the consequences could be abrupt. The principle is that access to the IANA zone(*) is conditional upon conduct, not entirely determined by mere fee alone. Eric Brunner-Williams Eugene, Oregon (*) currently property of the United States, a sort of contemporary Oregon joke for the US nationals on the list.

But Eric is probably wrong, even if this academic anyway.

Of course, but lets find out what the specific error is.

RFC 1591 is VERY clear on substantial misbehavior, probably only during the app lication phase, but most certainly also during tue application phase (as interp reted by the FoI Principles).

Jon submitted to Joyce the draft that was published as 1591 in the Winter of 1993-1994. At the moment, in the ccwg-acct list, the subject under discussion appears to me to be the enforcement of agreements contained in, or arising from, those delegations made after 1998, which were not made because of existing, or new allocations of iso3166-1 code points by the iso3166/MA. I do not recall Staff (that would be Louis) reliance upon 1591 when selecting 6-10 of the 41 new gTLD applications submitted to the Corporation in 2000, several of which I contributed to, and while tangential, when .us was transfered from the IANA to another operator, the NTIA did not take note of conditions existing during the IANA management period which were difficult to reconcile with the plain reading of 1591, which were continued after transition to another operator, and continue to the present. Similarly, I do not recall Staff (that would be several people, not just Louis) reliance upon 1591 when evaluating the 2004 sTLD applications, though of course the application for .cat was made with the plain reading of 1591 in mind. There was significant public comment on the next best 2004 application, which I'm confident Becky recalls -- I don't recall the issue of 1591 among the major critiques of the .xxx application. I'm confident that there are others contributing to the list who were involved in one or more applications in the 2010 round, and can offer their recollection of the import of 1591 language, section 2 in particular, in framing their application and any subsequent offers of conditions such as PIC statements. Of the linguistic and cultural and/or municipal and/or regional applications I contributed to or was informed of, as with the .cat application, these were made with the plain reading of 1591 in mind. I infer from your statement that my error lies in failing to discern the import of 1591 in the 2000 and/or 2004 and/or 2010 and/or subsequent, if any, processes which resulted in, or are likely to result in, delegations by the IANA function operator.

Never mind that i would be surprised that misrepresentations during the applica tion could not be sanctioned after delegation (in the agreement) ICANN could us e, in my view, RFC 1591 before execution of the agreement.

There is the history of .travel, and .pro, to name just two frequently mentioned over the past decade and a half, or more generally, the weakness of the compliance portion of the Corporation, whether directed at registrars, or at registries. However, as I understand it, the subject under discussion appears to me to be the enforcement of agreements contained in, or arising from, those delegations, with the past accomodated by "grandfathering" language, so the core issue is prospective enforcement, where the Applicant Guidebook is the primary source of authority, not 1591. Eric Brunner-Williams Eugene, Oregon

On 15/01/2016 22:53, Burr, Becky wrote:

I think this is a very useful discussion getting to the heart of the matter, so I would really like to encourage others to participate.

Thank you.

Ok, but can ICANN enforce the part of the contract that says you can¹t register in the domain unless you are licensed by an appropriate authority? I understand that having rules for allocating new TLDs is reasonably necessary to ensure the stability and security of the DNS, but I don¹t understand how enforcing that the registry licensing requirement is (in and of itself) UNLESS you say that the delegation (community preference) was made on the basis of that commitment, and enforcing the commitments underlying the delegation decision is an inherent requirement of the policy itself. I¹m grasping for a principle here.

To me, creating "community TLDs", that is, TLDs intended for the use of a particular community, seems a clear case of things that are entirely proper for ICANN to do as part of managing the root. And "banks" seem a perfectly coherent community, such that it is entirely reasonable for ICANN to seek to create a gTLD for the exclusive use of banks. Now it is proposed that domains in .bank should only be available to entities with a state-issued banking license. How should we interpret this? You ask:

I understand that having rules for allocating new TLDs is reasonably necessary to ensure the stability and security of the DNS, but I don¹t understand how enforcing that the registry licensing requirement is (in and of itself)

I don't think it's specifically about stability and security (except in the sense that some coordination is needed when new domains are created). But nor do I consider it an attempt by ICANN to regulate the behaviour of banks. What ICANN is doing, in the case of "only licensed banks", is creating a rule for recognising what is a bank, and distinguishing it from a non-bank. The need for some such rule is a necessary collorary of the notion of having a community TLD at all; if you can't find authority within the Mission for having such a rule, there is no authority to create community gTLDs at all, never mind the narrower questioning of whether licensing is a permissible requirement. I'm going to assume that authority for ICAN Nto create new gTLDs, to define a purpose for them, and to have serving a defined community as one of the potential purposes, can be found in the general statement that: "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 [...]" If not, we've a separate flaw we need to fix. So if ICANN is to make .bank only available to banks, it needs to ask itself, what is a "bank"? Is "A bank is an entity with a banking license?" an acceptable definition for ICANN to adopt? I think it is. For most people, a bank is any entity that has a banking license. If you don't have a banking license, you simply cannot be a bank: Honest Joe's Streetcorner Money Lending is not a real bank, and nobody is likely to confuse Joe for a bank, irrespective of licensing. Could you set up a proper bank without a license? Thanks to government regulation, this is impossible in practice whether or not you believe it conceptually valid: if you try, you'll be closed down overnight. So there's no such thing as an unlicensed bank. Now, from time to time some banks (as in any field) do things that they are not supposed to do. In doing some of these things, they may risk having their banking license removed. But mostly, they will just get fined when caught, not delicensed (which means, closed down). Suppose ICANN wrote those rules separately into the rules for .bank, and made its own adjudication as to whether a particular bank had breached them, and took their .bank domain away even though national authorities had not taken away the banking license. I think this would be overreaching by ICANN, of the sort we ought to constrain. Suppose instead that the (relevant) government decided to punish serious misbehaviour with removal of the only applicable banking license. That would effectively close the bank down: were ICANN also to require the cancellation of the relevant domain within .bank in such circumstances, that would not seem to me to be an overreach. This analysis shows that in the case of .bank using "is it licensed?" is a reasonable rule of recognising for whether someone is indeed a bank. It does NOT mean licensing - especially non-government forms of accreditation - will automatically be a reasonable rule for recognising members of different communities with differing characteristics. Consider, for example, an application for .cloud, a domain intended to be used by providers of cloud services, including consumer and enterprise storage hosting. If that Registry suggested that all registrants in .cloud must be licensed by "Greg Shatan's Copyright Compliance Squad - Guaranteed Infringement Free", I don't think that's merely a rule for recognising for what constitutes cloud storage; on the contrary, by writing Greg Shatan CCS into the registry ICANN would be writing a set of copyright compliance requirements for end registrants at one step removed. So not identify members of the community, but simply trying to control them. Of course, this doesn't stop the Registry concerned from requiring all registrants in their domain to sign up with Greg, but it's not ICANN's job to adopt such a requirement. For this reason I don't think "licensed entities only" is a Get-Out-Of-Jail-Free card for ICANN. Whether it is a legitimate rule depends on the context. For highly regulated sectors, it's likely to be reasonable to say "If you don't have a license to practice law/medicine/banking we don't consider you to be a real attorney/doctor of medicine/bank, and for that reason not eligible to register in .attorney/.doctor/.bank". In other cases, there is a much more compelling argument that you can be a legitimate member of the community without being licensed by the licensing authority ICANN has selected. .GAY springs to mind: I can't think of any legitimate excuse for ICANN to appoint an authority to "ensure registrants are legitimate members of the Gay Community". https://gtldresult.icann.org/application-result/applicationstatus/applicatio... Anyway, I hope that answers your question. One final aside: I have been speaking here about what I understand to be within and outside the scope of ICANN's Mission, not just what is prohibited by the "prohibition of regulation of services" clause. As that clause is narrowly drawn, some of the things I have described would not be specifically prohibited by that clause, but still (in my view) fall outside ICANN's Mission. 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

I don’t see how this is ICANN deciding what constitutes a bank. An applicant proposed a definition - you need a license that has the following characteristics - and ICANN accepted the applicant’s commitment to limit registration to entities possessing the necessary credentials. I suspect, on that basis, that a lot of financial institutions did not oppose the application on those grounds. Enforcement in this case means only that ICANN can require the applicant to do what it promised to do, and does not involve regulation of banks. 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 1/19/16, 5:02 PM, "Mueller, Milton L" <milton@gatech.edu> wrote:

It's unusual, but I find myself surprised at, and in strong disagreement with, Malcolm Hutty's points below. I am wondering whether Malcolm has abandoned his commitment to a limited mission for ICANN, or whether he does not understand that he is proposing to make ICANN into an international regulator of online banking.

Banking is not a "community" it is an industry. While it is a highly regulated industry, not all entities that use the word Bank in a prominent way are banks in the financial sense or subject to banking regulation, or are in any danger of deceiving people about their status as a repository for their money. Think of Food Bank, Blood Bank, etc.

Look at Malcolm's language:

...

And "banks" seem a perfectly coherent community, such that it is entirely reasonable for ICANN to seek to create a gTLD for the exclusive use of banks.

What? "ICANN" should not be seeking to create any gTLDs; _applicants_ should. If a registry proposes to run a .BANK tld and their business plan hinges on establishing its credible identity as a name space for (financial) banks, they have every incentive to maintain the reputation of the space and the consistency and integrity of registrations within the name space. There is no need for ICANN to become a bank regulator.

If a registry ends up running ANY tld in a way that facilitates or contributes to trademark violations and fraud, there are all kinds of existing regulations and laws to respond to that. You don't need to use registry contracts to enforce sectoral regulations on a tld string.

But this is the devil's bargain you get into with ICANN enforcing commitments that equate a TLD string's semantics with an industry and its regulatory commitments. If we put ICANN in charge of determining what a bank is and what policy a registry for banks should have, we have blown away mission limitations.

The idea that ICANN should be deciding what constitutes a bank, making policies based on a globalized decision as to what associations with the word bank are allowed or not allowed, and enforcing registry contracts designed to determine who is eligible to call themselves a bank, it is dangerous and all the more objectionable because it is so pointless.

...

-----Original Message----- From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Malcolm Hutty Sent: Monday, January 18, 2016 9:29 AM To: Burr, Becky <Becky.Burr@neustar.biz>; 'Accountability Community' <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

On 15/01/2016 22:53, Burr, Becky wrote:

...

I think this is a very useful discussion getting to the heart of the matter, so I would really like to encourage others to participate.

Thank you.

...

Ok, but can ICANN enforce the part of the contract that says you can¹t register in the domain unless you are licensed by an appropriate authority? I understand that having rules for allocating new TLDs is reasonably necessary to ensure the stability and security of the DNS, but I don¹t understand how enforcing that the registry licensing requirement is (in and of itself) UNLESS you say that the delegation (community preference) was made on the basis of that commitment, and enforcing the commitments underlying the delegation decision is an inherent requirement of the policy itself. I¹m grasping for a principle here.

To me, creating "community TLDs", that is, TLDs intended for the use of a particular community, seems a clear case of things that are entirely proper for ICANN to do as part of managing the root.

And "banks" seem a perfectly coherent community, such that it is entirely reasonable for ICANN to seek to create a gTLD for the exclusive use of banks.

Now it is proposed that domains in .bank should only be available to entities with a state-issued banking license. How should we interpret this?

You ask:

...

I understand that having rules for allocating new TLDs is reasonably necessary to ensure the stability and security of the DNS, but I don¹t understand how enforcing that the registry licensing requirement is (in and of itself)

I don't think it's specifically about stability and security (except in the sense that some coordination is needed when new domains are created). But nor do I consider it an attempt by ICANN to regulate the behaviour of banks. What ICANN is doing, in the case of "only licensed banks", is creating a rule for recognising what is a bank, and distinguishing it from a non-bank. The need for some such rule is a necessary collorary of the notion of having a community TLD at all; if you can't find authority within the Mission for having such a rule, there is no authority to create community gTLDs at all, never mind the narrower questioning of whether licensing is a permissible requirement.

I'm going to assume that authority for ICAN Nto create new gTLDs, to define a purpose for them, and to have serving a defined community as one of the potential purposes, can be found in the general statement that: "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 [...]"

If not, we've a separate flaw we need to fix.

So if ICANN is to make .bank only available to banks, it needs to ask itself, what is a "bank"? Is "A bank is an entity with a banking license?" an acceptable definition for ICANN to adopt? I think it is.

For most people, a bank is any entity that has a banking license. If you don't have a banking license, you simply cannot be a bank: Honest Joe's Streetcorner Money Lending is not a real bank, and nobody is likely to confuse Joe for a bank, irrespective of licensing. Could you set up a proper bank without a license? Thanks to government regulation, this is impossible in practice whether or not you believe it conceptually valid: if you try, you'll be closed down overnight. So there's no such thing as an unlicensed bank.

Now, from time to time some banks (as in any field) do things that they are not supposed to do. In doing some of these things, they may risk having their banking license removed. But mostly, they will just get fined when caught, not delicensed (which means, closed down). Suppose ICANN wrote those rules separately into the rules for .bank, and made its own adjudication as to whether a particular bank had breached them, and took their .bank domain away even though national authorities had not taken away the banking license. I think this would be overreaching by ICANN, of the sort we ought to constrain. Suppose instead that the (relevant) government decided to punish serious misbehaviour with removal of the only applicable banking license. That would effectively close the bank down: were ICANN also to require the cancellation of the relevant domain within .bank in such circumstances, that would not seem to me to be an overreach.

This analysis shows that in the case of .bank using "is it licensed?" is a reasonable rule of recognising for whether someone is indeed a bank. It does NOT mean licensing - especially non-government forms of accreditation - will automatically be a reasonable rule for recognising members of different communities with differing characteristics.

Consider, for example, an application for .cloud, a domain intended to be used by providers of cloud services, including consumer and enterprise storage hosting. If that Registry suggested that all registrants in .cloud must be licensed by "Greg Shatan's Copyright Compliance Squad - Guaranteed Infringement Free", I don't think that's merely a rule for recognising for what constitutes cloud storage; on the contrary, by writing Greg Shatan CCS into the registry ICANN would be writing a set of copyright compliance requirements for end registrants at one step removed. So not identify members of the community, but simply trying to control them.

Of course, this doesn't stop the Registry concerned from requiring all registrants in their domain to sign up with Greg, but it's not ICANN's job to adopt such a requirement.

For this reason I don't think "licensed entities only" is a Get-Out-Of-Jail-Free card for ICANN. Whether it is a legitimate rule depends on the context. For highly regulated sectors, it's likely to be reasonable to say "If you don't have a license to practice law/medicine/banking we don't consider you to be a real attorney/doctor of medicine/bank, and for that reason not eligible to register in .attorney/.doctor/.bank". In other cases, there is a much more compelling argument that you can be a legitimate member of the community without being licensed by the licensing authority ICANN has selected. .GAY springs to mind: I can't think of any legitimate excuse for ICANN to appoint an authority to "ensure registrants are legitimate members of the Gay Community".

https://urldefense.proofpoint.com/v2/url?u=https-3A__gtldresult.icann.org _application-2D&d=CwIFAw&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo 8TjDmrxdYahOP8WDDkMr4k&m=nPGWSPZJxul3zfA9P8qZMjnG3N_Ks3wZw3L7KP7k32M&s=Ek 1lDzaRBzEkWMxkDEti7btpv65cequn_CsMjGcjLBk&e= result/applicationstatus/applicationdetails/444

Anyway, I hope that answers your question. One final aside: I have been speaking here about what I understand to be within and outside the scope of ICANN's Mission, not just what is prohibited by the "prohibition of regulation of services" clause. As that clause is narrowly drawn, some of the things I have described would not be specifically prohibited by that clause, but still (in my view) fall outside ICANN's Mission.

Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.ne t_&d=CwIFAw&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP 8WDDkMr4k&m=nPGWSPZJxul3zfA9P8qZMjnG3N_Ks3wZw3L7KP7k32M&s=pqiv7Ch0i088teM dxNsVyizNa_l1j_TGCRsarqENxWI&e=

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

_______________________________________________ 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=CwIFAw&c=MOptNlVtIETeDALC_ lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=nPGWSPZJxul3zfA9P8q ZMjnG3N_Ks3wZw3L7KP7k32M&s=3EbySmANsjC4SV3aohVamoV_AEzU-VBo6aCvjx3LsLQ&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=CwIFAw&c=MOptNlVtIETeDALC_lU Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=nPGWSPZJxul3zfA9P8qZMj nG3N_Ks3wZw3L7KP7k32M&s=3EbySmANsjC4SV3aohVamoV_AEzU-VBo6aCvjx3LsLQ&e=

Hi, On Wed, Jan 20, 2016 at 12:30:40AM +0000, Malcolm Hutty wrote:

and that item 1 is a legitimate choice as an exercise of ICANN's authority within its Mission, and that (2) is an objectively reasonable definition for ICANN to adopt as part of implementing that choice.

As I tried to state on the call today (alas, I think I was not entirely coherent, so my apologies), I think even the above takes us a little too far. I don't think Malcolm and I disagree too much here, but I'm leery of the ratholes lurking under the cover "objectively reasonable definition". But I don't think we need to rely on it. I believe that the reason ICANN has something to enforce in gTLD contracts is because ICANN is making a decision [1] about delegating a name from the root zone. ICANN makes that decision based on information it has before it, including the various operational constraints that an applicant is offering to undertake. Because this is a matter of a contract between ICANN and some other party, ICANN has the right and (at least arguably) responsibility to enforce the terms of the contract. So, imagine someone applies for the TLD foobar and claims that every registrant beneath foobar must bar foos, and must be able to show that by virtue of the baz certificate they get from Bob's Bait Shop and Notary on Main Street. Imagine that ICANN agrees to this and delegates on that basis. In that case, that's what ICANN has to enforce. Note that what ICANN is enforcing is someone else's commitments on the basis of which ICANN did something (decided to permit a delegation). For that state to persist, ICANN needs to enforce the terms, or else admit that its policy control over the root zone is meaningless because people can offer anything and then just change their mind later. I believe the tightened mission and new powers nevertheless conspire to discourage such agreements. First of all, because of the clarified mission, ICANN can (and should) use judgement to refuse to embroil itself in some of these kinds of TLD schemes. The more the scheme looks like, "We're going to impose rules on what people can do all the way down the tree," the more ICANN should say, "We're not interested." If a term can't effectively be enforced (and "carries down the tree" rules can't be, in effect, without dedelgating the top of the tree), ICANN should stay away. More generally, anything that takes ICANN far afield of its narrow mission should be avoided. But second, ICANN the corporation doesn't need to do that alone any more, because the empowered community gives the corporation the foundation from which to refuse such requests. "We'd love to, but our community doesn't want us to do those sorts of things and they wrote the bylaws to prove it." And if ICANN the corporation does not act that way, and the community objects, the community will now have the tools necessary to reign in such regulatory and contractual adventures. "Oh," you may say, "But what if the community supports the foo barring, and discriminates against foos and is generally bad?" I agree that is a danger, but I claim there is no set of rules we could write that will avoid that danger. The entire accountability effort depends on the empowered community. If the community decides to neglect its responsibilities in this area, then it will be impossible to ensure such decisions don't get out of hand, regardless of what the decisions are. Best regards, A [1] The mechanics of who actually performs the delegation by putting the string in a zone file are not relevant to this. As far as I know, nobody disputes that ICANN gets to make the decision. -- Andrew Sullivan ajs@anvilwalrusden.com

FWIW, I am in full agreement with Avri on this. Though unconnected to the current subject, as I have indicated in the past, I am not sure the community powers as proposed in the current 3rd proposal will adequately respect and the outcome of a PDP. I think an interesting future is in the making and I just hope our intent of building a better ICANN would be experienced. Ofcourse the intent is most likely share by all. Regards On 20 Jan 2016 06:02, "Avri Doria" <avri@acm.org> wrote:

Hi,

Perhaps I am misunderstanding the conversation ongoing on this list, but this seems more like gTLD policy making than clarifying without changing the mission. It is almost as if we want to preclude the freedom of the GNSO to make bottom up multistakeholder decisions about gTLDs or community gTLDs that may be decided upon in the future.

We are getting into a very murky issue that is still the subject of reconsideration, CEP and IRP processes. In fact more all the time.

I think we are trying to do too much at the last minute with manipulation of the mission to meet people's political ideas about what ICANN should and should not do. My suggestions is that we go back to the wording for draft 3 and just make the minimal changes needed by the the IETF and the RIRs and leave discussions about ICANN's mission for WS2 or elsewhen - this is a long discussion we are embarking on.

Personally I am very committed to the policies that the GNSO initiated on communities and while I think there is a lot of work to do on them in the next PDP, I do not think it is work that is appropriate at this point in time for this process. We are supposed to be working on accountability not the mission or the gTLD program. but if this is going to become a question about what is acceptable in terms of communities, their commitments and the contracts they make with ICANN on behalf of the communities they intend to serve, I will have a whole lot more to say. I am currently saving those arguments for the subsequent gTLD PDP, but if those issues need to be fought here and now, I guess I am willing.

Is this part of the WS1 task? If so, why? I do not think this is part of the requirement for WS1 and transition.

avri

--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

Hi, I find myself agreeing with Becky on this short and to the point summary on ICANN's enforcement scope. When Milton says "...ICANN" should not be seeking to create any gTLDs; _applicants_ should" While I agree that applicants could indeed do this, I don't think there is anything wrong with ICANN doing that as well (ofcourse not delegating them without an applicant applying). There are instances where the record manager(a typical cctld or ICANN) may want to do that. For instance, within the ccTLD of my county, there are strings referred to as premium which have different pricing by default. The organisation NIRA builds a list of those premium strings, and every applicant knows this when he/she is applying. So while applicants have the freedom of been creative about the name he is applying for, if the creativity touches on those already imagined/listed by NIRA then he follows the process required to getting such string. Don't know if ICANN has similar process but I know within ICANN, there is usually auction for more than one qualified applicant to a name. I don't think anything should restrict ICANN from indeed going the route of reserving some names as premiums (if it suits their business strategy). Regards On 20 Jan 2016 00:40, "Burr, Becky" <Becky.Burr@neustar.biz> wrote:

I don’t see how this is ICANN deciding what constitutes a bank. An applicant proposed a definition - you need a license that has the following characteristics - and ICANN accepted the applicant’s commitment to limit registration to entities possessing the necessary credentials. I suspect, on that basis, that a lot of financial institutions did not oppose the application on those grounds. Enforcement in this case means only that ICANN can require the applicant to do what it promised to do, and does not involve regulation of banks.

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 1/19/16, 5:02 PM, "Mueller, Milton L" <milton@gatech.edu> wrote:

...

It's unusual, but I find myself surprised at, and in strong disagreement with, Malcolm Hutty's points below. I am wondering whether Malcolm has abandoned his commitment to a limited mission for ICANN, or whether he does not understand that he is proposing to make ICANN into an international regulator of online banking.

Banking is not a "community" it is an industry. While it is a highly regulated industry, not all entities that use the word Bank in a prominent way are banks in the financial sense or subject to banking regulation, or are in any danger of deceiving people about their status as a repository for their money. Think of Food Bank, Blood Bank, etc.

Look at Malcolm's language:

...

And "banks" seem a perfectly coherent community, such that it is entirely reasonable for ICANN to seek to create a gTLD for the exclusive use of banks.

What? "ICANN" should not be seeking to create any gTLDs; _applicants_ should. If a registry proposes to run a .BANK tld and their business plan hinges on establishing its credible identity as a name space for (financial) banks, they have every incentive to maintain the reputation of the space and the consistency and integrity of registrations within the name space. There is no need for ICANN to become a bank regulator.

If a registry ends up running ANY tld in a way that facilitates or contributes to trademark violations and fraud, there are all kinds of existing regulations and laws to respond to that. You don't need to use registry contracts to enforce sectoral regulations on a tld string.

But this is the devil's bargain you get into with ICANN enforcing commitments that equate a TLD string's semantics with an industry and its regulatory commitments. If we put ICANN in charge of determining what a bank is and what policy a registry for banks should have, we have blown away mission limitations.

The idea that ICANN should be deciding what constitutes a bank, making policies based on a globalized decision as to what associations with the word bank are allowed or not allowed, and enforcing registry contracts designed to determine who is eligible to call themselves a bank, it is dangerous and all the more objectionable because it is so pointless.

...

-----Original Message----- From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Malcolm Hutty Sent: Monday, January 18, 2016 9:29 AM To: Burr, Becky <Becky.Burr@neustar.biz>; 'Accountability Community' <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Deck for Meeting #75 Mission Statement discussion

On 15/01/2016 22:53, Burr, Becky wrote:

...

I think this is a very useful discussion getting to the heart of the matter, so I would really like to encourage others to participate.

Thank you.

...

Ok, but can ICANN enforce the part of the contract that says you can¹t register in the domain unless you are licensed by an appropriate authority? I understand that having rules for allocating new TLDs is reasonably necessary to ensure the stability and security of the DNS, but I don¹t understand how enforcing that the registry licensing requirement is (in and of itself) UNLESS you say that the delegation (community preference) was made on the basis of that commitment, and enforcing the commitments underlying the delegation decision is an inherent requirement of the policy itself. I¹m grasping for a principle here.

To me, creating "community TLDs", that is, TLDs intended for the use of a particular community, seems a clear case of things that are entirely proper for ICANN to do as part of managing the root.

And "banks" seem a perfectly coherent community, such that it is entirely reasonable for ICANN to seek to create a gTLD for the exclusive use of banks.

Now it is proposed that domains in .bank should only be available to entities with a state-issued banking license. How should we interpret this?

You ask:

...

I understand that having rules for allocating new TLDs is reasonably necessary to ensure the stability and security of the DNS, but I don¹t understand how enforcing that the registry licensing requirement is (in and of itself)

I don't think it's specifically about stability and security (except in the sense that some coordination is needed when new domains are created). But nor do I consider it an attempt by ICANN to regulate the behaviour of banks. What ICANN is doing, in the case of "only licensed banks", is creating a rule for recognising what is a bank, and distinguishing it from a non-bank. The need for some such rule is a necessary collorary of the notion of having a community TLD at all; if you can't find authority within the Mission for having such a rule, there is no authority to create community gTLDs at all, never mind the narrower questioning of whether licensing is a permissible requirement.

I'm going to assume that authority for ICAN Nto create new gTLDs, to define a purpose for them, and to have serving a defined community as one of the potential purposes, can be found in the general statement that: "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 [...]"

If not, we've a separate flaw we need to fix.

So if ICANN is to make .bank only available to banks, it needs to ask itself, what is a "bank"? Is "A bank is an entity with a banking license?" an acceptable definition for ICANN to adopt? I think it is.

For most people, a bank is any entity that has a banking license. If you don't have a banking license, you simply cannot be a bank: Honest Joe's Streetcorner Money Lending is not a real bank, and nobody is likely to confuse Joe for a bank, irrespective of licensing. Could you set up a proper bank without a license? Thanks to government regulation, this is impossible in practice whether or not you believe it conceptually valid: if you try, you'll be closed down overnight. So there's no such thing as an unlicensed bank.

Now, from time to time some banks (as in any field) do things that they are not supposed to do. In doing some of these things, they may risk having their banking license removed. But mostly, they will just get fined when caught, not delicensed (which means, closed down). Suppose ICANN wrote those rules separately into the rules for .bank, and made its own adjudication as to whether a particular bank had breached them, and took their .bank domain away even though national authorities had not taken away the banking license. I think this would be overreaching by ICANN, of the sort we ought to constrain. Suppose instead that the (relevant) government decided to punish serious misbehaviour with removal of the only applicable banking license. That would effectively close the bank down: were ICANN also to require the cancellation of the relevant domain within .bank in such circumstances, that would not seem to me to be an overreach.

This analysis shows that in the case of .bank using "is it licensed?" is a reasonable rule of recognising for whether someone is indeed a bank. It does NOT mean licensing - especially non-government forms of accreditation - will automatically be a reasonable rule for recognising members of different communities with differing characteristics.

Consider, for example, an application for .cloud, a domain intended to be used by providers of cloud services, including consumer and enterprise storage hosting. If that Registry suggested that all registrants in .cloud must be licensed by "Greg Shatan's Copyright Compliance Squad - Guaranteed Infringement Free", I don't think that's merely a rule for recognising for what constitutes cloud storage; on the contrary, by writing Greg Shatan CCS into the registry ICANN would be writing a set of copyright compliance requirements for end registrants at one step removed. So not identify members of the community, but simply trying to control them.

Of course, this doesn't stop the Registry concerned from requiring all registrants in their domain to sign up with Greg, but it's not ICANN's job to adopt such a requirement.

For this reason I don't think "licensed entities only" is a Get-Out-Of-Jail-Free card for ICANN. Whether it is a legitimate rule depends on the context. For highly regulated sectors, it's likely to be reasonable to say "If you don't have a license to practice law/medicine/banking we don't consider you to be a real attorney/doctor of medicine/bank, and for that reason not eligible to register in .attorney/.doctor/.bank". In other cases, there is a much more compelling argument that you can be a legitimate member of the community without being licensed by the licensing authority ICANN has selected. .GAY springs to mind: I can't think of any legitimate excuse for ICANN to appoint an authority to "ensure registrants are legitimate members of the Gay Community".

https://urldefense.proofpoint.com/v2/url?u=https-3A__gtldresult.icann.org

...

_application-2D&d=CwIFAw&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo 8TjDmrxdYahOP8WDDkMr4k&m=nPGWSPZJxul3zfA9P8qZMjnG3N_Ks3wZw3L7KP7k32M&s=Ek 1lDzaRBzEkWMxkDEti7btpv65cequn_CsMjGcjLBk&e= result/applicationstatus/applicationdetails/444

Anyway, I hope that answers your question. One final aside: I have been speaking here about what I understand to be within and outside the scope of ICANN's Mission, not just what is prohibited by the "prohibition of regulation of services" clause. As that clause is narrowly drawn, some of the things I have described would not be specifically prohibited by that clause, but still (in my view) fall outside ICANN's Mission.

Malcolm. -- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange |

https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.ne

...

t_&d=CwIFAw&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP 8WDDkMr4k&m=nPGWSPZJxul3zfA9P8qZMjnG3N_Ks3wZw3L7KP7k32M&s=pqiv7Ch0i088teM dxNsVyizNa_l1j_TGCRsarqENxWI&e=

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

_______________________________________________ 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=CwIFAw&c=MOptNlVtIETeDALC_ lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=nPGWSPZJxul3zfA9P8q ZMjnG3N_Ks3wZw3L7KP7k32M&s=3EbySmANsjC4SV3aohVamoV_AEzU-VBo6aCvjx3LsLQ&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=CwIFAw&c=MOptNlVtIETeDALC_lU Lrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=nPGWSPZJxul3zfA9P8qZMj nG3N_Ks3wZw3L7KP7k32M&s=3EbySmANsjC4SV3aohVamoV_AEzU-VBo6aCvjx3LsLQ&e=

_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

Are you asking for my views on 3.18 of the RAA? I think I am on record on that one. I have no problem with the RAA requiring registrars to get registrants to agree to comply with all applicable laws, including trademark and consumer protection laws. I have no problem with the RAA requiring registrars to get registrants to agree to abide by the outcome of a UDRP or a rapid suspension process. I believe that requiring registrars to maintain an abuse point of contact and to respond to reports appropriately is reasonably within the picket fence. I don¹t believe that registrars can reasonably or appropriately be required to make legal determinations about whether some registrant behavior constitutes a violation of law in they myriad jurisdictions in which they do business. Although I can conceive of ways that ICANN might attempt to enforce 3.18 that are inconsistent with the intent of the provision and exceed the scope of ICANN¹s Mission, I am not aware that ICANN has engaged in any effort to do so. At the same time, I do believe registries and registrars should be free to establish the terms and conditions under which they will do business with registrants, including the right to not accept and/or to terminate registrations that violate their terms and conditions. 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 1/20/16, 8:50 AM, "Mueller, Milton L" <milton@gatech.edu> wrote:

Becky: I noticed that you did not respond to this point:

...

...

If a registry ends up running ANY tld in a way that facilitates or contributes to trademark violations and fraud, there are all kinds of existing regulations and laws to respond to that. You don't need to use registry contracts to enforce sectoral regulations on a tld string.

Care to give it a try?

--MM

Eric

-----Original Message----- At no point did our longer, and, in my opinion, better informed, discussion, arrive at the rhetorical point of departure one CCWG-ACCT contributor has just offered, that of "make ICANN into an international regulator of online banking".

That's because you were talking about a completely different issue, namely the establishment of a verification or certification process of TLDs as "high security." This would have been a third-party verification seal and unrelated to the semantics of the domain, and thus your contribution is not relevant at all to the discussion we are having. --MM

Sorry, sloppy grammar on my part. I don¹t think that ICANN exceeds its mission by delegating a new gTLD designed to serve a particular community. In fact, I am a very strong proponent of community TLDs, and I regret that the new gTLD policy does not accommodate them better. My concern is that some of the commitments made by applicants in order to serve that community may not be ³reasonably necessary to ensure stability and security² of the DNS, etc., and so ICANN¹s enforcement of those commitments could be challenged. That seems quite problematic to me. 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 1/14/16, 1:38 PM, "Eric (Maule) Brunner-Williams" <ebw@abenaki.wabanaki.net> wrote:

Becky,

My appologies for not picking this nit earlier.

...

"To what extent should contracted parties be free to propose or voluntarily accept (and obligated to comply with) contract provisions that exceed the scope of ICANN's Mission, e.g., to serve a specific community, pro-actively address a public policy concern?

When I wrote one of the several proposals that came out of Working Group C - new gTLDs Interim Report, October 23th, 1999 [1], it was for the purpose of providing service to a specific community. Later the concept of a Sponsoring Organization capable of suplementing the (then rather sparse) requirements of ICANN's registry contracts with additional policy goals and mechanisms was incorporated into the Sponsored TLD, then referred to as "sTLD" form pursued by the applicants for .aero, .coop, and .museum, among the original "6-10" applications selected for the 2000 round of new TLDs by (a very much smaller) staff.

For completeness, these 2000 round appliccations were for sponsored TLDs: .air, .biz, .co-op, .dir, .dubai, .event, .fin, .geo, .health, .kids, .mas, .mus, .nom, .post, .tel, .travel, and .union.

Note that .air became .aero, .co-op became .coop, and .mus became .museum, and the sponsored .biz application came from an applicant other than JVTeam.

Subesequently, in the 2004 round several of these were approved: .asia, .cat, .jobs, .mobi, .tel and .travel.

The nit I'm picking is "... provisions that exceed the scope of ICANN's Mission, e.g., to serve a specific community ...", as that has been broadly seen as within ICANN's Mission, until this moment.

Eric Brunner-Williams Eugene, Oregon

[1] https://urldefense.proofpoint.com/v2/url?u=http-3A__www.dnso.org_dnso_note s_19991023.NCwgc-2Dreport.html-23Position-2520Paper-2520E&d=CwIFAg&c=MOptN lVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=crEHqTdH _Oqzn374ZdLH1V7nFEmsR0dQAeZDEayMnTo&s=17VZUKR5k5rVGyHEJOndI3rRBoIODG9s0vHP 77937Zc&e=