Re: [CCWG-ACCT] Board comments on the Mission statement
Bruce One question: The Board suggests that if language i adopted that says "ICANN shall not impose regulations on services (i.e., any software process that accepts connections for the Internet) that use the Internet's unique identifiers, or the content that such services carry or provide ..." there might be some existing registry agreements that would be "out of compliance with ICANN's responsibilities." I'd be curious to know what the Board is concerned with there - what parts of which registry agreements might be affected (and made non-compliant) by this language? With respect to that same "regulations on services" language, the Board says that it is "unclear," and asks for "some examples of what the CCWG believes that ICANN should and should not be able to do." I agree that the "services" language isn't clear at the moment. Here's my attempt to capture the point that I think is being made: ICANN should not be allowed to impose -- directly or indirectly, via its contracts -- obligations on persons or entities whose only connection to the DNS is that they use a domain name for Internet communication. I think it's pretty straightforward. I use a domain name (davidpost.com) for Internet communication. The idea -- and I think pretty much everyone agrees with this? - is that ICANN can't impose any obligations on me that affect how I operate the site, what content I host or don't host, what goods or services I can or cannot offer, what billing system I use for those goods and services, what anti-virus software I install, ... It can't do that directly (by imposing some contract terms on me itself) or indirectly (by getting 3d parties like the registries or registrars to impose the obligations on me). Registries and registrars, of course, are not entities "whose only connection to the DNS is that they use a domain name for Internet communication," so this clause shouldn't affect ICANN's ability to impose obligations on them (which remains limited by other portions of the Mission Statement). David David At 02:12 AM 11/19/2015, Bruce Tonkin wrote:
Hello All,
The Board has been considering the CCWG Update on Progress Made In and After ICANN54 in Dublin published on 15 Nov 2015.
The Board information call today considered the changes to the mission statement identified in that update.
Attached is the Board's preliminary comments on the mission statement part of the Dublin update report. As we review the remainder of that Update, we'll send through additional comments.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com *******************************
Bruce, I've just posted an email to this thread that clarifies what is meant by "services" in the following clause: ICANN shall not impose regulations on services (i.e., any software process that accepts connections for the Internet) that use the Internet's unique identifiers, or the content that such services carry or provide. ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its mission. The point is that the focus is on *services* such as "web services" running on a web server, or "mail services" running on a mail server. The focus is not on *service providers*, whether registries, registrars, internet service providers, nail salons or auto mechanics. The parenthetical language clarifies that and tries to be as technology-agnostic as possible (I note that it is consistent with the definition of web services in my other email, which was drafted in 2004), but improvements are always welcome. The examples provided in my other email may provide some inspiration for such improvements. As such, the novel "revised" "services clause" provided by David Post is going off in an entirely different direction, and is really of no help in explaining to the Board (or anyone else) what the above clause means. Indeed, it no longer deals just with "services" by any definition -- it refers to "persons or entities," which goes even beyond a misdirected definition of "services." Also, the concept of "obligations" goes far beyond the concept of "regulations" in terms of stating the limitations on ICANN. Finally,the idea that this focuses on "persons or entities whose only connection to the DNS is that they use a domain name for Internet communication" is nowhere found in the clause above or in any of the discussions I've seen or participated in regarding this provision. So, rather than being a "revision" of the current services clause, this alternative is a completely new construction. The "idea" that David postulates and then rapidly assumes that "pretty much everyone agrees with" also goes far beyond and in different directions from the above clause, which reflects hours of careful discussion and compromise among a number of participants from different stakeholder groups. I am confident that the statement that "pretty much everyone agrees with" David's idea is false. I, for one, certainly don't agree with it as a statement that bears any relationship to the above clause. As such, I think it has no value in the work of this group other than to yank it off course, which I think would be highly counterproductive at this point in the proceedings. As to the Board's concerns: - "Some existing registry agreements may be out of compliance with ICANN's responsibilities if this change is adopted": I, for one, had that concern about the language that appears in the November 15 formal update. I believe that the current language actually resolves, rather than causes this problem. If the Board disagrees, I think a far more specific discussion is needed -- one that clearly identifies the language (or change/deletion of language) that causes the Board's concern, and which provisions in which existing registry agreements might be out of compliance. Dealing in abstract concerns is not particularly helpful. As far as I know, it was not the intention of any of the drafters to nullify or expose to challenge any provisions of any registry or registrar agreements. Of course, this should be clarified, and if the Board has identified a "land mine" in the language that has been planted in anticipation of a later attempt to challenge provisions of existing agreements, that land mind should be extracted and de-fused. - The use of the word regulate (which occurs on both the November 15 and November 17 language, so I assume the Board's concern covers both versions): I have some sympathy for this, although there are instances of "regulation" for rules imposed by a private entity to carry out policy rather than rules imposed by a government to carry out laws. So far, though, finding a word that does not substantially change the intended meaning has been a challenge (such as when "obligation" was substituted for "regulation" as discussed above). I'm at a loss though to understand what risk this use would cause to ICANN. - The definition of services: This is discussed above and and in my prior email, so I won't reiterate here. While it could be improved. but it clearly points in the right direction and away from the wrong one -- and that is critical. Greg On Thu, Nov 19, 2015 at 4:39 PM, David Post <david.g.post@gmail.com> wrote:
Bruce
One question: The Board suggests that if language i adopted that says “ICANN shall not impose regulations on services (i.e., any software process that accepts connections for the Internet) that use the Internet's unique identifiers, or the content that such services carry or provide ..." there might be some existing registry agreements that would be "out of compliance with ICANN's responsibilities." I'd be curious to know what the Board is concerned with there - what parts of which registry agreements might be affected (and made non-compliant) by this language?
With respect to that same "regulations on services" language, the Board says that it is "unclear," and asks for "some examples of what the CCWG believes that ICANN should and should not be able to do."
I agree that the "services" language isn't clear at the moment. Here's my attempt to capture the point that I think is being made: ICANN should not be allowed to impose -- directly *or indirectly*, via its contracts -- obligations on persons or entities whose only connection to the DNS is that they use a domain name for Internet communication.
I think it's pretty straightforward. I use a domain name (davidpost.com) for Internet communication. The idea -- and I think pretty much everyone agrees with this? - is that ICANN can't impose any obligations on me that affect how I operate the site, what content I host or don't host, what goods or services I can or cannot offer, what billing system I use for those goods and services, what anti-virus software I install, ... It can't do that directly (by imposing some contract terms on me itself) or indirectly (by getting 3d parties like the registries or registrars to impose the obligations on me).
Registries and registrars, of course, are not entities "whose only connection to the DNS is that they use a domain name for Internet communication," so this clause shouldn't affect ICANN's ability to impose obligations on them (which remains limited by other portions of the Mission Statement).
David
David
At 02:12 AM 11/19/2015, Bruce Tonkin wrote:
Hello All,
The Board has been considering the CCWG Update on Progress Made In and After ICANN54 in Dublin published on 15 Nov 2015.
The Board information call today considered the changes to the mission statement identified in that update.
Attached is the Board's preliminary comments on the mission statement part of the Dublin update report. As we review the remainder of that Update, we'll send through additional comments.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n <http://tinyurl.com/c327w2n%A0%A0%A0%A0%A0%A0> music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com
*******************************
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Sent from my Asus Zenfone2 Kindly excuse brevity and typos. On 20 Nov 2015 19:07, "Greg Shatan" <gregshatanipc@gmail.com> wrote:
The point is that the focus is on services such as "web services" running
on a web server, or "mail services" running on a mail server. The focus is not on service providers, whether registries, registrars, internet service providers, nail salons or auto mechanics.
SO: FWIW (even though I have hinted this before) service providers are actually referred to as such because they provide services and those services could include web services, mail services et all. So when you say focus is not on service providers but on the providers you may want to recheck that. Overall, I hope we will soon realise that trying to define services in restrictive context is a tall order and could have unintended implications if such description gets included in a mission statement. Regards The parenthetical language clarifies that and tries to be as technology-agnostic as possible (I note that it is consistent with the definition of web services in my other email, which was drafted in 2004), but improvements are always welcome. The examples provided in my other email may provide some inspiration for such improvements.
As such, the novel "revised" "services clause" provided by David Post is
going off in an entirely different direction, and is really of no help in explaining to the Board (or anyone else) what the above clause means. Indeed, it no longer deals just with "services" by any definition -- it refers to "persons or entities," which goes even beyond a misdirected definition of "services." Also, the concept of "obligations" goes far beyond the concept of "regulations" in terms of stating the limitations on ICANN. Finally,the idea that this focuses on "persons or entities whose only connection to the DNS is that they use a domain name for Internet communication" is nowhere found in the clause above or in any of the discussions I've seen or participated in regarding this provision. So, rather than being a "revision" of the current services clause, this alternative is a completely new construction.
The "idea" that David postulates and then rapidly assumes that "pretty
much everyone agrees with" also goes far beyond and in different directions from the above clause, which reflects hours of careful discussion and compromise among a number of participants from different stakeholder groups. I am confident that the statement that "pretty much everyone agrees with" David's idea is false. I, for one, certainly don't agree with it as a statement that bears any relationship to the above clause. As such, I think it has no value in the work of this group other than to yank it off course, which I think would be highly counterproductive at this point in the proceedings.
As to the Board's concerns: "Some existing registry agreements may be out of compliance with ICANN's
responsibilities if this change is adopted": I, for one, had that concern about the language that appears in the November 15 formal update. I believe that the current language actually resolves, rather than causes this problem. If the Board disagrees, I think a far more specific discussion is needed -- one that clearly identifies the language (or change/deletion of language) that causes the Board's concern, and which provisions in which existing registry agreements might be out of compliance. Dealing in abstract concerns is not particularly helpful. As far as I know, it was not the intention of any of the drafters to nullify or expose to challenge any provisions of any registry or registrar agreements. Of course, this should be clarified, and if the Board has identified a "land mine" in the language that has been planted in anticipation of a later attempt to challenge provisions of existing agreements, that land mind should be extracted and de-fused.
The use of the word regulate (which occurs on both the November 15 and November 17 language, so I assume the Board's concern covers both versions): I have some sympathy for this, although there are instances of "regulation" for rules imposed by a private entity to carry out policy rather than rules imposed by a government to carry out laws. So far, though, finding a word that does not substantially change the intended meaning has been a challenge (such as when "obligation" was substituted for "regulation" as discussed above). I'm at a loss though to understand what risk this use would cause to ICANN. The definition of services: This is discussed above and and in my prior email, so I won't reiterate here. While it could be improved. but it clearly points in the right direction and away from the wrong one -- and that is critical.
Greg
On Thu, Nov 19, 2015 at 4:39 PM, David Post <david.g.post@gmail.com> wrote:
Bruce
One question: The Board suggests that if language i adopted that says
“ICANN shall not impose regulations on services (i.e., any software process that accepts connections for the Internet) that use the Internet's unique identifiers, or the content that such services carry or provide ..." there might be some existing registry agreements that would be "out of compliance with ICANN's responsibilities." I'd be curious to know what the Board is concerned with there - what parts of which registry agreements might be affected (and made non-compliant) by this language?
With respect to that same "regulations on services" language, the Board
says that it is "unclear," and asks for "some examples of what the CCWG believes that ICANN should and should not be able to do."
I agree that the "services" language isn't clear at the moment. Here's
my attempt to capture the point that I think is being made: ICANN should not be allowed to impose -- directly or indirectly, via its contracts -- obligations on persons or entities whose only connection to the DNS is that they use a domain name for Internet communication.
I think it's pretty straightforward. I use a domain name (davidpost.com)
for Internet communication. The idea -- and I think pretty much everyone agrees with this? - is that ICANN can't impose any obligations on me that affect how I operate the site, what content I host or don't host, what goods or services I can or cannot offer, what billing system I use for those goods and services, what anti-virus software I install, ... It can't do that directly (by imposing some contract terms on me itself) or indirectly (by getting 3d parties like the registries or registrars to impose the obligations on me).
Registries and registrars, of course, are not entities "whose only
connection to the DNS is that they use a domain name for Internet communication," so this clause shouldn't affect ICANN's ability to impose obligations on them (which remains limited by other portions of the Mission Statement).
David
David
At 02:12 AM 11/19/2015, Bruce Tonkin wrote:
Hello All,
The Board has been considering the CCWG Update on Progress Made In and
After ICANN54 in Dublin published on 15 Nov 2015.
The Board information call today considered the changes to the mission
statement identified in that update.
Attached is the Board's preliminary comments on the mission statement
part of the Dublin update report. As we review the remainder of that Update, we'll send through additional comments.
Regards,
Bruce Tonkin
ICANN Board Liaison to the CCWG
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
******************************* David G Post - Senior Fellow, Open Technology Institute/New America Foundation blog (Volokh Conspiracy) http://www.washingtonpost.com/people/david-post book (Jefferson's Moose) http://tinyurl.com/c327w2n music http://tinyurl.com/davidpostmusic publications etc. http://www.davidpost.com *******************************
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Hello Greg,
ICANN shall not impose regulations on services (i.e., any software process that accepts connections for the Internet) that use the Internet's unique identifiers, or the content that such services carry or provide.
I think as Andrew Sullivan pointed out - I would consider most of the processes that registries and registries use to register domain names as services that use the Internet's unique identifiers. That is a very general statement.
• "Some existing registry agreements may be out of compliance with ICANN's responsibilities if this change is adopted": I, for one, had that concern about the language that appears in the November 15 formal update. I believe that the current language actually resolves, rather than causes this problem. If the Board disagrees, I think a far more specific discussion is needed -- one that clearly identifies the language (or change/deletion of language) that causes the Board's concern, and which provisions in which existing registry agreements might be out of compliance. Dealing in abstract concerns is not particularly helpful. As far as I know, it was not the intention of any of the drafters to nullify or expose to challenge any provisions of any registry or registrar agreements. Of course, this should be clarified, and if the Board has identified a "land mine" in the language that has been planted in anticipation of a later attempt to challenge provisions of existing agreements, that land mind should be extracted and de-fused.
I have asked the legal staff at ICANN to provide some examples. Here is one that occurs to me though. The current new gTLD registry agreements in Specification 5 (http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-...) have a provision that restrict the ability of a registrant to register a country or territory name, or names relating to the International Olympic Committee; International Red Cross and Red Crescent Movement. These are examples of content in domain names that have some restrictions. There are no technical or security reasons for such restrictions. The restrictions have been put in place on the basis of "public policy" advice from the GAC.
• The use of the word regulate (which occurs on both the November 15 and November 17 language, so I assume the Board's concern covers both versions).
Yes - this is mostly a concern from ICANN legal staff. My understanding is that "regulate" has a specific meaning in the US law context and applies to the role of governments. I think it is possible to find another term that aligns with our practices. Ie ICANN develops policies, and incorporates those policies in registry, registrar and registrant (through their agreements with registrars) agreements. ICANN has a compliance team to ensure that registries, registrars, and registrants comply with those policies. An alternative formulation of the text could therefore be: ICANN does not impose "contractual terms" ...
• The definition of services: This is discussed above and in my prior email, so I won't reiterate here. While it could be improved. but it clearly points in the right direction and away from the wrong one -- and that is critical.
The Board certainly agrees with the intent of the language. It just needs refinement. Probably the best the group can do is to clearly define the intent, and allow time for appropriate language to be developed. Part of clarifying the intent is to give clear examples of what ICANN should not be doing as part of its role. Regards, Bruce Tonkin
Bruce, On Fri, Nov 20, 2015 at 7:41 PM, Bruce Tonkin < Bruce.Tonkin@melbourneit.com.au> wrote:
Hello Greg,
ICANN shall not impose regulations on services (i.e., any software process that accepts connections for the Internet) that use the Internet's unique identifiers, or the content that such services carry or provide.
I think as Andrew Sullivan pointed out - I would consider most of the processes that registries and registries use to register domain names as services that use the Internet's unique identifiers. That is a very general statement.
GS: Bruce, if you are talking about the software processes that underlie the websites and email systems used by registries and registrars, I believe that's correct. But what do you believe is the impact of that? Do you think that what ICANN currently does or hopes to do would constitute "imposing regulations on" these software processes?
• "Some existing registry agreements may be out of compliance with ICANN's responsibilities if this change is adopted": I, for one, had that concern about the language that appears in the November 15 formal update. I believe that the current language actually resolves, rather than causes this problem. If the Board disagrees, I think a far more specific discussion is needed -- one that clearly identifies the language (or change/deletion of language) that causes the Board's concern, and which provisions in which existing registry agreements might be out of compliance. Dealing in abstract concerns is not particularly helpful. As far as I know, it was not the intention of any of the drafters to nullify or expose to challenge any provisions of any registry or registrar agreements. Of course, this should be clarified, and if the Board has identified a "land mine" in the language that has been planted in anticipation of a later attempt to challenge provisions of existing agreements, that land mind should be extracted and de-fused.
I have asked the legal staff at ICANN to provide some examples.
Here is one that occurs to me though. The current new gTLD registry agreements in Specification 5 ( http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-...) have a provision that restrict the ability of a registrant to register a country or territory name, or names relating to the International Olympic Committee; International Red Cross and Red Crescent Movement.
These are examples of content in domain names that have some restrictions. There are no technical or security reasons for such restrictions. The restrictions have been put in place on the basis of "public policy" advice from the GAC.
GS: Bruce, I think you have (re)surfaced a couple of potentially
significant interpretive errors in looking at these provisions. *First, domain names are not "content."* If we start treating domain names as content, that opens up a whole Pandora's Box. But even if we avoid that larger issue, I think it is clear from the provision that domain names are not "content" for the purposes of this provision. Domain names are clearly among the "Internet's unique identifiers" in this provision, so they can't also be the "content" that is "carried" or "provided" by the "service." I think that if we could expressly associate "content" with "datagram(s)" this would be clearer. Alan Greenberg has raised this "domain names are not content" (or perhaps more restrictively, "domain names are not "content"" here) issue more than once, with unclear results. This needs to be clarified, at least in connection with this provision
• The use of the word regulate (which occurs on both the November 15 and November 17 language, so I assume the Board's concern covers both versions).
Yes - this is mostly a concern from ICANN legal staff. My understanding is that "regulate" has a specific meaning in the US law context and applies to the role of governments. I think it is possible to find another term that aligns with our practices. Ie ICANN develops policies, and incorporates those policies in registry, registrar and registrant (through their agreements with registrars) agreements. ICANN has a compliance team to ensure that registries, registrars, and registrants comply with those policies. An alternative formulation of the text could therefore be: ICANN does not impose "contractual terms" ...
GS: Bruce, this is the second potentially significant interpretive error
you surface. While "regulation" is most often used to describe governmental/public entity action, it is not limited to that sphere. But if we look at U.S. government regulation as a guide, regulations are rules and standards that are unilaterally imposed by the government in order to implement laws (e.g., the Americans with Disabilities Act is a law, but there are government-issued regulations that specify what must be done to comply with that law). That should be the definition that is carried over into this provision. I think it would be wrong and dangerous to consider the policies developed by ICANN through the various policy development processes as a form of "regulation." Similarly, it would be wrong and dangerous to consider the registry and registrar agreements to be forms of regulation, especially given how they are developed. Contractual terms are by definition not "imposed." They are agreed to (unless you are talking about "contracts of adhesion," which is a very narrow category of forced contract). *Thus, I would very strongly reject the idea that "ICANN does not impose contractual terms" is in any way an alternative statement of "ICANN does not impose regulations." * If we go down that road, then virtually everything ICANN does is regulation, and that is clearly not the intent of this text. That said, if there is any danger that one will be interpreted as synonymous with the other, that needs to be clearly and explicitly stopped. If some as well-informed as yourself can stumble into that mistake, then I think this is a clear and present danger, and one that must be resolved before this provision is finalized.
• The definition of services: This is discussed above and in my prior email, so I won't reiterate here. While it could be improved. but it clearly points in the right direction and away from the wrong one -- and that is critical.
The Board certainly agrees with the intent of the language. It just needs refinement. Probably the best the group can do is to clearly define the intent, and allow time for appropriate language to be developed.
Part of clarifying the intent is to give clear examples of what ICANN should not be doing as part of its role.
Regards, Bruce Tonkin
Greg
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On Sun, Nov 22, 2015 at 02:43:50AM -0500, Greg Shatan wrote:
GS: Bruce, if you are talking about the software processes that underlie the websites and email systems used by registries and registrars, I believe that's correct. But what do you believe is the impact of that? Do you think that what ICANN currently does or hopes to do would constitute "imposing regulations on" these software processes?
As I think I've already argued, ICANN does in fact impose regulations on some of those processes. ICANN imposes regulations on content of contracted registrars for some registries, and all contracted registries, for certain services offered over http(s) and also over whois ("port 43 whois" is the way ICANN policy people seem to express this). It's a direct specification of content: what must and must not be on the relevant web pages or available over the service. I think Becky has pointed out that we could get out of this by using the "service" definition we have and relying on the "ICANN can undertake contracts" sentence to permit this regulation. I wonder whether that approach solves our problem, however, since if ICANN can regulate content on some web pages in the service of the DNS, why can't it regulate others? Plainly, the line we want is the one distinguishing "things relevant to domain name registrations in contracted domains" and "everything else", but I still don't know how to write that down. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com
And as I think I've already argued, I think it is fundamental to accountability in a post-NTIA environment that we know exactly under what legal authority such regulation takes place. After all the millions on legal fees, is it the case that we still don't know? On 11/22/2015 03:41 PM, Andrew Sullivan wrote:
On Sun, Nov 22, 2015 at 02:43:50AM -0500, Greg Shatan wrote:
GS: Bruce, if you are talking about the software processes that underlie the websites and email systems used by registries and registrars, I believe that's correct. But what do you believe is the impact of that? Do you think that what ICANN currently does or hopes to do would constitute "imposing regulations on" these software processes?
As I think I've already argued, ICANN does in fact impose regulations on some of those processes. ICANN imposes regulations on content of contracted registrars for some registries, and all contracted registries, for certain services offered over http(s) and also over whois ("port 43 whois" is the way ICANN policy people seem to express this). It's a direct specification of content: what must and must not be on the relevant web pages or available over the service.
I think Becky has pointed out that we could get out of this by using the "service" definition we have and relying on the "ICANN can undertake contracts" sentence to permit this regulation. I wonder whether that approach solves our problem, however, since if ICANN can regulate content on some web pages in the service of the DNS, why can't it regulate others? Plainly, the line we want is the one distinguishing "things relevant to domain name registrations in contracted domains" and "everything else", but I still don't know how to write that down.
Best regards,
A
distinguishing "things relevant to domain name registrations in
contracted domains" and "everything else"
As I have already suggested, that "line" cannot be drawn, if it is to be future-proofed. Particularly as "everything else" apparently includes all the quality control, consumer protection, regulatory conformant preconditions for gTLDs proposing to operate in regulated sectors. (Banking, pharmacy, health services, professional services etc.) May I suggest that this question is out of scope for CCWG and should be referred to the forthcoming Review of the new gTLD programme. Regards CW On 22 Nov 2015, at 18:15, Nigel Roberts <nigel@channelisles.net> wrote:
And as I think I've already argued, I think it is fundamental to accountability in a post-NTIA environment that we know exactly under what legal authority such regulation takes place.
After all the millions on legal fees, is it the case that we still don't know?
On 11/22/2015 03:41 PM, Andrew Sullivan wrote:
On Sun, Nov 22, 2015 at 02:43:50AM -0500, Greg Shatan wrote:
GS: Bruce, if you are talking about the software processes that underlie the websites and email systems used by registries and registrars, I believe that's correct. But what do you believe is the impact of that? Do you think that what ICANN currently does or hopes to do would constitute "imposing regulations on" these software processes?
As I think I've already argued, ICANN does in fact impose regulations on some of those processes. ICANN imposes regulations on content of contracted registrars for some registries, and all contracted registries, for certain services offered over http(s) and also over whois ("port 43 whois" is the way ICANN policy people seem to express this). It's a direct specification of content: what must and must not be on the relevant web pages or available over the service.
I think Becky has pointed out that we could get out of this by using the "service" definition we have and relying on the "ICANN can undertake contracts" sentence to permit this regulation. I wonder whether that approach solves our problem, however, since if ICANN can regulate content on some web pages in the service of the DNS, why can't it regulate others? Plainly, the line we want is the one distinguishing "things relevant to domain name registrations in contracted domains" and "everything else", but I still don't know how to write that down.
Best regards,
A
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
On 21/11/2015 00:41, Bruce Tonkin wrote:
• "Some existing registry agreements may be out of compliance with ICANN's responsibilities if this change is adopted": [snip] I have asked the legal staff at ICANN to provide some examples.
Here is one that occurs to me though. The current new gTLD registry agreements in Specification 5 (http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-...) have a provision that restrict the ability of a registrant to register a country or territory name, or names relating to the International Olympic Committee; International Red Cross and Red Crescent Movement.
I would say that the reservation of strings relating to the International Olympic Committee, and to the International Red Cross and Red Crescent Movement, is just special case of the same kind of policy that is protected by the UDRP. These policies are all designed to prevent domain names being registered by persons who do not have the right to register that domain name, because of existing rights in that domain name held by another. For ICANN to have policies directed towards this goal is a legitimate aspect of ICANN's mission to "preserve the... secure operation of the [DNS]". If the CCWG Report is adopted, it will be clearly stated for the first time that preserving the secure operation of the DNS is part of ICANN's Mission; at the moment, that is only a "core value" that should "guide the decisions and actions of ICANN". So I think our report would makes this more clearly authorised than the existing bylaws do.
These are examples of content in domain names that have some restrictions. There are no technical or security reasons for such restrictions. The restrictions have been put in place on the basis of "public policy" advice from the GAC.
I would be careful about saying that there are no "technical or security reasons"; as above, you may find that on more careful examination that there are. You may also find, on closer examination, that actions ICANN has taken in response to public policy advice from the GAC can be entirely justified as being within the scope of ICANN's Mission. If "Action 1" and "Action 2" are alternative possible actions, and both are within legitimate options within the scope of ICANN's Mission, then it is entirely legitimate for ICANN to choose between them on the basis of public policy advice from the GAC. However, if Action 1 is something that is otherwise prohibited to ICANN, then GAC advice that it should perform "Action 1" does not legitimise that action. Do you not agree? Reading the Board's message, and yours, I do get a sense that you worry that ICANN may have in the past taken actions for which no legitimate justification could be found within the existing Mission. Perhaps I am misreading that. If so, I doubt that the problem is as extensive as you seem to fear; it may be simply that the inadequacy of the existing accountability measures have meant that ICANN has never felt the need to clearly examine the legitimacy of its actions, and has proceeded simply on "gut feel", but that when past actions are carefully examined, it will be shown that that "gut feel" as to what is authorised was usually correct. That said, should it be discovered that in the past ICANN truly has exceeded its legitimate authority in particular cases, then that would merely demonstrate the urgency and vital necessity of introducing clear and effective mechanisms to avoid such abuses in the future. 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
Hello Malcolm,
Reading the Board's message, and yours, I do get a sense that you worry that ICANN may have in the past taken actions for which no legitimate justification could be found within the existing Mission.
Our concern was not so much the mission statement, which we supported, but attempts to craft restrictions on how that statement should be interpreted that may impact the current agreements and legitimate actions in future. Regards, Bruce Tonkin
Bruce, On Sun, Nov 22, 2015 at 5:24 PM, Bruce Tonkin < Bruce.Tonkin@melbourneit.com.au> wrote:
Hello Malcolm,
Reading the Board's message, and yours, I do get a sense that you worry that ICANN may have in the past taken actions for which no legitimate justification could be found within the existing Mission.
Our concern was not so much the mission statement, which we supported, but attempts to craft restrictions on how that statement should be interpreted that may impact the current agreements and legitimate actions in future.
GS: Bruce, unfortunately, you (and the Board) have hit the nail on the head here. This is an attempt to use this process to undermine certain current legitimate activity and valid contracts of ICANN. Furthermore, it's a "proxy battle" in an ongoing policy dispute, and this is an attempt to "put a thumb on the scales" in that dispute by trying to put language into the Bylaws that can be used in that dispute and to invalidate portions of ICANN's contracts. This has gone beyond replacing the NTIA as a backstop and finding ways for the community to hold ICANN generally more accountable; in that sense, it's (ironically) beyond the scope of the CCWG. If this goes forward as some would want, how long do you think it will be before the first IRP is filed challenging current ICANN activity using this language as a basis for that challenge? Greg
Regards, Bruce Tonkin
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
participants (8)
-
Andrew Sullivan -
Bruce Tonkin -
Christopher Wilkinson -
David Post -
Greg Shatan -
Malcolm Hutty -
Nigel Roberts -
Seun Ojedeji