Personal Responses to Draft Summary of ALAC Issues on Mission (Recommendation 5)
According to the Draft Issues document circulated by Alan Greenberg, “ALAC has a grave concern that the wording used to restrict ICANN’s mission may have inadvertent results which severely impact its ability to carry out its intended mission.” That’s a pretty serious charge and I thought it would make sense to begin a substantive discussion of the ALAC points. Here is my attempt to start that conversation. In the hope of moving this issue forward quickly, I am stepping out of my role as rapporteur here and expressing my personal views. I apologize in advance for the length of this post, but wanted to respond as fully as possible to the ALAC Draft. 1. According to the Draft Summary, the notes to drafters incorrectly imply that ICANN’s Mission is limited to the “picket fence.” I believe this is inaccurate. ICANN’s Mission is specifically described as coordinating the development and implementation of bottom-up policies for which uniform coordinate resolution is reasonably necessary to facilitate the openness,, interoperability, and/or stability [of the DNS]. The note to drafters says that RAA Spec 4 and RA Spec 1 “are intended and understood to be within the scope of ICANN’s Mission.” 2. According to the Draft Summary, the ALAC wants a legal opinion that provides assurance that the “many areas of contracts” outside the so-called “picket fence,” established by negotiation, or other than through a PDP “may be renewed without change in the areas in question.” This concern also extends to new gTLD operators who have not signed contracts yet. I think we need to break this question down a bit. · First, recall that the Mission specifically empowers ICANN to “implement” policies. Also recall that the text we have provided states “ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission.” Most of the provisions of the RA and RAA of concern should be covered by these authorities, IMHO. · Second, I acknowledge that there could be some new gTLD applicant-provided PICs and new gTLD applicant-provided operating rules that fall outside of ICANN’s Mission Statement. For example, suppose the applicant for .singlemaltscotch specified in its application (which is, in turn, incorporated into its Registry Agreement) that all registrants in the domain must be 21 years old. That requirement probably is not strictly necessary to facilitate the openness, interoperability, resilience, security and/or stability [of the DNS]. While I don’t think that ICANN has the authority to demand that the registry operator adopt such a policy, I have no problem whatsoever with ICANN holding the registrant to that policy if it was offered as part of the application. (Others may well disagree with me.) · Third, rather than speaking in generalities, could we talk about some specific provisions that arguably fall outside ICANN’s Mission and its implementation authority? I’m asking both sides for contributions on this point. · Finally – the request for a “legal opinion.” I will repeat what I’ve already said, these kind of open-ended questions produce very expensive, very unsatisfying legal opinions. Rather than chase this option, once we agree on the problem statement, let’s ask the lawyers if there is language that could be added to reinforce the likelihood that any challenge will be resolved in the manner we collectively anticipate. 3. According to the ALAC Draft Summary “anything which would allow an IRP to invalidate the current contractual terms is not acceptable.” I don’t think that there is a risk of invalidating the current contractual terms – and the language that we have discussed as an additional note to drafters would reinforce that (This means that the parties who entered into existing contracts intended (and intend) to be bound by those agreements. It means that neither a contracting party nor anyone else should be able to bring a case that any provisions of such agreements on their face are ultra vires. It does not, however, modify any contracting party’s right to challenge the other party¹s interpretation of that language.) I don’t have a particular problem extending that to existing applicants who have yet to sign registry agreements, though others might. But seriously, is ALAC asking for a guarantee that certain provisions cannot be challenged? That is not a reasonable ask IMHO. That’s because it is always the case that ICANN could choose to enforce a provision of an existing agreement in a manner that is a frank violation of the Mission. I’ve previously provided several examples in the context of 3.18 of the RAA, which I believe is – on its face – consistent with Mission, but which could be enforced in a manner that is not. 4. ALAC continues to object to the removal of the “where feasible and appropriate” caveat to the Core Values regarding reliance on market mechanisms to promote and sustain a competitive environment. ALAC takes exception with my point that “ICANN does not possess the requisite skill or authority to intervene in the competitive market,” citing the RSEP provisions regarding concerns about significant competition issues. I think the example completely supports my point here. In the RSEP, if ICANN has competition concerns, it has the authority to “refer the matter to the appropriate competition authority.” From that point it is entirely up to the appropriate competition authority to exercise its sovereign authority with respect to antitrust law. If the concern is that somehow the omission of the “where feasible and appropriate” language would prevent ICANN from making such a referral (which I don’t believe is the case), then I am happy to clarify. But taking competition law into its own hands is, IMHO, a very clear example of the kind of regulatory authority that ICANN should not have. 5. ALAC objects to the Commitment to “preserve and enhance the neutral and judgment free operation of the DNS,” pointing out that the NTIA requirement is limited to the “neutral and judgment free administration of the technical DNS and IANA functions.” Good point, I am ok with that change. 6. The ALAC believes that the AoC commitment to “consumer trust” should be in the ICANN Commitments and Core Values rather than in the AoC reviews provisions of the Bylaws. Section 3 of the AoC describes what the “document” (the AoC) accomplishes: it affirms key commitments by DOC and ICANN, including commitments “to promote competition, consumer trust, and consumer choice in the DNS marketplace.” The context for promoting consumer trust is found exclusively in Section 9.3, which describes the reviews that must be undertaken in connection with the expansion of the top level domain space. This issue was debated extensively within the CCWG. A general commitment to promoting consumer trust threatens massive scope creep IMHO. 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>
But won't ALAC change their mind next week? On 12/17/2015 07:53 PM, Burr, Becky wrote:
According to the Draft Issues document circulated by Alan Greenberg, “ALAC has a grave concern that the wording used to restrict ICANN’s mission may have inadvertent results which severely impact its ability to carry out its intended mission.” That’s a pretty serious charge and I thought it would make sense to begin a substantive discussion of the ALAC points. Here is my attempt to start that conversation. In the hope of moving this issue forward quickly, I am stepping out of my role as rapporteur here and expressing my personal views. I apologize in advance for the length of this post, but wanted to respond as fully as possible to the ALAC Draft.
1.According to the Draft Summary, the notes to drafters incorrectly imply that ICANN’s Mission is limited to the “picket fence.”
/I believe this is inaccurate. ICANN’s Mission is specifically described as coordinating the development and implementation of bottom-up policies for which uniform coordinate resolution is reasonably necessary to facilitate the openness,, interoperability, and/or stability [of the DNS]. The note to drafters says that RAA Spec 4 and RA Spec 1 “are intended and understood to be within the scope of ICANN’s Mission.” /
//
2.According to the Draft Summary, the ALAC wants a legal opinion that provides assurance that the “many areas of contracts” outside the so-called “picket fence,” established by negotiation, or other than through a PDP “may be renewed without change in the areas in question.” This concern also extends to new gTLD operators who have not signed contracts yet.
/I think we need to break this question down a bit. /
//
·/First, recall that the Mission specifically empowers ICANN to “implement” policies. Also recall that the text we have provided states “ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission.” Most of the provisions of the RA and RAA of concern should be covered by these authorities, IMHO./
//
·/Second, I acknowledge that there could be some new gTLD applicant-provided PICs and new gTLD applicant-provided operating rules that fall outside of ICANN’s Mission Statement. For example, suppose the applicant for .singlemaltscotch specified in its application (which is, in turn, incorporated into its Registry Agreement) that all registrants in the domain must be 21 years old. That requirement probably is not strictly necessary to facilitate the openness, interoperability, resilience, security and/or stability [of the DNS]. While I don’t think that ICANN has the authority to *demand *that the registry operator adopt such a policy, I have no problem whatsoever with ICANN holding the registrant to that policy if it was offered as part of the application. (Others may well disagree with me.)/
//
·/Third, rather than speaking in generalities, could we talk about some specific provisions that arguably fall outside ICANN’s Mission and its implementation authority? I’m asking both sides for contributions on this point. /
//
·/Finally – the request for a “legal opinion.” I will repeat what I’ve already said, these kind of open-ended questions produce very expensive, very unsatisfying legal opinions. Rather than chase this option, once we agree on the problem statement, let’s ask the lawyers if there is language that could be added to reinforce the likelihood that any challenge will be resolved in the manner we collectively anticipate. /
3.According to the ALAC Draft Summary “anything which would allow an IRP to invalidate the current contractual terms is not acceptable.”
/I don’t think that there is a risk of invalidating the current contractual terms – and the language that we have discussed as an additional note to drafters would reinforce that (/This means that the parties who entered into existing contracts intended (and intend) to be bound by those agreements. It means that neither a contracting party nor anyone else should be able to bring a case that any provisions of such agreements on their face are ultra vires. It does not, however, modify any contracting party’s right to challenge the other party¹s interpretation of that language.) /I don’t have a particular problem extending that to existing applicants who have yet to sign registry agreements, though others might./
/But seriously, is ALAC asking for a guarantee that certain provisions cannot be challenged? That is not a reasonable ask IMHO. That’s because it is always the case that ICANN could choose to enforce a provision of an existing agreement in a manner that is a frank violation of the Mission. I’ve previously provided several examples in the context of 3.18 of the RAA, which I believe is – on its face – consistent with Mission, but which could be enforced in a manner that is not./
//
4.ALAC continues to object to the removal of the “where feasible and appropriate” caveat to the Core Values regarding reliance on market mechanisms to promote and sustain a competitive environment.
/ALAC takes exception with my point that “ICANN does not possess the requisite skill or authority to intervene in the competitive market,” citing the RSEP provisions regarding concerns about significant competition issues. I think the example completely supports my point here. In the RSEP, if ICANN has competition concerns, it has the authority to “refer the matter to the appropriate competition authority.” From that point it is entirely up to the appropriate competition authority to exercise its sovereign authority with respect to antitrust law. If the concern is that somehow the omission of the “where feasible and appropriate” language would prevent ICANN from making such a referral (which I don’t believe is the case), then I am happy to clarify. But taking competition law into its own hands is, IMHO, a very clear example of the kind of regulatory authority that ICANN should not have./
//
5.ALAC objects to the Commitment to “preserve and enhance the neutral and judgment free operation of the DNS,” pointing out that the NTIA requirement is limited to the “neutral and judgment free administration of the technical DNS and IANA functions.”
/Good point, I am ok with that change/.
6.The ALAC believes that the AoC commitment to “consumer trust” should be in the ICANN Commitments and Core Values rather than in the AoC reviews provisions of the Bylaws.
/Section 3 of the AoC describes what the “document” (the AoC) accomplishes: it affirms key commitments by //DOC and ICANN, including commitments “to promote competition, consumer trust, and consumer choice in the DNS marketplace.” The context for promoting consumer trust is found exclusively in Section 9.3, which describes the reviews that must be undertaken in connection with the expansion of the top level domain space. This issue was debated extensively within the CCWG. A general commitment to promoting consumer trust threatens massive scope creep IMHO. /
*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
Becky, I think trying to answer ALAC questions is an improper shift in the burden of proof. I think the question that Alan and the other 14 people on ALAC need to answer is whether they believe there should be ANY limits on ICANN's scope of authority that can be exercised via contracting with registrars and registries. My belief, based on the comments I see here, is that they do not want there to be any such limits. Could an ALAC spokesperson, or even an individual ALAC member, answer that question with a simple yes or no? Should the mission limit what ICANN can do via its contracts? If your answer is No, then it's clearly going to be a nonconsensual position and we will just have to go on without it. If the answer is Yes, I'd be interested in seeing examples of what kinds of things the 15 people in ALAC think ARE outside of CANN's scope and mission and would constitute an over-reaching use of its authority. More responses to Becky in line below: While I don't think that ICANN has the authority to demand that the registry operator adopt such a policy, I have no problem whatsoever with ICANN holding the registrant to that policy if it was offered as part of the application. (Others may well disagree with me.) I do disagree. One problem is that the line between what ICANN demands and what is offered "voluntarily" by the registry is unclear, and easily fudged, given ICANN's monopoly position. For example, suppose someone applied for that TLD and the GAC and ALAC advised that the applicant not be given the domain unless they adopted such a policy. If this would be classified as the registry "voluntarily" adopting the policy (because they will be denied entry if they don't) it is very clearly an example of ICANN using its monopoly control of the root to impose regulation on the users · Third, rather than speaking in generalities, could we talk about some specific provisions that arguably fall outside ICANN's Mission and its implementation authority? I'm asking both sides for contributions on this point. MM: I think David Post and I and others have provided numerous examples of this. · Finally - the request for a "legal opinion." I will repeat what I've already said, these kind of open-ended questions produce very expensive, very unsatisfying legal opinions. Rather than chase this option, once we agree on the problem statement, let's ask the lawyers if there is language that could be added to reinforce the likelihood that any challenge will be resolved in the manner we collectively anticipate. MM: totally agree 3. According to the ALAC Draft Summary "anything which would allow an IRP to invalidate the current contractual terms is not acceptable." I don't think that there is a risk of invalidating the current contractual terms - and the language that we have discussed as an additional note to drafters would reinforce that (This means that the parties who entered into existing contracts intended (and intend) to be bound by those agreements. It means that neither a contracting party nor anyone else should be able to bring a case that any provisions of such agreements on their face are ultra vires. It does not, however, modify any contracting party's right to challenge the other party¹s interpretation of that language.) I don't have a particular problem extending that to existing applicants who have yet to sign registry agreements, though others might. But seriously, is ALAC asking for a guarantee that certain provisions cannot be challenged? That is not a reasonable ask IMHO. That's because it is always the case that ICANN could choose to enforce a provision of an existing agreement in a manner that is a frank violation of the Mission. I've previously provided several examples in the context of 3.18 of the RAA, which I believe is - on its face - consistent with Mission, but which could be enforced in a manner that is not. 4. ALAC continues to object to the removal of the "where feasible and appropriate" caveat to the Core Values regarding reliance on market mechanisms to promote and sustain a competitive environment. ALAC takes exception with my point that "ICANN does not possess the requisite skill or authority to intervene in the competitive market," citing the RSEP provisions regarding concerns about significant competition issues. I think the example completely supports my point here. In the RSEP, if ICANN has competition concerns, it has the authority to "refer the matter to the appropriate competition authority." From that point it is entirely up to the appropriate competition authority to exercise its sovereign authority with respect to antitrust law. If the concern is that somehow the omission of the "where feasible and appropriate" language would prevent ICANN from making such a referral (which I don't believe is the case), then I am happy to clarify. But taking competition law into its own hands is, IMHO, a very clear example of the kind of regulatory authority that ICANN should not have. 5. ALAC objects to the Commitment to "preserve and enhance the neutral and judgment free operation of the DNS," pointing out that the NTIA requirement is limited to the "neutral and judgment free administration of the technical DNS and IANA functions." Good point, I am ok with that change. MM: I am not ok with that change 6. The ALAC believes that the AoC commitment to "consumer trust" should be in the ICANN Commitments and Core Values rather than in the AoC reviews provisions of the Bylaws. Section 3 of the AoC describes what the "document" (the AoC) accomplishes: it affirms key commitments by DOC and ICANN, including commitments "to promote competition, consumer trust, and consumer choice in the DNS marketplace." The context for promoting consumer trust is found exclusively in Section 9.3, which describes the reviews that must be undertaken in connection with the expansion of the top level domain space. This issue was debated extensively within the CCWG. A general commitment to promoting consumer trust threatens massive scope creep IMHO. 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>
Now I do not want to accuse Mr Greenberg of being intelligent, but that the ALAC appointed members to the CCWG agree to everything this CCWG comes up with just to renege on it, all the effing time, does cast doubt on that AC's involvement in the process. Again. Never mind their attempt to elevate themselves to the level of a SO. el -- Sent from Dr Lisse's iPad mini
On 17 Dec 2015, at 21:53, Burr, Becky <Becky.Burr@neustar.biz> wrote:
According to the Draft Issues document circulated by Alan Greenberg, “ALAC has a grave concern that the wording used to restrict ICANN’s mission may have inadvertent results which severely impact its ability to carry out its intended mission.” That’s a pretty serious charge and I thought it would make sense to begin a substantive discussion of the ALAC points. Here is my attempt to start that conversation. In the hope of moving this issue forward quickly, I am stepping out of my role as rapporteur here and expressing my personal views. I apologize in advance for the length of this post, but wanted to respond as fully as possible to the ALAC Draft.
1. According to the Draft Summary, the notes to drafters incorrectly imply that ICANN’s Mission is limited to the “picket fence.”
I believe this is inaccurate. ICANN’s Mission is specifically described as coordinating the development and implementation of bottom-up policies for which uniform coordinate resolution is reasonably necessary to facilitate the openness,, interoperability, and/or stability [of the DNS]. The note to drafters says that RAA Spec 4 and RA Spec 1 “are intended and understood to be within the scope of ICANN’s Mission.”
2. According to the Draft Summary, the ALAC wants a legal opinion that provides assurance that the “many areas of contracts” outside the so-called “picket fence,” established by negotiation, or other than through a PDP “may be renewed without change in the areas in question.” This concern also extends to new gTLD operators who have not signed contracts yet.
I think we need to break this question down a bit.
· First, recall that the Mission specifically empowers ICANN to “implement” policies. Also recall that the text we have provided states “ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission.” Most of the provisions of the RA and RAA of concern should be covered by these authorities, IMHO.
· Second, I acknowledge that there could be some new gTLD applicant-provided PICs and new gTLD applicant-provided operating rules that fall outside of ICANN’s Mission Statement. For example, suppose the applicant for .singlemaltscotch specified in its application (which is, in turn, incorporated into its Registry Agreement) that all registrants in the domain must be 21 years old. That requirement probably is not strictly necessary to facilitate the openness, interoperability, resilience, security and/or stability [of the DNS]. While I don’t think that ICANN has the authority to demand that the registry operator adopt such a policy, I have no problem whatsoever with ICANN holding the registrant to that policy if it was offered as part of the application. (Others may well disagree with me.)
· Third, rather than speaking in generalities, could we talk about some specific provisions that arguably fall outside ICANN’s Mission and its implementation authority? I’m asking both sides for contributions on this point.
· Finally – the request for a “legal opinion.” I will repeat what I’ve already said, these kind of open-ended questions produce very expensive, very unsatisfying legal opinions. Rather than chase this option, once we agree on the problem statement, let’s ask the lawyers if there is language that could be added to reinforce the likelihood that any challenge will be resolved in the manner we collectively anticipate.
3. According to the ALAC Draft Summary “anything which would allow an IRP to invalidate the current contractual terms is not acceptable.”
I don’t think that there is a risk of invalidating the current contractual terms – and the language that we have discussed as an additional note to drafters would reinforce that (This means that the parties who entered into existing contracts intended (and intend) to be bound by those agreements. It means that neither a contracting party nor anyone else should be able to bring a case that any provisions of such agreements on their face are ultra vires. It does not, however, modify any contracting party’s right to challenge the other party¹s interpretation of that language.) I don’t have a particular problem extending that to existing applicants who have yet to sign registry agreements, though others might.
But seriously, is ALAC asking for a guarantee that certain provisions cannot be challenged? That is not a reasonable ask IMHO. That’s because it is always the case that ICANN could choose to enforce a provision of an existing agreement in a manner that is a frank violation of the Mission. I’ve previously provided several examples in the context of 3.18 of the RAA, which I believe is – on its face – consistent with Mission, but which could be enforced in a manner that is not.
4. ALAC continues to object to the removal of the “where feasible and appropriate” caveat to the Core Values regarding reliance on market mechanisms to promote and sustain a competitive environment.
ALAC takes exception with my point that “ICANN does not possess the requisite skill or authority to intervene in the competitive market,” citing the RSEP provisions regarding concerns about significant competition issues. I think the example completely supports my point here. In the RSEP, if ICANN has competition concerns, it has the authority to “refer the matter to the appropriate competition authority.” From that point it is entirely up to the appropriate competition authority to exercise its sovereign authority with respect to antitrust law. If the concern is that somehow the omission of the “where feasible and appropriate” language would prevent ICANN from making such a referral (which I don’t believe is the case), then I am happy to clarify. But taking competition law into its own hands is, IMHO, a very clear example of the kind of regulatory authority that ICANN should not have.
5. ALAC objects to the Commitment to “preserve and enhance the neutral and judgment free operation of the DNS,” pointing out that the NTIA requirement is limited to the “neutral and judgment free administration of the technical DNS and IANA functions.”
Good point, I am ok with that change.
6. The ALAC believes that the AoC commitment to “consumer trust” should be in the ICANN Commitments and Core Values rather than in the AoC reviews provisions of the Bylaws.
Section 3 of the AoC describes what the “document” (the AoC) accomplishes: it affirms key commitments by DOC and ICANN, including commitments “to promote competition, consumer trust, and consumer choice in the DNS marketplace.” The context for promoting consumer trust is found exclusively in Section 9.3, which describes the reviews that must be undertaken in connection with the expansion of the top level domain space. This issue was debated extensively within the CCWG. A general commitment to promoting consumer trust threatens massive scope creep IMHO.
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
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Occasionally I like to follow my own posts... On reflection, with Ms Gross and myself having objected, and now the ALAC members having had their mind changes for them, it means we do not have Consensus. Nice tactics... el -- Sent from Dr Lisse's iPad mini
On 17 Dec 2015, at 23:55, Dr Eberhard W Lisse <el@lisse.na> wrote:
Now I do not want to accuse Mr Greenberg of being intelligent, but that the ALAC appointed members to the CCWG agree to everything this CCWG comes up with just to renege on it, all the effing time, does cast doubt on that AC's involvement in the process. Again.
Never mind their attempt to elevate themselves to the level of a SO.
el
-- Sent from Dr Lisse's iPad mini
On 17 Dec 2015, at 21:53, Burr, Becky <Becky.Burr@neustar.biz> wrote:
According to the Draft Issues document circulated by Alan Greenberg, “ALAC has a grave concern that the wording used to restrict ICANN’s mission may have inadvertent results which severely impact its ability to carry out its intended mission.” That’s a pretty serious charge and I thought it would make sense to begin a substantive discussion of the ALAC points. Here is my attempt to start that conversation. In the hope of moving this issue forward quickly, I am stepping out of my role as rapporteur here and expressing my personal views. I apologize in advance for the length of this post, but wanted to respond as fully as possible to the ALAC Draft.
1. According to the Draft Summary, the notes to drafters incorrectly imply that ICANN’s Mission is limited to the “picket fence.”
I believe this is inaccurate. ICANN’s Mission is specifically described as coordinating the development and implementation of bottom-up policies for which uniform coordinate resolution is reasonably necessary to facilitate the openness,, interoperability, and/or stability [of the DNS]. The note to drafters says that RAA Spec 4 and RA Spec 1 “are intended and understood to be within the scope of ICANN’s Mission.”
2. According to the Draft Summary, the ALAC wants a legal opinion that provides assurance that the “many areas of contracts” outside the so-called “picket fence,” established by negotiation, or other than through a PDP “may be renewed without change in the areas in question.” This concern also extends to new gTLD operators who have not signed contracts yet.
I think we need to break this question down a bit.
· First, recall that the Mission specifically empowers ICANN to “implement” policies. Also recall that the text we have provided states “ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission.” Most of the provisions of the RA and RAA of concern should be covered by these authorities, IMHO.
· Second, I acknowledge that there could be some new gTLD applicant-provided PICs and new gTLD applicant-provided operating rules that fall outside of ICANN’s Mission Statement. For example, suppose the applicant for .singlemaltscotch specified in its application (which is, in turn, incorporated into its Registry Agreement) that all registrants in the domain must be 21 years old. That requirement probably is not strictly necessary to facilitate the openness, interoperability, resilience, security and/or stability [of the DNS]. While I don’t think that ICANN has the authority to demand that the registry operator adopt such a policy, I have no problem whatsoever with ICANN holding the registrant to that policy if it was offered as part of the application. (Others may well disagree with me.)
· Third, rather than speaking in generalities, could we talk about some specific provisions that arguably fall outside ICANN’s Mission and its implementation authority? I’m asking both sides for contributions on this point.
· Finally – the request for a “legal opinion.” I will repeat what I’ve already said, these kind of open-ended questions produce very expensive, very unsatisfying legal opinions. Rather than chase this option, once we agree on the problem statement, let’s ask the lawyers if there is language that could be added to reinforce the likelihood that any challenge will be resolved in the manner we collectively anticipate.
3. According to the ALAC Draft Summary “anything which would allow an IRP to invalidate the current contractual terms is not acceptable.”
I don’t think that there is a risk of invalidating the current contractual terms – and the language that we have discussed as an additional note to drafters would reinforce that (This means that the parties who entered into existing contracts intended (and intend) to be bound by those agreements. It means that neither a contracting party nor anyone else should be able to bring a case that any provisions of such agreements on their face are ultra vires. It does not, however, modify any contracting party’s right to challenge the other party¹s interpretation of that language.) I don’t have a particular problem extending that to existing applicants who have yet to sign registry agreements, though others might.
But seriously, is ALAC asking for a guarantee that certain provisions cannot be challenged? That is not a reasonable ask IMHO. That’s because it is always the case that ICANN could choose to enforce a provision of an existing agreement in a manner that is a frank violation of the Mission. I’ve previously provided several examples in the context of 3.18 of the RAA, which I believe is – on its face – consistent with Mission, but which could be enforced in a manner that is not.
4. ALAC continues to object to the removal of the “where feasible and appropriate” caveat to the Core Values regarding reliance on market mechanisms to promote and sustain a competitive environment.
ALAC takes exception with my point that “ICANN does not possess the requisite skill or authority to intervene in the competitive market,” citing the RSEP provisions regarding concerns about significant competition issues. I think the example completely supports my point here. In the RSEP, if ICANN has competition concerns, it has the authority to “refer the matter to the appropriate competition authority.” From that point it is entirely up to the appropriate competition authority to exercise its sovereign authority with respect to antitrust law. If the concern is that somehow the omission of the “where feasible and appropriate” language would prevent ICANN from making such a referral (which I don’t believe is the case), then I am happy to clarify. But taking competition law into its own hands is, IMHO, a very clear example of the kind of regulatory authority that ICANN should not have.
5. ALAC objects to the Commitment to “preserve and enhance the neutral and judgment free operation of the DNS,” pointing out that the NTIA requirement is limited to the “neutral and judgment free administration of the technical DNS and IANA functions.”
Good point, I am ok with that change.
6. The ALAC believes that the AoC commitment to “consumer trust” should be in the ICANN Commitments and Core Values rather than in the AoC reviews provisions of the Bylaws.
Section 3 of the AoC describes what the “document” (the AoC) accomplishes: it affirms key commitments by DOC and ICANN, including commitments “to promote competition, consumer trust, and consumer choice in the DNS marketplace.” The context for promoting consumer trust is found exclusively in Section 9.3, which describes the reviews that must be undertaken in connection with the expansion of the top level domain space. This issue was debated extensively within the CCWG. A general commitment to promoting consumer trust threatens massive scope creep IMHO.
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
_______________________________________________ Accountability-Cross-Community mailing list Accountability-Cross-Community@icann.org https://mm.icann.org/mailman/listinfo/accountability-cross-community
Becky, thanks for taking the time and effort to reply. Please see my comments embedded. As with your comments, these are my personal comments and have not been passed by my ALAC/At-Large colleagues. Alan At 17/12/2015 02:53 PM, Burr, Becky wrote:
According to the Draft Issues document circulated by Alan Greenberg, ALAC has a grave concern that the wording used to restrict ICANNs mission may have inadvertent results which severely impact its ability to carry out its intended mission. Thats a pretty serious charge and I thought it would make sense to begin a substantive discussion of the ALAC points. Here is my attempt to start that conversation. In the hope of moving this issue forward quickly, I am stepping out of my role as rapporteur here and expressing my personal views. I apologize in advance for the length of this post, but wanted to respond as fully as possible to the ALAC Draft.
AG: That was not a "charge" but a concern. My reading of the Board comments is that they have a similar concern. That does not make it any more valid, but does imply that we are not alone in worrying that the new mission statements, where some of the implications of the wording is unclear, and where there may be implications due to interactions among the various new clauses is a possible source of future problems in the enforcing of the contracts that are at the core of our gTLD responsibilities. That "grave concern" was an overall caveat. The text that followed were the specific issues that we have identified to date. The caveat was expressing the worry that there may be others lurking. You will recall that the current grandfathering language was only invented after the ALAC expressed concern over the proposed text allowing current contracts (or parts of them such as PICs) from being questions via an IRP.
1. According to the Draft Summary, the notes to drafters incorrectly imply that ICANNs Mission is limited to the picket fence.
I believe this is inaccurate. ICANNs Mission is specifically described as coordinating the development and implementation of bottom-up policies for which uniform coordinate resolution is reasonably necessary to facilitate the openness,, interoperability, and/or stability [of the DNS]. The note to drafters says that RAA Spec 4 and RA Spec 1 are intended and understood to be within the scope of ICANNs Mission.
AG:The area in question is whether the parts of contracts that were not developed through a bottom-up process (in some cases because the clauses pre-date the process, or in the case of the RAA, were agreed to by negotiation) might be invalidated due to the new Article I wording.
2. According to the Draft Summary, the ALAC wants a legal opinion that provides assurance that the many areas of contracts outside the so-called picket fence, established by negotiation, or other than through a PDP may be renewed without change in the areas in question. This concern also extends to new gTLD operators who have not signed contracts yet.
I think we need to break this question down a bit.
· First, recall that the Mission specifically empowers ICANN to implement policies. Also recall that the text we have provided states ICANN shall have the ability to negotiate, enter into and enforce agreements with contracted parties in service of its Mission. Most of the provisions of the RA and RAA of concern should be covered by these authorities, IMHO.
AG: The specific question is whether the grandfathering that protects a current contract will also include its renewal. It is a simple question and presumably can be covered by careful wording of the Bylaw if the CCWG agrees that this is what we want.
· Second, I acknowledge that there could be some new gTLD applicant-provided PICs and new gTLD applicant-provided operating rules that fall outside of ICANNs Mission Statement. For example, suppose the applicant for .singlemaltscotch specified in its application (which is, in turn, incorporated into its Registry Agreement) that all registrants in the domain must be 21 years old. That requirement probably is not strictly necessary to facilitate the openness, interoperability, resilience, security and/or stability [of the DNS]. While I dont think that ICANN has the authority to demand that the registry operator adopt such a policy, I have no problem whatsoever with ICANN holding the registrant to that policy if it was offered as part of the application. (Others may well disagree with me.)
AG: We are in agreement here (except PICs post-date the application and must be covered).
· Third, rather than speaking in generalities, could we talk about some specific provisions that arguably fall outside ICANNs Mission and its implementation authority? Im asking both sides for contributions on this point.
· Finally the request for a legal opinion. I will repeat what Ive already said, these kind of open-ended questions produce very expensive, very unsatisfying legal opinions. Rather than chase this option, once we agree on the problem statement, lets ask the lawyers if there is language that could be added to reinforce the likelihood that any challenge will be resolved in the manner we collectively anticipate.
AG: The question was not open ended. It covers whether renewal is or can be covered under the grandfathering, and whether we can have wording that covers the unsigned contracts.
3. According to the ALAC Draft Summary anything which would allow an IRP to invalidate the current contractual terms is not acceptable.
I dont think that there is a risk of invalidating the current contractual terms and the language that we have discussed as an additional note to drafters would reinforce that (This means that the parties who entered into existing contracts intended (and intend) to be bound by those agreements. It means that neither a contracting party nor anyone else should be able to bring a case that any provisions of such agreements on their face are ultra vires. It does not, however, modify any contracting partys right to challenge the other party¹s interpretation of that language.) I dont have a particular problem extending that to existing applicants who have yet to sign registry agreements, though others might.
AG: Yes, when the issue of the unsigned contracts was first brought up, come CCWG participants basically said Too bad - any new contacts will have to work by the new rules", and the proposal was silent on the issue, thus our concern.
But seriously, is ALAC asking for a guarantee that certain provisions cannot be challenged? That is not a reasonable ask IMHO. Thats because it is always the case that ICANN could choose to enforce a provision of an existing agreement in a manner that is a frank violation of the Mission. Ive previously provided several examples in the context of 3.18 of the RAA, which I believe is on its face consistent with Mission, but which could be enforced in a manner that is not.
AG: My concern is that if terms that under today's Bylaws cannot be challenged, that should not change. If current practice is outside of today's mission, it can be challenged today, and that is fine.
4. ALAC continues to object to the removal of the where feasible and appropriate caveat to the Core Values regarding reliance on market mechanisms to promote and sustain a competitive environment.
ALAC takes exception with my point that ICANN does not possess the requisite skill or authority to intervene in the competitive market, citing the RSEP provisions regarding concerns about significant competition issues. I think the example completely supports my point here. In the RSEP, if ICANN has competition concerns, it has the authority to refer the matter to the appropriate competition authority. From that point it is entirely up to the appropriate competition authority to exercise its sovereign authority with respect to antitrust law. If the concern is that somehow the omission of the where feasible and appropriate language would prevent ICANN from making such a referral (which I dont believe is the case), then I am happy to clarify. But taking competition law into its own hands is, IMHO, a very clear example of the kind of regulatory authority that ICANN should not have.
AG: No, the concern is that with the wording removed, ALL competition issues are outside of our mission and we may not even be allowed to ask the question or make the initial evaluation.
5. ALAC objects to the Commitment to preserve and enhance the neutral and judgment free operation of the DNS, pointing out that the NTIA requirement is limited to the neutral and judgment free administration of the technical DNS and IANA functions.
Good point, I am ok with that change.
6. The ALAC believes that the AoC commitment to consumer trust should be in the ICANN Commitments and Core Values rather than in the AoC reviews provisions of the Bylaws.
Section 3 of the AoC describes what the document (the AoC) accomplishes: it affirms key commitments by DOC and ICANN, including commitments to promote competition, consumer trust, and consumer choice in the DNS marketplace. The context for promoting consumer trust is found exclusively in Section 9.3, which describes the reviews that must be undertaken in connection with the expansion of the top level domain space. This issue was debated extensively within the CCWG. A general commitment to promoting consumer trust threatens massive scope creep IMHO.
AG: I am afraid that we read Section 3 differently. The references to, for instance, the public interest and international participation are wider in scope than the particular reviews (although the review do address aspects of these). We (ALAC/At-Large) recently had an interaction with a senior compliance officer where it was claimed that consumer trust was not a significant concern (my wording), despite it being mentioned in the department's mission statement. That misunderstanding is in the process of being resolved, but it has made us particularly sensitive to the issue. Is there a harm in referencing it in the Bylaws, as was done in an earlier draft of the CCWG Proposal? Alan
J. Beckwith Burr Neustar, Inc. / Deputy General Counsel & Chief Privacy Offic 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 (5)
-
Alan Greenberg -
Burr, Becky -
Dr Eberhard W Lisse -
Mueller, Milton L -
Nigel Roberts