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.