Thanks Malcolm. I will have to review the comments you¹ve submitted for the specific propositions. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz <http://www.neustar.biz> On 11/10/15, 7:55 PM, "Malcolm Hutty" <malcolm@linx.net> wrote:

Dear Becky,

According to our charter, the following definitions are used: a) Full Consensus - a position where no minority disagrees; identified by an absence of objection b) Consensus ­ a position where a small minority disagrees, but most agree

See https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_d isplay_acctcrosscomm_Charter&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifz m6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=meioLcwo4WoKkpjbb8u-zgp25NiZ0ljNmk77u -KFnfI&s=vuS0ygH1S_caOlGOjf5UrjN2jLRgPKyjKzjzdS825Y8&e=

I am writing to supply evidence that two of your consensus level estimations are not consistent with these standards.

I am writing to disagree with your estimation of the level of consensus on certain points.

...

o To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.

/NOTE: There is not ³full consensus² on this position/.

To the extent that this principle as stated would override the principle that ICANN should not seek to regulate the content of web sites or the general business practices of domain registrants (parties who have no privity of contract with ICANN), I believe there is widespread disagreement with your proposal in evidence in the public comment record.

Please find attached 11 comment extracts from the first public comment period. I have chosen these 11 comments as being examples that clearly and unequivocally expresses opposition to your proposed principle, to the extent stated above. These comments come from a broad range of stakeholders, including a Congressional Resolution.

I therefore content that the correct assessment is that there is *no consensus* in favour of this principle.

...

*We do not appear to have consensus on the following concept*: /Without in any way limiting the foregoing absolute prohibition, ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide./

The same attached comments express clear support for this concept, and in many cases explicit endorsement of the wording.

The only criticism of it in the public comment was from the intellectual property stakeholders spread across BC/IPC.

Since there is both broadly based support and the only objections to this principle come from a narrow segment of the community, I contend that the proper assessment is that this principle *has achieved consensus, stopping short of full consensus*.

...

Coordinating development, implementation, and enforcement of Consensus Policy, as defined by Specification 1 of the New gTLD Registry Agreement and Specification 4 of the 2013 Registrar Accreditation Agreement, is within ICANN¹s Mission.

Becky, I'm afraid the only person who keeps coming back to Specification 1/Spec 4 as an adequate statement of the bounds of the Mission is you. And whenever you do so, it is challenged.

I don't think you have any basis whatsoever for claiming that this group as a whole has selected these documents as its view of the best or most appropriate way to define or describe the parameters of the Mission, let alone the best mechanism for recording those parameters.

I contend that the text in the first and second public comment rounds has a much better claim to represent a consensus view of how to draw the bounds of ICANN's Mission in this area. Unlike those demanding further changes, I offer evidence in support of this claim, in the form of the attached document.

It seems to me deeply regretable and contrary to our declared aims of transparency and inclusion to disregard both the general tenor and explicit recommendations of the public comment, and to allow vitally important last minute changes to be pushed through at the behest of a small group merely because that group has greater stamina for conducting a war of attrition.

Removing the widely popular restriction on ICANN's Mission would dishonour the public comment. For that reason, this group really ought not to support your proposal. Public comment replies should matter.

There being no new proposal that has reached consensus and that still honours the public comment response, the only proper course is to proceed with the existing text. Those few that disagree may be invited submit a minority statement, should they wish to do so.

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=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=meioLcwo4WoKkpjbb8u-zgp25NiZ0ljNmk77u-KFnfI&s=Otta_4g1f9RBJbUkPa ovRLs9e9UkRYWqz25dWn6TU1Y&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 11/11/2015 02:10, Burr, Becky wrote:

Malcolm et al:

I have to agree that the 11 comments appended by Malcolm express strong support for the notion that ICANN should not use its contractual authority to ³regulate services that use the DNS or the regulation of content these services carry or provide² and that ICANN should not attempt to establish obligations on non-contracted parties.² But the very commenters cited (BC, USCIB, etc.)

Do you mean to imply that more than those two did?

also request clarification regarding ICANN¹s authority to enforce its contracts. What are we to make of this?

That's misleading. They didn't make a generalised, open-ended request for clarification that opens the door to you to construct an entirely new principle inconsistent with the main principle. They had a proposal of their own. BC said: BC strongly support the proposition that ICANN should not attempt to establish obligations on non-contracted parties. Paragraph 60 should be clarified and we propose that it should read as follows: “ICANN shall not engage in or use its powers to attempt to establish contractual obligations on companies with which it is not in privity of contract and shall not attempt to establish contractual obligations on contracted parties that are not agreed by such parties.” Similarly, USCIB said: Indeed, ICANN’s entire multi-stakeholder structure is built on a self-regulatory system implemented through contractual obligations and thus ICANN can only establish contractual obligations on parties with which it has privity through a negotiated and mutually agreeable contract/amendment with such parties. Therefore, para 60 should be clarified and we propose that it should read as follows: “ICANN shall not engage in or use its powers to attempt to establish contractual obligations on companies with which it is not in privity of contract and shall not attempt to establish contractual obligations on contracted parties that are not agreed by such parties.” This new language is simply not consistent with the proposition that ICANN should have any ability to enter into contracts with Registries for the purpose of regulating (or controlling, or any-of-a-number-of-other-verbs) the companies who register domain names, their business models or the content those companies carry on their web sites. Doing any of those things would entail "establishing contractual obligations on companies with which it [ICANN] is not in privity of contract", which is precisely what they say ICANN must not do.

With all due respect Malcolm, I will take a back seat to no one as a consistent and ardent defender of ICANN¹s limited mission.

Take care, Becky. You are starting to make it sound as though your own self-image as the defender of ICANN's limited mission is getting in the way of recognising other input with that same aim, but with which you personally disagree.

So I will restate the specific questions for the CCWG:

1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.²

The expressed view of these 11 commenters (including, I note, the formal submission of the BC) clearly gives their answer to this question as "disagree", at least inasmuch as those obligations impose further obligations on third parties (registrants) that limit what content they may carry or provide on their web sites and suchlike services. There is simply no fair reading of these 11 commenters' submissions that could answer this question as "agree", without first adding very substantial qualifications to the generality of your proposition.

2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.² - Wherever you land, please explain what you mean by ³regulate² and ³services."

9 of these 11 have said they agree, and accept the wording - so they don't accept your suggestion that the words "regulate" or "services" are unclear in the context used in the Draft Report. 2 of these 11 have also said they agree, but propose alternate wording to achieve that; you may consider this wording, quoted above, as responsive to your question about defining "regulate" and "services".

I would be very interested in responses to these specific an limited questions.

-- 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

Could I get you to expand on one point Robin, Paul and others? To the extent ICANN obligates registrars to make registrants agree to submit to a UDRP, is that regulation of parties not in privity of contract with ICANN? What about the requirement that registrants provide accurate WHOIS Information. What about the new gTLD applicant guidebook prohibition on Strings at the top level that advocate behavior that violateS globally accepted human rights standards? These examples are things that ICANN does right now. Are they ultra vires under the regulatory prohibition? If not, why not? Sent from my iPad

On Nov 11, 2015, at 8:30 AM, Robin Gross <robin@ipjustice.org> wrote:

I do not agree that there lacks consensus on including the text which states ICANN won't regulate content. There IS consensus on that point, but not full consensus because a small minority disagrees with that position (IPC). Some in the BC don't even take this extreme IPC position.

Many different parts of the community have commented that this is a crucial component to our proposed accountability plan, so taking it out at this stage, simply because the IPC won't relent is unacceptable. The other parts of the community have to accept that we don't always get everything we want, and I find it difficult to understand why the same standard doesn't apply to the IPC - why we continue to go in circles until the IPC is satisfied. These extra bites at the apple must stop. We need some strength and backbone in our chairs and rapporteurs to not allow a small minority to impose this on the rest of the community, simply by refusing to relent until time runs out.

Deleting this point, which has been repeatedly stated as crucial for such a wide segment of the community will create much more trouble for the acceptance of our report than not allowing the IPC to get everything it wants.

Robin

...

On Nov 10, 2015, at 7:19 PM, Malcolm Hutty wrote:

...

On 11/11/2015 02:10, Burr, Becky wrote: Malcolm et al:

I have to agree that the 11 comments appended by Malcolm express strong support for the notion that ICANN should not use its contractual authority to ³regulate services that use the DNS or the regulation of content these services carry or provide² and that ICANN should not attempt to establish obligations on non-contracted parties.² But the very commenters cited (BC, USCIB, etc.)

Do you mean to imply that more than those two did?

...

also request clarification regarding ICANN¹s authority to enforce its contracts. What are we to make of this?

That's misleading. They didn't make a generalised, open-ended request for clarification that opens the door to you to construct an entirely new principle inconsistent with the main principle. They had a proposal of their own.

BC said:

BC strongly support the proposition that ICANN should not attempt to establish obligations on non-contracted parties. Paragraph 60 should be clarified and we propose that it should read as follows: “ICANN shall not engage in or use its powers to attempt to establish contractual obligations on companies with which it is not in privity of contract and shall not attempt to establish contractual obligations on contracted parties that are not agreed by such parties.”

Similarly, USCIB said:

Indeed, ICANN’s entire multi-stakeholder structure is built on a self-regulatory system implemented through contractual obligations and thus ICANN can only establish contractual obligations on parties with which it has privity through a negotiated and mutually agreeable contract/amendment with such parties. Therefore, para 60 should be clarified and we propose that it should read as follows: “ICANN shall not engage in or use its powers to attempt to establish contractual obligations on companies with which it is not in privity of contract and shall not attempt to establish contractual obligations on contracted parties that are not agreed by such parties.”

This new language is simply not consistent with the proposition that ICANN should have any ability to enter into contracts with Registries for the purpose of regulating (or controlling, or any-of-a-number-of-other-verbs) the companies who register domain names, their business models or the content those companies carry on their web sites. Doing any of those things would entail "establishing contractual obligations on companies with which it [ICANN] is not in privity of contract", which is precisely what they say ICANN must not do.

...

With all due respect Malcolm, I will take a back seat to no one as a consistent and ardent defender of ICANN¹s limited mission.

Take care, Becky. You are starting to make it sound as though your own self-image as the defender of ICANN's limited mission is getting in the way of recognising other input with that same aim, but with which you personally disagree.

...

So I will restate the specific questions for the CCWG:

1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.²

The expressed view of these 11 commenters (including, I note, the formal submission of the BC) clearly gives their answer to this question as "disagree", at least inasmuch as those obligations impose further obligations on third parties (registrants) that limit what content they may carry or provide on their web sites and suchlike services.

There is simply no fair reading of these 11 commenters' submissions that could answer this question as "agree", without first adding very substantial qualifications to the generality of your proposition.

...

2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.² - Wherever you land, please explain what you mean by ³regulate² and ³services."

9 of these 11 have said they agree, and accept the wording - so they don't accept your suggestion that the words "regulate" or "services" are unclear in the context used in the Draft Report.

2 of these 11 have also said they agree, but propose alternate wording to achieve that; you may consider this wording, quoted above, as responsive to your question about defining "regulate" and "services".

...

I would be very interested in responses to these specific an limited questions.

-- 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

Malcolm, even if ICANN's ability to enforce agreements with contracted parties is enshrined in the language below, how would we address an argument that the prohibition against regulation precludes such contracts having a downstream effect on non-contracted parties (and content)? As Becky alludes, the URDP and WHOIS requirements are examples of those downstream effects. -----Original Message----- From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Malcolm Hutty Sent: Wednesday, November 11, 2015 10:26 AM To: Burr, Becky; Robin Gross Cc: ACCT-Staff; Accountability Community Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract On 11/11/2015 14:47, Burr, Becky wrote:

Could I get you to expand on one point Robin, Paul and others? To the extent ICANN obligates registrars to make registrants agree to submit to a UDRP, is that regulation of parties not in privity of contract with ICANN? What about the requirement that registrants provide accurate WHOIS Information.

Perhaps I can take that. The proposal that we frame this as a prohibition on "regulation of parties not in privity of contract with ICANN" is a proposal from BC and USCIB. It is one form of wording that aims at the same basic intent as the original wording. For myself, I think this alternative wording is intended to resolve one fear (that an excessively broad interpretation of "regulate" might result in ICANN being unable to form contracts of any sort), but it introduces problems of its own. If the BC's wording were used, I think UDRP and WHOIS requirements would be in jeopardy. I wouldn't want to do that, not do I see any public comment that suggests this is anybody's aim, least of all BC. That's why, when we sought a compromise that would address that concern, we did not adopt the BC wording, but instead added the following: "ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission." I think this is a good faith effort to accomodate the point that BC and USCIB raised, without reneging on the basic attempt to prevent the downstream content regulation, a principle that BC, USCIB have been clear that they also support. In other words, if we keep the Second Draft Report text and adopt the above sentence in addition, I believe we can in good conscience say that we have accommodated BOTH those that supported the original language AND the BC/USCIB input. Such reconciliation is surely what we should be aiming at, is it not? So the answer to your question is that if we go with the Second Draft Report language (with or without the additional sentence), I don't think there is any problem with continuing UDRP or WHOIS. If we adopted the BC text as an alternative solution, I think that would make the UDRP ultra vires (which is surely accidental on BC's part).

What about the new gTLD applicant guidebook prohibition on Strings at the top level that advocate behavior that violateS globally accepted human rights standards?

These examples are things that ICANN does right now. Are they ultra vires under the regulatory prohibition? If not, why not?

Again, we need to distinguish between the BC text and the Second Draft Report text. I think that BC text would create a conflict here too. The Second Draft Report text (with or without the additional sentence quoted above) would not conflict with those rules. The reason is that the text does not restrain ICANN in its choices as to which top-level domains to approve or decline to approve in any way. The text only restricts ICANN from seeking to regulate the services (such as web servers) that use the DNS. Declining to approve the delegation of a controversial string could not credibly be said to be an example of regulating the services (such as web servers) that use the DNS. Any attempt to mount such a claim in an IRP challenge would be doomed to failure. Indeed, assuming the IRP adopts procedures for the swift dismissal of claims with no reasonable prospect of success, as we recommend elsewhere in our report, such an ill-founded claim would be dismissed rapidly. That said, Alan Greenberg has said he doesn't consider this point to be as unequivocally clear as I claim. Alan and I are entirely in agreement that this clause should not restrain ICANN's unlimited discretion as to which strings to approve as new gTLDs, but Alan thinks there is room for confusion on whether our text successfully achieves that. I would be happy to add a drafting note to our lawyers that the final text must not bring this into question. In conclusion, as long as we proceed with the text that has been published, scrutinised, commented upon and widely suppored, we need have no fear concerning the points you raise. Your questions do, however, point up the dangers of unforeseen consequences in making, at this late stage, substantial changes to the text we have previously published. Kind Regards, Malcolm.

Sent from my iPad

...

On Nov 11, 2015, at 8:30 AM, Robin Gross <robin@ipjustice.org> wrote:

I do not agree that there lacks consensus on including the text which states ICANN won't regulate content. There IS consensus on that point, but not full consensus because a small minority disagrees with that position (IPC). Some in the BC don't even take this extreme IPC position.

Many different parts of the community have commented that this is a crucial component to our proposed accountability plan, so taking it out at this stage, simply because the IPC won't relent is unacceptable. The other parts of the community have to accept that we don't always get everything we want, and I find it difficult to understand why the same standard doesn't apply to the IPC - why we continue to go in circles until the IPC is satisfied. These extra bites at the apple must stop. We need some strength and backbone in our chairs and rapporteurs to not allow a small minority to impose this on the rest of the community, simply by refusing to relent until time runs out.

Deleting this point, which has been repeatedly stated as crucial for such a wide segment of the community will create much more trouble for the acceptance of our report than not allowing the IPC to get everything it wants.

Robin

...

On Nov 10, 2015, at 7:19 PM, Malcolm Hutty wrote:

...

On 11/11/2015 02:10, Burr, Becky wrote: Malcolm et al:

I have to agree that the 11 comments appended by Malcolm express strong support for the notion that ICANN should not use its contractual authority to ³regulate services that use the DNS or the regulation of content these services carry or provide² and that ICANN should not attempt to establish obligations on non-contracted parties.² But the very commenters cited (BC, USCIB, etc.)

Do you mean to imply that more than those two did?

...

also request clarification regarding ICANN¹s authority to enforce its contracts. What are we to make of this?

That's misleading. They didn't make a generalised, open-ended request for clarification that opens the door to you to construct an entirely new principle inconsistent with the main principle. They had a proposal of their own.

BC said:

BC strongly support the proposition that ICANN should not attempt to establish obligations on non-contracted parties. Paragraph 60 should be clarified and we propose that it should read as follows: "ICANN shall not engage in or use its powers to attempt to establish contractual obligations on companies with which it is not in privity of contract and shall not attempt to establish contractual obligations on contracted parties that are not agreed by such parties."

Similarly, USCIB said:

Indeed, ICANN's entire multi-stakeholder structure is built on a self-regulatory system implemented through contractual obligations and thus ICANN can only establish contractual obligations on parties with which it has privity through a negotiated and mutually agreeable contract/amendment with such parties. Therefore, para 60 should be clarified and we propose that it should read as follows: "ICANN shall not engage in or use its powers to attempt to establish contractual obligations on companies with which it is not in privity of contract and shall not attempt to establish contractual obligations on contracted parties that are not agreed by such parties."

This new language is simply not consistent with the proposition that ICANN should have any ability to enter into contracts with Registries for the purpose of regulating (or controlling, or any-of-a-number-of-other-verbs) the companies who register domain names, their business models or the content those companies carry on their web sites. Doing any of those things would entail "establishing contractual obligations on companies with which it [ICANN] is not in privity of contract", which is precisely what they say ICANN must not do.

...

With all due respect Malcolm, I will take a back seat to no one as a consistent and ardent defender of ICANN¹s limited mission.

Take care, Becky. You are starting to make it sound as though your own self-image as the defender of ICANN's limited mission is getting in the way of recognising other input with that same aim, but with which you personally disagree.

...

So I will restate the specific questions for the CCWG:

1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.²

The expressed view of these 11 commenters (including, I note, the formal submission of the BC) clearly gives their answer to this question as "disagree", at least inasmuch as those obligations impose further obligations on third parties (registrants) that limit what content they may carry or provide on their web sites and suchlike services.

There is simply no fair reading of these 11 commenters' submissions that could answer this question as "agree", without first adding very substantial qualifications to the generality of your proposition.

...

2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.² - Wherever you land, please explain what you mean by ³regulate² and ³services."

9 of these 11 have said they agree, and accept the wording - so they don't accept your suggestion that the words "regulate" or "services" are unclear in the context used in the Draft Report.

2 of these 11 have also said they agree, but propose alternate wording to achieve that; you may consider this wording, quoted above, as responsive to your question about defining "regulate" and "services".

...

I would be very interested in responses to these specific an limited questions.

-- 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

--

...

...

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 ================================================================= This message is the property of Time Warner Inc. and is intended only for the use of the addressee(s) and may be legally privileged and/or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, he or she is hereby notified that any dissemination, distribution, printing, forwarding, or any method of copying of this information, and/or the taking of any action in reliance on the information herein is strictly prohibited except by the intended recipient or those to whom he or she intentionally distributes this message. If you have received this communication in error, please immediately notify the sender, and delete the original message and any copies from your computer or storage system. Thank you. =================================================================

Malcolm said: * NB: This is an important point, with important ramifications. ICANN is not prohibited by this clause from any form of regulation of domain registrants at all. That may disappoint some (perhaps in civil society). I think it shows that this clause is balanced. This is an important point. So a blog may be covered by the prohibition but the blogger/registrant is not? ICANN can obligate registrars to impose and enforce terms and conditions related to the registration of a name - eg, in order to register you must provide accurate Whois data and agree to use the name in compliance with applicable law. But ICANN cannot require a registrar to suspend a registration where the use/service is alleged to be operating in violation of applicable law (eg operating an online gambling site in a jurisdiction that prohibits gambling). The registrar would have the choice to suspend (assuming it reserved that right) but not the obligation? Another example. As part of a community application for an adult TLD, the applicant says that registrants may not display animations of children under 18. In some countries such displays would be entirely legal. Suppose the applicant further commits to suspend registrations found to be in violation of this prohibition. In this case ICANN could require the registry operator to make the prohibition a condition of registration. Could ICANN require the registry to make good on its commitment to suspend? Sent from my iPad

On Nov 11, 2015, at 8:14 AM, Malcolm Hutty <malcolm@linx.net> wrote:

Malcolm.

* NB: This is an important point, with important ramifications. ICANN is not prohibited by this clause from any form of regulation of domain registrants at all. That may disappoint some (perhaps in civil society). I think it shows that this clause is balanced.

Greg: Alas, it is not an accurate formulation. It is far too specific, invokes technologies that may be superseded or not conform to future architectures, etc. What does it mean to regulate a “web server” anyway? Configure its technology? ICANN could do all kinds of things we don’t want it to do without doing that. There is nothing wrong with the concept of “services” as the thing that we don’t want ICANN to regulate, with the obvious exception of domain name registry and registrar services. --MM From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Greg Shatan Sent: Wednesday, November 11, 2015 12:33 PM To: Malcolm Hutty <malcolm@linx.net> Cc: Accountability Community <accountability-cross-community@icann.org>; ACCT-Staff <acct-staff@icann.org> Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract Based on Malcolm's explanations, here's a possible alternate formulation: "ICANN shall not regulate web servers, mail servers and other devices that are located using the Internet's unique identifiers, or the content they carry." * This clarifies what was meant by "service" by using more concrete terminology (It's clear that "service" isn't working here, just based on the limited responses on this thread.) * It also clarifies what is meant by "use" in a way that I think is more clear than an earlier offering by Malcolm intended to do the same thing (the "reachability" proposal) * I removed the word "provide," since it's not entirely clear to me what is being referred to as the "content" "provided" by an Internet-connected device. I thought about substituting "generate," but if we are talking about "device-generated" data, then there may be some need for "regulation" (or at least "standardization") by ICANN (and IETF) in order to maintain data flow (and thus SSR). Also, I think the current draft formulation, which essentially refers to regulating "services" that "provide" "content", is the basis for much of the misunderstanding we have about the meaning of this proposal, and thus should be avoided. I'm not saying I "agree" with this formulation, but I think it's a clearer statement (and I support my changes in that regard). If there are those that fundamentally disagree that this is an accurate statement of the current proposal, it's important to know that. Greg On Wed, Nov 11, 2015 at 11:14 AM, Malcolm Hutty <malcolm@linx.net<mailto:malcolm@linx.net>> wrote: On 11/11/2015 15:45, Silver, Bradley wrote:

Malcolm, even if ICANN's ability to enforce agreements with contracted parties is enshrined in the language below, how would we address an argument that the prohibition against regulation precludes such contracts having a downstream effect on non-contracted parties (and content)? As Becky alludes, the URDP and WHOIS requirements are examples of those downstream effects.

When answering such a question, it's very important to analyse the text itself, not various loose paraphrasings of the text we have all been using in more casual conversation. While "the prohibition against regulation" and "precludes contracts having a downstream effect on non-contracted parties" are broad descriptions of the kind of thing this clause is intended to prohibit, they are not sufficiently precise to give an accurate answer to your question. To answer it, we have to look at the precise wording itself. The text as proposed only says that ICANN may not: "regulate of services that use the Internet's unique identifiers [to enable or facilitate their reachability over the Internet], nor shall it regulate the content that those services carry or provide" When we analyse this closely, we will see that this prohibition is not as broad as the paraphrasing. So let's split this into parts: 1. Who does this apply to? "The services that use the Internet's unique identifiers to enable or facilitate their reachability over the Internet". These services are things like web servers, mail servers and so forth. Services are a technical thing. They're not companies: companies are the *providers* of such services. 2. What is ICANN prohibited from doing? a) regulating those services; or b) regulating the content that those services carry or provide So ICANN is, by this text, precluded from regulating the services themselves, but is not explicitly prohibited from regulating the providers of those services in ways that do not entail the regulation of those services (although it will have to find authorisation for doing that elsewhere in its mission)*. Now, let's apply that to WHOIS requirements. "WHOIS requirements", loosely stated, require registrants to disclose certain information for publication in the WHOIS system. You could argue about whether that's a form of "regulation" of registrants, but even if it is, it's not regulation of a web service or a mail service. It doesn't say "the web service must do this" or "the web service must not do that". Web services don't register domains; companies and individuals do. Nor is this regulation of the content that those services carry or provide. The things you do when you register a domain are not web content, they're actions taken by the registrant. The WHOIS requirement says things like "If ACME corporation wishes to register ACME.com, it must disclose its name and address for WHOIS publication". Nothing in that is regulation of what appears on ACME's web site, in any way. It would be up to someone who wanted to challenge the UDRP or the WHOIS requirements to prove that this text precludes those requirements. They will be unable to do so. If you would like me to walk you through the same analysis with UDRP, I can do so, but I think the above answers your question. Kind Regards, Malcolm. * NB: This is an important point, with important ramifications. ICANN is not prohibited by this clause from any form of regulation of domain registrants at all. That may disappoint some (perhaps in civil society). I think it shows that this clause is balanced.

-----Original Message----- 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 Malcolm Hutty Sent: Wednesday, November 11, 2015 10:26 AM To: Burr, Becky; Robin Gross Cc: ACCT-Staff; Accountability Community Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract

On 11/11/2015 14:47, Burr, Becky wrote:

...

Could I get you to expand on one point Robin, Paul and others? To the extent ICANN obligates registrars to make registrants agree to submit to a UDRP, is that regulation of parties not in privity of contract with ICANN? What about the requirement that registrants provide accurate WHOIS Information.

Perhaps I can take that.

The proposal that we frame this as a prohibition on "regulation of parties not in privity of contract with ICANN" is a proposal from BC and USCIB. It is one form of wording that aims at the same basic intent as the original wording.

For myself, I think this alternative wording is intended to resolve one fear (that an excessively broad interpretation of "regulate" might result in ICANN being unable to form contracts of any sort), but it introduces problems of its own. If the BC's wording were used, I think UDRP and WHOIS requirements would be in jeopardy. I wouldn't want to do that, not do I see any public comment that suggests this is anybody's aim, least of all BC. That's why, when we sought a compromise that would address that concern, we did not adopt the BC wording, but instead added the following:

"ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission."

I think this is a good faith effort to accomodate the point that BC and USCIB raised, without reneging on the basic attempt to prevent the downstream content regulation, a principle that BC, USCIB have been clear that they also support. In other words, if we keep the Second Draft Report text and adopt the above sentence in addition, I believe we can in good conscience say that we have accommodated BOTH those that supported the original language AND the BC/USCIB input. Such reconciliation is surely what we should be aiming at, is it not?

So the answer to your question is that if we go with the Second Draft Report language (with or without the additional sentence), I don't think there is any problem with continuing UDRP or WHOIS. If we adopted the BC text as an alternative solution, I think that would make the UDRP ultra vires (which is surely accidental on BC's part).

...

What about the new gTLD applicant guidebook prohibition on Strings at the top level that advocate behavior that violateS globally accepted human rights standards?

...

These examples are things that ICANN does right now. Are they ultra vires under the regulatory prohibition? If not, why not?

Again, we need to distinguish between the BC text and the Second Draft Report text.

I think that BC text would create a conflict here too.

The Second Draft Report text (with or without the additional sentence quoted above) would not conflict with those rules. The reason is that the text does not restrain ICANN in its choices as to which top-level domains to approve or decline to approve in any way.

The text only restricts ICANN from seeking to regulate the services (such as web servers) that use the DNS. Declining to approve the delegation of a controversial string could not credibly be said to be an example of regulating the services (such as web servers) that use the DNS. Any attempt to mount such a claim in an IRP challenge would be doomed to failure. Indeed, assuming the IRP adopts procedures for the swift dismissal of claims with no reasonable prospect of success, as we recommend elsewhere in our report, such an ill-founded claim would be dismissed rapidly.

That said, Alan Greenberg has said he doesn't consider this point to be as unequivocally clear as I claim. Alan and I are entirely in agreement that this clause should not restrain ICANN's unlimited discretion as to which strings to approve as new gTLDs, but Alan thinks there is room for confusion on whether our text successfully achieves that. I would be happy to add a drafting note to our lawyers that the final text must not bring this into question.

In conclusion, as long as we proceed with the text that has been published, scrutinised, commented upon and widely suppored, we need have no fear concerning the points you raise.

Your questions do, however, point up the dangers of unforeseen consequences in making, at this late stage, substantial changes to the text we have previously published.

Kind Regards,

Malcolm.

...

Sent from my iPad

...

On Nov 11, 2015, at 8:30 AM, Robin Gross <robin@ipjustice.org<mailto:robin@ipjustice.org>> wrote:

I do not agree that there lacks consensus on including the text which states ICANN won't regulate content. There IS consensus on that point, but not full consensus because a small minority disagrees with that position (IPC). Some in the BC don't even take this extreme IPC position.

Many different parts of the community have commented that this is a crucial component to our proposed accountability plan, so taking it out at this stage, simply because the IPC won't relent is unacceptable. The other parts of the community have to accept that we don't always get everything we want, and I find it difficult to understand why the same standard doesn't apply to the IPC - why we continue to go in circles until the IPC is satisfied. These extra bites at the apple must stop. We need some strength and backbone in our chairs and rapporteurs to not allow a small minority to impose this on the rest of the community, simply by refusing to relent until time runs out.

Deleting this point, which has been repeatedly stated as crucial for such a wide segment of the community will create much more trouble for the acceptance of our report than not allowing the IPC to get everything it wants.

Robin

...

On Nov 10, 2015, at 7:19 PM, Malcolm Hutty wrote:

...

On 11/11/2015 02:10, Burr, Becky wrote: Malcolm et al:

I have to agree that the 11 comments appended by Malcolm express strong support for the notion that ICANN should not use its contractual authority to ³regulate services that use the DNS or the regulation of content these services carry or provide² and that ICANN should not attempt to establish obligations on non-contracted parties.² But the very commenters cited (BC, USCIB, etc.)

Do you mean to imply that more than those two did?

...

also request clarification regarding ICANN¹s authority to enforce its contracts. What are we to make of this?

That's misleading. They didn't make a generalised, open-ended request for clarification that opens the door to you to construct an entirely new principle inconsistent with the main principle. They had a proposal of their own.

BC said:

BC strongly support the proposition that ICANN should not attempt to establish obligations on non-contracted parties. Paragraph 60 should be clarified and we propose that it should read as follows: "ICANN shall not engage in or use its powers to attempt to establish contractual obligations on companies with which it is not in privity of contract and shall not attempt to establish contractual obligations on contracted parties that are not agreed by such parties."

Similarly, USCIB said:

Indeed, ICANN's entire multi-stakeholder structure is built on a self-regulatory system implemented through contractual obligations and thus ICANN can only establish contractual obligations on parties with which it has privity through a negotiated and mutually agreeable contract/amendment with such parties. Therefore, para 60 should be clarified and we propose that it should read as follows: "ICANN shall not engage in or use its powers to attempt to establish contractual obligations on companies with which it is not in privity of contract and shall not attempt to establish contractual obligations on contracted parties that are not agreed by such parties."

This new language is simply not consistent with the proposition that ICANN should have any ability to enter into contracts with Registries for the purpose of regulating (or controlling, or any-of-a-number-of-other-verbs) the companies who register domain names, their business models or the content those companies carry on their web sites. Doing any of those things would entail "establishing contractual obligations on companies with which it [ICANN] is not in privity of contract", which is precisely what they say ICANN must not do.

...

With all due respect Malcolm, I will take a back seat to no one as a consistent and ardent defender of ICANN¹s limited mission.

Take care, Becky. You are starting to make it sound as though your own self-image as the defender of ICANN's limited mission is getting in the way of recognising other input with that same aim, but with which you personally disagree.

...

So I will restate the specific questions for the CCWG:

1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.²

The expressed view of these 11 commenters (including, I note, the formal submission of the BC) clearly gives their answer to this question as "disagree", at least inasmuch as those obligations impose further obligations on third parties (registrants) that limit what content they may carry or provide on their web sites and suchlike services.

There is simply no fair reading of these 11 commenters' submissions that could answer this question as "agree", without first adding very substantial qualifications to the generality of your proposition.

...

2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.² - Wherever you land, please explain what you mean by ³regulate² and ³services."

9 of these 11 have said they agree, and accept the wording - so they don't accept your suggestion that the words "regulate" or "services" are unclear in the context used in the Draft Report.

2 of these 11 have also said they agree, but propose alternate wording to achieve that; you may consider this wording, quoted above, as responsive to your question about defining "regulate" and "services".

...

I would be very interested in responses to these specific an limited questions.

-- 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<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community

...

...

...

--

...

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 | 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<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community

================================================================= This message is the property of Time Warner Inc. and is intended only for the use of the addressee(s) and may be legally privileged and/or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, he or she is hereby notified that any dissemination, distribution, printing, forwarding, or any method of copying of this information, and/or the taking of any action in reliance on the information herein is strictly prohibited except by the intended recipient or those to whom he or she intentionally distributes this message. If you have received this communication in error, please immediately notify the sender, and delete the original message and any copies from your computer or storage system. Thank you. =================================================================

-- 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 | 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<mailto:Accountability-Cross-Community@icann.org> https://mm.icann.org/mailman/listinfo/accountability-cross-community

I agree with Prof. Müller. We must endeavour to be technology and implementation neutral despite the fact that ICANN is built on a specific, Port 53, protocol. On 11/11/2015 06:19 PM, Mueller, Milton L wrote:

Greg:

Alas, it is not an accurate formulation. It is far too specific, invokes technologies that may be superseded or not conform to future architectures, etc. What does it mean to regulate a “web server” anyway?

On 11/11/2015 18:33, Greg Shatan wrote:

Malcolm,

Thanks for your reply. I took those terms from an email you wrote, but clearly did not apply it quite correctly. It's critically important to get clarity here, and drilling down and getting concrete examples is extremely helpful.

What are a few examples of what you mean when you say "web service" and "other services"?

On 11/11/2015 18:55, Greg Shatan wrote:

I am trying to get to a concrete and shared understanding of what this proposal means when it says "services." Based on the varying responses in this and earlier threads, we're not there yet.

I can't see my stumbling attempts to provide a technical definition helping this discussion. I'll write to you privately. Perhaps Andrew can do better than me, or point us to a formal definition of a service? Has the IETF produced such a thing? -- 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

Apologies, but is this where we left off on the wordsmithing? Is Milton correct that we’re closer than I thought? Is it just a matter of resolving the definition around “services?” Thanks, Keith From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Greg Shatan Sent: Wednesday, November 11, 2015 2:11 PM To: Malcolm Hutty Cc: Accountability Cross Community Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract I'm not looking for a technical definition -- rather a practical definition. Actually, I asked for examples, so a definition may not be necessary, as long as the examples offer sufficient clarity. It's important that when the CCWG/Commenters/SOs/ACs/etc. look at the word "services" (or the word services plus some exemplars), they all see the same thing. Otherwise, we are like "The Six Blind Men and the Elephant" (apologies for culturally-specific, archaic and politically incorrect reference; please note as a counterbalance that I am a member of the CCWG-Accessibility, seeking to improve web access (and ICANN access) for people with disabilities). On Wed, Nov 11, 2015 at 2:05 PM, Malcolm Hutty <malcolm@linx.net<mailto:malcolm@linx.net>> wrote: On 11/11/2015 18:33, Greg Shatan wrote:

Malcolm,

Thanks for your reply. I took those terms from an email you wrote, but clearly did not apply it quite correctly. It's critically important to get clarity here, and drilling down and getting concrete examples is extremely helpful.

What are a few examples of what you mean when you say "web service" and "other services"?

On 11/11/2015 18:55, Greg Shatan wrote:

I am trying to get to a concrete and shared understanding of what this proposal means when it says "services." Based on the varying responses in this and earlier threads, we're not there yet.

I can't see my stumbling attempts to provide a technical definition helping this discussion. I'll write to you privately. Perhaps Andrew can do better than me, or point us to a formal definition of a service? Has the IETF produced such a thing? -- 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 | 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

All, I would like to suggest the following alternative, in the hopes that it can be a broadly acceptable formulation, and thread the needle on some of the discussions we've been having. ICANN shall act strictly in accordance with, and only as reasonably appropriate to achieve its Mission. Without limiting the foregoing: - ICANN shall not impose regulations on: - services (i.e., the software processes by which commands received via the Internet are processed and a response is generated and transmitted via the Internet, to be viewed in a web browser, email client, or the like) which use the Internet’s unique identifiers, or - the content that such services carry or provide - ICANN shall have the ability to enter into and enforce agreements with contracted parties, in furtherance of its Mission. Your thoughts would be most appreciated. Greg On Thu, Nov 12, 2015 at 3:24 PM, Burr, Becky <Becky.Burr@neustar.biz> wrote:

I share Keith’s confusion. Just where are we?

*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: <Drazek>, Keith Drazek <kdrazek@verisign.com> Date: Thursday, November 12, 2015 at 10:00 AM To: Greg Shatan <gregshatanipc@gmail.com>, Malcolm Hutty <malcolm@linx.net

...

Cc: Accountability Community <accountability-cross-community@icann.org>

Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract

Apologies, but is this where we left off on the wordsmithing? Is Milton correct that we’re closer than I thought? Is it just a matter of resolving the definition around “services?”

Thanks,

Keith

*From:* accountability-cross-community-bounces@icann.org [ mailto:accountability-cross-community-bounces@icann.org <accountability-cross-community-bounces@icann.org>] *On Behalf Of *Greg Shatan *Sent:* Wednesday, November 11, 2015 2:11 PM *To:* Malcolm Hutty *Cc:* Accountability Cross Community *Subject:* Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract

I'm not looking for a technical definition -- rather a practical definition. Actually, I asked for examples, so a definition may not be necessary, as long as the examples offer sufficient clarity.

It's important that when the CCWG/Commenters/SOs/ACs/etc. look at the word "services" (or the word services plus some exemplars), they all see the same thing.

Otherwise, we are like "The Six Blind Men and the Elephant" (apologies for culturally-specific, archaic and politically incorrect reference; please note as a counterbalance that I am a member of the CCWG-Accessibility, seeking to improve web access (and ICANN access) for people with disabilities).

On Wed, Nov 11, 2015 at 2:05 PM, Malcolm Hutty <malcolm@linx.net> wrote:

On 11/11/2015 18:33, Greg Shatan wrote:

...

Malcolm,

Thanks for your reply. I took those terms from an email you wrote, but clearly did not apply it quite correctly. It's critically important to get clarity here, and drilling down and getting concrete examples is extremely helpful.

What are a few examples of what you mean when you say "web service" and "other services"?

On 11/11/2015 18:55, Greg Shatan wrote:

...

I am trying to get to a concrete and shared understanding of what this proposal means when it says "services." Based on the varying responses in this and earlier threads, we're not there yet.

I can't see my stumbling attempts to provide a technical definition helping this discussion. I'll write to you privately.

Perhaps Andrew can do better than me, or point us to a formal definition of a service? Has the IETF produced such a thing?

-- Malcolm Hutty | tel: +44 20 7645 3523 Head of Public Affairs | Read the LINX Public Affairs blog London Internet Exchange | http://publicaffairs.linx.net/ <https://urldefense.proofpoint.com/v2/url?u=http-3A__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

+1 The revised language is a bit clearer and based more on general principle than on specific technology. We're building a governing construct for the future ICANN regardless of where technology takes us. Milton's proposed language better allows us to carry these general principles forward regardless of any changes to base technology that ICANN might encounter or need to adapt to. Ed

On Nov 13, 2015, at 2:45 AM, Mueller, Milton L <milton@gatech.edu> wrote:

Greg: I think with some modifications to your proposed text we can find widespread agreement. Here is how I would modify your proposal:

ICANN shall act strictly in accordance with, and only as reasonably appropriate to, achieve its Mission. Without limiting the foregoing: ICANN shall not impose regulations on: Information services which use the Internet’s unique identifiers but are not registries or registrars, or The content that such services carry or provide ICANN shall have the ability to enter into and enforce agreements with contracted parties, insofar as those agreements are consistent with its Mission. Explanation: “information services” is a simpler and more generic way to describe what we you are referring to and has a long regulatory history. As others noted before, it is dangerous to try to get too technologically specific. What we need to do here is carve out an exception to the regulation band for registries and registrars, which ICANN can and does regulate in accord with its mission. The second point, pertaining to enforcing contracts, puts in clearer and more restrictive language. Rather than “in furtherance of’ its mission I proposed “consistent with” its mission. One might claim that many ancillary activities might “further” ICANN’s mission in some way; it is more precise to ask that ICANN’s activities be “consistent” with its mission. --MM

On Thu, Nov 12, 2015 at 3:24 PM, Burr, Becky <Becky.Burr@neustar.biz> wrote: I share Keith’s confusion. Just where are we?

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

All, This was discussed last night and adjustments were made to the base text. I’m not really following this debate too closely, so I have no idea if the changes would alleviate your concerns or not. Perhaps Becky can circulate the latest version. Best, Brett ________________________________ 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: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Silver, Bradley Sent: Friday, November 13, 2015 8:47 AM To: Edward Morris; Mueller, Milton L Cc: Accountability Cross Community Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract Thanks Milton and Ed - Doesn’t calling our registries and registrars get us back into the problem area of whether activities such as the accreditation of Privacy & Proxy services is in breach of the no-regulation clause? I had thought the goal of the draft Greg circulated was to describe the specific processes that ICANN would stay clear of imposing regulation on (the distinction being that “services” is not meant to describe entities, but rather a certain type of activity). Also, the change the second bullet does not provide the clarity that is needed – it essentially makes it a narrower way saying what the first sentence says. The point of the contractual language was to clarify that the first bullet would not impede ICANN’s furtherance of its mission via contractual agreements. I think flipping it around doesn’t give the necessary guidance and clarity. These are important distinctions, but I think a good step towards finding agreement on language that could satisfy broad interests. Bradley From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Edward Morris Sent: Friday, November 13, 2015 6:24 AM To: Mueller, Milton L Cc: Accountability Cross Community Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract +1 The revised language is a bit clearer and based more on general principle than on specific technology. We're building a governing construct for the future ICANN regardless of where technology takes us. Milton's proposed language better allows us to carry these general principles forward regardless of any changes to base technology that ICANN might encounter or need to adapt to. Ed On Nov 13, 2015, at 2:45 AM, Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>> wrote: Greg: I think with some modifications to your proposed text we can find widespread agreement. Here is how I would modify your proposal: ICANN shall act strictly in accordance with, and only as reasonably appropriate to, achieve its Mission. Without limiting the foregoing: * ICANN shall not impose regulations on: * Information services which use the Internet’s unique identifiers but are not registries or registrars, or * The content that such services carry or provide * ICANN shall have the ability to enter into and enforce agreements with contracted parties, insofar as those agreements are consistent with its Mission. Explanation: “information services” is a simpler and more generic way to describe what we you are referring to and has a long regulatory history. As others noted before, it is dangerous to try to get too technologically specific. What we need to do here is carve out an exception to the regulation band for registries and registrars, which ICANN can and does regulate in accord with its mission. The second point, pertaining to enforcing contracts, puts in clearer and more restrictive language. Rather than “in furtherance of’ its mission I proposed “consistent with” its mission. One might claim that many ancillary activities might “further” ICANN’s mission in some way; it is more precise to ask that ICANN’s activities be “consistent” with its mission. --MM On Thu, Nov 12, 2015 at 3:24 PM, Burr, Becky <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> wrote: I share Keith’s confusion. Just where are we? _______________________________________________ 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 ================================================================= Reminder: Any email that requests your login credentials or that asks you to click on a link could be a phishing attack. If you have any questions regarding the authenticity of this email or its sender, please contact the IT Service Desk at 212.484.6000 or via email at ITServices@timewarner.com<mailto:ITServices@timewarner.com> ================================================================= ================================================================= This message is the property of Time Warner Inc. and is intended only for the use of the addressee(s) and may be legally privileged and/or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, he or she is hereby notified that any dissemination, distribution, printing, forwarding, or any method of copying of this information, and/or the taking of any action in reliance on the information herein is strictly prohibited except by the intended recipient or those to whom he or she intentionally distributes this message. If you have received this communication in error, please immediately notify the sender, and delete the original message and any copies from your computer or storage system. Thank you. =================================================================

Like many, I have completely lost track of this thread, particularly since many messages are arriving out-of-sequence. Not sure if this this the best place to jump in, but here goes: I do not support the inclusion of the terms “Registries” or “Registrars” in to ICANN’s mission or bylaws. We are entering a new era of vertical integration between & among a wide variety of service providers. Some of these commercial activities are subject to ICANN governance, others are not. We have a hard enough time defining these terms in our own Stakeholder Group Charter(s), so I don’t recommend transplanting that mess here. Thanks— J. From: <accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org>> on behalf of "Silver, Bradley" <Bradley.Silver@timewarner.com<mailto:Bradley.Silver@timewarner.com>> Date: Friday, November 13, 2015 at 7:46 To: Edward Morris <egmorris1@toast.net<mailto:egmorris1@toast.net>>, "Mueller, Milton L" <milton@gatech.edu<mailto:milton@gatech.edu>> Cc: Accountability Cross Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract Thanks Milton and Ed - Doesn’t calling our registries and registrars get us back into the problem area of whether activities such as the accreditation of Privacy & Proxy services is in breach of the no-regulation clause? I had thought the goal of the draft Greg circulated was to describe the specific processes that ICANN would stay clear of imposing regulation on (the distinction being that “services” is not meant to describe entities, but rather a certain type of activity). Also, the change the second bullet does not provide the clarity that is needed – it essentially makes it a narrower way saying what the first sentence says. The point of the contractual language was to clarify that the first bullet would not impede ICANN’s furtherance of its mission via contractual agreements. I think flipping it around doesn’t give the necessary guidance and clarity. These are important distinctions, but I think a good step towards finding agreement on language that could satisfy broad interests. Bradley From: accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org> [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Edward Morris Sent: Friday, November 13, 2015 6:24 AM To: Mueller, Milton L Cc: Accountability Cross Community Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract +1 The revised language is a bit clearer and based more on general principle than on specific technology. We're building a governing construct for the future ICANN regardless of where technology takes us. Milton's proposed language better allows us to carry these general principles forward regardless of any changes to base technology that ICANN might encounter or need to adapt to. Ed On Nov 13, 2015, at 2:45 AM, Mueller, Milton L <milton@gatech.edu<mailto:milton@gatech.edu>> wrote: Greg: I think with some modifications to your proposed text we can find widespread agreement. Here is how I would modify your proposal: ICANN shall act strictly in accordance with, and only as reasonably appropriate to, achieve its Mission. Without limiting the foregoing: * ICANN shall not impose regulations on: * Information services which use the Internet’s unique identifiers but are not registries or registrars, or * The content that such services carry or provide * ICANN shall have the ability to enter into and enforce agreements with contracted parties, insofar as those agreements are consistent with its Mission. Explanation: “information services” is a simpler and more generic way to describe what we you are referring to and has a long regulatory history. As others noted before, it is dangerous to try to get too technologically specific. What we need to do here is carve out an exception to the regulation band for registries and registrars, which ICANN can and does regulate in accord with its mission. The second point, pertaining to enforcing contracts, puts in clearer and more restrictive language. Rather than “in furtherance of’ its mission I proposed “consistent with” its mission. One might claim that many ancillary activities might “further” ICANN’s mission in some way; it is more precise to ask that ICANN’s activities be “consistent” with its mission. --MM On Thu, Nov 12, 2015 at 3:24 PM, Burr, Becky <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> wrote: I share Keith’s confusion. Just where are we? _______________________________________________ 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 ================================================================= Reminder: Any email that requests your login credentials or that asks you to click on a link could be a phishing attack. If you have any questions regarding the authenticity of this email or its sender, please contact the IT Service Desk at 212.484.6000 or via email at ITServices@timewarner.com<mailto:ITServices@timewarner.com> ================================================================= ================================================================= This message is the property of Time Warner Inc. and is intended only for the use of the addressee(s) and may be legally privileged and/or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, he or she is hereby notified that any dissemination, distribution, printing, forwarding, or any method of copying of this information, and/or the taking of any action in reliance on the information herein is strictly prohibited except by the intended recipient or those to whom he or she intentionally distributes this message. If you have received this communication in error, please immediately notify the sender, and delete the original message and any copies from your computer or storage system. Thank you. =================================================================

This topic was just discussed extensively on the call yesterday and there was considerable progress. The recordings, notes, chat and call transcripts are all available now at https://community.icann.org/pages/viewpage.action?pageId=56145283. I've attached the call transcript; the relevant discussion is on pp. 4-19. It's important to read the whole section, but the concluding remarks from that discussion are helpful for us to build on: ​ Becky Burr: Well, no, I mean, I think that the point is - and Greg has just echoed me in this - what we are talking about is services, not service providers. So the question is what is the underlying service, not what is the nature of the business. So I guess I agree with - I agree with the way it is set up in this language here. Thomas Rickert: Yes, and I guess that what you’ve just refined is a better description of what Greg I think meant by saying differing classes of services - class of businesses. So I guess that’s helpful. So I think we can confirm and please let me know if you do not agree with this, that that we are looking for a technology-neutral description of this. But still if we’re using the technique that Kavouss has suggested, for example, we could have examples of technology to illustrate what we mean by the definition that should then go - or by the language that should then go into the bylaws. Alan, you’ve raised your hand. Alan Greenberg: Yeah, thank you. It [dawns] on me that when we're looking at the two classes of service, someone may be offering a graphics design service over the web. Clearly, we are never saying we are going to be regulating the graphics design service. So at some level we could not - we don’t have to differentiate because we’re - the higher level service is always carved out. But since the word has two different very distinct meanings it’s probably better to be clear. Thank you. Thomas Rickert: Thanks very much, Alan. And I think that these are excellent final words on this conversation. So I think this is as far as we can get during this call. And with that I’d like to thank you all for your contributions and for bearing with us for those who are not calling this their favorite item. And let’s now move to the next agenda item which is going to be chaired by Mathieu.​ ​ ​Andrew Sullivan had two suggested revisions to the first part of the provision , both of which are consistent with this direction: - *​ ICANN shall not impose regulations on ​services (i.e., any software process that accepts​ * *connections from the Internet) that use the Internet’s unique ​ identifiers, or​ the content that such services carry or provide​* ​or, alternatively - *​ICANN shall not impose regulations on ​​services (i.e., any software process that accepts datagrams from the Internet, when those datagrams are not themselves necessarily the consequence of a datagram previously sent by the software process itself) that use the Internet’s unique identifiers, or​ the content that such services carry or provide​* ​ ​These parentheticals are both more "technically neutral" than the parenthetical I circulated ("(i.e., the software processes by which commands received via the Internet are processed and a response is generated and transmitted via the Internet, to be viewed in a web browser, email client, or the like")). I tend to prefer the first one, which has the virtue of brevity. That said, we should see if there are tweaks consistent with Thomas's summary of the call "we’re not talking about the service providers or the class of business that they're in but that we're talking about the technical processes, the technical services." ​Another suggestion came from Milton Mueller: - *ICANN shall not impose regulations on ​Information services which use the Internet’s unique identifiers but are not registries or registrars, or​ ​t​he content that such services carry or provide* ​In response to James Bladel, Milton suggests "Instead of saying “registries or registrars” we could simply say “under the Registrar Accreditation Agreement (RAA) or the Registry Agreement (RA).” - ​ * ICANN shall not impose regulations on ​Information services which use the Internet’s unique identifiers but are not under the Registrar Accreditation Agreement (RAA) or the Registry Agreement (RA), or​ ​t​he content that such services carry or provide*​ ​Although "information services" could be preferable to "services," the first suggestion clearly takes us away from describing "technical processes" and instead describes "service providers" since it refers to "registries or registrars" as the kind of thing that would be included as "information services" (unless carved out). The second suggestion is not as clearly about "service providers" but it's also not clearly about "technical services" either (there's not enough information to read it clearly). Perhaps there's a way to combine these various thoughts in a manner consistent with the overall direction, for instance in the following synthesis: - ​​ * ICANN shall not impose regulations on:* - *​ Information services (i.e., any software process that accepts​ connections from the Internet) that use the Internet’s unique identifiers, other than those covered by the Registrar Accreditation Agreement (RAA) or * *the Registry Agreement (RA), or ​ * - *​ t​he content that such information services carry or provide*​ ​or, alternatively (if the carve-out for the RAA/RA seems confusing, unnecessary or overbroad) ​ - ​​ * ICANN shall not impose regulations on:* - *​ Information services (i.e., any software process that accepts​ connections from the Internet) that use the Internet’s unique identifiers, * * or ​ * - *​ t​he content that such information services carry or provide*​ ​In order to focus this email, I haven't touched on the second sentence, which we should finalize as well. I look forward to your thoughts. ​Greg​ On Fri, Nov 13, 2015 at 11:44 AM, Mueller, Milton L <milton@gatech.edu> wrote:

James:

Understand your concern. I think we can easily fix this.

Instead of saying “registries or registrars” we could simply say “under the Registrar Accreditation Agreement (RAA) or the Registry Agreement (RA).”

Vertical integration between registries and registrars does not alter the fact that they are still contracted parties under either RAA or RA or both, and by specifying the RAA and RA we make it very clear which aspects of the business are “regulated” and which are not.

*From:* James M. Bladel [mailto:jbladel@godaddy.com] *Sent:* Friday, November 13, 2015 11:22 AM *To:* Silver, Bradley <Bradley.Silver@timewarner.com>; Edward Morris < egmorris1@toast.net>; Mueller, Milton L <milton@gatech.edu>

*Cc:* Accountability Cross Community < accountability-cross-community@icann.org> *Subject:* Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract

Like many, I have completely lost track of this thread, particularly since many messages are arriving out-of-sequence. Not sure if this this the best place to jump in, but here goes: I do not support the inclusion of the terms “Registries” or “Registrars” in to ICANN’s mission or bylaws.

We are entering a new era of vertical integration between & among a wide variety of service providers. Some of these commercial activities are subject to ICANN governance, others are not.

We have a hard enough time defining these terms in our own Stakeholder Group Charter(s), so I don’t recommend transplanting that mess here.

Thanks—

J.

*From: *<accountability-cross-community-bounces@icann.org> on behalf of "Silver, Bradley" <Bradley.Silver@timewarner.com> *Date: *Friday, November 13, 2015 at 7:46 *To: *Edward Morris <egmorris1@toast.net>, "Mueller, Milton L" < milton@gatech.edu> *Cc: *Accountability Cross Community < accountability-cross-community@icann.org> *Subject: *Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract

Thanks Milton and Ed -

Doesn’t calling our registries and registrars get us back into the problem area of whether activities such as the accreditation of Privacy & Proxy services is in breach of the no-regulation clause? I had thought the goal of the draft Greg circulated was to describe the specific processes that ICANN would stay clear of imposing regulation on (the distinction being that “services” is not meant to describe entities, but rather a certain type of activity).

Also, the change the second bullet does not provide the clarity that is needed – it essentially makes it a narrower way saying what the first sentence says. The point of the contractual language was to clarify that the first bullet would not impede ICANN’s furtherance of its mission via contractual agreements. I think flipping it around doesn’t give the necessary guidance and clarity.

These are important distinctions, but I think a good step towards finding agreement on language that could satisfy broad interests.

*Bradley *

*From:* accountability-cross-community-bounces@icann.org [ mailto:accountability-cross-community-bounces@icann.org <accountability-cross-community-bounces@icann.org>] *On Behalf Of *Edward Morris *Sent:* Friday, November 13, 2015 6:24 AM *To:* Mueller, Milton L *Cc:* Accountability Cross Community *Subject:* Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract

+1

The revised language is a bit clearer and based more on general principle than on specific technology. We're building a governing construct for the future ICANN regardless of where technology takes us. Milton's proposed language better allows us to carry these general principles forward regardless of any changes to base technology that ICANN might encounter or need to adapt to.

Ed

On Nov 13, 2015, at 2:45 AM, Mueller, Milton L <milton@gatech.edu> wrote:

Greg:

I think with some modifications to your proposed text we can find widespread agreement. Here is how I would modify your proposal:

ICANN shall act strictly in accordance with, and only as reasonably appropriate to, achieve its Mission. Without limiting the foregoing:

? ICANN shall not impose regulations on:

o Information services which use the Internet’s unique identifiers but are not registries or registrars, or

o The content that such services carry or provide

? ICANN shall have the ability to enter into and enforce agreements with contracted parties, insofar as those agreements are consistent with its Mission.

Explanation:

“information services” is a simpler and more generic way to describe what we you are referring to and has a long regulatory history. As others noted before, it is dangerous to try to get too technologically specific. What we need to do here is carve out an exception to the regulation band for registries and registrars, which ICANN can and does regulate in accord with its mission.

The second point, pertaining to enforcing contracts, puts in clearer and more restrictive language. Rather than “in furtherance of’ its mission I proposed “consistent with” its mission. One might claim that many ancillary activities might “further” ICANN’s mission in some way; it is more precise to ask that ICANN’s activities be “consistent” with its mission.

--MM

On Thu, Nov 12, 2015 at 3:24 PM, Burr, Becky <Becky.Burr@neustar.biz> wrote:

I share Keith’s confusion. Just where are we?

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

================================================================= *Reminder: Any email that requests your login credentials or that asks you to click on a link could be a phishing attack. If you have any questions regarding the authenticity of this email or its sender, please contact the IT Service Desk at 212.484.6000 <212.484.6000> or via email at ITServices@timewarner.com <ITServices@timewarner.com> *

=================================================================

================================================================= This message is the property of Time Warner Inc. and is intended only for the use of the addressee(s) and may be legally privileged and/or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, he or she is hereby notified that any dissemination, distribution, printing, forwarding, or any method of copying of this information, and/or the taking of any action in reliance on the information herein is strictly prohibited except by the intended recipient or those to whom he or she intentionally distributes this message. If you have received this communication in error, please immediately notify the sender, and delete the original message and any copies from your computer or storage system. Thank you. =================================================================

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

Hi, I sent an alternative to this in the "whole text" message I just mailed, but I thought it better to follow up to this specifically in this thread. On Thu, Nov 12, 2015 at 04:05:40PM -0500, Greg Shatan wrote:

- services (i.e., the software processes by which commands received via the Internet are processed and a response is generated and transmitted via the Internet, to be viewed in a web browser, email client, or the like) which use the Internet’s unique identifiers, or

That can't be the definition of services, I think. First, I'm not entirely sure that we want to say "receives commands": DNS, for instance, is a completely bilateral protocol that just sends messages back and forth. The messages are the same format in "command" (query) and response, differeing technically only in the setting of a bit. I _could_ make an argument that these are commands, but I don't think we want anything that tenuous. In general, not all services are client-server. Second, not all responses are to be viewed: some are machine to machine (so nobody views them) and some are non-visual (SIP calls, for instance). Third, not all Internet services are connnection-oriented: UDP datagrams, for instance, are connectionless. Finally, for a given service and a given inbound datagram, response datagrams might or might not be generated depending on various local policies. It's problems like this that make people avoid trying to define too precisely. It does seem that a service on the Internet is something that accepts datagrams, when those datagrams are not necessarily the result of datagrams sent by the same thing. Therefore, I _think_ this will work: services (i.e., any software process that accepts datagrams from the Internet, when those datagrams are not themselves necessarily the consequence of a datagram previously sent by the software process itself) that use the Internet’s unique identifiers I'm not absolutely sure this is right, but I think it might be close enough. The problem with it, of course, is that every single thing connected to the Internet uses at least one of the Internet's unique identifiers (this problem is, remember, part of what alarmed the IAB in the first place). So this basically says, "Any software process that accepts datagrams from the Internet," and that very nearly boils down to, "A program with a socket open to the Internet." If that's ok, I guess I can live with it, though it'd be good to get some more technically-clueful (or even, some would argue, "at least one pair of") eyes on this. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com

On Thu, Nov 12, 2015 at 06:00:34PM +0000, Drazek, Keith wrote:

Apologies, but is this where we left off on the wordsmithing? Is Milton correct that we’re closer than I thought? Is it just a matter of resolving the definition around “services?”

I can't tell, but your earlier message with part of the other text I thought we'd already settled made me worried, too. So, here's what _I_ think is the state of affairs. I'm probably wrong, but maybe the fact that I'm confused and how will us to converge on what questions are still open. I thought it might be good to put down before the call tonight (I hope I wake up). This includes a bit I just saw from Greg, with some edits from me; I'll justify those in the other thread. I hope this is useful; if not, feel free to flame me off list. SLIGHT CONTROVERSY: The Mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is to ensure the stable and secure operation of the Internet's unique identifier systems as described below. Specifically, ICANN: ***OR*** The Mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is to ensure the stable and secure operation of the Internet's unique identifier systems in the ways described below. Specifically, ICANN: [The difference here is the "as described" vs "in the ways described". I think the latter is more flexible.] AGREED: 1. Coordinates the allocation and assignment of names in the root zone of the Domain Name System ("DNS"). In this role, 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: • That are developed through a bottom-up, consensus-based multi- stakeholder process and designed to ensure the stable and secure operation of the Internet’s unique names systems. 2. Coordinates the operation and evolution of the DNS root name server system. In this role, ICANN’s Mission is to [to be provided by root server operators]. [note: this could be called "controversial" since it's not filled in.] 3. Coordinates the allocation and assignment at the top-most level of Internet Protocol ("IP") and Autonomous System ("AS") numbers. ICANN’s Mission is described in the ASO MoU between ICANN and RIRs. SLIGHT CONTROVERSY: 4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by Internet protocol development organizations, such as the Internet Engineering Task Force. ***OR*** 4. Collaborates with other bodies as appropriate to publish core registries needed for the functioning of the Internet. In this role, with respect to protocol ports and parameters, ICANN's Mission is to provide registration services and open access for registries in the public domain requested by the Internet Engineering Task Force. [The difference here is the "such as". I prefer that a little bit because I think it is more consistent with the MoU between ICANN and the IETF and IAB -- ICANN's allowed to do this for other organizations, too.] AGREED: ICANN shall act strictly other than in accordance with, and only as reasonably appropriate to achieve its Mission. CONTROVERSIAL: ICANN shall not impose regulations on: • services (i.e., any software process that accepts connections from the Internet) that use the Internet’s unique identifiers, or • the content that such services carry or provide ICANN shall have the ability to enter into and enforce agreements with contracted parties, in furtherance of its Mission. [this is the latest version from Greg, adjusted to deal with what a "service" might be. I'll follow up on that text in that thread.] Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com

Thanks, Keith

From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Greg Shatan Sent: Wednesday, November 11, 2015 2:11 PM To: Malcolm Hutty Cc: Accountability Cross Community Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract

I'm not looking for a technical definition -- rather a practical definition. Actually, I asked for examples, so a definition may not be necessary, as long as the examples offer sufficient clarity.

It's important that when the CCWG/Commenters/SOs/ACs/etc. look at the word "services" (or the word services plus some exemplars), they all see the same thing.

Otherwise, we are like "The Six Blind Men and the Elephant" (apologies for culturally-specific, archaic and politically incorrect reference; please note as a counterbalance that I am a member of the CCWG-Accessibility, seeking to improve web access (and ICANN access) for people with disabilities).

On Wed, Nov 11, 2015 at 2:05 PM, Malcolm Hutty <malcolm@linx.net<mailto:malcolm@linx.net>> wrote: On 11/11/2015 18:33, Greg Shatan wrote:

...

Malcolm,

Thanks for your reply. I took those terms from an email you wrote, but clearly did not apply it quite correctly. It's critically important to get clarity here, and drilling down and getting concrete examples is extremely helpful.

What are a few examples of what you mean when you say "web service" and "other services"?

On 11/11/2015 18:55, Greg Shatan wrote:

...

I am trying to get to a concrete and shared understanding of what this proposal means when it says "services." Based on the varying responses in this and earlier threads, we're not there yet.

I can't see my stumbling attempts to provide a technical definition helping this discussion. I'll write to you privately.

Perhaps Andrew can do better than me, or point us to a formal definition of a service? Has the IETF produced such a thing?

-- 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 | 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

-- Andrew Sullivan ajs@anvilwalrusden.com

On 11/11/2015 17:32, Greg Shatan wrote:

Based on Malcolm's explanations, here's a possible alternate formulation:

*"ICANN shall not regulate web servers, mail servers and other devices that are located using the Internet's unique identifiers, or the content they carry."*

Web servers, mail servers and other devices are hardware. It's not hardware that ICANN needs to be specifically prohibited from regulating, but what is done using that hardware. So the proper term is "web service" not "web server", and "other services" not "other devices". -- 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

Sent from my Asus Zenfone2 Kindly excuse brevity and typos. On 11 Nov 2015 18:33, "Greg Shatan" <gregshatanipc@gmail.com> wrote:

Based on Malcolm's explanations, here's a possible alternate formulation:

"ICANN shall not regulate web servers, mail servers and other devices

that are located using the Internet's unique identifiers, or the content they carry."

SO: Webserver and mail servers are services that run on a device. So when you say "other devices" it still implies either of the 2: - Any service (including mail and web) Or - The actual hardware itself. I assume option1 is what you have in mind (because ICANN hasn't been perceived to be regulating hardware at all). If it's option 1 then it still comes back to what's the description of "services" we don't want ICANN to regulate among all the services. Perhaps indicating what ICANN does regulate may help. Regards

This clarifies what was meant by "service" by using more concrete terminology (It's clear that "service" isn't working here, just based on the limited responses on this thread.) It also clarifies what is meant by "use" in a way that I think is more clear than an earlier offering by Malcolm intended to do the same thing (the "reachability" proposal) I removed the word "provide," since it's not entirely clear to me what is being referred to as the "content" "provided" by an Internet-connected device. I thought about substituting "generate," but if we are talking about "device-generated" data, then there may be some need for "regulation" (or at least "standardization") by ICANN (and IETF) in order to maintain data flow (and thus SSR). Also, I think the current draft formulation, which essentially refers to regulating "services" that "provide" "content", is the basis for much of the misunderstanding we have about the meaning of this proposal, and thus should be avoided. I'm not saying I "agree" with this formulation, but I think it's a clearer statement (and I support my changes in that regard). If there are those that fundamentally disagree that this is an accurate statement of the current proposal, it's important to know that.

Greg

On Wed, Nov 11, 2015 at 11:14 AM, Malcolm Hutty <malcolm@linx.net> wrote:

...

On 11/11/2015 15:45, Silver, Bradley wrote:

...

Malcolm, even if ICANN's ability to enforce agreements with contracted parties is enshrined in the language below, how would we address an argument that the prohibition against regulation precludes such contracts having a downstream effect on non-contracted parties (and content)? As Becky alludes, the URDP and WHOIS requirements are examples of those downstream effects.

When answering such a question, it's very important to analyse the text itself, not various loose paraphrasings of the text we have all been using in more casual conversation. While "the prohibition against regulation" and "precludes contracts having a downstream effect on non-contracted parties" are broad descriptions of the kind of thing this clause is intended to prohibit, they are not sufficiently precise to give an accurate answer to your question. To answer it, we have to look at the precise wording itself.

The text as proposed only says that ICANN may not:

"regulate of services that use the Internet's unique identifiers [to enable or facilitate their reachability over the Internet], nor shall it regulate the content that those services carry or provide"

When we analyse this closely, we will see that this prohibition is not as broad as the paraphrasing.

So let's split this into parts:

1. Who does this apply to? "The services that use the Internet's unique identifiers to enable or facilitate their reachability over the Internet".

These services are things like web servers, mail servers and so forth. Services are a technical thing. They're not companies: companies are the *providers* of such services.

2. What is ICANN prohibited from doing? a) regulating those services; or b) regulating the content that those services carry or provide

So ICANN is, by this text, precluded from regulating the services themselves, but is not explicitly prohibited from regulating the providers of those services in ways that do not entail the regulation of those services (although it will have to find authorisation for doing that elsewhere in its mission)*.

Now, let's apply that to WHOIS requirements.

"WHOIS requirements", loosely stated, require registrants to disclose certain information for publication in the WHOIS system.

You could argue about whether that's a form of "regulation" of registrants, but even if it is, it's not regulation of a web service or a mail service. It doesn't say "the web service must do this" or "the web service must not do that". Web services don't register domains; companies and individuals do.

Nor is this regulation of the content that those services carry or provide. The things you do when you register a domain are not web content, they're actions taken by the registrant. The WHOIS requirement says things like "If ACME corporation wishes to register ACME.com, it must disclose its name and address for WHOIS publication". Nothing in that is regulation of what appears on ACME's web site, in any way.

It would be up to someone who wanted to challenge the UDRP or the WHOIS requirements to prove that this text precludes those requirements. They will be unable to do so.

If you would like me to walk you through the same analysis with UDRP, I can do so, but I think the above answers your question.

Kind Regards,

Malcolm.

* NB: This is an important point, with important ramifications. ICANN is not prohibited by this clause from any form of regulation of domain registrants at all. That may disappoint some (perhaps in civil society). I think it shows that this clause is balanced.

...

-----Original Message----- From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Malcolm Hutty Sent: Wednesday, November 11, 2015 10:26 AM To: Burr, Becky; Robin Gross Cc: ACCT-Staff; Accountability Community Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract

On 11/11/2015 14:47, Burr, Becky wrote:

...

Could I get you to expand on one point Robin, Paul and others? To the extent ICANN obligates registrars to make registrants agree to submit to a UDRP, is that regulation of parties not in privity of contract with ICANN? What about the requirement that registrants provide accurate WHOIS Information.

Perhaps I can take that.

The proposal that we frame this as a prohibition on "regulation of parties not in privity of contract with ICANN" is a proposal from BC and USCIB. It is one form of wording that aims at the same basic intent as the original wording.

For myself, I think this alternative wording is intended to resolve one fear (that an excessively broad interpretation of "regulate" might result in ICANN being unable to form contracts of any sort), but it introduces problems of its own. If the BC's wording were used, I think UDRP and WHOIS requirements would be in jeopardy. I wouldn't want to do that, not do I see any public comment that suggests this is anybody's aim, least of all BC. That's why, when we sought a compromise that would address that concern, we did not adopt the BC wording, but instead added the following:

"ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission."

I think this is a good faith effort to accomodate the point that BC and USCIB raised, without reneging on the basic attempt to prevent the downstream content regulation, a principle that BC, USCIB have been clear that they also support. In other words, if we keep the Second Draft Report text and adopt the above sentence in addition, I believe we can in good conscience say that we have accommodated BOTH those that supported the original language AND the BC/USCIB input. Such reconciliation is surely what we should be aiming at, is it not?

So the answer to your question is that if we go with the Second Draft Report language (with or without the additional sentence), I don't think there is any problem with continuing UDRP or WHOIS. If we adopted the BC text as an alternative solution, I think that would make the UDRP ultra vires (which is surely accidental on BC's part).

...

What about the new gTLD applicant guidebook prohibition on Strings at the top level that advocate behavior that violateS globally accepted human rights standards?

...

These examples are things that ICANN does right now. Are they ultra vires under the regulatory prohibition? If not, why not?

Again, we need to distinguish between the BC text and the Second Draft Report text.

I think that BC text would create a conflict here too.

The Second Draft Report text (with or without the additional sentence quoted above) would not conflict with those rules. The reason is that the text does not restrain ICANN in its choices as to which top-level domains to approve or decline to approve in any way.

The text only restricts ICANN from seeking to regulate the services (such as web servers) that use the DNS. Declining to approve the delegation of a controversial string could not credibly be said to be an example of regulating the services (such as web servers) that use the DNS. Any attempt to mount such a claim in an IRP challenge would be doomed to failure. Indeed, assuming the IRP adopts procedures for the swift dismissal of claims with no reasonable prospect of success, as we recommend elsewhere in our report, such an ill-founded claim would be dismissed rapidly.

That said, Alan Greenberg has said he doesn't consider this point to be as unequivocally clear as I claim. Alan and I are entirely in agreement that this clause should not restrain ICANN's unlimited discretion as to which strings to approve as new gTLDs, but Alan thinks there is room for confusion on whether our text successfully achieves that. I would be happy to add a drafting note to our lawyers that the final text must not bring this into question.

In conclusion, as long as we proceed with the text that has been published, scrutinised, commented upon and widely suppored, we need have no fear concerning the points you raise.

Your questions do, however, point up the dangers of unforeseen consequences in making, at this late stage, substantial changes to the text we have previously published.

Kind Regards,

Malcolm.

...

Sent from my iPad

...

On Nov 11, 2015, at 8:30 AM, Robin Gross <robin@ipjustice.org> wrote:

I do not agree that there lacks consensus on including the text which states ICANN won't regulate content. There IS consensus on that point, but not full consensus because a small minority disagrees with that position (IPC). Some in the BC don't even take this extreme IPC position.

Many different parts of the community have commented that this is a crucial component to our proposed accountability plan, so taking it out at this stage, simply because the IPC won't relent is unacceptable. The other parts of the community have to accept that we don't always get everything we want, and I find it difficult to understand why the same standard doesn't apply to the IPC - why we continue to go in circles until the IPC is satisfied. These extra bites at the apple must stop. We need some strength and backbone in our chairs and rapporteurs to not allow a small minority to impose this on the rest of the community, simply by refusing to relent until time runs out.

Deleting this point, which has been repeatedly stated as crucial for such a wide segment of the community will create much more trouble for the acceptance of our report than not allowing the IPC to get everything it wants.

Robin

...

On Nov 10, 2015, at 7:19 PM, Malcolm Hutty wrote:

> On 11/11/2015 02:10, Burr, Becky wrote: Malcolm et al: > > I have to agree that the 11 comments appended by Malcolm > express strong support for the notion that ICANN should not > use its contractual authority to ³regulate services that use > the DNS or the regulation of content these services carry or > provide² and that ICANN should not attempt to establish > obligations on non-contracted parties.² But the very > commenters cited (BC, USCIB, etc.)

Do you mean to imply that more than those two did?

> also request clarification regarding ICANN¹s authority to > enforce its contracts. What are we to make of this?

That's misleading. They didn't make a generalised, open-ended request for clarification that opens the door to you to construct an entirely new principle inconsistent with the main principle. They had a proposal of their own.

BC said:

BC strongly support the proposition that ICANN should not attempt to establish obligations on non-contracted parties. Paragraph 60 should be clarified and we propose that it should read as follows: "ICANN shall not engage in or use its powers to attempt to establish contractual obligations on companies with which it is not in privity of contract and shall not attempt to establish contractual obligations on contracted parties that are not agreed by such parties."

Similarly, USCIB said:

Indeed, ICANN's entire multi-stakeholder structure is built on a self-regulatory system implemented through contractual obligations and thus ICANN can only establish contractual obligations on parties with which it has privity through a negotiated and mutually agreeable contract/amendment with such parties. Therefore, para 60 should be clarified and we propose that it should read as follows: "ICANN shall not engage in or use its powers to attempt to establish contractual obligations on companies with which it is not in privity of contract and shall not attempt to establish contractual obligations on contracted parties that are not agreed by such parties."

This new language is simply not consistent with the proposition that ICANN should have any ability to enter into contracts with Registries for the purpose of regulating (or controlling, or any-of-a-number-of-other-verbs) the companies who register domain names, their business models or the content those companies carry on their web sites. Doing any of those things would entail "establishing contractual obligations on companies with which it [ICANN] is not in privity of contract", which is precisely what they say ICANN must not do.

> With all due respect Malcolm, I will take a back seat to no > one as a consistent and ardent defender of ICANN¹s limited > mission.

Take care, Becky. You are starting to make it sound as though your own self-image as the defender of ICANN's limited mission is getting in the way of recognising other input with that same aim, but with which you personally disagree.

> So I will restate the specific questions for the CCWG: > > 1. Do you agree or disagree with the following statement: "To > the extent that registry operators voluntarily assume > obligations with respect to registry operations as part of > the application process, ICANN should have the authority to > enforce those commitments.²

The expressed view of these 11 commenters (including, I note, the formal submission of the BC) clearly gives their answer to this question as "disagree", at least inasmuch as those obligations impose further obligations on third parties (registrants) that limit what content they may carry or provide on their web sites and suchlike services.

There is simply no fair reading of these 11 commenters' submissions that could answer this question as "agree", without first adding very substantial qualifications to the generality of your proposition.

> 2. Do you agree or disagree with the following statement: > "ICANN shall not regulate services that use the Internet's > unique identifiers, or the content that such services carry > or provide.² - Wherever you land, please explain what you > mean by ³regulate² and ³services."

9 of these 11 have said they agree, and accept the wording - so they don't accept your suggestion that the words "regulate" or "services" are unclear in the context used in the Draft Report.

2 of these 11 have also said they agree, but propose alternate wording to achieve that; you may consider this wording, quoted above, as responsive to your question about defining "regulate" and "services".

> I would be very interested in responses to these specific an > limited questions.

-- 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

...

...

...

--

...

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

================================================================= This message is the property of Time Warner Inc. and is intended only for the use of the addressee(s) and may be legally privileged and/or confidential. If the reader of this message is not the intended recipient, or the employee or agent responsible to deliver it to the intended recipient, he or she is hereby notified that any dissemination, distribution, printing, forwarding, or any method of copying of this information, and/or the taking of any action in reliance on the information herein is strictly prohibited except by the intended recipient or those to whom he or she intentionally distributes this message. If you have received this communication in error, please immediately notify the sender, and delete the original message and any copies from your computer or storage system. Thank you. =================================================================

-- 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

Dear Becky (and others in WP2) I apologize for not having chimed in earlier -- but many large commitments have limited my participation. Permit me to react at a slightly different level -- for me, an iron clad mission limitation is the single defining characteristic of what we need out of the transition -- even more than the IRP and the ST18 limits. Because, in the end, a concrete justiciable limitation on ICANN doing more than what it is assigned to do in managing the network is all that stands between the users and, in the end, some unrestrained monopoly. To that end, I cannot support a statement that suggests that any voluntary commitment between a registry and ICANN is per se enforceable by ICANN. I can easily imagine many situations in which a registry and ICANN might in friendly agreement both expand on ICANN's mission. If we lose that limitation -- if we go the way of endorsing all voluntaryily assumed obligations, we lose much control over ICANN and that is a prospect I do not think we should accept. As to your question #2 -- I have supported that language for a long time and I do not see any real ambiguity in the terms regulate and services. For "regulate" I mean " control or supervise (something, especially a company or business activity) by means of rules and regulations." As for services, I think it applies quite simply to the intangible products provided. Traditionally, it is distinguished from a physical good. To be sure in both definitions there are edge cases and gray areas -- but that is true of any language at all. So I think the language is clear enough to provide a justiciable standard. If you are concerned about that then we could get more "lawyerly" and use the BC formulation related to privity of contract. I could support that as well. But I am fundamentally concerned that in a rush to try and find a consensus we are relaxing our basic demands for ICANN accountability. So to return to my original notation above -- without a firm limitation on ICANN, one that cannot be modified by voluntary contractual agreement between ICANN and others, we lose all ability to restrain ICANN's mission. The voluntary contract exception swallows the mission limitation rule and I would strongly urge us not to go in that direction. So -- Question 1: Disagree strongly. Question 2: Agree, with the definitions I have given. Warm regards 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: Burr, Becky [mailto:Becky.Burr@neustar.biz] Sent: Tuesday, November 10, 2015 9:10 PM To: Malcolm Hutty <malcolm@linx.net>; Accountability Community <accountability-cross-community@icann.org>; ACCT-Staff (acct-staff@icann.org) <acct-staff@icann.org> Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract Malcolm et al: I have to agree that the 11 comments appended by Malcolm express strong support for the notion that ICANN should not use its contractual authority to ³regulate services that use the DNS or the regulation of content these services carry or provide² and that ICANN should not attempt to establish obligations on non-contracted parties.² But the very commenters cited (BC, USCIB, etc.) also request clarification regarding ICANN¹s authority to enforce its contracts. What are we to make of this? IMHO it reflects a lack of consensus on the specific questions posed. With all due respect Malcolm, I will take a back seat to no one as a consistent and ardent defender of ICANN¹s limited mission. I completely respect your right to question the ³picket fence,² but I will also stand hard in defense of that line. That is the original bargain, and I personally will honor it. (IMHO, ICANN¹s legitimacy turns on its commitment to honor the "picket fence.²) That said, I believe I have fairly represented the diversity of views on the specific language in the proposed Mission statement. Of course, all are free to disagree. So I will restate the specific questions for the CCWG: 1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.² 2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.² - Wherever you land, please explain what you mean by ³regulate² and ³services." I would be very interested in responses to these specific an limited questions. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz <http://www.neustar.biz> On 11/10/15, 7:55 PM, "Malcolm Hutty" <malcolm@linx.net> wrote:

Dear Becky,

According to our charter, the following definitions are used: a) Full Consensus - a position where no minority disagrees; identified by an absence of objection b) Consensus ­ a position where a small minority disagrees, but most agree

See https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_d isplay_acctcrosscomm_Charter&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifz m6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=meioLcwo4WoKkpjbb8u-zgp25NiZ0ljNmk77u -KFnfI&s=vuS0ygH1S_caOlGOjf5UrjN2jLRgPKyjKzjzdS825Y8&e=

I am writing to supply evidence that two of your consensus level estimations are not consistent with these standards.

I am writing to disagree with your estimation of the level of consensus on certain points.

...

o To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.

/NOTE: There is not ³full consensus² on this position/.

To the extent that this principle as stated would override the principle that ICANN should not seek to regulate the content of web sites or the general business practices of domain registrants (parties who have no privity of contract with ICANN), I believe there is widespread disagreement with your proposal in evidence in the public comment record.

Please find attached 11 comment extracts from the first public comment period. I have chosen these 11 comments as being examples that clearly and unequivocally expresses opposition to your proposed principle, to the extent stated above. These comments come from a broad range of stakeholders, including a Congressional Resolution.

I therefore content that the correct assessment is that there is *no consensus* in favour of this principle.

...

*We do not appear to have consensus on the following concept*: /Without in any way limiting the foregoing absolute prohibition, ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide./

The same attached comments express clear support for this concept, and in many cases explicit endorsement of the wording.

The only criticism of it in the public comment was from the intellectual property stakeholders spread across BC/IPC.

Since there is both broadly based support and the only objections to this principle come from a narrow segment of the community, I contend that the proper assessment is that this principle *has achieved consensus, stopping short of full consensus*.

...

Coordinating development, implementation, and enforcement of Consensus Policy, as defined by Specification 1 of the New gTLD Registry Agreement and Specification 4 of the 2013 Registrar Accreditation Agreement, is within ICANN¹s Mission.

Becky, I'm afraid the only person who keeps coming back to Specification 1/Spec 4 as an adequate statement of the bounds of the Mission is you. And whenever you do so, it is challenged.

I don't think you have any basis whatsoever for claiming that this group as a whole has selected these documents as its view of the best or most appropriate way to define or describe the parameters of the Mission, let alone the best mechanism for recording those parameters.

I contend that the text in the first and second public comment rounds has a much better claim to represent a consensus view of how to draw the bounds of ICANN's Mission in this area. Unlike those demanding further changes, I offer evidence in support of this claim, in the form of the attached document.

It seems to me deeply regretable and contrary to our declared aims of transparency and inclusion to disregard both the general tenor and explicit recommendations of the public comment, and to allow vitally important last minute changes to be pushed through at the behest of a small group merely because that group has greater stamina for conducting a war of attrition.

Removing the widely popular restriction on ICANN's Mission would dishonour the public comment. For that reason, this group really ought not to support your proposal. Public comment replies should matter.

There being no new proposal that has reached consensus and that still honours the public comment response, the only proper course is to proceed with the existing text. Those few that disagree may be invited submit a minority statement, should they wish to do so.

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=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=meioLcwo4WoKkpjbb8u-zgp25NiZ0ljNmk77u-KFnfI&s=Otta_4g1f9RBJbUkPa ovRLs9e9UkRYWqz25dWn6TU1Y&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

My responses to Becky’s two specific questions: 1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.” AGREE. 2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.” - Wherever you land, please explain what you mean by “regulate” and “services." DISAGREE, to the extent that provisions in contracts entered into after full opportunity for public comment are defined as “regulation.” Also DISAGREE to the extent that “services that use the Internet’s unique identifiers” includes, e.g., domain name registration. One of the defining features of the multi-stakeholder model for management of the DNS is the reliance on contractual arrangements, in lieu of governmental regulation. If ICANN’s mission is defined in a way that impinges substantially on the ability to enforce those contracts, then it seems to me the entire model is at risk. One point that those in this discussion who are relatively new to ICANN may not fully appreciate is the extent to which all the terms of contracts between ICANN and gTLD registries and accredited registrars are subjected to public comment and robust debate before they are executed. For example, not only were there two or three rounds of formal public comment on draft versions of both the standard new gTLD Registry Agreement and the 2013 Registrar Accreditation Agreement; there were also numerous earlier opportunities for public input into the structure and contents of these agreements, including (for the RAA) through a joint GNSO-ALAC drafting team that identified and prioritized issues for inclusion in the RAA revision (its final report was published in October 2010) and (for the gTLD Registry Agreement) through the public comment proceedings on the numerous drafts of the new gTLD Applicant Guidebook between 2008 and 2012. Proposed contract renewals for the legacy gTLDs are also posted for public comment, and sometimes multiple rounds of such comments. While these opportunities for public debate and input are not the same as the full-blown Policy Development Process used within the GNSO to develop consensus policies, they constitute an extraordinary level of transparency, compared to contract negotiations in almost any other setting, whether private sector or public sector. While this transparency has certainly been irksome to contracted parties at times, and also frustrating to interested non-parties at times (since many of our suggestions, tendered through the public input and comment processes, were not ultimately incorporated into the agreements), it has become a firmly established feature of contract development in the ICANN environment. The concerns expressed by some in this discussion about the potential for outlandish or rogue contract provisions, or the asserted lack of “checks and balances” in the system, need to be evaluated in light of this reality. Steve Metalitz From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Steve DelBianco Sent: Wednesday, November 11, 2015 10:08 AM To: Burr, Becky; Malcolm Hutty; Accountability Community; ACCT-Staff (acct-staff@icann.org) Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract As Becky noted, the BC supports a limited mission for ICANN that would not allow content regulation — but the BC also insisted that ICANN could enforce its contracts. Anyone citing the BC position should understand the full BC comment on CCWG’s 2nd draft: 2.1) Element of potential concern to the BC: New bylaws might prevent ICANN from enforcing contracts and Public Interest Commitments with registries and registrars. In our Jun-2015 comments on the CCWG’s 1st draft, the BC raised a concern with the proposal to limit the scope of ICANN’s mission via the Bylaws, worrying that it would prevent ICANN from taking appropriate steps to enforce certain provisions of its contracts. As we stated in our Jun-2015 comments, the BC believes that ICANN should be able to enforce contracts that are voluntarily entered by registries and registrars, and to enforce contract terms that are voluntarily added by new gTLD registries in the form of Public Interest Commitments However, public comments from Danielle Kehl and David Post at New America requested stress tests designed to suggest that ICANN’s enforcement of contract provisions such as section 3.18 of the 2013 RAA could violate the new limited mission and prohibition on regulation of services and content12. The BC believes that the CCWG’s bylaws text is not clear on the tension between contract enforcement and a limited mission for ICANN. On the one hand, CCWG’s text could be read to prevent ICANN from enforcing Public Interest Commitments, or from agreeing to other contract provisions implementing consensus policies. On the other hand, CCWG’s text does not effectively limit ICANN from acting outside consensus policy in the implementation of those contracts. The BC asks CCWG to resolve the ambiguity with more clarity in the final proposal. From: <accountability-cross-community-bounces@icann.org<mailto:accountability-cross-community-bounces@icann.org>> on behalf of Becky Burr <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> Date: Tuesday, November 10, 2015 at 11:10 PM To: Malcolm Hutty <malcolm@linx.net<mailto:malcolm@linx.net>>, Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>>, ACCT-Staff <acct-staff@icann.org<mailto:acct-staff@icann.org>> Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract Malcolm et al: I have to agree that the 11 comments appended by Malcolm express strong support for the notion that ICANN should not use its contractual authority to ³regulate services that use the DNS or the regulation of content these services carry or provide² and that ICANN should not attempt to establish obligations on non-contracted parties.² But the very commenters cited (BC, USCIB, etc.) also request clarification regarding ICANN¹s authority to enforce its contracts. What are we to make of this? IMHO it reflects a lack of consensus on the specific questions posed. With all due respect Malcolm, I will take a back seat to no one as a consistent and ardent defender of ICANN¹s limited mission. I completely respect your right to question the ³picket fence,² but I will also stand hard in defense of that line. That is the original bargain, and I personally will honor it. (IMHO, ICANN¹s legitimacy turns on its commitment to honor the "picket fence.²) That said, I believe I have fairly represented the diversity of views on the specific language in the proposed Mission statement. Of course, all are free to disagree. So I will restate the specific questions for the CCWG: 1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.² 2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.² - Wherever you land, please explain what you mean by ³regulate² and ³services." I would be very interested in responses to these specific an limited questions. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://neustar.biz> <http://www.neustar.biz<http://www.neustar.biz>> On 11/10/15, 7:55 PM, "Malcolm Hutty" <malcolm@linx.net<mailto:malcolm@linx.net>> wrote: Dear Becky, According to our charter, the following definitions are used: a) Full Consensus - a position where no minority disagrees; identified by an absence of objection b) Consensus ­ a position where a small minority disagrees, but most agree See https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_d<https://urldefense.proofpoint.com/v2/url?u=https-3A__community.icann.org_d> isplay_acctcrosscomm_Charter&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifz m6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=meioLcwo4WoKkpjbb8u-zgp25NiZ0ljNmk77u -KFnfI&s=vuS0ygH1S_caOlGOjf5UrjN2jLRgPKyjKzjzdS825Y8&e= I am writing to supply evidence that two of your consensus level estimations are not consistent with these standards. I am writing to disagree with your estimation of the level of consensus on certain points. o To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments. /NOTE: There is not ³full consensus² on this position/. To the extent that this principle as stated would override the principle that ICANN should not seek to regulate the content of web sites or the general business practices of domain registrants (parties who have no privity of contract with ICANN), I believe there is widespread disagreement with your proposal in evidence in the public comment record. Please find attached 11 comment extracts from the first public comment period. I have chosen these 11 comments as being examples that clearly and unequivocally expresses opposition to your proposed principle, to the extent stated above. These comments come from a broad range of stakeholders, including a Congressional Resolution. I therefore content that the correct assessment is that there is *no consensus* in favour of this principle. *We do not appear to have consensus on the following concept*: /Without in any way limiting the foregoing absolute prohibition, ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide./ The same attached comments express clear support for this concept, and in many cases explicit endorsement of the wording. The only criticism of it in the public comment was from the intellectual property stakeholders spread across BC/IPC. Since there is both broadly based support and the only objections to this principle come from a narrow segment of the community, I contend that the proper assessment is that this principle *has achieved consensus, stopping short of full consensus*. Coordinating development, implementation, and enforcement of Consensus Policy, as defined by Specification 1 of the New gTLD Registry Agreement and Specification 4 of the 2013 Registrar Accreditation Agreement, is within ICANN¹s Mission. Becky, I'm afraid the only person who keeps coming back to Specification 1/Spec 4 as an adequate statement of the bounds of the Mission is you. And whenever you do so, it is challenged. I don't think you have any basis whatsoever for claiming that this group as a whole has selected these documents as its view of the best or most appropriate way to define or describe the parameters of the Mission, let alone the best mechanism for recording those parameters. I contend that the text in the first and second public comment rounds has a much better claim to represent a consensus view of how to draw the bounds of ICANN's Mission in this area. Unlike those demanding further changes, I offer evidence in support of this claim, in the form of the attached document. It seems to me deeply regretable and contrary to our declared aims of transparency and inclusion to disregard both the general tenor and explicit recommendations of the public comment, and to allow vitally important last minute changes to be pushed through at the behest of a small group merely because that group has greater stamina for conducting a war of attrition. Removing the widely popular restriction on ICANN's Mission would dishonour the public comment. For that reason, this group really ought not to support your proposal. Public comment replies should matter. There being no new proposal that has reached consensus and that still honours the public comment response, the only proper course is to proceed with the existing text. Those few that disagree may be invited submit a minority statement, should they wish to do so. 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<https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net> _&d=CwIF-g&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8W DDkMr4k&m=meioLcwo4WoKkpjbb8u-zgp25NiZ0ljNmk77u-KFnfI&s=Otta_4g1f9RBJbUkPa ovRLs9e9UkRYWqz25dWn6TU1Y&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

At 09:10 PM 11/10/2015, Burr, Becky wrote:

SNIP So I will restate the specific questions for the CCWG:

1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.²

I disagree. This is the camel sneaking its nose under the tent. ICANN is, in effect, a monopoly provider of registration (and other) services to the Internet community. Having a single provider of these services is, of course, desirable for many reasons. But like all monopolists, it can get consumers of its services to "voluntarily assume" any number of obligations - with respect to both price and non-price terms in their contracts - that are not in the best interest of the community as a whole, and which consumers would never agree to in a competitive market where there were alternative sources of supply to which they could turn. This is precisely what the accountability mechanisms should be guarding against. The whole point of this accountability exercise, and of the careful delineation of ICANN's Mission, in my opinion, is to ensure that ICANN cannot act outside of that mission - including acting by means of including (and enforcing) contractual terms that are offered to, and "voluntarily" assumed by, registries and registrars (who have no alternatives to accepting ICANN's terms).

2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.² - Wherever you land, please explain what you mean by ³regulate² and ³services."

I agree with the thrust of this statement, though I do not believe that it is well-crafted to the job it is trying to do. The statement, in context, is intended just to clarify the "absolute prohibition" against acting in a manner that is not "reasonably appropriate to achieve [ICANN's] mission," without limiting that prohibition in any way. But it is not doing that job well. First, I don't know what definitions of "regulate" and "services" could make the statement that "ICANN shall not regulate services that use the Internet's unique identifiers" a correct one. Registries and registrars offer "services" that "use the Internet's unique identifiers" - if "services" means what it ordinarily means ("the performance of any duties or work for another; helpful or professional activity" - Webster's). And ICANN clearly "regulates" registries and registrars - if "regulates" means what it ordinarily does, i.e. proposing, imposing, and enforcing binding rules of conduct on those entities. So saying "ICANN shall not regulate services that use the Internet's unique identifiers" is, at best, muddying the waters. As for regulating "the content that such services carry or provide," if this is not already taken care of in the Mission Statement, it should be. I believe that it is. ICANN can only "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 [and] that are developed through a bottom-up, consensus-based multistakeholder process and designed to ensure the stable and secure operation of the Internet’s unique names system." As long as there's no "contract exception" to that "absolute prohibition," this excludes the kind of content regulation we're concerned about. David ******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com *******************************

At 11:58 AM 11/11/2015, Burr, Becky wrote:

So you would drop both the language about regulation and the language about contracts? If so, that's what I proposed several days ago (which was not well received.). Or am I misunderstanding?

Yes, that is my position; I would support dropping both. The contract language should be dropped because the language proposed would do substantial damage to much of the entire accountability project, giving ICANN an easy way to work around the limitations in the Mission Statement. The "regulation" language does less harm, so in my opinion dropping it is less critical. But I don't think it adds anything much beyond additional confusion to the mission statement; if the mission statement doesn't already prohibit this kind of "regulation," we should amend it so that it does. I think it already does the job, but I wouldn't object strongly if the final proposal contained something like a statement that "Without limiting the foregoing absolute prohibition, ICANN shall not regulate the content carried or provided by services that use the Internet's unique identifiers." David

On Nov 11, 2015, at 8:39 AM, David Post <<mailto:david.g.post@gmail.com>david.g.post@gmail.com> wrote:

...

At 09:10 PM 11/10/2015, Burr, Becky wrote:

...

SNIP So I will restate the specific questions for the CCWG:

1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.²

I disagree.

This is the camel sneaking its nose under the tent. ICANN is, in effect, a monopoly provider of registration (and other) services to the Internet community. Having a single provider of these services is, of course, desirable for many reasons. But like all monopolists, it can get consumers of its services to "voluntarily assume" any number of obligations - with respect to both price and non-price terms in their contracts - that are not in the best interest of the community as a whole, and which consumers would never agree to in a competitive market where there were alternative sources of supply to which they could turn. This is precisely what the accountability mechanisms should be guarding against.

The whole point of this accountability exercise, and of the careful delineation of ICANN's Mission, in my opinion, is to ensure that ICANN cannot act outside of that mission - including acting by means of including (and enforcing) contractual terms that are offered to, and "voluntarily" assumed by, registries and registrars (who have no alternatives to accepting ICANN's terms).

...

2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.² - Wherever you land, please explain what you mean by ³regulate² and ³services."

I agree with the thrust of this statement, though I do not believe that it is well-crafted to the job it is trying to do. The statement, in context, is intended just to clarify the "absolute prohibition" against acting in a manner that is not "reasonably appropriate to achieve [ICANN's] mission," without limiting that prohibition in any way. But it is not doing that job well.

First, I don't know what definitions of "regulate" and "services" could make the statement that "ICANN shall not regulate services that use the Internet's unique identifiers" a correct one. Registries and registrars offer "services" that "use the Internet's unique identifiers" - if "services" means what it ordinarily means ("the performance of any duties or work for another; helpful or professional activity" - Webster's). And ICANN clearly "regulates" registries and registrars - if "regulates" means what it ordinarily does, i.e. proposing, imposing, and enforcing binding rules of conduct on those entities.

So saying "ICANN shall not regulate services that use the Internet's unique identifiers" is, at best, muddying the waters.

As for regulating "the content that such services carry or provide," if this is not already taken care of in the Mission Statement, it should be. I believe that it is. ICANN can only

"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 [and] that are developed through a bottom-up, consensus-based multistakeholder process and designed to ensure the stable and secure operation of the Internet’s unique names system."

As long as there's no "contract exception" to that "absolute prohibition," this excludes the kind of content regulation we're concerned about.

David

******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com *******************************

******************************* 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 *******************************

As I said earlier, there are two reasons not to do what Becky proposed, even though it is quite an elegant effort to say more by saying less. The first is the unfortunate drafting history that will give credence to arguments that the deletion has meaning. The second is that affirmative restrictions are much more readily enforceable than are limitations on authorization – compare in the US our muddled Commerce Clause jurisprudence with most (though admittedly not all) of our understanding of the Bill of Rights. I still think it would be a very unfortunate mistake with long-term collateral adverse unintended consequences. Paul Paul Rosenzweig <mailto:paul.rosenzweigesq@redbranchconsulting.com> paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 VOIP: +1 (202) 738-1739 Skype: paul.rosenzweig1066 <http://www.redbranchconsulting.com/index.php?option=com_content&view=articl e&id=19&Itemid=9> Link to my PGP Key From: David Post [mailto:david.g.post@gmail.com] Sent: Wednesday, November 11, 2015 1:17 PM To: Burr, Becky <Becky.Burr@neustar.biz> Cc: ACCT-Staff (acct-staff@icann.org) <acct-staff@icann.org>; Accountability Community <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract At 11:58 AM 11/11/2015, Burr, Becky wrote: So you would drop both the language about regulation and the language about contracts? If so, that's what I proposed several days ago (which was not well received.). Or am I misunderstanding? Yes, that is my position; I would support dropping both. The contract language should be dropped because the language proposed would do substantial damage to much of the entire accountability project, giving ICANN an easy way to work around the limitations in the Mission Statement. The "regulation" language does less harm, so in my opinion dropping it is less critical. But I don't think it adds anything much beyond additional confusion to the mission statement; if the mission statement doesn't already prohibit this kind of "regulation," we should amend it so that it does. I think it already does the job, but I wouldn't object strongly if the final proposal contained something like a statement that "Without limiting the foregoing absolute prohibition, ICANN shall not regulate the content carried or provided by services that use the Internet's unique identifiers." David On Nov 11, 2015, at 8:39 AM, David Post <david.g.post@gmail.com <mailto:david.g.post@gmail.com> > wrote: At 09:10 PM 11/10/2015, Burr, Becky wrote: SNIP So I will restate the specific questions for the CCWG: 1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.² I disagree. This is the camel sneaking its nose under the tent. ICANN is, in effect, a monopoly provider of registration (and other) services to the Internet community. Having a single provider of these services is, of course, desirable for many reasons. But like all monopolists, it can get consumers of its services to "voluntarily assume" any number of obligations - with respect to both price and non-price terms in their contracts - that are not in the best interest of the community as a whole, and which consumers would never agree to in a competitive market where there were alternative sources of supply to which they could turn. This is precisely what the accountability mechanisms should be guarding against. The whole point of this accountability exercise, and of the careful delineation of ICANN's Mission, in my opinion, is to ensure that ICANN cannot act outside of that mission - including acting by means of including (and enforcing) contractual terms that are offered to, and "voluntarily" assumed by, registries and registrars (who have no alternatives to accepting ICANN's terms). 2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.² - Wherever you land, please explain what you mean by ³regulate² and ³services." I agree with the thrust of this statement, though I do not believe that it is well-crafted to the job it is trying to do. The statement, in context, is intended just to clarify the "absolute prohibition" against acting in a manner that is not "reasonably appropriate to achieve [ICANN's] mission," without limiting that prohibition in any way. But it is not doing that job well. First, I don't know what definitions of "regulate" and "services" could make the statement that "ICANN shall not regulate services that use the Internet's unique identifiers" a correct one. Registries and registrars offer "services" that "use the Internet's unique identifiers" - if "services" means what it ordinarily means ("the performance of any duties or work for another; helpful or professional activity" - Webster's). And ICANN clearly "regulates" registries and registrars - if "regulates" means what it ordinarily does, i.e. proposing, imposing, and enforcing binding rules of conduct on those entities. So saying "ICANN shall not regulate services that use the Internet's unique identifiers" is, at best, muddying the waters. As for regulating "the content that such services carry or provide," if this is not already taken care of in the Mission Statement, it should be. I believe that it is. ICANN can only "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 [and] that are developed through a bottom-up, consensus-based multistakeholder process and designed to ensure the stable and secure operation of the Internet’s unique names system." As long as there's no "contract exception" to that "absolute prohibition," this excludes the kind of content regulation we're concerned about. David ******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n <http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0> music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com <http://www.davidpost.com /> ******************************* ******************************* 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 <http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0> music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com <http://www.davidpost.com /> *******************************

Fair enough David, but I am skeptical. First, such negation declarations have a way of being ignored by courts in ways that actual lanague is not. Second, the negation is particularly likely to be ineffective when the drafting history is so robust and so … frankly … contradictory. Given the posts we’ve seen from many on this list – well educated and thoughtful ones from e.g. Greg and Malcolm – the absence of any clarification and firm result – one way OR the other – will be seen as purposefully baking in ambiguity and papering over differences. That is certainly how I would read it. Or to put it in the affirmative – if we cannot state in plain language what it is that ICANN can do and what it cannot, we can’t reasonably expect the IRP to understand that. For myself, I could probably accept your limitation as helping in that regard … Cheers Paul Paul Rosenzweig <mailto:paul.rosenzweigesq@redbranchconsulting.com> paul.rosenzweig@redbranchconsulting.com O: +1 (202) 547-0660 M: +1 (202) 329-9650 VOIP: +1 (202) 738-1739 Skype: paul.rosenzweig1066 <http://www.redbranchconsulting.com/index.php?option=com_content&view=articl e&id=19&Itemid=9> Link to my PGP Key From: David Post [mailto:david.g.post@gmail.com] Sent: Wednesday, November 11, 2015 2:45 PM To: Paul Rosenzweig <paul.rosenzweig@redbranchconsulting.com> Cc: 'Burr, Becky' <Becky.Burr@neustar.biz>; 'ACCT-Staff' <acct-staff@icann.org>; 'Accountability Community' <accountability-cross-community@icann.org> Subject: RE: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract At 02:10 PM 11/11/2015, Paul Rosenzweig wrote: As I said earlier, there are two reasons not to do what Becky proposed, even though it is quite an elegant effort to say more by saying less. The first is the unfortunate drafting history that will give credence to arguments that the deletion has meaning. But that can be relatively easily dealt with by means of an accompanying statement, no? "The deletion does not reflect a consensus that ICANN is authorized to regulate content. The consensus is in precisely the opposite direction, but we believe that this is already achieved by the language in the mission statement ..." or something like that? The second is that affirmative restrictions are much more readily enforceable than are limitations on authorization – compare in the US our muddled Commerce Clause jurisprudence with most (though admittedly not all) of our understanding of the Bill of Rights. I still think it would be a very unfortunate mistake with long-term collateral adverse unintended consequences. I can see that - as I said, I'd support including something like: "Without limiting the foregoing absolute prohibition, ICANN shall not regulate the content carried or provided by services that use the Internet's unique identifiers." Doesn't that do the job? If you think it doesn't, what is it about the missing language (referring to the impermissibility of regulating "services that use the Internet's unique system of identifiers") that you think needs to be in there? David From: David Post [ mailto:david.g.post@gmail.com <mailto:david.g.post@gmail.com> ] Sent: Wednesday, November 11, 2015 1:17 PM To: Burr, Becky <Becky.Burr@neustar.biz <mailto:Becky.Burr@neustar.biz> > Cc: ACCT-Staff (acct-staff@icann.org <mailto:acct-staff@icann.org> ) <acct-staff@icann.org <mailto:acct-staff@icann.org> >; Accountability Community <accountability-cross-community@icann.org <mailto:accountability-cross-community@icann.org> > Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract At 11:58 AM 11/11/2015, Burr, Becky wrote: So you would drop both the language about regulation and the language about contracts? If so, that's what I proposed several days ago (which was not well received.). Or am I misunderstanding? Yes, that is my position; I would support dropping both. The contract language should be dropped because the language proposed would do substantial damage to much of the entire accountability project, giving ICANN an easy way to work around the limitations in the Mission Statement. The "regulation" language does less harm, so in my opinion dropping it is less critical. But I don't think it adds anything much beyond additional confusion to the mission statement; if the mission statement doesn't already prohibit this kind of "regulation," we should amend it so that it does. I think it already does the job, but I wouldn't object strongly if the final proposal contained something like a statement that "Without limiting the foregoing absolute prohibition, ICANN shall not regulate the content carried or provided by services that use the Internet's unique identifiers." David On Nov 11, 2015, at 8:39 AM, David Post <david.g.post@gmail.com <mailto:david.g.post@gmail.com> > wrote: At 09:10 PM 11/10/2015, Burr, Becky wrote: SNIP So I will restate the specific questions for the CCWG: 1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.² I disagree. This is the camel sneaking its nose under the tent. ICANN is, in effect, a monopoly provider of registration (and other) services to the Internet community. Having a single provider of these services is, of course, desirable for many reasons. But like all monopolists, it can get consumers of its services to "voluntarily assume" any number of obligations - with respect to both price and non-price terms in their contracts - that are not in the best interest of the community as a whole, and which consumers would never agree to in a competitive market where there were alternative sources of supply to which they could turn. This is precisely what the accountability mechanisms should be guarding against. The whole point of this accountability exercise, and of the careful delineation of ICANN's Mission, in my opinion, is to ensure that ICANN cannot act outside of that mission - including acting by means of including (and enforcing) contractual terms that are offered to, and "voluntarily" assumed by, registries and registrars (who have no alternatives to accepting ICANN's terms). 2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.² - Wherever you land, please explain what you mean by ³regulate² and ³services." I agree with the thrust of this statement, though I do not believe that it is well-crafted to the job it is trying to do. The statement, in context, is intended just to clarify the "absolute prohibition" against acting in a manner that is not "reasonably appropriate to achieve [ICANN's] mission," without limiting that prohibition in any way. But it is not doing that job well. First, I don't know what definitions of "regulate" and "services" could make the statement that "ICANN shall not regulate services that use the Internet's unique identifiers" a correct one. Registries and registrars offer "services" that "use the Internet's unique identifiers" - if "services" means what it ordinarily means ("the performance of any duties or work for another; helpful or professional activity" - Webster's). And ICANN clearly "regulates" registries and registrars - if "regulates" means what it ordinarily does, i.e. proposing, imposing, and enforcing binding rules of conduct on those entities. So saying "ICANN shall not regulate services that use the Internet's unique identifiers" is, at best, muddying the waters. As for regulating "the content that such services carry or provide," if this is not already taken care of in the Mission Statement, it should be. I believe that it is. ICANN can only "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 [and] that are developed through a bottom-up, consensus-based multistakeholder process and designed to ensure the stable and secure operation of the Internet’s unique names system." As long as there's no "contract exception" to that "absolute prohibition," this excludes the kind of content regulation we're concerned about. David ******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n <http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0> music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com <http://www.davidpost.com %20/> ******************************* ******************************* 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 <http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0> music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com <http://www.davidpost.com %20/> ******************************* ******************************* 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 <http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0> music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com <http://www.davidpost.com /> *******************************

Paul is right, David is wrong. You can't drop both, unless you don't want to have an effective limit on ICANN's mission --MM From: accountability-cross-community-bounces@icann.org [mailto:accountability-cross-community-bounces@icann.org] On Behalf Of Paul Rosenzweig Sent: Wednesday, November 11, 2015 2:11 PM To: 'David Post' <david.g.post@gmail.com>; 'Burr, Becky' <Becky.Burr@neustar.biz> Cc: 'ACCT-Staff' <acct-staff@icann.org>; 'Accountability Community' <accountability-cross-community@icann.org> Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract As I said earlier, there are two reasons not to do what Becky proposed, even though it is quite an elegant effort to say more by saying less. The first is the unfortunate drafting history that will give credence to arguments that the deletion has meaning. The second is that affirmative restrictions are much more readily enforceable than are limitations on authorization - compare in the US our muddled Commerce Clause jurisprudence with most (though admittedly not all) of our understanding of the Bill of Rights. I still think it would be a very unfortunate mistake with long-term collateral adverse unintended consequences. Paul Paul Rosenzweig paul.rosenzweig@redbranchconsulting.com<mailto:paul.rosenzweigesq@redbranchconsulting.com> O: +1 (202) 547-0660 M: +1 (202) 329-9650 VOIP: +1 (202) 738-1739 Skype: paul.rosenzweig1066 Link to my PGP Key<http://www.redbranchconsulting.com/index.php?option=com_content&view=article...> From: David Post [mailto:david.g.post@gmail.com] Sent: Wednesday, November 11, 2015 1:17 PM To: Burr, Becky <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> Cc: ACCT-Staff (acct-staff@icann.org<mailto:acct-staff@icann.org>) <acct-staff@icann.org<mailto:acct-staff@icann.org>>; Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>> Subject: Re: [CCWG-ACCT] Attempt to summarize discussion regarding Mission and Contract At 11:58 AM 11/11/2015, Burr, Becky wrote: So you would drop both the language about regulation and the language about contracts? If so, that's what I proposed several days ago (which was not well received.). Or am I misunderstanding? Yes, that is my position; I would support dropping both. The contract language should be dropped because the language proposed would do substantial damage to much of the entire accountability project, giving ICANN an easy way to work around the limitations in the Mission Statement. The "regulation" language does less harm, so in my opinion dropping it is less critical. But I don't think it adds anything much beyond additional confusion to the mission statement; if the mission statement doesn't already prohibit this kind of "regulation," we should amend it so that it does. I think it already does the job, but I wouldn't object strongly if the final proposal contained something like a statement that "Without limiting the foregoing absolute prohibition, ICANN shall not regulate the content carried or provided by services that use the Internet's unique identifiers." David On Nov 11, 2015, at 8:39 AM, David Post <david.g.post@gmail.com<mailto:david.g.post@gmail.com> > wrote: At 09:10 PM 11/10/2015, Burr, Becky wrote: SNIP So I will restate the specific questions for the CCWG: 1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.² I disagree. This is the camel sneaking its nose under the tent. ICANN is, in effect, a monopoly provider of registration (and other) services to the Internet community. Having a single provider of these services is, of course, desirable for many reasons. But like all monopolists, it can get consumers of its services to "voluntarily assume" any number of obligations - with respect to both price and non-price terms in their contracts - that are not in the best interest of the community as a whole, and which consumers would never agree to in a competitive market where there were alternative sources of supply to which they could turn. This is precisely what the accountability mechanisms should be guarding against. The whole point of this accountability exercise, and of the careful delineation of ICANN's Mission, in my opinion, is to ensure that ICANN cannot act outside of that mission - including acting by means of including (and enforcing) contractual terms that are offered to, and "voluntarily" assumed by, registries and registrars (who have no alternatives to accepting ICANN's terms). 2. Do you agree or disagree with the following statement: "ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide.² - Wherever you land, please explain what you mean by ³regulate² and ³services." I agree with the thrust of this statement, though I do not believe that it is well-crafted to the job it is trying to do. The statement, in context, is intended just to clarify the "absolute prohibition" against acting in a manner that is not "reasonably appropriate to achieve [ICANN's] mission," without limiting that prohibition in any way. But it is not doing that job well. First, I don't know what definitions of "regulate" and "services" could make the statement that "ICANN shall not regulate services that use the Internet's unique identifiers" a correct one. Registries and registrars offer "services" that "use the Internet's unique identifiers" - if "services" means what it ordinarily means ("the performance of any duties or work for another; helpful or professional activity" - Webster's). And ICANN clearly "regulates" registries and registrars - if "regulates" means what it ordinarily does, i.e. proposing, imposing, and enforcing binding rules of conduct on those entities. So saying "ICANN shall not regulate services that use the Internet's unique identifiers" is, at best, muddying the waters. As for regulating "the content that such services carry or provide," if this is not already taken care of in the Mission Statement, it should be. I believe that it is. ICANN can only "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 [and] that are developed through a bottom-up, consensus-based multistakeholder process and designed to ensure the stable and secure operation of the Internet's unique names system." As long as there's no "contract exception" to that "absolute prohibition," this excludes the kind of content regulation we're concerned about. David ******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n <http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0> music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com <http://www.davidpost.com       /> ******************************* ******************************* 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 <http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0> music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com <http://www.davidpost.com        /> *******************************

Those are, of course, not the provisions of which we speak Jonathan Zuck President ACT: The App Association Www.ACTonline.org From: Dr Eberhard W Lisse<mailto:el@lisse.NA> Sent: ?Wednesday?, ?November? ?11?, ?2015 ?1?:?41? ?PM To: Accountability CCWG<mailto:accountability-cross-community@icann.org> Cc: directors@omadhina.net<mailto:directors@omadhina.net> I find that the words "voluntary" and "enforce" are mutually exclusive. In particular in the situation where "voluntary" means "take it or leave it". el On 2015-11-11 04:10, Burr, Becky wrote: [...]

1. Do you agree or disagree with the following statement: "To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.^2 [...]

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

Many words, but still wrong. Any consensus is measured by the members, appointed by the chairing organizations. Commenters have, per se, nothing to do with it. Unless of course they are ALAC appointed members. el -- Sent from Dr Lisse's iPad mini

On 11 Nov 2015, at 02:55, Malcolm Hutty <malcolm@linx.net> wrote:

Dear Becky,

According to our charter, the following definitions are used: a) Full Consensus - a position where no minority disagrees; identified by an absence of objection b) Consensus – a position where a small minority disagrees, but most agree

See https://community.icann.org/display/acctcrosscomm/Charter

I am writing to supply evidence that two of your consensus level estimations are not consistent with these standards.

I am writing to disagree with your estimation of the level of consensus on certain points.

...

o To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.

/NOTE: There is not “full consensus” on this position/.

To the extent that this principle as stated would override the principle that ICANN should not seek to regulate the content of web sites or the general business practices of domain registrants (parties who have no privity of contract with ICANN), I believe there is widespread disagreement with your proposal in evidence in the public comment record.

Please find attached 11 comment extracts from the first public comment period. I have chosen these 11 comments as being examples that clearly and unequivocally expresses opposition to your proposed principle, to the extent stated above. These comments come from a broad range of stakeholders, including a Congressional Resolution.

I therefore content that the correct assessment is that there is *no consensus* in favour of this principle.

...

*We do not appear to have consensus on the following concept*: /Without in any way limiting the foregoing absolute prohibition, ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide./

The same attached comments express clear support for this concept, and in many cases explicit endorsement of the wording.

The only criticism of it in the public comment was from the intellectual property stakeholders spread across BC/IPC.

Since there is both broadly based support and the only objections to this principle come from a narrow segment of the community, I contend that the proper assessment is that this principle *has achieved consensus, stopping short of full consensus*.

...

Coordinating development, implementation, and enforcement of Consensus Policy, as defined by Specification 1 of the New gTLD Registry Agreement and Specification 4 of the 2013 Registrar Accreditation Agreement, is within ICANN’s Mission.

Becky, I'm afraid the only person who keeps coming back to Specification 1/Spec 4 as an adequate statement of the bounds of the Mission is you. And whenever you do so, it is challenged.

I don't think you have any basis whatsoever for claiming that this group as a whole has selected these documents as its view of the best or most appropriate way to define or describe the parameters of the Mission, let alone the best mechanism for recording those parameters.

I contend that the text in the first and second public comment rounds has a much better claim to represent a consensus view of how to draw the bounds of ICANN's Mission in this area. Unlike those demanding further changes, I offer evidence in support of this claim, in the form of the attached document.

It seems to me deeply regretable and contrary to our declared aims of transparency and inclusion to disregard both the general tenor and explicit recommendations of the public comment, and to allow vitally important last minute changes to be pushed through at the behest of a small group merely because that group has greater stamina for conducting a war of attrition.

Removing the widely popular restriction on ICANN's Mission would dishonour the public comment. For that reason, this group really ought not to support your proposal. Public comment replies should matter.

There being no new proposal that has reached consensus and that still honours the public comment response, the only proper course is to proceed with the existing text. Those few that disagree may be invited submit a minority statement, should they wish to do so.

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

<Mission comments extracts.docx> <Mission comments extracts.pdf> _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community

My responses to Malcolm's first email are inline. Greg On Tue, Nov 10, 2015 at 7:55 PM, Malcolm Hutty <malcolm@linx.net> wrote:

Dear Becky,

According to our charter, the following definitions are used: a) Full Consensus - a position where no minority disagrees; identified by an absence of objection b) Consensus – a position where a small minority disagrees, but most agree

See https://community.icann.org/display/acctcrosscomm/Charter

I am writing to supply evidence that two of your consensus level estimations are not consistent with these standards.

I am writing to disagree with your estimation of the level of consensus on certain points.

...

o To the extent that registry operators voluntarily assume obligations with respect to registry operations as part of the application process, ICANN should have the authority to enforce those commitments.

/NOTE: There is not “full consensus” on this position/.

To the extent that this principle as stated would override the principle that ICANN should not seek to regulate the content of web sites or the general business practices of domain registrants (parties who have no privity of contract with ICANN), I believe there is widespread disagreement with your proposal in evidence in the public comment record.

Please find attached 11 comment extracts from the first public comment period. I have chosen these 11 comments as being examples that clearly and unequivocally expresses opposition to your proposed principle, to the extent stated above. These comments come from a broad range of stakeholders, including a Congressional Resolution.

​GS: I think there are two fundamental flaws here, which essentially negate this entire analysis. First, this attempts to conflate the public comment record and the concept of CCWG consensus. Public comments are important and they must be considered in the work of the CCWG (or any WG) but they are in no way a measure of consensus (or lack of consensus) within the CCWG​. These are apples and oranges; though I suppose if you juggle them fast enough, they all look like fruit. Any attempt to use public comments to determine CCWG consensus should be rejected. (It's worth noting that these are 11 comments out of well over 100, so clearly that doesn't represent any kind of consensus, even among the commenters. The second fundamental flaw is the presumption that enforcing " voluntarily assume ​d​ obligations ​ with respect to registry operations ​" constitutes "regulation of services that use the DNS or the content these services carry or provide" or the regulation of entities with which iCANN does not have a contractual relationship. I contend that it is nothing of the sort.​ Indeed it's hard to see any linkage between the registry obligations on the one hand, and the regulation of services or content, on the other hand. And frankly, if there is a linkage, nullifying agreements and obligations that form the basis of the new gTLD program is something to be avoided aggressively, not embraced. Finally, HR 2251 is not a "Congressional Resolution': it is merely a piece of proposed legislation (the "Defending Internet Freedom Act") which is now dead and carries essentially zero weight. "Congressional Resolution" sounded pretty impressive, though....

I therefore content that the correct assessment is that there is *no consensus* in favour of this principle.

...

*We do not appear to have consensus on the following concept*: /Without in any way limiting the foregoing absolute prohibition, ICANN shall not regulate services that use the Internet's unique identifiers, or the content that such services carry or provide./

The same attached comments express clear support for this concept, and in many cases explicit endorsement of the wording.

The only criticism of it in the public comment was from the intellectual property stakeholders spread across BC/IPC.

​This is actually incorrect; there where critical comments from DotMusic, China Academy of ICT and, less directly, Jan Scholte. Also, as Becky noted, a number of the comments you cited actually cut both ways, in spite of the selective quotes offered up. Furthermore, I reject the compartmentalization and marginalization of a wide variety of businesses, to be dismissed ​as mere "intellectual property stakeholders". ​ Finally, I, for one, am not a big fan of "regulation" of "content" as a general matter; freedom to express opinions, freedom to be creative, and freedom of the press are important (and entirely consistent with the concerns of "intellectual property stakeholders"); rather, there are specific and limited concerns at play here. Unfortunately, bylaws tend to be a blunt instrument and resistant to any nuance or balancing of concerns in their drafting. As such, while there may be a formulation that can meet everyone's needs, we are unlikely to find it in this exercise in this time frame.​ We are particularly unlikely to find it, or harmony generally, if this is turned into an "us vs. them" exercise.

Since there is both broadly based support and the only objections to this principle come from a narrow segment of the community, I contend that the proper assessment is that this principle *has achieved consensus, stopping short of full consensus*.

...

Coordinating development, implementation, and enforcement of Consensus Policy, as defined by Specification 1 of the New gTLD Registry Agreement and Specification 4 of the 2013 Registrar Accreditation Agreement, is within ICANN’s Mission.

Becky, I'm afraid the only person who keeps coming back to Specification 1/Spec 4 as an adequate statement of the bounds of the Mission is you. And whenever you do so, it is challenged.

​Malcolm, I'm afraid that's incorrect. I certainly see Consensus Policy as an important cornerstone of ICANN's Mission, and actually a foundational concept for ICANN.​ While it may not fit to the boundaries of ICANN's mission exactly, making, implementing and enforcing Consensus Policy is at the heart of ICANN's mission. ​There was support for that on the call and I'm sure there's significant support for that in the CCWG and the community.​

I don't think you have any basis whatsoever for claiming that this group as a whole has selected these documents as its view of the best or most appropriate way to define or describe the parameters of the Mission, let alone the best mechanism for recording those parameters.

​I actually agree we have not reached consensus on this point, but "these documents" (as you dismissively term the Consensus Policy Specifications of the RA and RAA)​ ​are hardly the lonely and unloved "documents" you paint them as.​ The explicit concern of the interplay between Consensus Policy and this proposed bylaw has been slow growing and was not recognized in the early stages of this process, but it is a very real one.

I contend that the text in the first and second public comment rounds has a much better claim to represent a consensus view of how to draw the bounds of ICANN's Mission in this area. Unlike those demanding further changes, I offer evidence in support of this claim, in the form of the attached document.

​I would reject that contention. The public comments did not consider, one way or the other, the effect this Bylaw might have on Consensus Policy. In any event, 11 comments from a comment period of something like 115 comments is hardly a "consensus" of anything (and as discussed above, certainly not a consensus of the CCWG). In any event, I actually don't think there is a tension between protecting Consensus Policy and the concerns of those you quote. Frankly, I think if you asked most, if not all, of those commenting whether there intent was to redefine Consensus Policy, their response would either be "absolutely not" or "I had no idea that was going to happen" and not "absolutely."​

It seems to me deeply regretable and contrary to our declared aims of transparency and inclusion to disregard both the general tenor and explicit recommendations of the public comment, and to allow vitally important last minute changes to be pushed through at the behest of a small group merely because that group has greater stamina for conducting a war of attrition.

​I am not sure what group (much less, "small group") you are referring to, but I would say first that the changes Becky has proposed are not at the behest of "intellectual property interests"; second, (assuming you are referrikng to "intellectual property interests" and casting me as such, which is rather reductive) I don't view this as a war, much less a war of attrition -- this should be a collaborative process (but if war is preferable, I'm sure I can figure out what "war mode" is); and third, as to stamina, my hat's off to you -- I still have two (no, it's now three) recent emails of yours that I should respond to, but haven't yet found the time to. ​

Removing the widely popular restriction on ICANN's Mission would dishonour the public comment. For that reason, this group really ought not to support your proposal. Public comment replies should matter.

​Of course, public comments do matter; we must take them into consideration, and we have, but we are not enslaved by them. The work of the CCWG (or any WG) is dynamic and we don't "dishonour" Public Comments generally by not adopting any particular suggestion in any particular comment or set of comments. Finally, I would question whether anything that was supported in 11 out of 115 comments is "widely popular."

There being no new proposal that has reached consensus and that still honours the public comment response, the only proper course is to proceed with the existing text. Those few that disagree may be invited submit a minority statement, should they wish to do so.

"Honoring the public comment response" is a newly invented criterion, which I would suggest is both too vague and too restrictive to be adopted, at least as suggested. i would contend we have honored them by taking them into consideration, and frankly, Becky's suggestion is still broadly congruent with those comments, which is even more of an honor.​

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