Attempt to summarize discussion regarding Mission and Contract
Please read all the way through to the bottom for a question and proposal. Based on our discussion this morning, I believe that the following statements reflect the consensus of the CCWG (lack of “full consensus” on 1 point noted in text): · ICANN’s Mission with respect to names is described in the Mission Statement as follows: With respect to NAMES, ICANN’s Mission is to coordinate 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: (I)For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and (ii) 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. · ICANN’s Mission is limited and enumerated. · ICANN’s should act in accordance with, and only as reasonably appropriate to achieve its Mission. · 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. · ICANN should have the authority to enforce agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANN’s Mission on such parties. 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. o In general, consistent with ordinary contract concepts, registries and registrars should be presumed to have agreed to the terms and conditions of any contract with ICANN. That said, there should be some mechanism whereby contracted parties can enter into such agreements without waiving their rights to challenge specified provisions of such an agreement on the grounds that they exceed the scope of ICANN’s Mission. Any such mechanism would have to provide adequate notice, needs to be developed, etc. 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. Question: Does the following formulation thread the needle between those who say that ICANN should not use its contracting authority to regulate registrant behavior and those who point out that the Registrar Accreditation Agreement, for example, requires registrants to provide accurate and up-to-date WHOIS data: ICANN should not use its authority to enter into contracts with registries and registrars to impose obligations and limitations on registrants with respect to issues that are not properly the subject of Consensus Policy. PROPOSAL: If so, I propose that the CCWG provide the text above as guidance for the final bylaws drafters in interpreting the admonition that "ICANN shall act strictly in accordance with, and only as reasonably appropriate to achieve its Mission.” I believe this would (1) eliminate concerns and ambiguity regarding use of the word “regulation,”; (2) reflect consensus on the principles; and (3) address the late change/legislative history/statutory construction concern raised by Paul R. and others. 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>
I hope this comes through! 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: <Burr>, Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>> Date: Tuesday, November 10, 2015 at 5:58 PM To: Accountability Community <accountability-cross-community@icann.org<mailto:accountability-cross-community@icann.org>>, "ACCT-Staff (acct-staff@icann.org<mailto:acct-staff@icann.org>)" <acct-staff@icann.org<mailto:acct-staff@icann.org>> Subject: Attempt to summarize discussion regarding Mission and Contract Please read all the way through to the bottom for a question and proposal. Based on our discussion this morning, I believe that the following statements reflect the consensus of the CCWG (lack of “full consensus” on 1 point noted in text): · ICANN’s Mission with respect to names is described in the Mission Statement as follows: With respect to NAMES, ICANN’s Mission is to coordinate 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: (I)For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and (ii) 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. · ICANN’s Mission is limited and enumerated. · ICANN’s should act in accordance with, and only as reasonably appropriate to achieve its Mission. · 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. · ICANN should have the authority to enforce agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANN’s Mission on such parties. 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. o In general, consistent with ordinary contract concepts, registries and registrars should be presumed to have agreed to the terms and conditions of any contract with ICANN. That said, there should be some mechanism whereby contracted parties can enter into such agreements without waiving their rights to challenge specified provisions of such an agreement on the grounds that they exceed the scope of ICANN’s Mission. Any such mechanism would have to provide adequate notice, needs to be developed, etc. 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. Question: Does the following formulation thread the needle between those who say that ICANN should not use its contracting authority to regulate registrant behavior and those who point out that the Registrar Accreditation Agreement, for example, requires registrants to provide accurate and up-to-date WHOIS data: ICANN should not use its authority to enter into contracts with registries and registrars to impose obligations and limitations on registrants with respect to issues that are not properly the subject of Consensus Policy. PROPOSAL: If so, I propose that the CCWG provide the text above as guidance for the final bylaws drafters in interpreting the admonition that "ICANN shall act strictly in accordance with, and only as reasonably appropriate to achieve its Mission.” I believe this would (1) eliminate concerns and ambiguity regarding use of the word “regulation,”; (2) reflect consensus on the principles; and (3) address the late change/legislative history/statutory construction concern raised by Paul R. and others. J. Beckwith Burr Neustar, Inc./Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office:+1.202.533.2932 Mobile:+1.202.352.6367 /neustar.biz<http://www.neustar.biz>
Dear Becky, According to 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
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
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
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
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
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
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
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. =================================================================
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
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.
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> 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
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
+1 to Milton Greg, thanks for the attempt to re-formulate, but I think the proposed definition is (1) not technology neutral and (2) doesn't really make much sense in terms of regulation. I have hard time to imagine what regulation of "mail servers" might mean in legal and regulatory terms. Best regards Tanya On 11/11/15 19:19, 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? 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/ <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
_______________________________________________ Accountability-Cross-Community mailing list 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?
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. Greg On Wed, Nov 11, 2015 at 1:49 PM, Nigel Roberts <nigel@channelisles.net> wrote:
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?
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
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
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/
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
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<mailto:kdrazek@verisign.com>> Date: Thursday, November 12, 2015 at 10:00 AM To: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>>, Malcolm Hutty <malcolm@linx.net<mailto:malcolm@linx.net>> Cc: 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 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> [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/<https://urldefense.proofpoint.com/v2/url?u=http-3A__publicaffairs.linx.net_&d=CwMGaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=bcrrKe1p2mL3nqn_satc0VMM8gpXLAK6Ei8JzkjRlrA&s=63ytAxfDe685jGPt_iXtqmkBmc4r3m098MBIjR2ToOY&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
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
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?
+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
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] 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. =================================================================
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. =================================================================
Bradley: 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? MM: No, not at all. If ICANN wants to regulate Privacy and Proxy services it will do so via RAA; i.e., by regulating registrars. That is the only way it _can_ and _should_ be able to affect those services. 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). MM: This way Greg falls into the trap of specifying a technological method rather than an actual service. All kinds of tricks can be played with that. That is not where you want to go, believe me. 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. MM: I don’t see how it does that. I think it’s a lot clearer. The statement is meant to be limiting rather than empowering. These are important distinctions, but I think a good step towards finding agreement on language that could satisfy broad interests. MM: Thanks,
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. =================================================================
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<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: 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<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 the 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 the 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 * - * the 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 * - * the 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
I have prepared a side by side comparing the 2nd Draft Report language with Greg’s suggested language. I hope this will make our discussion later on more productive. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / neustar.biz<http://www.neustar.biz> From: Greg Shatan <gregshatanipc@gmail.com<mailto:gregshatanipc@gmail.com>> Date: Thursday, November 12, 2015 at 1:05 PM To: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>> Cc: Keith Drazek <kdrazek@verisign.com<mailto:kdrazek@verisign.com>>, Malcolm Hutty <malcolm@linx.net<mailto:malcolm@linx.net>>, 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 * 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.
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
Andrew, I support the direction you're moving in. Greg On Thursday, November 12, 2015, Andrew Sullivan <ajs@anvilwalrusden.com> wrote:
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 <javascript:;> _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org <javascript:;> https://mm.icann.org/mailman/listinfo/accountability-cross-community
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
Andrew, without commenting on the specific wording issues, I strongly support the intent to put words in the Bylaws to accurately reflect ICANN's responsibilities related to Names as well as both the numbering community and the protocol community. I understand the possible difficulty of getting it right, but it is something that we do need to fix at this point. Alan At 12/11/2015 09:16 PM, Andrew Sullivan wrote:
Apologies, but is this where we left off on the wordsmithing? Is Milton correct that were 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, ICANNs Mission is to coordinate the development and implementation of policies:
For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability: That are developed through a bottom-up, consensus-based multi- stakeholder process and designed to ensure the stable and secure operation of the Internets unique names systems.
2. Coordinates the operation and evolution of the DNS root name server system. In this role, ICANNs 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. ICANNs 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 Internets 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 <https://mm.icann.org/mailman/listinfo/accountability-cross-community>ajs at anvilwalrusden.com
Thanks, Keith
From: <https://mm.icann.org/mailman/listinfo/accountability-cross-community>accountability-cross-community-bounces at icann.org [mailto:accountability-cross-community-bounces at 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 <<https://mm.icann.org/mailman/listinfo/accountability-cross-community>malcolm at linx.net<mailto:malcolm at 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/>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
<https://mm.icann.org/mailman/listinfo/accountability-cross-community>Accountability-Cross-Community at icann.org
https://mm.icann.org/mailman/listinfo/accountability-cross-community
-- Andrew Sullivan <https://mm.icann.org/mailman/listinfo/accountability-cross-community>ajs at 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
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"? Thanks! Greg On Wed, Nov 11, 2015 at 1:20 PM, Malcolm Hutty <malcolm@linx.net> wrote:
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
Hi, Insert my standard disclaimer here :) On Wed, Nov 11, 2015 at 02:10:17AM +0000, 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.²
I think there's an important part of that statement, and that is the voluntary assumption part. I think I agree with the above statement, but I want to say something slightly more. There are really two different cases we're talking about here. One of them is like the new gTLD case where a registry invents a bunch of special rules that it says it will use in deciding whether it will undertake delegation. It enshrines those commitments in its agreement with ICANN, and ICANN's delegation of the name from the root zone is predicated on those commitments. It seems to me there are three separable issues (for our purposes) here: 1. Should ICANN be able to enforce such contractual obligations under its mission? 2. Should ICANN make decisions about what to delegate on the basis of such commitments? 3. Should ICANN be able to use its power over the delegation from the root to force additional terms about how TLDs will operate on the TLD operators, beyond the narrow security and stability rules that are already in place (or substantially similar ones emerging from new technical developments)? I am convinced, unambiguously, that the answer to (1) must be, "Yes." ICANN is a party to an agreement, and if the other party does not hold up its end of the bargain ICANN needs to be able to take the enforcement actions appropriate. I think that this ability is entirely consistent with the short formulation you (Becky) proposed a little while ago, but of course I am lamentably not a lawyer. I am convinced, unambiguously, that the answer to (3) must be, "No." I think just about everyone in this discussion who agrees with the "narrow mandate" approach would be worried about this case. I think that this prohibition would be made by the short formulation you (Becky) proposed, but I'm not a lawyer in this paragraph either. The answer to (2) is perhaps what we are having trouble with. Some people think that ICANN shouldn't be in the business of supporting, creating, or enforcing different registration and delegation rules in different registries. But clearly it has done so in the last gTLD round. It seems to me that this case is, however, in part mitigated by competition. That is, yes, ICANN is implicitly taking on a role of upper-level enforcer of registry policies when it grants delegations on the basis of those policies. I confess that, were I ICANN, I would avoid those kinds of entanglements like the plague; but we've already unleashed this fact onto the world by delegating all those new TLDs with all those new covenants. Having made such a fact, it's hard for me to see how we could unmake it. Moreover, with well over a thousand TLDs to choose from, there's an easy solution for registrants who do not want the meddling: don't register a name in those domains. I think that this issue is one that is genuinely open to disagreement under the mission. I think that's ok: the mission cannot possibly be a way for the community to foreordain all future choices by ICANN, or we wouldnt need an ICANN. It could be replaced by a small shell script. This sort of disagreement would have to be worked out in the ICANN tussle.
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."
If "regulate" means the kind of imposition in (3) above, then I agree with this. ("Services" are "that which an operator makes available at a named location", which is hardly more enlightening.) If "regulate" means the enforcement under (2) or the ability of ICANN to undertake agreements with particular registries under (2), then I suppose I feel some inner conflict about it. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
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
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://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 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
My responses to Becky’s 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.” DISAGREE. Not if enforcing those commitments takes ICANN out of its own mission. 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." AGREE. By “regulate” I mean impose legally binding commitments and conditions on the service not related to the domain registration itself, but moving beyond the registration to include the content, activities or prices of the services that happening to be using the domain. Services means online offerings, either commercial or noncommercial, through which one party provides something that another party wants. In response to Steve Metalitz’s comment here: 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. I would say that the existence of public comment on proposed policies is good, but there is nothing (except the mission statement and IRP) that prevents ICANN from ignoring them. In effect, Steve is saying that ICANN should have no limitations on its mission because the public can comment on such deviations. This just doesn’t work. There will be pressure on ICANN to stray from its mission and the limits imposed on it, just as any national government ends up with laws that are unconstitutional. The fact that one group or coalition of groups succeeds in getting something imposed on us via a contract does not necessarily mean it should stand. We have to have a clear and firm mission limitation.
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 Internets 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 *******************************
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? Sent from my iPad 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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.washingtonpost.com_people_david-2Dpost&d=CwMFAw&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=3QgUKRsdiv9T2POWG7982JhMEHI4n8Ke7FAPxyxs3uY&s=TCgrCtgGjcefLZQuJk6fUVbhVRP1_mmePs_tNvxyyIA&e=>book (Jefferson's Moose) http://tinyurl.com/c327w2n <https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_c327w2n-25A0...> music http://tinyurl.com/davidpostmusic <https://urldefense.proofpoint.com/v2/url?u=http-3A__tinyurl.com_davidpostmus...> publications etc. http://www.davidpost.com <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.davidpost.com-25C2-2...> *******************************
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 Internets 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 *******************************
+1 Well said. thanks. On 11-Nov-15 15:16, David Post wrote:
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 <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 <http://tinyurl.com/davidpostmusic> publications etc. http://www.davidpost.com <http://www.davidpost.com%A0%A0%A0%A0%A0%A0%A0/> *******************************
******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post <http://www.washingtonpost.com/people/david-post>book (Jefferson's Moose) http://tinyurl.com/c327w2n <http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0> music http://tinyurl.com/davidpostmusic <http://tinyurl.com/davidpostmusic> publications etc. http://www.davidpost.com <http://www.davidpost.com%A0%A0%A0%A0%A0%A0%A0%A0/> *******************************
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
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 Internets 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 /> *******************************
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] 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 <<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 Internets 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>http://www.washingtonpost.com/people/david-post
book (Jefferson's Moose) <http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0>http://tinyurl.com/c327w2n music <http://tinyurl.com/davidpostmusic>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>http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) <http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0>http://tinyurl.com/c327w2n music <http://tinyurl.com/davidpostmusic>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 music http://tinyurl.com/davidpostmusic publications etc. 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 weve 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 cant 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 Internets 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 /> *******************************
Thank you David for clarifying your position, which is that you do NOT support deleting both statements and DO want to keep a clear affirmative restriction in place. You have proposed to modify the wording of the restriction in the following manner: "Without limiting the foregoing absolute prohibition, ICANN shall not regulate the content carried or provided by services that use the Internet's unique identifiers." Doesn't that do the job? MM: Possibly. It depends on whether regulating content also means regulating the type or nature of the service provided. If content was interpreted broadly I could accept this formulation
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 /> *******************************
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.² [...]
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
I find no such exclusion. If I voluntarily buy an air ticket and board the flight, I am then obliged to follow certain rules and the airlline may choose to enforce those rules. Alan At 11/11/2015 11:34 AM, Dr Eberhard W Lisse wrote:
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.² [...]
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
Finally, responding to Becky's questions: 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 agree with this statement, but I disagree with any implication that these are the only obligations that ICANN can enforce. In any contract between two parties (including the RA and the RAA), each party is bound to comply with each and every obligation in the contract pertinent to that party; if a party fails to comply, the other party can and should take steps to ensure that the party complies; if the non-compliance rises to the level of breach, the non-breaching party has every right to enforce the provisions of the agreement that come into play at that time. So, to make a long story short, ICANN -- like every other party to every other contract -- should have the right to "enforce" every obligation of its counter-parties. And those counter-parties have the right to do the same to ICANN. Any bylaw that implies that ICANN's contracts are contracts of adhesion (in whole or in part) and thus do not need to be complied with (in whole or in part) due to that bylaw or are nullified (in whole or in part) by that bylaw is a very unique and dangerous idea that really has no place in a bylaw. And I would say that under any circumstances. "Contracts of adhesion" are a narrow concept with very specific criteria that may allow a party to get out from under the agreement. There's a body of law around this concept, including the type and level of proof needed. Using a bylaw to rewrite this law just for ICANN is very troublesome. 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." With the right definition of "regulate" and "services" I could agree with this statement. First, I would define regulation as the unilateral imposition of rules (typically, rules of conduct) by a regulatory body. As such, entering into, complying with and enforcing contracts is mutually exclusive from "regulation." This includes the RA, the RAA and any end-user or registrant agreements that include provisions specified in ICANN's agreements. That does not mean that ICANN can do anything it wants in its agreements, only that what occurs in those agreements is not "regulation" (or any synonym for regulation). I would also emphasize that any consensus policy, as defined in the Consensus Policy Specification, should not be considered "regulation" either. As for "services" my concern is a more neutral one of clarity; "services" can have a number of meanings. Whatever we draft will need to be interpreted by our counsel (who are not telecom lawyers) and by the larger community, including non-native English speakers, so our meaning needs to be clear. If "services" is limited to the "Internet services" that use the DNS offered by an "Internet Service Provider," then I am likely okay; however, we need a concrete list, even if it is exemplary rather than exhaustive, so that the meaning is beyond doubt. If we mean every entity that provides any kind of service and does so through or using the Internet and a domain name or IP address in some fashion, that's likely a problem -- this is simply too broad and off-topic for us to deal with. If there's any intent or effect that this language will be used to waive, nullify or make unenforceable any provision of any current ICANN contract, that should be made clear now. As a matter of fact, I would suggest that we should have a statement to the effect that "This Bylaw may not be used to challenge, nullify or make unenforceable any provision in any contract with ICANN in effect as of the adoption of this Bylaw." That would solve a lot of problems and make it clear that this Bylaw is not just a short-term ploy to attempt to reshape ICANN's current contracts. Greg I would be very interested in responses to these specific an limited questions. On Wed, Nov 11, 2015 at 12:52 AM, Dr Eberhard W Lisse <el@lisse.na> wrote:
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
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
On 11/11/2015 06:26, Greg Shatan wrote:
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.
Greg, You can lawyer this as much as you like, but at the end of the day we are trying to produce a report that has broad consensus in the community. To present a Final Draft Report that does the opposite of the overwhelming majority of public feedback received would be offensive to the very concept of bottom-up multistakeholderism, however you try to slice and dice it.
The second fundamental flaw is the presumption that enforcing " voluntarily assumed 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.
Nobody has said that such obligations will necessarily constitute such regulation. This is a straw man of your own creation. The point is that such obligations *could* include provisions that would amount to such regulation. Accordingly, if we immunise those contracts from all possibility of review, as you propose, it will not be possible to prevent ICANN from engaging in such regulation. This is an entirely realistic fear. If ICANN did attempt such regulation, it would pretty much have to use this mechanism; as Andrew has pointed out, the only other lever is the threat to remove the delegation, which isn't realistic. If there is to be any restriction on the scope of ICANN's ability to regulate content whatsoever, we cannot have these contracts deemed to be acceptable by definition. These contracts are necessary and, in most respects, entirely proper. But they cannot be put beyond challenge. All aspects of ICANN's activities must be held accountable to standards set out in the Mission, not merely "all aspects except the contracts it signs". Support for this position in the public comment record is clear and overwhelming. Malcolm * An agreement for ICANN to start regulating this content might be entered into with a registry's entirely willing collusion, or it might be effectively imposed, as in "if you want the gTLD you've applied to run, you'd better sign up to these "voluntarily" obligations. Either way circumvents the limits on ICANN's Mission, to the potential detriment of registrants. So whether these obligations are truly "voluntary" *for the registry* is completely immaterial; if they impose mandatory controls on the registrant beyond the legitimate extent of ICANN's Mission, then ICANN should have no part of them and should not sign such a contract. -- 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
Responding first to Becky's original email..... Comments inline. Greg On Tue, Nov 10, 2015 at 5:58 PM, Burr, Becky <Becky.Burr@neustar.biz> wrote:
Please read all the way through to the bottom for a question and proposal.
Based on our discussion this morning, I believe that the following statements reflect the consensus of the CCWG (lack of “full consensus” on 1 point noted in text):
GS: I think it's premature (at best) to call consensus (much less full consensus) on a number of these topics. We begin well but go downhill after that
· ICANN’s Mission with respect to names is described in the Mission Statement as follows: With respect to NAMES, ICANN’s Mission is to coordinate 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: (I)For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and (ii) 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.
I can agree with that.
· ICANN’s Mission is limited and enumerated.
I can agree with that.
· ICANN’s should act in accordance with, and only as reasonably appropriate to achieve its Mission.
I can agree with that.
· 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.
I can agree with that.
· ICANN should have the authority to enforce agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANN’s Mission on such parties.
I can agree up to the comma. After that, it gets less clear. If the "established means of community input" are public comments on form contracts during their development, I can agree with that. Indeed, I think there should be more "community input" when contracts are being developed. If it refers to some form of community input after the agreements have been signed, I'm less sure about that (especially as something to be baked into a Bylaw). I would note that both Malcolm and I crossed out the language after the first comma in the chart you circulated, so it's hard to say there's consensus on that part of the sentence.
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*.
The lack of "full consensus" (and almost certainly lack of consensus) probably goes in two different directions, those who think this goes too far, and those that think this isn't going far enough. If these obligations are in contracts, registry operators are obligated to comply with them. As with each and every obligation in ICANN's agreements, the parties (both ICANN and the contracted party) must comply with their obligations, they are in breach if they don't do so, and the non-breaching party should take the necessary steps to get the other party to comply.
o In general, consistent with ordinary contract concepts, registries and registrars should be presumed to have agreed to the terms and conditions of any contract with ICANN.
I think that phrasing this merely as a presumption is too weak. Contracts are obligations of the contracting parties, not merely presumed obligations. Creating a special version of contract law just for ICANN is dangerous, and I can't agree with that. So no agreement here, though getting rid of the "wiggle words" would change that. We could say that ICANN can only enforce those parts of its contracts that the counter-parties say are enforceable, but that would be utterly bizarre.
*That said*, there should be some mechanism whereby contracted parties can enter into such agreements without waiving their rights to challenge specified provisions of such an agreement on the grounds that they exceed the scope of ICANN’s Mission. Any such mechanism would have to provide adequate notice, needs to be developed, etc.
It's quite interesting to see the CCWG being used as a factory in which to construct a machine to challenge provisions of registry and registrar agreements that some may not like. First, we have bylaws changes to the Mission primarily phrased as prohibitions rather than positive missions statements, designed to form a basis for a challenge; then we have a statement supporting an affirmative right for contracted parties (and for some, any "aggrieved party") to challenge their contracts, after that we have the foundation for a mechanism where this right can be exercised. All under the banner of enhancing ICANN's accountability. I'm becoming less convinced that this is about accountability, and more concerned that this is just a tool in a campaign to renegotiate ICANN's contract, with a playing prepared for the needs of one set of parties. All being done at a level of abstraction where the real controversies are not quite apparent, or at least are not typically discussed.
*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.*
It all depends on what one thinks "regulation" is and (to a lesser extent) what the "services" are, and whether this prohibition is limited in any way. Contracting? Consensus Policy?
*Question: Does the following formulation t*hread the needle between those who say that ICANN should not use its contracting authority to regulate registrant behavior and those who point out that the Registrar Accreditation Agreement, for example, requires registrants to provide accurate and up-to-date WHOIS data: *I**CANN should not use its authority to enter into contracts with registries and registrars to impose obligations and limitations on registrants with respect to issues that are not properly the subject of Consensus Policy.*
This seems even narrower than prior propositions where the limitation was ICANN's Mission. It should be clear that Consensus Policy is within ICANN's Mission, but ICANN's Mission goes beyond Consensus Policy. And in terms of abstraction, "issues that are not properly the subject of Consensus Policy" is pretty darn abstract. It's not something that is clear on its face, to say the least. It would be instructive to pull out the RA and RAA and see which provisions if any would effectively be nullified by this Bylaw. Depending on what we do here, we may need to change the statement in the Executive Summary that the CCWG is not proposing any changes in the way ICANN conducts day-to-day operations. I would say that using Bylaws to rewrite ICANN's contracts is a significant change in how ICANN does business, and not a particularly good use of Bylaws or the CCWG. Frankly, the efforts here to resolve (or tilt the playing field to resolve) a particular controversy are probably misplaced in the CCWG and particularly in the Bylaws. But that seems to be where we are and what we (or at least, some of us) are trying to do....
*PROPOSAL*: If so, I propose that the CCWG provide the text above as guidance for the final bylaws drafters in interpreting the admonition that "ICANN shall act strictly in accordance with, and only as reasonably appropriate to achieve its Mission.” I believe this would (1) eliminate concerns and ambiguity regarding use of the word “regulation,”; (2) reflect consensus on the principles; and (3) address the late change/legislative history/statutory construction concern raised by Paul R. and others.
Unfortunately, I don't think it does any of the above, at least not at this point. I'm open to continued discussion, as my goal (as always) is to try and find solutions which nobody may think are perfect, but which everybody can find acceptable. However, I'm concerned this is a step backwards from consensus, not towards it. Greg
*J. Beckwith Burr* *Neustar, Inc.* / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 *Office:* +1.202.533.2932 *Mobile:* +1.202.352.6367 */* *neustar.biz* <http://www.neustar.biz>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hello, Here is the current ICANN mission. *Section 1. MISSION* The mission of The Internet Corporation for Assigned Names and Numbers ("ICANN") is to coordinate, at the overall level, the global Internet's systems of unique identifiers, and in particular to ensure the stable and secure operation of the Internet's unique identifier systems. In particular, ICANN: 1. Coordinates the allocation and assignment of the three sets of unique identifiers for the Internet, which are a. Domain names (forming a system referred to as "DNS"); b. Internet protocol ("IP") addresses and autonomous system ("AS") numbers; and c. Protocol port and parameter numbers. 2. Coordinates the operation and evolution of the DNS root name server system. 3. Coordinates policy development reasonably and appropriately related to these technical functions. Could you kindly provide what the full newly proposed mission statement look like. As it's looking like we are about developing a full page mission statement. Regards Sent from my Asus Zenfone2 Kindly excuse brevity and typos. On 10 Nov 2015 23:58, "Burr, Becky" <Becky.Burr@neustar.biz> wrote:
Please read all the way through to the bottom for a question and proposal.
Based on our discussion this morning, I believe that the following statements reflect the consensus of the CCWG (lack of “full consensus” on 1 point noted in text):
· ICANN’s Mission with respect to names is described in the Mission Statement as follows: With respect to NAMES, ICANN’s Mission is to coordinate 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: (I)For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and (ii) 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.
· ICANN’s Mission is limited and enumerated.
· ICANN’s should act in accordance with, and only as reasonably appropriate to achieve its Mission.
· 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.
· ICANN should have the authority to enforce agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANN’s Mission on such parties.
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*.
o In general, consistent with ordinary contract concepts, registries and registrars should be presumed to have agreed to the terms and conditions of any contract with ICANN.
*That said*, there should be some mechanism whereby contracted parties can enter into such agreements without waiving their rights to challenge specified provisions of such an agreement on the grounds that they exceed the scope of ICANN’s Mission. Any such mechanism would have to provide adequate notice, needs to be developed, etc.
*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.*
*Question: Does the following formulation t*hread the needle between those who say that ICANN should not use its contracting authority to regulate registrant behavior and those who point out that the Registrar Accreditation Agreement, for example, requires registrants to provide accurate and up-to-date WHOIS data: *I**CANN should not use its authority to enter into contracts with registries and registrars to impose obligations and limitations on registrants with respect to issues that are not properly the subject of Consensus Policy.*
*PROPOSAL*: If so, I propose that the CCWG provide the text above as guidance for the final bylaws drafters in interpreting the admonition that "ICANN shall act strictly in accordance with, and only as reasonably appropriate to achieve its Mission.” I believe this would (1) eliminate concerns and ambiguity regarding use of the word “regulation,”; (2) reflect consensus on the principles; and (3) address the late change/legislative history/statutory construction concern raised by Paul R. and others.
*J. Beckwith Burr* *Neustar, Inc.* / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 *Office:* +1.202.533.2932 *Mobile:* +1.202.352.6367 */* *neustar.biz* <http://www.neustar.biz>
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
I generally accept this, but see embedded comments. At 10/11/2015 05:58 PM, Burr, Becky wrote:
Please read all the way through to the bottom for a question and proposal.
Based on our discussion this morning, I believe that the following statements reflect the consensus of the CCWG (lack of full consensus on 1 point noted in text):
· ICANNs Mission with respect to names is described in the Mission Statement as follows: With respect to NAMES, ICANNs Mission is to coordinate the allocation and assignment of names in the root zone of the Domain Name System ("DNS"). In this role, ICANNs Mission is to coordinate the development and implementation of policies: (I)For which uniform or coordinated resolution is reasonably necessary to facilitate the openness, interoperability, resilience, security and/or stability of the DNS; and (ii) That are developed through a bottom-up, consensus-based multi- stakeholder process and designed to ensure the stable and secure operation of the Internets unique names systems.
· ICANNs Mission is limited and enumerated.
· ICANNs should act in accordance with, and only as reasonably appropriate to achieve its Mission.
· 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 ICANNs Mission.
· ICANN should have the authority to enforce agreements with contracted parties, subject to established means of community input on those agreements and reasonable checks and balances on its ability to impose obligations exceeding ICANNs Mission on such parties.
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.
o In general, consistent with ordinary contract concepts, registries and registrars should be presumed to have agreed to the terms and conditions of any contract with ICANN.
That said, there should be some mechanism whereby contracted parties can enter into such agreements without waiving their rights to challenge specified provisions of such an agreement on the grounds that they exceed the scope of ICANNs Mission. Any such mechanism would have to provide adequate notice, needs to be developed, etc.
I support this, but given that we are adding that policy should be developed through a bottom up process, contracted parties should NOT be able to dispute parts of contracts that are not developed through a bottom-up process if those parts are not eligible for (as per Spec 1/4) for bottom-up Consensus Policy.
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.
If it comforts anyone, I am happy to add a restriction that such content-related enforcement must not rely on ICANN to make judgement calls on such content and must rely on external authoritative agencies or mechanisms to make such judgements.
Question: Does the following formulation thread the needle between those who say that ICANN should not use its contracting authority to regulate registrant behavior and those who point out that the Registrar Accreditation Agreement, for example, requires registrants to provide accurate and up-to-date WHOIS data: ICANN should not use its authority to enter into contracts with registries and registrars to impose obligations and limitations on registrants with respect to issues that are not properly the subject of Consensus Policy.
PROPOSAL: If so, I propose that the CCWG provide the text above as guidance for the final bylaws drafters in interpreting the admonition that "ICANN shall act strictly in accordance with, and only as reasonably appropriate to achieve its Mission. I believe this would (1) eliminate concerns and ambiguity regarding use of the word regulation,; (2) reflect consensus on the principles; and (3) address the late change/legislative history/statutory construction concern raised by Paul R. and others.
J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington D.C. 20006 Office: +1.202.533.2932 Mobile: +1.202.352.6367 / <http://www.neustar.biz>neustar.biz _______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
participants (22)
-
Alan Greenberg -
Andrew Sullivan -
Avri Doria -
Burr, Becky -
David Post -
Dr Eberhard W Lisse -
Dr. Tatiana Tropina -
Drazek, Keith -
Edward Morris -
Greg Shatan -
James M. Bladel -
Jonathan Zuck -
Malcolm Hutty -
Metalitz, Steven -
Mueller, Milton L -
Nigel Roberts -
Paul Rosenzweig -
Robin Gross -
Schaefer, Brett -
Seun Ojedeji -
Silver, Bradley -
Steve DelBianco