Do we really need a Contracting Co.?
Dear Greg, In your response to Holly you mentioned something that might be worth exploring further regarding the need of a new Contracting Co. : they (BPC: the parameters and numbers people) have existing organizations that are not ICANN that can be used for that oversight function. Names does not have that. Two questions then come to mind: 1) IETF has a MoU with ICANN, but unless I am mistaken (and I can very well be), it is not incorporated. I don't remember if the NRO has a similar arrangement, but I do not think it is incorporated either. Doesn't this open the possibility of arrangements without having to create a Contract Co., with all the recursive accountability and jurisdiction concerns we discussed? 2) The absence of an independent structure for names (potentially including distinction between ccTLDs and gTLDs) is indeed a clear difference between the names group and the two others. The gNSO however is the policy forum for gTLDs and all gTLDs are represented there. Would anything prevent the gNSO Council on its own (ie: without validation from the ICANN Board) to have a MoU with he IANA operator? Some specific role (to be determined) could be given to the Registry constituency in that decision-making process, given their high stake in the functioning of the IANA. On the cc side, it is true that the ccNSO does not encompass all ccTLD operators. Still, the ccNSO and the GAC have jointly developed the "Framework of Interpretation" for ccTLD delegation-redelegation and once finally approved, it will apply to all ccTLDs in the context of the IANA function. So, in the absence of an external exhaustive collective of all ccTLDs, isn't the ccNSO de facto acting as the policy structure for ccs in what regards the IANA functions? Why couldn't it then as well be making a MoU with the IANA operator, without involvement of the ICANN Board? The "contracting" architecture would thus be based on a *simple set of four MoUs*, without the need of a new Contracting Co. Upon signature of these four arrangements, NTIA would just let the current contract expire, without having to formally transition its responsibilities to a new entity. Each of these MoUs would contain common clauses regarding the renewal or rescinding of these arrangements (regular intervals, compulsory RFPs or not, etc... as discussed) and an ad hoc procedure put in place for choosing the contractor. Such a procedure could include the setting up of an ad hoc group (cf. the notion of a PRT) at the regular renewal intervals or upon situation of crisis, with appropriate triggers and decision-making rules. I wonder if this approach would not alleviate the need for creating a new structure and build upon the existing structures within ICANN, without conferring the contracting role to ICANN the organization (which I agree makes little sense). I noted with interest the response by the IETF and its clear message that the current architecture is OK with them. I am a bit worried if the proposals from the names group were to require a complex new architecture that would be very different from the one envisaged on the parameters and numbers sides, making reconciliation of the proposals a bit harder. I hope this helps explore practical options. Please tell me if this is not workable and why a shell company would be a better (or necessary) solution. Maybe there is something I am missing here. Best Bertrand "*Le plus beau métier des hommes, c'est d'unir les hommes*", Antoine de Saint Exupéry ("*There is no greater mission for humans than uniting humans*")BERTRAND DE LA CHAPELLEInternet & Jurisdiction Project | Directoremail bdelachapelle@internetjurisdiction.netemail bdelachapelle@gmail.comtwitter @IJurisdiction <https://twitter.com/IJurisdiction> | @bdelachapelle <https://twitter.com/bdelachapelle>mobile +33 (0)6 11 88 33 32 www.internetjurisdiction.net[image: A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS]
Hi, On 01-Dec-14 12:54, Bertrand de La Chapelle wrote:
1) IETF has a MoU with ICANN, but unless I am mistaken (and I can very well be), it is not incorporated. I don't remember if the NRO has a similar arrangement, but I do not think it is incorporated either. Doesn't this open the possibility of arrangements without having to create a Contract Co., with all the recursive accountability and jurisdiction concerns we discussed?
I do not see Company Co. as having recursive accountabilty issues as it reports to the PRT and is only an administror as indicated analogously in BCP101. Which shows such arrangements are possible. But if we do accept the notion that ICANN does not hold the function in perpetuity, and I don't such a iCANN forever proposal could reach consensus, then there has to be someone to hold that contract in 'trust' for for the Internet community. In the IETF situation, as BCP 101 indicated, all contracts are actually held by ISOC in trust for the Internet community. Maybe we can ask ISOC to hold the contract for us as well instead and avoid the need for the Contract Co. Personally I would trust ISOC to stand up ICANN and they have shown over the years that they know how to do only that which the IETF, or in our case the PRT, instructs them to do in a bottom up way. I am still fine with creating our own contracting holding entity, but I am also fine with asking ISOC to serve as that entity,hence avoiding the creation of a new corporate entity. So, no we don't need a Contracting Co, though we do need someone to hold the contract in 'trust' for the community. On another topic, it concerns me that our draft document seems to have buried the notion of the periodic RFP. RFP is listed on page 30, but Annex 3 seems to avoid mention at all. and even in section 3, there is no notion of a periodic RFC, just the fact that there can be one. I believe that without a peridoic RFP for the IANA contract there can be no accountability for the IANA function at ICANN or anywhere else for that matter - and this is not something that can be remedied by the CCSG Accountability. The IETF and the RIRs can walk away from ICANN if they are ever unhappy. The Names community needs the ability to move the IANA contract elsewhere as well. Whether the contract is held in 'trust' for us by ISOC or Company Co. matters less to me that it be held externally. avri
On another topic, it concerns me that our draft document seems to have buried the notion of the periodic >RFP. RFP is listed on page 30, but Annex 3 seems to avoid mention at all. and even in section 3, there is no >notion of a periodic RFC, just the fact that there can be one. I believe that without a peridoic RFP for the >IANA contract there can be no accountability for the IANA function at ICANN or anywhere else for that >matter - and this is not something that can be remedied by the CCSG Accountability. The IETF and the RIRs >can walk away from ICANN if they are ever unhappy. The Names community needs the ability to move the >IANA contract elsewhere as well. Whether the contract is held in 'trust' for us by ISOC or Company Co. >matters less to me that it be held externally.
avri
That concerns me, too. We had extensive discussion of the periodicity issue and seem to agree on a contract period of around 5 years. This needs to be incorporated into the draft. Milton L. Mueller Laura J. and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/mueller/Home.html
As we continue in this contracting route, i think we should remember 2 things: - ICANN is home for gTLD and because it was handled by contract in the past does not mean it should continue that way so i would expect this process to think of how it solidifies on the mechanisms within ICANN instead of always making the organisation's goals circle around contracting terms - ICANN has built a highly diverse multi-stakeholder environment and we should leverage on that by providing mechanisms that will energise it. Cheers! On Mon, Dec 1, 2014 at 4:20 PM, Avri Doria <avri@acm.org> wrote:
Hi,
On 01-Dec-14 12:54, Bertrand de La Chapelle wrote:
1) IETF has a MoU with ICANN, but unless I am mistaken (and I can very well be), it is not incorporated. I don't remember if the NRO has a similar arrangement, but I do not think it is incorporated either. Doesn't this open the possibility of arrangements without having to create a Contract Co., with all the recursive accountability and jurisdiction concerns we discussed?
I do not see Company Co. as having recursive accountabilty issues as it reports to the PRT and is only an administror as indicated analogously in BCP101. Which shows such arrangements are possible.
But if we do accept the notion that ICANN does not hold the function in perpetuity, and I don't such a iCANN forever proposal could reach consensus, then there has to be someone to hold that contract in 'trust' for for the Internet community.
In the IETF situation, as BCP 101 indicated, all contracts are actually held by ISOC in trust for the Internet community. Maybe we can ask ISOC to hold the contract for us as well instead and avoid the need for the Contract Co. Personally I would trust ISOC to stand up ICANN and they have shown over the years that they know how to do only that which the IETF, or in our case the PRT, instructs them to do in a bottom up way. I am still fine with creating our own contracting holding entity, but I am also fine with asking ISOC to serve as that entity,hence avoiding the creation of a new corporate entity. So, no we don't need a Contracting Co, though we do need someone to hold the contract in 'trust' for the community.
On another topic, it concerns me that our draft document seems to have buried the notion of the periodic RFP. RFP is listed on page 30, but Annex 3 seems to avoid mention at all. and even in section 3, there is no notion of a periodic RFC, just the fact that there can be one. I believe that without a peridoic RFP for the IANA contract there can be no accountability for the IANA function at ICANN or anywhere else for that matter - and this is not something that can be remedied by the CCSG Accountability. The IETF and the RIRs can walk away from ICANN if they are ever unhappy. The Names community needs the ability to move the IANA contract elsewhere as well. Whether the contract is held in 'trust' for us by ISOC or Company Co. matters less to me that it be held externally.
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* The key to understanding is humility - my view !
On 01-Dec-14 16:40, Seun Ojedeji wrote:
- ICANN has built a highly diverse multi-stakeholder environment and we should leverage on that by providing mechanisms that will energise it.
Indeed the PRT does that. The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. Thus there needs to be an external entity that the ICANN stakeholder environment we have created can directly affect without threat of capture by ICANN Corporate. That is the primary Capture Entity we need to concern ourselves with: ICANN Corporate. avri
Avri, I want to clarify. You wrote: *The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. * The avenue I am exploring is to empower the ccNSO and the gNSO *as such* with the capacity to sign an MoU with the chosen IANA contractor (and to choose it). In that approach, the ICANN Board would NOT be in the loop. Does that clarify and answer your concern? B. On Mon, Dec 1, 2014 at 4:57 PM, Avri Doria <avri@acm.org> wrote:
On 01-Dec-14 16:40, Seun Ojedeji wrote:
- ICANN has built a highly diverse multi-stakeholder environment and we should leverage on that by providing mechanisms that will energise it.
Indeed the PRT does that.
The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. Thus there needs to be an external entity that the ICANN stakeholder environment we have created can directly affect without threat of capture by ICANN Corporate.
That is the primary Capture Entity we need to concern ourselves with: ICANN Corporate.
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
hi, GNSO and ccNSO have no ability to sign a contract with anyone, they are just parts of ICANN and ICANn cannot sign a contract with itself. The contracting authority for IANA must be outside ICANN and it must be an entity that is capable of signing a contract. avri On 01-Dec-14 17:13, Bertrand de La Chapelle wrote:
Avri,
I want to clarify. You wrote:
/The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. /
The avenue I am exploring is to empower the ccNSO and the gNSO _as such_ with the capacity to sign an MoU with the chosen IANA contractor (and to choose it). In that approach, the ICANN Board would NOT be in the loop.
Does that clarify and answer your concern?
B.
On Mon, Dec 1, 2014 at 4:57 PM, Avri Doria <avri@acm.org <mailto:avri@acm.org>> wrote:
On 01-Dec-14 16:40, Seun Ojedeji wrote:
- ICANN has built a highly diverse multi-stakeholder environment and we should leverage on that by providing mechanisms that will energise it.
Indeed the PRT does that.
The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. Thus there needs to be an external entity that the ICANN stakeholder environment we have created can directly affect without threat of capture by ICANN Corporate.
That is the primary Capture Entity we need to concern ourselves with: ICANN Corporate.
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
Sorry to insist, my legal background may be lacking, but: 1) I am sure that the W3C, while not incorporated, signed its "host agreements" with three universities. So, contracting may not be linked so indisputably with formal incorporation. 2) the ccNSO and the gNSO are structures within ICANN for the purpose of policy-making and in that regard under the ICANN Board for validation. However, they do perform other useful functions for the respective communities without having to refer to the ICANN Board. as a matter of fact, a lot in the ccNSO relates to internal issues. Nothing would prevent in my view conferring them with a specific role regarding the IANA function, that would not be subject to the Board validation, should we collectively decide to follow that route. This would seem to me much more bottom up and distributed that creating a single new, different structure for the sole purpose of contracting, with the concerns that some people have. Aren't we too unimaginatively trying to mimic the currant arrangement? After all, we have not discussed in detail (or I missed it) the composition of the PRT, but my guess is that it would leverage such existing structures. So why not explore doing it also for the agreement part? B. "*Le plus beau métier des hommes, c'est d'unir les hommes*", Antoine de Saint Exupéry ("*There is no greater mission for humans than uniting humans*")BERTRAND DE LA CHAPELLEInternet & Jurisdiction Project | Directoremail bdelachapelle@internetjurisdiction.netemail bdelachapelle@gmail.comtwitter @IJurisdiction <https://twitter.com/IJurisdiction> | @bdelachapelle <https://twitter.com/bdelachapelle>mobile +33 (0)6 11 88 33 32 www.internetjurisdiction.net[image: A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS] On Mon, Dec 1, 2014 at 5:19 PM, Avri Doria <avri@acm.org> wrote:
hi,
GNSO and ccNSO have no ability to sign a contract with anyone, they are just parts of ICANN and ICANn cannot sign a contract with itself.
The contracting authority for IANA must be outside ICANN and it must be an entity that is capable of signing a contract.
avri
On 01-Dec-14 17:13, Bertrand de La Chapelle wrote:
Avri,
I want to clarify. You wrote:
*The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. *
The avenue I am exploring is to empower the ccNSO and the gNSO *as such* with the capacity to sign an MoU with the chosen IANA contractor (and to choose it). In that approach, the ICANN Board would NOT be in the loop.
Does that clarify and answer your concern?
B.
On Mon, Dec 1, 2014 at 4:57 PM, Avri Doria <avri@acm.org> wrote:
On 01-Dec-14 16:40, Seun Ojedeji wrote:
- ICANN has built a highly diverse multi-stakeholder environment and we should leverage on that by providing mechanisms that will energise it.
Indeed the PRT does that.
The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. Thus there needs to be an external entity that the ICANN stakeholder environment we have created can directly affect without threat of capture by ICANN Corporate.
That is the primary Capture Entity we need to concern ourselves with: ICANN Corporate.
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Bertrand, Every time someone has tried to demonstrate that there is an MoU that is signed by a body that is not a legal entity, the result has been the same. Voila -- a legal entity pops up on the agreement. Avri pointed out that ISOC (which is a legal entity) signed the IETF MoU The ICANN/NRO MoU was signed by each of the RIRs (which are legal entities). The W3C website says "In administrative terms: W3C is administered via a joint agreement among these "Host Institutions": MIT <http://www.csail.mit.edu/>, ERCIM <http://www.ercim.org/>, Keio University <http://www.keio.ac.jp/>, and Beihang University <http://ev.buaa.edu.cn/>." Elsewhere in the site it says "W3C is a contractual entity arising from agreements between the "Host institutions" and W3C Members." W3C Member Agreements are signed by the host universities and by the member. So again, all the contracts are between legal entities. The Joint Agreement doesn't appear to be publicly available (at least not easily findable), but I am quite confident that my conclusions are correct -- where the W3C appears to enter into a contract, it is actually the host institutions on the agreement. In sum, contracting is linked indisputably with some sort of legal entity (of which corporations is a major type, along with partnerships -- both in various types -- and other entities recognized as legal entities). Greg On Mon, Dec 1, 2014 at 11:40 AM, Bertrand de La Chapelle < bdelachapelle@gmail.com> wrote:
Sorry to insist, my legal background may be lacking, but:
1) I am sure that the W3C, while not incorporated, signed its "host agreements" with three universities. So, contracting may not be linked so indisputably with formal incorporation.
2) the ccNSO and the gNSO are structures within ICANN for the purpose of policy-making and in that regard under the ICANN Board for validation. However, they do perform other useful functions for the respective communities without having to refer to the ICANN Board. as a matter of fact, a lot in the ccNSO relates to internal issues.
Nothing would prevent in my view conferring them with a specific role regarding the IANA function, that would not be subject to the Board validation, should we collectively decide to follow that route.
This would seem to me much more bottom up and distributed that creating a single new, different structure for the sole purpose of contracting, with the concerns that some people have. Aren't we too unimaginatively trying to mimic the currant arrangement?
After all, we have not discussed in detail (or I missed it) the composition of the PRT, but my guess is that it would leverage such existing structures. So why not explore doing it also for the agreement part?
B.
"*Le plus beau métier des hommes, c'est d'unir les hommes*", Antoine de Saint Exupéry ("*There is no greater mission for humans than uniting humans*")BERTRAND DE LA CHAPELLEInternet & Jurisdiction Project | Directoremail bdelachapelle@internetjurisdiction.netemail bdelachapelle@gmail.com twitter @IJurisdiction <https://twitter.com/IJurisdiction> | @bdelachapelle <https://twitter.com/bdelachapelle>mobile +33 (0)6 11 88 33 32www.internetjurisdiction.net[image: A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS]
On Mon, Dec 1, 2014 at 5:19 PM, Avri Doria <avri@acm.org> wrote:
hi,
GNSO and ccNSO have no ability to sign a contract with anyone, they are just parts of ICANN and ICANn cannot sign a contract with itself.
The contracting authority for IANA must be outside ICANN and it must be an entity that is capable of signing a contract.
avri
On 01-Dec-14 17:13, Bertrand de La Chapelle wrote:
Avri,
I want to clarify. You wrote:
*The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. *
The avenue I am exploring is to empower the ccNSO and the gNSO *as such* with the capacity to sign an MoU with the chosen IANA contractor (and to choose it). In that approach, the ICANN Board would NOT be in the loop.
Does that clarify and answer your concern?
B.
On Mon, Dec 1, 2014 at 4:57 PM, Avri Doria <avri@acm.org> wrote:
On 01-Dec-14 16:40, Seun Ojedeji wrote:
- ICANN has built a highly diverse multi-stakeholder environment and we should leverage on that by providing mechanisms that will energise it.
Indeed the PRT does that.
The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. Thus there needs to be an external entity that the ICANN stakeholder environment we have created can directly affect without threat of capture by ICANN Corporate.
That is the primary Capture Entity we need to concern ourselves with: ICANN Corporate.
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- *Gregory S. Shatan **ï* *Abelman Frayne & Schwab* *666 Third Avenue **ï** New York, NY 10017-5621* *Direct* 212-885-9253 *| **Main* 212-949-9022 *Fax* 212-949-9190 *|* *Cell *917-816-6428 *gsshatan@lawabel.com <gsshatan@lawabel.com>* *ICANN-related: gregshatanipc@gmail.com <gregshatanipc@gmail.com> * *www.lawabel.com <http://www.lawabel.com/>*
In addition to Avri’s points, the GNSO and ccNSO are policy management bodies and my understanding that there is strong agreement that policy and IANA functions should be separated. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Avri Doria Sent: Monday, December 01, 2014 11:19 AM To: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? hi, GNSO and ccNSO have no ability to sign a contract with anyone, they are just parts of ICANN and ICANn cannot sign a contract with itself. The contracting authority for IANA must be outside ICANN and it must be an entity that is capable of signing a contract. avri On 01-Dec-14 17:13, Bertrand de La Chapelle wrote: Avri, I want to clarify. You wrote: The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. The avenue I am exploring is to empower the ccNSO and the gNSO as such with the capacity to sign an MoU with the chosen IANA contractor (and to choose it). In that approach, the ICANN Board would NOT be in the loop. Does that clarify and answer your concern? B. On Mon, Dec 1, 2014 at 4:57 PM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 01-Dec-14 16:40, Seun Ojedeji wrote: - ICANN has built a highly diverse multi-stakeholder environment and we should leverage on that by providing mechanisms that will energise it. Indeed the PRT does that. The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. Thus there needs to be an external entity that the ICANN stakeholder environment we have created can directly affect without threat of capture by ICANN Corporate. That is the primary Capture Entity we need to concern ourselves with: ICANN Corporate. avri _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
Chuck, On that specific point, what needs to be separated is the performance of the policy functions and the performance of the IANA functions. We are all in agreement about that, that's true. But ii is the allocation of the mandate that is under discussion here, not the actual performance of the function. It would then be compatible with the separation in my view. After all, if the IETF (or ISOC) contracts for its part, and the NRO (or its members) contract for its own, this would be the same situation, as they both are the policy bodies. In any case, at some point, the allocation of the mandate will have to come from the interested parties, and by definition, the interested parties are also the ones who, separately, develop the policies. Attributing the mandate is therefore not a confusion of functions. What I am trying to explore is the maximum similarity between what is expected to come from the parameters and numbers communities with what this group might suggest for names. Of course names have problems of their own, and one of them is that the structures that deal with the policies (certainly for gTLDs) are within ICANN and not formally incorporated, whereas they are outside of ICANN and to a certain extend incorporated for the two others. B. "*Le plus beau métier des hommes, c'est d'unir les hommes*", Antoine de Saint Exupéry ("*There is no greater mission for humans than uniting humans*")BERTRAND DE LA CHAPELLEInternet & Jurisdiction Project | Directoremail bdelachapelle@internetjurisdiction.netemail bdelachapelle@gmail.comtwitter @IJurisdiction <https://twitter.com/IJurisdiction> | @bdelachapelle <https://twitter.com/bdelachapelle>mobile +33 (0)6 11 88 33 32 www.internetjurisdiction.net[image: A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS] On Mon, Dec 1, 2014 at 7:25 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
In addition to Avri’s points, the GNSO and ccNSO are policy management bodies and my understanding that there is strong agreement that policy and IANA functions should be separated.
Chuck
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Avri Doria *Sent:* Monday, December 01, 2014 11:19 AM *To:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
hi,
GNSO and ccNSO have no ability to sign a contract with anyone, they are just parts of ICANN and ICANn cannot sign a contract with itself.
The contracting authority for IANA must be outside ICANN and it must be an entity that is capable of signing a contract.
avri
On 01-Dec-14 17:13, Bertrand de La Chapelle wrote:
Avri,
I want to clarify. You wrote:
*The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. *
The avenue I am exploring is to empower the ccNSO and the gNSO *as such* with the capacity to sign an MoU with the chosen IANA contractor (and to choose it). In that approach, the ICANN Board would NOT be in the loop.
Does that clarify and answer your concern?
B.
On Mon, Dec 1, 2014 at 4:57 PM, Avri Doria <avri@acm.org> wrote:
On 01-Dec-14 16:40, Seun Ojedeji wrote:
- ICANN has built a highly diverse multi-stakeholder environment and we should leverage on that by providing mechanisms that will energise it.
Indeed the PRT does that.
The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. Thus there needs to be an external entity that the ICANN stakeholder environment we have created can directly affect without threat of capture by ICANN Corporate.
That is the primary Capture Entity we need to concern ourselves with: ICANN Corporate.
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Bertrand: Following parallelism to its logical conclusion would lead us to a "take IANA out of ICANN so that ICANN can contract like ISOC/IETF and NRO/RIRs for IANA services" solution. This was on the table and gained no traction due to all the difficulties in taking IANA out of ICANN, etc., etc. Greg On Mon, Dec 1, 2014 at 2:38 PM, Bertrand de La Chapelle < bdelachapelle@gmail.com> wrote:
Chuck,
On that specific point, what needs to be separated is the performance of the policy functions and the performance of the IANA functions. We are all in agreement about that, that's true.
But ii is the allocation of the mandate that is under discussion here, not the actual performance of the function. It would then be compatible with the separation in my view. After all, if the IETF (or ISOC) contracts for its part, and the NRO (or its members) contract for its own, this would be the same situation, as they both are the policy bodies.
In any case, at some point, the allocation of the mandate will have to come from the interested parties, and by definition, the interested parties are also the ones who, separately, develop the policies.
Attributing the mandate is therefore not a confusion of functions.
What I am trying to explore is the maximum similarity between what is expected to come from the parameters and numbers communities with what this group might suggest for names. Of course names have problems of their own, and one of them is that the structures that deal with the policies (certainly for gTLDs) are within ICANN and not formally incorporated, whereas they are outside of ICANN and to a certain extend incorporated for the two others.
B.
"*Le plus beau métier des hommes, c'est d'unir les hommes*", Antoine de Saint Exupéry ("*There is no greater mission for humans than uniting humans*")BERTRAND DE LA CHAPELLEInternet & Jurisdiction Project | Directoremail bdelachapelle@internetjurisdiction.netemail bdelachapelle@gmail.com twitter @IJurisdiction <https://twitter.com/IJurisdiction> | @bdelachapelle <https://twitter.com/bdelachapelle>mobile +33 (0)6 11 88 33 32www.internetjurisdiction.net[image: A GLOBAL MULTI-STAKEHOLDER DIALOGUE PROCESS]
On Mon, Dec 1, 2014 at 7:25 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
In addition to Avri’s points, the GNSO and ccNSO are policy management bodies and my understanding that there is strong agreement that policy and IANA functions should be separated.
Chuck
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Avri Doria *Sent:* Monday, December 01, 2014 11:19 AM *To:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
hi,
GNSO and ccNSO have no ability to sign a contract with anyone, they are just parts of ICANN and ICANn cannot sign a contract with itself.
The contracting authority for IANA must be outside ICANN and it must be an entity that is capable of signing a contract.
avri
On 01-Dec-14 17:13, Bertrand de La Chapelle wrote:
Avri,
I want to clarify. You wrote:
*The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. *
The avenue I am exploring is to empower the ccNSO and the gNSO *as such* with the capacity to sign an MoU with the chosen IANA contractor (and to choose it). In that approach, the ICANN Board would NOT be in the loop.
Does that clarify and answer your concern?
B.
On Mon, Dec 1, 2014 at 4:57 PM, Avri Doria <avri@acm.org> wrote:
On 01-Dec-14 16:40, Seun Ojedeji wrote:
- ICANN has built a highly diverse multi-stakeholder environment and we should leverage on that by providing mechanisms that will energise it.
Indeed the PRT does that.
The problem is that if the ICANN internal multistakeholder community says A, the ICANN Board can say Not A, and there is NOTHING we can do about it. Thus there needs to be an external entity that the ICANN stakeholder environment we have created can directly affect without threat of capture by ICANN Corporate.
That is the primary Capture Entity we need to concern ourselves with: ICANN Corporate.
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- *Gregory S. Shatan **ï* *Abelman Frayne & Schwab* *666 Third Avenue **ï** New York, NY 10017-5621* *Direct* 212-885-9253 *| **Main* 212-949-9022 *Fax* 212-949-9190 *|* *Cell *917-816-6428 *gsshatan@lawabel.com <gsshatan@lawabel.com>* *ICANN-related: gregshatanipc@gmail.com <gregshatanipc@gmail.com> * *www.lawabel.com <http://www.lawabel.com/>*
sent from Google nexus 4 kindly excuse brevity and typos. On 1 Dec 2014 16:57, "Avri Doria" <avri@acm.org> wrote:
On 01-Dec-14 16:40, Seun Ojedeji wrote:
- ICANN has built a highly diverse multi-stakeholder environment and we
should leverage on that by providing mechanisms that will energise it.
Indeed the PRT does that.
The problem is that if the ICANN internal multistakeholder community says
A, the ICANN Board can say Not A, and there is NOTHING we can do about it. Thus there needs to be an external entity that the ICANN stakeholder environment we have created can directly affect without threat of capture by ICANN Corporate.
Honestly at this point I think something is not clear here. Can you confirm if this PRT is within ICANN or not because your message above is implying outside. The second question is, what are the "IANA operation" related issues that ICANN board could say no to? and how is the accountability track fixing/addressing that.
That is the primary Capture Entity we need to concern ourselves with: ICANN Corporate.
Well it will become 2 if the PRT is introduced and the PRT could be more complicated. I will also note that the possibility of ICANN corporate being captured is becoming less probable. So we should not in fear of the improbable create another monster structure that will comes back to hunt us all. Cheers!
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
On 01-Dec-14 20:25, Seun Ojedeji wrote:
Honestly at this point I think something is not clear here. Can you confirm if this PRT is within ICANN or not because your message above is implying outside. The second question is, what are the "IANA operation" related issues that ICANN board could say no to? and how is the accountability track fixing/addressing that.
a few of us were talking about this evening over Eurodig drings and over dinner. I have come to believe the the MRT is really the ICANN Community as we know + others, but instead of sending its decisions to the Board for blessing it sends its decision to the Contract Co. for execution. It has been obvious for a while that the ICANN community and ICANN Corporate are separate. So I have no trouble imagining that for the purposes of the MRT we organize what is essentially the stakeholders invovled in the ICANN community + some other parts of the Internet community into the MRT. Pretty much exactly just as we done with the ICG. As for who pays for the whole sructure we are talking about, it should be the IANA contractor, ICANN at this point, as part of its zero cost support of the IANA function. The only thing that seems like it may require outside funding is the RFP/rebid process. And for that we just follow the example we have been taught by ICANN Corporate and Contract Co. charges the applicants for the IANA contract an application fee sufficient for the process to be, as they say, cost neutral. So it is not within ICANN, but it is formed by the ICANN Community with others. avri
Avri, On Mon, Dec 1, 2014 at 4:15 PM, Avri Doria <avri@acm.org> wrote:
On 01-Dec-14 20:25, Seun Ojedeji wrote:
Honestly at this point I think something is not clear here. Can you confirm if this PRT is within ICANN or not because your message above is implying outside. The second question is, what are the "IANA operation" related issues that ICANN board could say no to? and how is the accountability track fixing/addressing that.
a few of us were talking about this evening over Eurodig drings and over dinner.
I have come to believe the the MRT is really the ICANN Community as we know + others, but instead of sending its decisions to the Board for blessing it sends its decision to the Contract Co. for execution.
That is certainly the intent, in my mind. And I expect the details to be consistent with that general statement, as they get filled in.
It has been obvious for a while that the ICANN community and ICANN Corporate are separate. So I have no trouble imagining that for the purposes of the MRT we organize what is essentially the stakeholders invovled in the ICANN community + some other parts of the Internet community into the MRT. Pretty much exactly just as we done with the ICG.
As for who pays for the whole sructure we are talking about, it should be the IANA contractor, ICANN at this point, as part of its zero cost support of the IANA function. The only thing that seems like it may require outside funding is the RFP/rebid process. And for that we just follow the example we have been taught by ICANN Corporate and Contract Co. charges the applicants for the IANA contract an application fee sufficient for the process to be, as they say, cost neutral.
I think these are excellent suggestions.
So it is not within ICANN, but it is formed by the ICANN Community with others.
That is how I hope for it to be. But we'll need to make our way there, in terms of details. Greg
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- *Gregory S. Shatan **ï* *Abelman Frayne & Schwab* *666 Third Avenue **ï** New York, NY 10017-5621* *Direct* 212-885-9253 *| **Main* 212-949-9022 *Fax* 212-949-9190 *|* *Cell *917-816-6428 *gsshatan@lawabel.com <gsshatan@lawabel.com>* *ICANN-related: gregshatanipc@gmail.com <gregshatanipc@gmail.com> * *www.lawabel.com <http://www.lawabel.com/>*
Greg, Avri and Everyone On the Contract Co issue, we did manage to get its size down to that of a shelf company, a skeleton for the MRT. But somewhere in there, discussion has raised the issue of suing/being sued- in which case Contract Co will have to have an existence larger than that or a mere shelf company. So I think we’re back a few paces, although heading in the right direction. But the larger the Contract Co, the more urgent the ‘Who Pays’ question becomes. If we don’t want Contract Co to have a life (and significant funds) of its own, but largely be a vehicle for the MRT, then we need to think through why we need more than a shelf company/if we need more than a shelf company. Bertrand’s stress tests and discussion about MoUs and SLAs have been very useful in that regard. And a reminder - enforceability is often through legal processes. But it can often be through processes of regulators as well. So again, we need to think beyond legal paradigms for possible answers. Holly On 2 Dec 2014, at 10:43 am, Greg Shatan <gregshatanipc@gmail.com> wrote:
Avri,
On Mon, Dec 1, 2014 at 4:15 PM, Avri Doria <avri@acm.org> wrote:
On 01-Dec-14 20:25, Seun Ojedeji wrote:
Honestly at this point I think something is not clear here. Can you confirm if this PRT is within ICANN or not because your message above is implying outside. The second question is, what are the "IANA operation" related issues that ICANN board could say no to? and how is the accountability track fixing/addressing that.
a few of us were talking about this evening over Eurodig drings and over dinner.
I have come to believe the the MRT is really the ICANN Community as we know + others, but instead of sending its decisions to the Board for blessing it sends its decision to the Contract Co. for execution.
That is certainly the intent, in my mind. And I expect the details to be consistent with that general statement, as they get filled in.
It has been obvious for a while that the ICANN community and ICANN Corporate are separate. So I have no trouble imagining that for the purposes of the MRT we organize what is essentially the stakeholders invovled in the ICANN community + some other parts of the Internet community into the MRT. Pretty much exactly just as we done with the ICG.
As for who pays for the whole sructure we are talking about, it should be the IANA contractor, ICANN at this point, as part of its zero cost support of the IANA function. The only thing that seems like it may require outside funding is the RFP/rebid process. And for that we just follow the example we have been taught by ICANN Corporate and Contract Co. charges the applicants for the IANA contract an application fee sufficient for the process to be, as they say, cost neutral.
I think these are excellent suggestions.
So it is not within ICANN, but it is formed by the ICANN Community with others.
That is how I hope for it to be. But we'll need to make our way there, in terms of details.
Greg
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- Gregory S. Shatan ï Abelman Frayne & Schwab 666 Third Avenue ï New York, NY 10017-5621 Direct 212-885-9253 | Main 212-949-9022 Fax 212-949-9190 | Cell 917-816-6428 gsshatan@lawabel.com ICANN-related: gregshatanipc@gmail.com www.lawabel.com _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
sent from Google nexus 4 kindly excuse brevity and typos. On 1 Dec 2014 22:18, "Avri Doria" <avri@acm.org> wrote:
On 01-Dec-14 20:25, Seun Ojedeji wrote:
Honestly at this point I think something is not clear here. Can you
confirm if this PRT is within ICANN or not because your message above is implying outside. The second question is, what are the "IANA operation" related issues that ICANN board could say no to? and how is the accountability track fixing/addressing that.
a few of us were talking about this evening over Eurodig drings and over
dinner.
I have come to believe the the MRT is really the ICANN Community as we
know + others, but instead of sending its decisions to the Board for blessing it sends its decision to the Contract Co. for execution.
Okay it's MRT not PRT then... this is noted!
It has been obvious for a while that the ICANN community and ICANN Corporate are separate. So I have no trouble imagining that for the purposes of the MRT we organize what is essentially the stakeholders invovled in the ICANN community + some other parts of the Internet community into the MRT. Pretty much exactly just as we done with the ICG.
There is definitely a non-negligible flaw and replication in what you are proposing Avri, and I like the fact that you are using ICG as an example. ICG is a group that can only survive for a short while...It's not a sustainable group. ICG at the moment has not done their main task.. so you wait and see how that process will look like. I think this is like creating a new ICANN community and it's a replication of effort, wastage of customer money and further creation of cabals (which is already existing in the young ICG). I also don't understand the view that ICANN community and corporate are separate. What does that mean? and how is ICANN community different from a typical RIR community.
As for who pays for the whole sructure we are talking about, it should be the IANA contractor, ICANN at this point, as part of its zero cost support of the IANA function.
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
The only thing that seems like it may require outside funding is the RFP/rebid process. And for that we just follow the example we have been taught by ICANN Corporate and Contract Co. charges the applicants for the IANA contract an application fee sufficient for the process to be, as they say, cost neutral.
Oh so the MRT will even be the team to do an RFP process. Well I think this cwg is just trying to drag us to a more complicated future which I am definitely opposed to.
So it is not within ICANN, but it is formed by the ICANN Community with others.
Maybe when we see the details of the formation and the charter of the team we will better appreciate what we are proposing. On a lighter note, it's interesting that we will want to put all these structure just because of a "what if". It's also interesting that we are not thinking of the possibility of the young MRT being subject to capture. Cheers!
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. I do not understand how anyone can see ICANN community and ICANN Corporate as being the same entity, though there are points of contact. There is a strict division between the two, especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
On a lighter note, it's interesting that we will want to put all these structure just because of a "what if". It's also interesting that we are not thinking of the possibility of the young MRT being subject to capture.
I think people are beginning to see the ghost of possible capture everywhere and it is becoming another paralyzing function that is being used much the way an overblown fear of gaming is being used, as a counter to any idea. I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against. avri
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* The key to understanding is humility - my view !
Seun, Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... . Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 02-Dec-14 07:16, Seun Ojedeji wrote: I also don't understand the view that ICANN community and corporate are separate. The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg). especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff. Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;). What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making. The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process. How does the contractor paying hurt the consumers? I think it will be safer to answer this with another question, where will the contractor get the money to pay from? I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against. Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards avri _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng Mobile: +2348035233535 alt email: <http://goog_1872880453> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view !
Hi Chuck, Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes: - Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away - While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame. That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG. Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Seun,
Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... .
Chuck
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Seun Ojedeji *Sent:* Tuesday, December 02, 2014 3:57 AM *To:* Avri Doria *Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive.
Regards
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
--
------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: * *http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> **Mobile: +2348035233535 <%2B2348035233535>* *alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* The key to understanding is humility - my view !
ICANN needs to be accountable for (1) developing and implementing policy through the multistakeholder process in accordance with its bylaws and (2) actually performing the technical IANA functions in a competent way. Proper independent review and redress works for the first, and sometimes for the second, but it doesn’t guarantee technical competence. The ability to move IANA functions out of ICANN is most important in the situation where ICANN is incompetent and can’t or won’t fix the problem. I continue to think that we are making this process much more difficult by trying to deal with broader accountability issues in this track. J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz From: Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> Date: Tuesday, December 2, 2014 at 3:21 PM To: Chuck Gomes <cgomes@verisign.com<mailto:cgomes@verisign.com>> Cc: "cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>" <cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Hi Chuck, Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes: - Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away - While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame. That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG. Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: Seun, Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-en<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_correspondence_gomes-2Dto-2Dchehade-2D2013-2D08-2D30-2Den&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=cMZ8gYzJLCkFvsRC1iv_MEWJLGT-Wkx3fcwNLEJIBXI&e=> . Chuck From:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org>] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 02-Dec-14 07:16, Seun Ojedeji wrote: I also don't understand the view that ICANN community and corporate are separate. The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg). especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff. Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;). What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making. The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process. How does the contractor paying hurt the consumers? I think it will be safer to answer this with another question, where will the contractor get the money to pay from? I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against. Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards avri _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_cwg-2Dstewardship&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=sQ5Q6jLzCAgZPNkjr5Fpp0xVbabUlzidfZRR4jHnQeo&e=> -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fuoye.edu.ng&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=GHypwKbVmWeLVjSpjEmVlxxM9E8J5DSj-Vnys1YnxXc&e=> Mobile: +2348035233535<tel:%2B2348035233535> alt email:<https://urldefense.proofpoint.com/v2/url?u=http-3A__goog-5F1872880453&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=2LTakbB8A0yGGGdo1cmpMO9RrV32tCpqIGIs4HS8lVI&e=>seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fuoye.edu.ng&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=GHypwKbVmWeLVjSpjEmVlxxM9E8J5DSj-Vnys1YnxXc&e=> Mobile: +2348035233535 alt email:<https://urldefense.proofpoint.com/v2/url?u=http-3A__goog-5F1872880453&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=2LTakbB8A0yGGGdo1cmpMO9RrV32tCpqIGIs4HS8lVI&e=>seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view !
On Tue, Dec 2, 2014 at 9:43 PM, Burr, Becky <Becky.Burr@neustar.biz> wrote:
ICANN needs to be accountable for (1) developing and implementing policy through the multistakeholder process in accordance with its bylaws and (2) actually performing the technical IANA functions in a competent way. Proper independent review and redress works for the first, and sometimes for the second, but it doesn’t guarantee technical competence. The ability to move IANA functions out of ICANN is most important in the situation where ICANN is incompetent and can’t or won’t fix the problem. I continue to think that we are making this process much more difficult by trying to deal with broader accountability issues in this track.
Hi Burr,
I am not sure the current cwg proposal is just looking at technical competence of the operator. The way i have come to understand it; is that all the proposed structures are being justified on the basis that ICANN is not responsive to item 1 and 2 stated above and so they need to be held accountable by the proposed new structure (especially with the MRT/PRT) so in that case there won't be any basis to insist on any other accountability mechanism to be put in place within ICANN Cheers!
J. Beckwith Burr
*Neustar, Inc. /* Deputy General Counsel and Chief Privacy Officer
1775 Pennsylvania Avenue NW, Washington, DC 20006
Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz / www.neustar.biz
From: Seun Ojedeji <seun.ojedeji@gmail.com> Date: Tuesday, December 2, 2014 at 3:21 PM To: Chuck Gomes <cgomes@verisign.com> Cc: "cwg-stewardship@icann.org" <cwg-stewardship@icann.org>
Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Hi Chuck,
Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes:
- Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away
- While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN
I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame.
That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG.
Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Seun,
Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> .
Chuck
*From:*cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Seun Ojedeji *Sent:* Tuesday, December 02, 2014 3:57 AM *To:* Avri Doria *Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive.
Regards
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...>
--
------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: * *http://www.fuoye.edu.ng <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fuoye.edu.ng&d=AwMFa...> **Mobile: +2348035233535 <%2B2348035233535>* *alt email: <https://urldefense.proofpoint.com/v2/url?u=http-3A__goog-5F1872880453&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=2LTakbB8A0yGGGdo1cmpMO9RrV32tCpqIGIs4HS8lVI&e=>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
-- ------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fuoye.edu.ng&d=AwMFa...> Mobile: +2348035233535 **alt email: <https://urldefense.proofpoint.com/v2/url?u=http-3A__goog-5F1872880453&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=2LTakbB8A0yGGGdo1cmpMO9RrV32tCpqIGIs4HS8lVI&e=>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* The key to understanding is humility - my view !
Seun, I think your understanding of what is going on may be correct – but that is IMHO a mistake. b J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz From: Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> Date: Tuesday, December 2, 2014 at 4:13 PM To: Becky Burr <becky.burr@neustar.biz<mailto:becky.burr@neustar.biz>> Cc: Chuck Gomes <cgomes@verisign.com<mailto:cgomes@verisign.com>>, "cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>" <cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? On Tue, Dec 2, 2014 at 9:43 PM, Burr, Becky <Becky.Burr@neustar.biz<mailto:Becky.Burr@neustar.biz>> wrote: ICANN needs to be accountable for (1) developing and implementing policy through the multistakeholder process in accordance with its bylaws and (2) actually performing the technical IANA functions in a competent way. Proper independent review and redress works for the first, and sometimes for the second, but it doesn’t guarantee technical competence. The ability to move IANA functions out of ICANN is most important in the situation where ICANN is incompetent and can’t or won’t fix the problem. I continue to think that we are making this process much more difficult by trying to deal with broader accountability issues in this track. Hi Burr, I am not sure the current cwg proposal is just looking at technical competence of the operator. The way i have come to understand it; is that all the proposed structures are being justified on the basis that ICANN is not responsive to item 1 and 2 stated above and so they need to be held accountable by the proposed new structure (especially with the MRT/PRT) so in that case there won't be any basis to insist on any other accountability mechanism to be put in place within ICANN Cheers! J. Beckwith Burr Neustar, Inc. / Deputy General Counsel and Chief Privacy Officer 1775 Pennsylvania Avenue NW, Washington, DC 20006 Office: + 1.202.533.2932<tel:%2B%201.202.533.2932> Mobile: +1.202.352.6367<tel:%2B1.202.352.6367> / becky.burr@neustar.biz<mailto:becky.burr@neustar.biz> / www.neustar.biz<http://www.neustar.biz> From: Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> Date: Tuesday, December 2, 2014 at 3:21 PM To: Chuck Gomes <cgomes@verisign.com<mailto:cgomes@verisign.com>> Cc: "cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>" <cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org>> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Hi Chuck, Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes: - Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away - While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame. That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG. Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: Seun, Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-en<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources_correspondence_gomes-2Dto-2Dchehade-2D2013-2D08-2D30-2Den&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=cMZ8gYzJLCkFvsRC1iv_MEWJLGT-Wkx3fcwNLEJIBXI&e=> . Chuck From:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org>] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 02-Dec-14 07:16, Seun Ojedeji wrote: I also don't understand the view that ICANN community and corporate are separate. The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg). especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff. Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;). What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making. The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process. How does the contractor paying hurt the consumers? I think it will be safer to answer this with another question, where will the contractor get the money to pay from? I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against. Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards avri _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship<https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_listinfo_cwg-2Dstewardship&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=sQ5Q6jLzCAgZPNkjr5Fpp0xVbabUlzidfZRR4jHnQeo&e=> -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fuoye.edu.ng&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=GHypwKbVmWeLVjSpjEmVlxxM9E8J5DSj-Vnys1YnxXc&e=> Mobile: +2348035233535<tel:%2B2348035233535> alt email:<https://urldefense.proofpoint.com/v2/url?u=http-3A__goog-5F1872880453&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=2LTakbB8A0yGGGdo1cmpMO9RrV32tCpqIGIs4HS8lVI&e=>seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fuoye.edu.ng&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=GHypwKbVmWeLVjSpjEmVlxxM9E8J5DSj-Vnys1YnxXc&e=> Mobile: +2348035233535 alt email:<https://urldefense.proofpoint.com/v2/url?u=http-3A__goog-5F1872880453&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=2LTakbB8A0yGGGdo1cmpMO9RrV32tCpqIGIs4HS8lVI&e=>seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fuoye.edu.ng&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=kppIzBhNPLqAor3nlRYOjeJHpuI7CGxyVC-XHXYeuiQ&s=wSwiZ299TmLbq0OHk5QBIBp0wojAMkiqtFhUgRV0-ZA&e=> Mobile: +2348035233535 alt email:<https://urldefense.proofpoint.com/v2/url?u=http-3A__goog-5F1872880453&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=kppIzBhNPLqAor3nlRYOjeJHpuI7CGxyVC-XHXYeuiQ&s=tdnONzfen2Ikcsk6pjh6oAMGKeh85nq2TMDCvvdSjAA&e=>seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view !
On Tue, Dec 2, 2014 at 10:20 PM, Burr, Becky <Becky.Burr@neustar.biz> wrote:
Seun,
I think your understanding of what is going on may be correct – but that is IMHO a mistake.
...and just for the record i share the same view as you've stated above. Cheers!
b
J. Beckwith Burr
*Neustar, Inc. /* Deputy General Counsel and Chief Privacy Officer
1775 Pennsylvania Avenue NW, Washington, DC 20006
Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz / www.neustar.biz
From: Seun Ojedeji <seun.ojedeji@gmail.com> Date: Tuesday, December 2, 2014 at 4:13 PM To: Becky Burr <becky.burr@neustar.biz> Cc: Chuck Gomes <cgomes@verisign.com>, "cwg-stewardship@icann.org" < cwg-stewardship@icann.org>
Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 9:43 PM, Burr, Becky <Becky.Burr@neustar.biz> wrote:
ICANN needs to be accountable for (1) developing and implementing policy through the multistakeholder process in accordance with its bylaws and (2) actually performing the technical IANA functions in a competent way. Proper independent review and redress works for the first, and sometimes for the second, but it doesn’t guarantee technical competence. The ability to move IANA functions out of ICANN is most important in the situation where ICANN is incompetent and can’t or won’t fix the problem. I continue to think that we are making this process much more difficult by trying to deal with broader accountability issues in this track.
Hi Burr,
I am not sure the current cwg proposal is just looking at technical competence of the operator. The way i have come to understand it; is that all the proposed structures are being justified on the basis that ICANN is not responsive to item 1 and 2 stated above and so they need to be held accountable by the proposed new structure (especially with the MRT/PRT) so in that case there won't be any basis to insist on any other accountability mechanism to be put in place within ICANN
Cheers!
J. Beckwith Burr
*Neustar, Inc. /* Deputy General Counsel and Chief Privacy Officer
1775 Pennsylvania Avenue NW, Washington, DC 20006
Office: + 1.202.533.2932 Mobile: +1.202.352.6367 / becky.burr@neustar.biz / www.neustar.biz
From: Seun Ojedeji <seun.ojedeji@gmail.com> Date: Tuesday, December 2, 2014 at 3:21 PM To: Chuck Gomes <cgomes@verisign.com> Cc: "cwg-stewardship@icann.org" <cwg-stewardship@icann.org>
Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Hi Chuck,
Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes:
- Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away
- While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN
I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame.
That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG.
Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Seun,
Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.icann.org_resources...> .
Chuck
*From:*cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Seun Ojedeji *Sent:* Tuesday, December 02, 2014 3:57 AM *To:* Avri Doria *Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive.
Regards
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship <https://urldefense.proofpoint.com/v2/url?u=https-3A__mm.icann.org_mailman_li...>
--
------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: * *http://www.fuoye.edu.ng <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fuoye.edu.ng&d=AwMFa...> **Mobile: +2348035233535 <%2B2348035233535>* *alt email: <https://urldefense.proofpoint.com/v2/url?u=http-3A__goog-5F1872880453&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=2LTakbB8A0yGGGdo1cmpMO9RrV32tCpqIGIs4HS8lVI&e=>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
-- ------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fuoye.edu.ng&d=AwMFa...> Mobile: +2348035233535 **alt email: <https://urldefense.proofpoint.com/v2/url?u=http-3A__goog-5F1872880453&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=sniwjEyqX-KlwYBcEHMa2VMvj54--czhko-gznTZNyI&s=2LTakbB8A0yGGGdo1cmpMO9RrV32tCpqIGIs4HS8lVI&e=>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
-- ------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.fuoye.edu.ng&d=AwMFa...> Mobile: +2348035233535 **alt email: <https://urldefense.proofpoint.com/v2/url?u=http-3A__goog-5F1872880453&d=AwMFaQ&c=MOptNlVtIETeDALC_lULrw&r=62cJFOifzm6X_GRlaq8Mo8TjDmrxdYahOP8WDDkMr4k&m=kppIzBhNPLqAor3nlRYOjeJHpuI7CGxyVC-XHXYeuiQ&s=tdnONzfen2Ikcsk6pjh6oAMGKeh85nq2TMDCvvdSjAA&e=>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* The key to understanding is humility - my view !
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Burr, Becky ICANN needs to be accountable for (1) developing and implementing policy through the multistakeholder process in accordance with its bylaws and (2) actually performing the technical IANA functions in a competent way. Proper independent review and redress works for the first, and sometimes for the second, but it doesn't guarantee technical competence. The ability to move IANA functions out of ICANN is most important in the situation where ICANN is incompetent and can't or won't fix the problem. I continue to think that we are making this process much more difficult by trying to deal with broader accountability issues in this track. Becky: I don't think this group is trying to solve all the broader accountability issues, nor should it. We are just recognizing that there is some risk that a technically competent but rogue ICANN could abuse its control of IANA to circumvent legitimate policy processes. I think that risk is small to begin with, but I believe that we can reduce it to the vanishing point by making it the basis for moving the IANA functions out of ICANN. There is nothing terribly difficult about that, because the same separability capability that responds to an incompetent IANA would be used in the case of a rogue IANA. Milton L Mueller Laura J. and L. Douglas Meredith Professor Syracuse University School of Information Studies http://faculty.ischool.syr.edu/mueller/ Internet Governance Project http://internetgovernance.org<http://internetgovernance.org/>
Seun You have summed up the issue wonderfully. Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced. Holly On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
Hi Chuck,
Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes:
- Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away
- While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN
I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame.
That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG.
Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com> wrote: Seun,
Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... .
Chuck
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive.
Regards
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
--
------------------------------------------------------------------------
Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng Mobile: +2348035233535 alt email: seun.ojedeji@fuoye.edu.ng
The key to understanding is humility - my view !
-- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng Mobile: +2348035233535 alt email: seun.ojedeji@fuoye.edu.ng
The key to understanding is humility - my view !
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Holly and all: I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second. -ed On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net> wrote:
Seun
You have summed up the issue wonderfully.
Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced.
Holly
On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
Hi Chuck,
Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes:
- Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away
- While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN
I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame.
That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG.
Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Seun,
Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... .
Chuck
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Seun Ojedeji *Sent:* Tuesday, December 02, 2014 3:57 AM *To:* Avri Doria *Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive.
Regards
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
--
------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: * *http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/> **Mobile: +2348035233535 <%2B2348035233535>* *alt email: <http://goog_1872880453/>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
-- ------------------------------------------------------------------------
*Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/> Mobile: +2348035233535**alt email: <http://goog_1872880453/>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- *NOTICE:* This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
Hi all, I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN’s bylaws specifically aimed on the IANA function. If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT. As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would. Best, Maarten From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Eduardo Diaz Sent: woensdag 3 december 2014 1:19 To: Holly Raiche Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Holly and all: I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second. -ed On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Seun You have summed up the issue wonderfully. Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced. Holly On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> wrote: Hi Chuck, Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes: - Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away - While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame. That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG. Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: Seun, Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... . Chuck From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org>] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 02-Dec-14 07:16, Seun Ojedeji wrote: I also don't understand the view that ICANN community and corporate are separate. The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg). especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff. Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;). What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making. The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process. How does the contractor paying hurt the consumers? I think it will be safer to answer this with another question, where will the contractor get the money to pay from? I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against. Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards avri _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535<tel:%2B2348035233535> alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535 alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- NOTICE: This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
On Thu, Dec 4, 2014 at 2:55 PM, Maarten Simon <maarten.simon@sidn.nl> wrote:
Hi all,
I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN’s bylaws specifically aimed on the IANA function.
Makes sense for an option
As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would.
Actually we have no clue yet on the legal aspect of current proposal either. It would be good to present all these options as we seek legal perspective around all of them. Thanks Cheers!
Best,
Maarten
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Eduardo Diaz *Sent:* woensdag 3 december 2014 1:19 *To:* Holly Raiche
*Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Holly and all:
I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second.
-ed
On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net> wrote:
Seun
You have summed up the issue wonderfully.
Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced.
Holly
On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
Hi Chuck,
Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes:
- Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away
- While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN
I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame.
That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG.
Regards
On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Seun,
Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... .
Chuck
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Seun Ojedeji *Sent:* Tuesday, December 02, 2014 3:57 AM *To:* Avri Doria *Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive.
Regards
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
--
------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: * *http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/> **Mobile: +2348035233535 <%2B2348035233535>* *alt email: <http://goog_1872880453/>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
--
------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: * *http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/> **Mobile: +2348035233535 <%2B2348035233535>* *alt email: <http://goog_1872880453/>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
--
*NOTICE:* This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* The key to understanding is humility - my view !
Maarten Simon writes:
I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN's bylaws specifically aimed on the IANA function.
Similar suggestions were made at the F2F meeting in Frankfurt. jaap
Maarten I think this proposal is not viable. In effect, it makes the ICANN board the contracting authority for the IANA functions, thus eliminating the separability principle. You try to patch this problem in a kludgy way by saying that the MRT can “order the ICANN board” to give up the IANA function, which in effect makes the MRT a continuing legal entity, and paves the way for an ongoing power struggle should the MRT and board come into conflict over the future control of IANA. This is yet another example of people tying themselves in knots and putting at risk the separability principle in order to avoid the simple expedient of creating a Contract Co. But why do you fear the Contract Co so much? No clear rationale for avoiding this has ever been put forward. If you want to be able to move the IANA functions contract it is much cleaner and simpler to have an independent, separate contract co. --MM From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Maarten Simon Sent: Thursday, December 4, 2014 8:56 AM To: 'Eduardo Diaz'; Holly Raiche Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Hi all, I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN’s bylaws specifically aimed on the IANA function. If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT. As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would. Best, Maarten From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Eduardo Diaz Sent: woensdag 3 december 2014 1:19 To: Holly Raiche Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Holly and all: I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second. -ed On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Seun You have summed up the issue wonderfully. Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced. Holly On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> wrote: Hi Chuck, Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes: - Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away - While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame. That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG. Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: Seun, Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... . Chuck From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org>] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 02-Dec-14 07:16, Seun Ojedeji wrote: I also don't understand the view that ICANN community and corporate are separate. The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg). especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff. Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;). What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making. The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process. How does the contractor paying hurt the consumers? I think it will be safer to answer this with another question, where will the contractor get the money to pay from? I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against. Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards avri _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535<tel:%2B2348035233535> alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535 alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- NOTICE: This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
On Thu, Dec 4, 2014 at 3:51 PM, Milton L Mueller <mueller@syr.edu> wrote:
I think this proposal is not viable. In effect, it makes the ICANN board the
This is yet another example of people tying themselves in knots and putting at risk the separability principle in order to avoid the simple expedient of creating a Contract Co. But why do you fear the Contract Co so much? No clear rationale for avoiding this has ever been put forward.
Just for the record, i don't fear a contract co but i fear a contract co whose details i am yet to see and review. I also fear a contract co which will be receiving directive from set of people referred to as multi-stakeholder (the set of people which i am yet to also see the details of its formation). So we cannot afford not to have details of Contract co and MRT to determine what the future will look like
If you want to be able to move the IANA functions contract it is much cleaner and simpler to have an independent, separate contract co.
Again its pains me that all we are concerned about is moving IANA, can we just be concerned about building an organisation for once. Thinking all over my head and wondering what's the extreme scenario where it would be concluded that ICANN is no longer worthy of IANA? I am thinking of that and imagining that a lot and i mean a lot would have gone wrong to warrant that conclusion. If we then move IANA to another operator, the other question is what's the policy source going to be? ICANN's? so what have we solved if the policy source is still ICANN? and if policy source is not ICANN, it will then mean building something like ICANN again....so again what have we solved!!! Unfortunately some on this list will have retired by then and may not be able to witness all this neither will they have strength to fix things then. Cheers!
--MM
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Maarten Simon *Sent:* Thursday, December 4, 2014 8:56 AM *To:* 'Eduardo Diaz'; Holly Raiche
*Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Hi all,
I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN’s bylaws specifically aimed on the IANA function.
If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT.
As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would.
Best,
Maarten
*From:* cwg-stewardship-bounces@icann.org [ mailto:cwg-stewardship-bounces@icann.org <cwg-stewardship-bounces@icann.org>] *On Behalf Of *Eduardo Diaz *Sent:* woensdag 3 december 2014 1:19 *To:* Holly Raiche *Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Holly and all:
I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second.
-ed
On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net> wrote:
Seun
You have summed up the issue wonderfully.
Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced.
Holly
On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
Hi Chuck,
Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes:
- Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away
- While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN
I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame.
That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG.
Regards
On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Seun,
Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... .
Chuck
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *Seun Ojedeji *Sent:* Tuesday, December 02, 2014 3:57 AM *To:* Avri Doria *Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive.
Regards
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
--
------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: * *http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/> **Mobile: +2348035233535 <%2B2348035233535>* *alt email: <http://goog_1872880453/>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
--
------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: * *http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/> **Mobile: +2348035233535 <%2B2348035233535>* *alt email: <http://goog_1872880453/>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
--
*NOTICE:* This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------ *Seun Ojedeji,Federal University Oye-Ekitiweb: http://www.fuoye.edu.ng <http://www.fuoye.edu.ng> Mobile: +2348035233535**alt email: <http://goog_1872880453>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>* The key to understanding is humility - my view !
Milton: There is no clear rationale for avoiding moving forward with the Contact Co. at the moment because there are still many questions to be answered regarding the composition, structure, jurisdiction, etc. for such organization. Many questions have been arised as to what this organization is going to look like. About the separability principle: According to the latest principle draft document, this principle states: 1. *"a. Seperability: any proposal must ensure the ability:* 1. *i. To separate the IANA functions from the current operator if warranted and in line with agreed processes; and* 2. *ii. To convene a process for selecting a new operator.* * Seperability should persist through any future transfer of the IANA functions. (Note the current NTIA contract requires such separation.)"* I am not a person with legal background but I can presume (until proven wrong) that it is possible to create internal mechanisms within ICANN to satisfy this principle without risk.Strawman proposal 1 <https://community.icann.org/download/attachments/49352017/StrawmanMatrix%20%...> presented such a case but it did not have to much traction in Frankfurt at that moment. -ed On Thu Dec 04 2014 at 10:52:05 AM Milton L Mueller <mueller@syr.edu> wrote:
Maarten
I think this proposal is not viable. In effect, it makes the ICANN board the contracting authority for the IANA functions, thus eliminating the separability principle. You try to patch this problem in a kludgy way by saying that the MRT can “order the ICANN board” to give up the IANA function, which in effect makes the MRT a continuing legal entity, and paves the way for an ongoing power struggle should the MRT and board come into conflict over the future control of IANA.
This is yet another example of people tying themselves in knots and putting at risk the separability principle in order to avoid the simple expedient of creating a Contract Co. But why do you fear the Contract Co so much? No clear rationale for avoiding this has ever been put forward.
If you want to be able to move the IANA functions contract it is much cleaner and simpler to have an independent, separate contract co.
--MM
*From:* cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship- bounces@icann.org] *On Behalf Of *Maarten Simon *Sent:* Thursday, December 4, 2014 8:56 AM *To:* 'Eduardo Diaz'; Holly Raiche
*Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Hi all,
I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN’s bylaws specifically aimed on the IANA function.
If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT.
As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would.
Best,
Maarten
*From:* cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship- bounces@icann.org <cwg-stewardship-bounces@icann.org>] *On Behalf Of *Eduardo Diaz *Sent:* woensdag 3 december 2014 1:19 *To:* Holly Raiche *Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Holly and all:
I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second.
-ed
On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net> wrote:
Seun
You have summed up the issue wonderfully.
Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced.
Holly
On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
Hi Chuck,
Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes:
- Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away
- While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN
I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame.
That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG.
Regards
On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com> wrote:
Seun,
Please see the letter I sent to Fadi in 2013: https://www.icann.org/ resources/correspondence/gomes-to-chehade-2013-08-30-en .
Chuck
*From:* cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship- bounces@icann.org] *On Behalf Of *Seun Ojedeji *Sent:* Tuesday, December 02, 2014 3:57 AM *To:* Avri Doria *Cc:* cwg-stewardship@icann.org *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive.
Regards
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
--
------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: * *http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/> **Mobile: +2348035233535 <%2B2348035233535>* *alt email: <http://goog_1872880453/>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
--
------------------------------------------------------------------------
*Seun Ojedeji, Federal University Oye-Ekiti web: * *http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/> **Mobile: +2348035233535 <%2B2348035233535>* *alt email: <http://goog_1872880453/>seun.ojedeji@fuoye.edu.ng <seun.ojedeji@fuoye.edu.ng>*
The key to understanding is humility - my view !
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
--
*NOTICE:* This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
Milton, Viable or legal possible are two different things and yes I find the separability principle less central than the stability one and am therefore willing to accept something like the ‘kludgy patch’ as an escape from ICANN as a worst case scenario and as the last resort safeguard if all others fail. I further wonder if there will be a different ‘ongoing power struggle between the MRT and the board’ in the contract co situation or in the internal ICANN situation. That all depends on the whole set of the arrangements and in the end on the acceptance of the authority of the MRT by the board. Best, Maarten From: Milton L Mueller [mailto:mueller@syr.edu] Sent: donderdag 4 december 2014 15:52 To: Maarten Simon; 'Eduardo Diaz'; 'Holly Raiche' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] Do we really need a Contracting Co.? Maarten I think this proposal is not viable. In effect, it makes the ICANN board the contracting authority for the IANA functions, thus eliminating the separability principle. You try to patch this problem in a kludgy way by saying that the MRT can “order the ICANN board” to give up the IANA function, which in effect makes the MRT a continuing legal entity, and paves the way for an ongoing power struggle should the MRT and board come into conflict over the future control of IANA. This is yet another example of people tying themselves in knots and putting at risk the separability principle in order to avoid the simple expedient of creating a Contract Co. But why do you fear the Contract Co so much? No clear rationale for avoiding this has ever been put forward. If you want to be able to move the IANA functions contract it is much cleaner and simpler to have an independent, separate contract co. --MM From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Maarten Simon Sent: Thursday, December 4, 2014 8:56 AM To: 'Eduardo Diaz'; Holly Raiche Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Hi all, I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN’s bylaws specifically aimed on the IANA function. If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT. As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would. Best, Maarten From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Eduardo Diaz Sent: woensdag 3 december 2014 1:19 To: Holly Raiche Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Holly and all: I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second. -ed On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Seun You have summed up the issue wonderfully. Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced. Holly On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> wrote: Hi Chuck, Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes: - Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away - While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame. That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG. Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: Seun, Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... . Chuck From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org>] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 02-Dec-14 07:16, Seun Ojedeji wrote: I also don't understand the view that ICANN community and corporate are separate. The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg). especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff. Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;). What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making. The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process. How does the contractor paying hurt the consumers? I think it will be safer to answer this with another question, where will the contractor get the money to pay from? I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against. Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards avri _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535<tel:%2B2348035233535> alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535 alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- NOTICE: This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
It seems to me that ‘on the acceptance of the authority of the MRT by the board’ would need to be built into the ICANN Bylaws with very stiff requirements for amending that clause. Chuck From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Maarten Simon Sent: Thursday, December 04, 2014 11:08 AM To: 'Milton L Mueller' Cc: 'cwg-stewardship@icann.org' Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Milton, Viable or legal possible are two different things and yes I find the separability principle less central than the stability one and am therefore willing to accept something like the ‘kludgy patch’ as an escape from ICANN as a worst case scenario and as the last resort safeguard if all others fail. I further wonder if there will be a different ‘ongoing power struggle between the MRT and the board’ in the contract co situation or in the internal ICANN situation. That all depends on the whole set of the arrangements and in the end on the acceptance of the authority of the MRT by the board. Best, Maarten From: Milton L Mueller [mailto:mueller@syr.edu]<mailto:[mailto:mueller@syr.edu]> Sent: donderdag 4 december 2014 15:52 To: Maarten Simon; 'Eduardo Diaz'; 'Holly Raiche' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] Do we really need a Contracting Co.? Maarten I think this proposal is not viable. In effect, it makes the ICANN board the contracting authority for the IANA functions, thus eliminating the separability principle. You try to patch this problem in a kludgy way by saying that the MRT can “order the ICANN board” to give up the IANA function, which in effect makes the MRT a continuing legal entity, and paves the way for an ongoing power struggle should the MRT and board come into conflict over the future control of IANA. This is yet another example of people tying themselves in knots and putting at risk the separability principle in order to avoid the simple expedient of creating a Contract Co. But why do you fear the Contract Co so much? No clear rationale for avoiding this has ever been put forward. If you want to be able to move the IANA functions contract it is much cleaner and simpler to have an independent, separate contract co. --MM From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Maarten Simon Sent: Thursday, December 4, 2014 8:56 AM To: 'Eduardo Diaz'; Holly Raiche Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Hi all, I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN’s bylaws specifically aimed on the IANA function. If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT. As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would. Best, Maarten From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Eduardo Diaz Sent: woensdag 3 december 2014 1:19 To: Holly Raiche Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Holly and all: I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second. -ed On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Seun You have summed up the issue wonderfully. Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced. Holly On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> wrote: Hi Chuck, Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes: - Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away - While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame. That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG. Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: Seun, Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... . Chuck From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org>] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 02-Dec-14 07:16, Seun Ojedeji wrote: I also don't understand the view that ICANN community and corporate are separate. The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg). especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff. Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;). What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making. The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process. How does the contractor paying hurt the consumers? I think it will be safer to answer this with another question, where will the contractor get the money to pay from? I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against. Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards avri _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535<tel:%2B2348035233535> alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535 alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- NOTICE: This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
Hi, Maarten In your scenario, the MRT has to tell the board to do something that it probably won’t want to do. In the CWG scenario, the MRT tells the Contracting Co, which has no interest, what to do. Clearly, your approach produces an internal power struggle. If you say the MRT can unambiguously order the board to spin off IANA according to the bylaws, you run into California law problems; but even if you didn’t, you are simply making the MRT an authority no different from the Contract Co. How is that an improvement over the CWG plan? --MM From: Maarten Simon [mailto:maarten.simon@sidn.nl] Sent: Thursday, December 4, 2014 11:08 AM To: Milton L Mueller Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] Do we really need a Contracting Co.? Milton, Viable or legal possible are two different things and yes I find the separability principle less central than the stability one and am therefore willing to accept something like the ‘kludgy patch’ as an escape from ICANN as a worst case scenario and as the last resort safeguard if all others fail. I further wonder if there will be a different ‘ongoing power struggle between the MRT and the board’ in the contract co situation or in the internal ICANN situation. That all depends on the whole set of the arrangements and in the end on the acceptance of the authority of the MRT by the board. Best, Maarten From: Milton L Mueller [mailto:mueller@syr.edu] Sent: donderdag 4 december 2014 15:52 To: Maarten Simon; 'Eduardo Diaz'; 'Holly Raiche' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] Do we really need a Contracting Co.? Maarten I think this proposal is not viable. In effect, it makes the ICANN board the contracting authority for the IANA functions, thus eliminating the separability principle. You try to patch this problem in a kludgy way by saying that the MRT can “order the ICANN board” to give up the IANA function, which in effect makes the MRT a continuing legal entity, and paves the way for an ongoing power struggle should the MRT and board come into conflict over the future control of IANA. This is yet another example of people tying themselves in knots and putting at risk the separability principle in order to avoid the simple expedient of creating a Contract Co. But why do you fear the Contract Co so much? No clear rationale for avoiding this has ever been put forward. If you want to be able to move the IANA functions contract it is much cleaner and simpler to have an independent, separate contract co. --MM From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Maarten Simon Sent: Thursday, December 4, 2014 8:56 AM To: 'Eduardo Diaz'; Holly Raiche Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Hi all, I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN’s bylaws specifically aimed on the IANA function. If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT. As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would. Best, Maarten From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Eduardo Diaz Sent: woensdag 3 december 2014 1:19 To: Holly Raiche Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Holly and all: I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second. -ed On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Seun You have summed up the issue wonderfully. Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced. Holly On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> wrote: Hi Chuck, Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes: - Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away - While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame. That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG. Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: Seun, Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... . Chuck From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org>] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 02-Dec-14 07:16, Seun Ojedeji wrote: I also don't understand the view that ICANN community and corporate are separate. The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg). especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff. Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;). What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making. The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process. How does the contractor paying hurt the consumers? I think it will be safer to answer this with another question, where will the contractor get the money to pay from? I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against. Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards avri _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535<tel:%2B2348035233535> alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535 alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- NOTICE: This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
Hi Milton, It is not that I see the Contracting co as a non option but I try to get a better understanding of what it will actually brings us. A clear one is that it probably makes a future separation mainly from a legal perspective a bit easier. But as stated by others, I think separation will in whatever form always only be a nuclear option. (I do not like the idea of a recurring 3 or whatever number of years RFP cycle as it will likely cause a lot of political turmoil each time which I think will not be supportive to the stability of the function that the solution is supposed to warrant). I am further still not sure if I am with you on the power struggle. As I see it now the MRT will be in both options a sort of the ICANN community minus the board and staff. In that case I do not see much of a difference, and certainly do not expect to see that in practice, between the MRT telling the Contracting co to tell the ICANN board what the ICANN board has to do or the MRT telling the ICANN board directly what to do. In the first instance the ICANN board has to follow orders because of a contract. In the second the ICANN board has to follow orders because of its bylaws. The improvement of the plan would be that we do not need to discuss all kind of legal (capture, liability) and political (jurisdiction) technicalities around an entity we do not need. (as far as the bylaws option is technically legally possible under Californian law). Best, Maarten From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Milton L Mueller Sent: donderdag 4 december 2014 18:54 To: cwg-stewardship@icann.org Subject: [CWG-Stewardship] FW: Do we really need a Contracting Co.? Hi, Maarten In your scenario, the MRT has to tell the board to do something that it probably won’t want to do. In the CWG scenario, the MRT tells the Contracting Co, which has no interest, what to do. Clearly, your approach produces an internal power struggle. If you say the MRT can unambiguously order the board to spin off IANA according to the bylaws, you run into California law problems; but even if you didn’t, you are simply making the MRT an authority no different from the Contract Co. How is that an improvement over the CWG plan? --MM From: Maarten Simon [mailto:maarten.simon@sidn.nl] Sent: Thursday, December 4, 2014 11:08 AM To: Milton L Mueller Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] Do we really need a Contracting Co.? Milton, Viable or legal possible are two different things and yes I find the separability principle less central than the stability one and am therefore willing to accept something like the ‘kludgy patch’ as an escape from ICANN as a worst case scenario and as the last resort safeguard if all others fail. I further wonder if there will be a different ‘ongoing power struggle between the MRT and the board’ in the contract co situation or in the internal ICANN situation. That all depends on the whole set of the arrangements and in the end on the acceptance of the authority of the MRT by the board. Best, Maarten From: Milton L Mueller [mailto:mueller@syr.edu] Sent: donderdag 4 december 2014 15:52 To: Maarten Simon; 'Eduardo Diaz'; 'Holly Raiche' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] Do we really need a Contracting Co.? Maarten I think this proposal is not viable. In effect, it makes the ICANN board the contracting authority for the IANA functions, thus eliminating the separability principle. You try to patch this problem in a kludgy way by saying that the MRT can “order the ICANN board” to give up the IANA function, which in effect makes the MRT a continuing legal entity, and paves the way for an ongoing power struggle should the MRT and board come into conflict over the future control of IANA. This is yet another example of people tying themselves in knots and putting at risk the separability principle in order to avoid the simple expedient of creating a Contract Co. But why do you fear the Contract Co so much? No clear rationale for avoiding this has ever been put forward. If you want to be able to move the IANA functions contract it is much cleaner and simpler to have an independent, separate contract co. --MM From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Maarten Simon Sent: Thursday, December 4, 2014 8:56 AM To: 'Eduardo Diaz'; Holly Raiche Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Hi all, I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN’s bylaws specifically aimed on the IANA function. If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT. As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would. Best, Maarten From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Eduardo Diaz Sent: woensdag 3 december 2014 1:19 To: Holly Raiche Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Holly and all: I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second. -ed On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Seun You have summed up the issue wonderfully. Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced. Holly On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com>> wrote: Hi Chuck, Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes: - Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away - While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame. That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG. Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: Seun, Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... . Chuck From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org>] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 02-Dec-14 07:16, Seun Ojedeji wrote: I also don't understand the view that ICANN community and corporate are separate. The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg). especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff. Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;). What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making. The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process. How does the contractor paying hurt the consumers? I think it will be safer to answer this with another question, where will the contractor get the money to pay from? I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against. Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards avri _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535<tel:%2B2348035233535> alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535 alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- NOTICE: This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
Hi The recurring RFP approach would not cause any more turmoil than we could have under the present contract construct. For example, a 5 year recurring RFP would be a longer contract period than the current NTIA-ICANN contract (which is 3 years, /with two two-year options to extend//that are entirely at the discretion of the USG /which one can argue do not provide the kind of contractual predictability we would want). Extensions, and whether they might be awarded or not, merely contribute to longer term uncertainty. W/r/t/ continuity and stability the operator, according to section C.7.3 of the current contract, is required to provide a "a plan in place for transitioning each of the IANA functions to ensure an orderly transition while maintaining continuity and security of operations" in the event that "the Government selects a successor contractor." Of course these safeguards should be kept to ensure continuity from one operator to another post RFP. A recurring 5 year RFP offers more certainty from a contracting perspective than what we have at the moment and, it could be argued, should provide equal stability and continuity _and_, importantly, greater accountability. Matthew On 12/5/2014 10:13 AM, Maarten Simon wrote:
Hi Milton,
It is not that I see the Contracting co as a non option but I try to get a better understanding of what it will actually brings us.
A clear one is that it probably makes a future separation mainly from a legal perspective a bit easier. But as stated by others, I think separation will in whatever form always only be a nuclear option. (I do not like the idea of a recurring 3 or whatever number of years RFP cycle as it will likely cause a lot of political turmoil each time which I think will not be supportive to the stability of the function that the solution is supposed to warrant).
I am further still not sure if I am with you on the power struggle. As I see it now the MRT will be in both options a sort of the ICANN community minus the board and staff. In that case I do not see much of a difference, and certainly do not expect to see that in practice, between the MRT telling the Contracting co to tell the ICANN board what the ICANN board has to do or the MRT telling the ICANN board directly what to do. In the first instance the ICANN board has to follow orders because of a contract. In the second the ICANN board has to follow orders because of its bylaws.
The improvement of the plan would be that we do not need to discuss all kind of legal (capture, liability) and political (jurisdiction) technicalities around an entity we do not need. (as far as the bylaws option is technically legally possible under Californian law).
Best,
Maarten
*From:*cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] *On Behalf Of *Milton L Mueller *Sent:* donderdag 4 december 2014 18:54 *To:* cwg-stewardship@icann.org *Subject:* [CWG-Stewardship] FW: Do we really need a Contracting Co.?
Hi, Maarten
In your scenario, the MRT has to tell the board to do something that it probably won't want to do.
In the CWG scenario, the MRT tells the Contracting Co, which has no interest, what to do.
Clearly, your approach produces an internal power struggle.
If you say the MRT can unambiguously order the board to spin off IANA according to the bylaws, you run into California law problems; but even if you didn't, you are simply making the MRT an authority no different from the Contract Co. How is that an improvement over the CWG plan?
--MM
*From:*Maarten Simon [mailto:maarten.simon@sidn.nl] *Sent:* Thursday, December 4, 2014 11:08 AM *To:* Milton L Mueller *Cc:* 'cwg-stewardship@icann.org' *Subject:* RE: [CWG-Stewardship] Do we really need a Contracting Co.?
Milton,
Viable or legal possible are two different things and yes I find the separability principle less central than the stability one and am therefore willing to accept something like the 'kludgy patch' as an escape from ICANN as a worst case scenario and as the last resort safeguard if all others fail.
I further wonder if there will be a different 'ongoing power struggle between the MRT and the board' in the contract co situation or in the internal ICANN situation. That all depends on the whole set of the arrangements and in the end on the acceptance of the authority of the MRT by the board.
Best,
Maarten
*From:*Milton L Mueller [mailto:mueller@syr.edu] *Sent:* donderdag 4 december 2014 15:52 *To:* Maarten Simon; 'Eduardo Diaz'; 'Holly Raiche' *Cc:* 'cwg-stewardship@icann.org' *Subject:* RE: [CWG-Stewardship] Do we really need a Contracting Co.?
Maarten
I think this proposal is not viable. In effect, it makes the ICANN board the contracting authority for the IANA functions, thus eliminating the separability principle. You try to patch this problem in a kludgy way by saying that the MRT can "order the ICANN board" to give up the IANA function, which in effect makes the MRT a continuing legal entity, and paves the way for an ongoing power struggle should the MRT and board come into conflict over the future control of IANA.
This is yet another example of people tying themselves in knots and putting at risk the separability principle in order to avoid the simple expedient of creating a Contract Co. But why do you fear the Contract Co so much? No clear rationale for avoiding this has ever been put forward.
If you want to be able to move the IANA functions contract it is much cleaner and simpler to have an independent, separate contract co.
--MM
*From:*cwg-stewardship-bounces@icann.org <mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] *On Behalf Of *Maarten Simon *Sent:* Thursday, December 4, 2014 8:56 AM *To:* 'Eduardo Diaz'; Holly Raiche *Cc:* cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Hi all,
I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN's bylaws specifically aimed on the IANA function.
If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT.
As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would.
Best,
Maarten
*From:*cwg-stewardship-bounces@icann.org <mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org] *On Behalf Of *Eduardo Diaz *Sent:* woensdag 3 december 2014 1:19 *To:* Holly Raiche *Cc:* cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Holly and all:
I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second.
-ed
On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net <mailto:h.raiche@internode.on.net>> wrote:
Seun
You have summed up the issue wonderfully.
Yes, we appear to be going down the second route. But there are still questions around that route. Alan's (and Olivier's and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced.
Holly
On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com <mailto:seun.ojedeji@gmail.com>> wrote:
Hi Chuck,
Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes:
- Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away
- While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN
I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame.
That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG.
Regards
On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com <mailto:cgomes@verisign.com>> wrote:
Seun,
Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... .
Chuck
*From:*cwg-stewardship-bounces@icann.org <mailto:cwg-stewardship-bounces@icann.org> [mailto:cwg-stewardship-bounces@icann.org <mailto:cwg-stewardship-bounces@icann.org>] *On Behalf Of *Seun Ojedeji *Sent:* Tuesday, December 02, 2014 3:57 AM *To:* Avri Doria *Cc:* cwg-stewardship@icann.org <mailto:cwg-stewardship@icann.org> *Subject:* Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org <mailto:avri@acm.org>> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive.
Regards
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
--
------------------------------------------------------------------------
/Seun Ojedeji, Federal University Oye-Ekiti web: //http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/> //Mobile: +2348035233535 <tel:%2B2348035233535>// //alt email:<http://goog_1872880453/>seun.ojedeji@fuoye.edu.ng <mailto:seun.ojedeji@fuoye.edu.ng>/
The key to understanding is humility - my view !
--
------------------------------------------------------------------------
/Seun Ojedeji, Federal University Oye-Ekiti web: //http://www.fuoye.edu.ng <http://www.fuoye.edu.ng/> //Mobile: +2348035233535// //alt email:<http://goog_1872880453/>seun.ojedeji@fuoye.edu.ng <mailto:seun.ojedeji@fuoye.edu.ng>/
The key to understanding is humility - my view !
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org <mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
--
*NOTICE:* This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately.
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- Matthew Shears Director - Global Internet Policy and Human Rights Center for Democracy & Technology (CDT) mshears@cdt.org + 44 771 247 2987
Thank you Maarten for asking questions that I am also puzzling over. I have always been a bit dubious with the idea that another entity (yes, legal or not) provided additional accountability. From where I sit, it would amount to more money, more people - with the overriding question of accountability of that body - to whom. I’m still of the view that the many good suggestions about additional structures within ICANN that are multi-stakeholder - along with must strengthened by-laws, could achieve almost the same thing. Holly On 5 Dec 2014, at 9:13 pm, Maarten Simon <maarten.simon@sidn.nl> wrote:
Hi Milton,
It is not that I see the Contracting co as a non option but I try to get a better understanding of what it will actually brings us.
A clear one is that it probably makes a future separation mainly from a legal perspective a bit easier. But as stated by others, I think separation will in whatever form always only be a nuclear option. (I do not like the idea of a recurring 3 or whatever number of years RFP cycle as it will likely cause a lot of political turmoil each time which I think will not be supportive to the stability of the function that the solution is supposed to warrant).
I am further still not sure if I am with you on the power struggle. As I see it now the MRT will be in both options a sort of the ICANN community minus the board and staff. In that case I do not see much of a difference, and certainly do not expect to see that in practice, between the MRT telling the Contracting co to tell the ICANN board what the ICANN board has to do or the MRT telling the ICANN board directly what to do. In the first instance the ICANN board has to follow orders because of a contract. In the second the ICANN board has to follow orders because of its bylaws.
The improvement of the plan would be that we do not need to discuss all kind of legal (capture, liability) and political (jurisdiction) technicalities around an entity we do not need. (as far as the bylaws option is technically legally possible under Californian law).
Best,
Maarten
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Milton L Mueller Sent: donderdag 4 december 2014 18:54 To: cwg-stewardship@icann.org Subject: [CWG-Stewardship] FW: Do we really need a Contracting Co.?
Hi, Maarten In your scenario, the MRT has to tell the board to do something that it probably won’t want to do. In the CWG scenario, the MRT tells the Contracting Co, which has no interest, what to do.
Clearly, your approach produces an internal power struggle.
If you say the MRT can unambiguously order the board to spin off IANA according to the bylaws, you run into California law problems; but even if you didn’t, you are simply making the MRT an authority no different from the Contract Co. How is that an improvement over the CWG plan?
--MM
From: Maarten Simon [mailto:maarten.simon@sidn.nl] Sent: Thursday, December 4, 2014 11:08 AM To: Milton L Mueller Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] Do we really need a Contracting Co.?
Milton,
Viable or legal possible are two different things and yes I find the separability principle less central than the stability one and am therefore willing to accept something like the ‘kludgy patch’ as an escape from ICANN as a worst case scenario and as the last resort safeguard if all others fail.
I further wonder if there will be a different ‘ongoing power struggle between the MRT and the board’ in the contract co situation or in the internal ICANN situation. That all depends on the whole set of the arrangements and in the end on the acceptance of the authority of the MRT by the board.
Best,
Maarten
From: Milton L Mueller [mailto:mueller@syr.edu] Sent: donderdag 4 december 2014 15:52 To: Maarten Simon; 'Eduardo Diaz'; 'Holly Raiche' Cc: 'cwg-stewardship@icann.org' Subject: RE: [CWG-Stewardship] Do we really need a Contracting Co.?
Maarten I think this proposal is not viable. In effect, it makes the ICANN board the contracting authority for the IANA functions, thus eliminating the separability principle. You try to patch this problem in a kludgy way by saying that the MRT can “order the ICANN board” to give up the IANA function, which in effect makes the MRT a continuing legal entity, and paves the way for an ongoing power struggle should the MRT and board come into conflict over the future control of IANA.
This is yet another example of people tying themselves in knots and putting at risk the separability principle in order to avoid the simple expedient of creating a Contract Co. But why do you fear the Contract Co so much? No clear rationale for avoiding this has ever been put forward.
If you want to be able to move the IANA functions contract it is much cleaner and simpler to have an independent, separate contract co.
--MM
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Maarten Simon Sent: Thursday, December 4, 2014 8:56 AM To: 'Eduardo Diaz'; Holly Raiche Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Hi all,
I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN’s bylaws specifically aimed on the IANA function.
If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT.
As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would.
Best,
Maarten
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Eduardo Diaz Sent: woensdag 3 december 2014 1:19 To: Holly Raiche Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Holly and all:
I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second.
-ed
On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <h.raiche@internode.on.net> wrote: Seun
You have summed up the issue wonderfully.
Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced.
Holly
On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com> wrote:
Hi Chuck,
Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes:
- Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away
- While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN
I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame.
That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG.
Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com> wrote: Seun,
Please see the letter I sent to Fadi in 2013:https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... .
Chuck
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive.
Regards
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng Mobile: +2348035233535 alt email: seun.ojedeji@fuoye.edu.ng
The key to understanding is humility - my view !
-- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng Mobile: +2348035233535 alt email: seun.ojedeji@fuoye.edu.ng
The key to understanding is humility - my view !
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- NOTICE: This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately. _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
From: Maarten Simon [mailto:maarten.simon@sidn.nl] It is not that I see the Contracting co as a non option but I try to get a better understanding of what it will actually brings us. A clear one is that it probably makes a future separation mainly from a legal perspective a bit easier. MM: It also makes it easier from a political perspective. The members of the ICANN community likely to be on a MRT are in many ways dependent on ICANN; in some cases (e.g., gTLDs seeking a new resource) the very livelihood as a business is in ICANN’s hands. Often that can influence their positioning on other issues. An accountability mechanism that resides entirely within ICANN and its bylaws is not an independent accountability mechanism. MM: This brings up what may be a delicate issue. Maarten, surely you have noticed that the groups more concerned with harder and separable forms of accountability tend to come from the gTLD space. That is no accident. You are a ccTLD operator not subject to ICANN policy authority; here in gTLD land we know a bit more about the exercise of arbitrary power and the real costs of the lack of accountability mechanisms. Therefore I think that, as the lawyers say, you kind of lack standing on some of the issues regarding regarding accountability mechanisms. Of course, you are as interested in a stable and accountable IANA as we are, but when you say “we don’t need an independent Contract Co.,” what I hear is “we ccTLDs don’t see a need for it.“ I understand that cc’s have a very good deal in certain respects – free service from IANA (or voluntary contributions) with no contractual obligations – but just as I said to Paul Kane, that situation does not apply to the rest of us and it is a mistake to design a solution that the rest of the TLD world has to live with based on your contentment with the status quo. I would ask for some deference to our views regarding the independence of the MRT and contracting process of ICANN. We have to live with the results a bit more than you do.
Maarten, I definitely agree with you. Not only is the proposed contracting infrastructure complex, but in the possible absence of ICANN (since eliminating ICANN from the entire IANA management equation is a prime rationale for inventing this structure in the first place), how the MRT is composed, and how to ensure that it is indeed representative is an issue that has not received much discussion. Milton makes reference to the "Principle of Separability", but that is one of the work products of the CWG, and not a premise going in. I believe that it was driven by the lack of trust in ICANN, and that there may well be ways to ensure that ICANN does not violate the MS trust. That is not there today, and that is why we will have an Accountability CCWG to address just that kind of question. Alan At 04/12/2014 08:55 AM, Maarten Simon wrote:
Hi all,
I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANNâs bylaws specifically aimed on the IANA function.
If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT.
As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would.
Best,
Maarten
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Eduardo Diaz Sent: woensdag 3 december 2014 1:19 To: Holly Raiche Cc: cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.?
Holly and all:
I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second.
-ed
On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche <<mailto:h.raiche@internode.on.net>h.raiche@internode.on.net> wrote: Seun
You have summed up the issue wonderfully.
Yes, we appear to be going down the second route. But there are still questions around that route. Alanâs (and Olivierâs and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced.
Holly
On 3 Dec 2014, at 7:21 am, Seun Ojedeji <<mailto:seun.ojedeji@gmail.com>seun.ojedeji@gmail.com> wrote:
Hi Chuck,
Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes: - Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away - While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame. That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG. Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <<mailto:cgomes@verisign.com>cgomes@verisign.com> wrote: Seun,
Please see the letter I sent to Fadi in 2013: <https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-en>https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-en .
Chuck
From: <mailto:cwg-stewardship-bounces@icann.org>cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: <mailto:cwg-stewardship@icann.org>cwg-stewardship@icann.org Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.?
On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <<mailto:avri@acm.org>avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote: I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement.
Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg).
especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;).
What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
I think it will be safer to answer this with another question, where will the contractor get the money to pay from?
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards
avri
_______________________________________________ CWG-Stewardship mailing list <mailto:CWG-Stewardship@icann.org>CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: <http://www.fuoye.edu.ng/>http://www.fuoye.edu.ng Mobile: <tel:%2B2348035233535>+2348035233535 alt email:<http://goog_1872880453/> <mailto:seun.ojedeji@fuoye.edu.ng>seun.ojedeji@fuoye.edu.ng The key to understanding is humility - my view !
-- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: <http://www.fuoye.edu.ng/>http://www.fuoye.edu.ng Mobile: +2348035233535 alt email:<http://goog_1872880453/> <mailto:seun.ojedeji@fuoye.edu.ng>seun.ojedeji@fuoye.edu.ng The key to understanding is humility - my view !
_______________________________________________ CWG-Stewardship mailing list <mailto:CWG-Stewardship@icann.org>CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
_______________________________________________ CWG-Stewardship mailing list <mailto:CWG-Stewardship@icann.org>CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- NOTICE: This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately. _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Alan Greenberg
Milton makes reference to the "Principle of Separability", but that is one of the work products of the CWG, and not a premise going in. I believe that it was driven by the lack of trust in ICANN, and that there may well be ways to ensure that ICANN does not violate the MS trust. That is not there today, and that is why we will have an Accountability CCWG to address just that kind of question.
Sorry, Alan, we fundamentally disagree on the approach to this. Whether I trust ICANN or not, we are making global governance arrangements that require checks and balances. It is not about trusting people or not trusting people, it is about giving the stakeholders who rely on IANA a basic form of accountability for the long term. I am still having trouble understanding the motivations for this concerted rear-guard action against the simple expedient of Contract Co. First it was claimed that it was something that could be “captured” but then the error of this perception was clearly explained: it is a shelf corporation and it takes instructions from the MRT. Now it is claimed that this is too complex; but it’s not complex at all compared to what you offer as an alternative, namely creating an entity within ICANN that requires modification of the bylaws in a way that magically creates a group within ICANN that has the power to overrule the board of a corporation it is part of. None of the problems regarding the composition of the MRT or the threat of capturing the MRT are simplified or improved by what you propose; in fact they are worsened. Is this really just an attempt to reverse the separability option? If so, I think that’s something that will not ever be acceptable to the bulk of the community nor will such a proposal make it through the Washington DC gauntlet. Alan At 04/12/2014 08:55 AM, Maarten Simon wrote: Hi all, I am of the same opinion and wonder, not noing much about Californian corporate law, if we could find a solution in adding specific elements to ICANN’s bylaws specifically aimed on the IANA function. If we could arrange via the bylaws that the ICANN board explicitly has to follow orders from a MRT-like structure, we might not need a contract but have an (internal) MoU/SLA or whatever. If the ICANN board would at a certain moment in time still decide not to follow orders of the MRT, I would assume it may be sued by affected parties for violating its own bylaws. We further may dictate in the bylaws that ICANN has to give up the IANA function if decided by this MRT and of course seal it by dictating that these specific articles may only be changed with the explicit consent of the MRT. As I said, I have no clue if such a solution would be possible under Californian law. Under my legal system I think it would. Best, Maarten From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [ mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Eduardo Diaz Sent: woensdag 3 december 2014 1:19 To: Holly Raiche Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? Holly and all: I have the same questions and concerns. Are we taking the route of a Contrac Co, because is what NTIA is expecting to see as part of the proposal or is it because concerns of ICANN accountability. My impression is the second. -ed On Tue, Dec 2, 2014 at 7:12 PM, Holly Raiche < h.raiche@internode.on.net<mailto:h.raiche@internode.on.net>> wrote: Seun You have summed up the issue wonderfully. Yes, we appear to be going down the second route. But there are still questions around that route. Alan’s (and Olivier’s and many other's) inputs have asked hard questions about the route - as have I. In particular, I asked about the proposed Contract Co. If it is to be created, what is to be its nature, size, powers, funding. From Greg, it emerged that what was envisaged was a shelf company and the multi stakeholder processes under its umbrella would be the mechanisms of accountability. Since then, it appears that the Contract Co will be more than a shelf company, so the many questions about its nature, powers, funding remain. And without answers, I am not sure why the first alternative - fixing the accountability mechanisms - has been rejected. It appears we are hoping the creation of a legal entity (however small) will solve problems. I remain to be convinced. Holly On 3 Dec 2014, at 7:21 am, Seun Ojedeji <seun.ojedeji@gmail.com<mailto:seun.ojedeji@gmail.com> > wrote: Hi Chuck, Thanks a lot for sharing this url....its really useful and i am going to hope that the accountability team are looking at scenarios like that to fix ICANN. Inview of this, there are generally 2 routes: - Fix the accountability mechanisms within ICANN and let the NTIA role naturally go away - While the accountability mechanism is yet to be fixed, provide a means by which IANA can still be moved out of ICANN I presume we are currently going the second route at the moment. So a question that i may ask is, will it not be better to work towards the first route through the second route? This will mean maintaining the ability to move IANA from current operator with an external body (can be an existing body like ISOC, IETF etc) or the lightweight (Contracting Co earlier proposed) and then provide certain principles/mechanisms that this CWG expect to have been addressed within specific time-frame. That will give ICANN (and its community) enough time to work on improving its accountability measures within the timeline indicated by this CWG. Regards On Tue, Dec 2, 2014 at 2:05 PM, Gomes, Chuck <cgomes@verisign.com<mailto:cgomes@verisign.com>> wrote: Seun, Please see the letter I sent to Fadi in 2013: https://www.icann.org/resources/correspondence/gomes-to-chehade-2013-08-30-e... . Chuck From: cwg-stewardship-bounces@icann.org<mailto:cwg-stewardship-bounces@icann.org> [ mailto:cwg-stewardship-bounces@icann.org] On Behalf Of Seun Ojedeji Sent: Tuesday, December 02, 2014 3:57 AM To: Avri Doria Cc: cwg-stewardship@icann.org<mailto:cwg-stewardship@icann.org> Subject: Re: [CWG-Stewardship] Do we really need a Contracting Co.? On Tue, Dec 2, 2014 at 7:33 AM, Avri Doria <avri@acm.org<mailto:avri@acm.org>> wrote: On 02-Dec-14 07:16, Seun Ojedeji wrote: I also don't understand the view that ICANN community and corporate are separate. The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. Okay, may i ask if this is happening at the moment and what the NTIA role has been in making sure it does not happen? because what we are trying to transition is the NTIA role and not ICANN management itself....if there is something that needs to be fixed in the ICANN structure then it could be put in the requirement for transition (most of which should be looked into by the accountability cwg). especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff. Well in the RIR world the board (by by-law) acts in the interest of the organisation. They may also choose not to listen to the community but they usually wisely choose otherwise.... ;). What does that mean? and how is ICANN community different from a typical RIR community. In the RIRs there is no body with a vote that can overrule the will of the community in policy making. The RIR board by the by-law could decide not to approve a policy proposal, its just that they have not had any reason to exercise such powers. So if you are saying there has been consistence instances where a policy that achieved consensus in the ICANN community was overruled by the board, then there is definitely something wrong and will be good to have an example of such scenario to understand why they took such action and determine how to avoid such in future. This is how we build the organisation from inside especially if we understand that ICANN is the home for gTLD Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process. How does the contractor paying hurt the consumers? I think it will be safer to answer this with another question, where will the contractor get the money to pay from? I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against. Looks like you are now referring the MRT to be a MASSIVE multi-stakeholder body, please can we fashion out the composition and charter of this organisation so we appreciate what we are looking at. It sure seem there is going to be a lot of mechanism required to ensure that the multistakeholder body is indeed inclusive. Regards avri _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535<tel:%2B2348035233535> alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! -- ------------------------------------------------------------------------ Seun Ojedeji, Federal University Oye-Ekiti web: http://www.fuoye.edu.ng<http://www.fuoye.edu.ng/> Mobile: +2348035233535 alt email: <http://goog_1872880453/> seun.ojedeji@fuoye.edu.ng<mailto:seun.ojedeji@fuoye.edu.ng> The key to understanding is humility - my view ! _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship -- NOTICE: This email may contain information which is confidential and/or subject to legal privilege, and is intended for the use of the named addressee only. If you are not the intended recipient, you must not use, disclose or copy any part of this email. If you have received this email by mistake, please notify the sender and delete this message immediately. _______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org<mailto:CWG-Stewardship@icann.org> https://mm.icann.org/mailman/listinfo/cwg-stewardship
On 04-Dec-14 12:19, Alan Greenberg wrote:
I believe that it was driven by the lack of trust in ICANN, and that there may well be ways to ensure that ICANN does not violate the MS trust.
As I have stated several times, my position has to do with the accountability of the holder of the IANA contract, no matter who has it. I can think of NO better mechanism to guarantee that ANY holder of such a contract is accountable other than the threat of withdrawing the contract. Just as the NTIA or IETF can do. It is a clean simple mechanism and no one has suggested anything simpler, cleaner or more workable. For me that is one of the absolute requirements and has nothing to do with ICANN. Again I believe my SG is behind this view. avri
sent from Google nexus 4 kindly excuse brevity and typos. On 4 Dec 2014 21:08, "Avri Doria" <avri@acm.org> wrote:
On 04-Dec-14 12:19, Alan Greenberg wrote:
I believe that it was driven by the lack of trust in ICANN, and that
there may well be ways to ensure that ICANN does not violate the MS trust.
As I have stated several times, my position has to do with the
accountability of the holder of the IANA contract, no matter who has it.
I believe accountability of the operator is what we are all interested in.
I can think of NO better mechanism to guarantee that ANY holder of such a contract is accountable other than the threat of withdrawing the contract. Just as the NTIA or IETF can do.
Well each RIR are not threatened with withdraw of contract. Come to think of it... those that should actually be insistence on contracting are those that relate with the current operator at IANA record keeping only (i.e the numbers, cctlds and protocol). The gTLDs have a whole lot at stake with the current operator and they should instead build the organisation to ensure it has the mechanisms that makes it accountable to it's community. While it may be fine to keep the right to move IANA, I think it's good we all face the reality that at this stage it will require a great technical mismanagement to justify moving IANA from the current operator and if the operator knows this then I don't think it's more of a threat any longer. -
It is a clean simple mechanism and no one has suggested anything simpler, cleaner or more workable. For me that is one of the absolute requirements and has nothing to do with ICANN.
Perhaps a cleaner way is shelf the contract somewhere; maybe at IETF (ISOC) then work with the ICANN accountability team to define IANA specific measures that should be in place internally within specific timeline. This will only require this CWG staying much longer to see those measures put in place. A sign of commitment from the operator could also be identifying the basic part of the accountability that needs to be implemented before transition.
Again I believe my SG is behind this view.
If I may ask, how is this determined? Cheers!
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
Capture can take on multiple forms. If whoever convenes this group does not invite certain parties, it may be considered captured by the rest. We have seen this repeatedly within ICANN in the past. Alan At 02/12/2014 01:33 AM, Avri Doria wrote:
I think people are beginning to see the ghost of possible capture everywhere and it is becoming another paralyzing function that is being used much the way an overblown fear of gaming is being used, as a counter to any idea.
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
avri
Hi, "How does the contractor paying hurting the consumers"? Is like trying to cut off the roots transporting water to the branches of a tree, saying branches and leaves don't need roots. Can ICANN board and staff survive without the consumers? IMHO I think, it's more of a dependent relationship. Regards, Wale On Dec 2, 2014 6:34 AM, "Avri Doria" <avri@acm.org> wrote:
On 02-Dec-14 07:16, Seun Ojedeji wrote:
I also don't understand the view that ICANN community and corporate are separate.
The ICANN Board and Staff are independent of the Community and can overrule the community either by a vote of the Board, or by calling an action 'implementation' that does not require community agreement. I do not understand how anyone can see ICANN community and ICANN Corporate as being the same entity, though there are points of contact. There is a strict division between the two, especially since the Board, given its understanding of the its fiduciary responsibility sees itself as NOT representing the community. Adn the staff is governed by a CEO that is not subject, in any way, to community appproval in hiring or contract renewal. The Community has NO influence over ICANN Staff.
What does that mean? and how is ICANN community different from a typical RIR community.
In the RIRs there is no body with a vote that can overrule the will of the community in policy making.
Please when you think of who pays, think of it from the customer perspective, think of participation, think of the resources that's already been expended in this current ICG process.
How does the contractor paying hurt the consumers?
On a lighter note, it's interesting that we will want to put all these structure just because of a "what if". It's also interesting that we are not thinking of the possibility of the young MRT being subject to capture.
I think people are beginning to see the ghost of possible capture everywhere and it is becoming another paralyzing function that is being used much the way an overblown fear of gaming is being used, as a counter to any idea.
I persist in seeing the only real possibility of capture in a massively multistakeholder body is that the community process can be captured by ICANN corporate decisions made that disregard the community's consensus, and that is what we need to protect against.
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
hi On 01-Dec-14 16:20, Avri Doria wrote:
On another topic, it concerns me that our draft document seems to have buried the notion of the periodic RFP. RFP is listed on page 30, but Annex 3 seems to avoid mention at all. and even in section 3, there is no notion of a periodic RFC, just the fact that there can be one. I believe that without a peridoic RFP for the IANA contract there can be no accountability for the IANA function at ICANN or anywhere else for that matter - and this is not something that can be remedied by the CCSG Accountability. The IETF and the RIRs can walk away from ICANN if they are ever unhappy. The Names community needs the ability to move the IANA contract elsewhere as well. Whether the contract is held in 'trust' for us by ISOC or Company Co. matters less to me that it be held externally.
on rereading the 1.6 version I see a function of the MRT (was PRT).
o Managing a rebidding process in the case of performance deficiencies or at regular rebidding intervals;
this comes real close to what I mean by Periodic RFPs. Was looking too narrowly for identical text instead of reading what was actually there. I think it is necessary and I am glad to see this there. apologies. avri
But still, I don't like the "or" in there. I thought the preponderance of opinion was very much in favor of fixed, recurring intervals and not only in the case of disastrous "performance deficiencies." --MM From: cwg-stewardship-bounces@icann.org [mailto:cwg-stewardship-bounces@icann.org] On Behalf Of on rereading the 1.6 version I see a function of the MRT (was PRT). o Managing a rebidding process in the case of performance deficiencies or at regular rebidding intervals; this comes real close to what I mean by Periodic RFPs. Was looking too narrowly for identical text instead of reading what was actually there. I think it is necessary and I am glad to see this there. apologies. avri
Milton, I think this is actually a drafting issue, not a substance issue. There are definitely fixed, recurring intervals at which time the contract would expire AND the possibility of termination for breach at any time. We should be able to clear this up in the document, so that our intent is clarified. (I have seen lengthy articles written about the use of "or" in agreements, which boil down to discussions of when and if "or" means "and" under certain circumstances. Agreement drafters hate "and/or" for some reason.) The length of those intervals, and whether there would be intermediate "options" for Contract Co. to extend the agreement within those intervals, is still under discussion. (Current IANA Contract is 3+2+2 (3 year initial term, and 2 2 year options, exercisable by Contract Co.).) Also under discussion is whether an RFP for a new Contract is mandatory every time or is a decision to be made by the MRT at the time. A further nuance is whether an RFP should be required upon termination for breach but not for expiration or vice versa -- I don think this has been discussed yet, but as we drill down, we'll hit this issue. Greg On Mon, Dec 1, 2014 at 11:53 AM, Milton L Mueller <mueller@syr.edu> wrote:
But still, I don’t like the “or” in there. I thought the preponderance of opinion was very much in favor of fixed, recurring intervals and not only in the case of disastrous “performance deficiencies.”
--MM
*From:* cwg-stewardship-bounces@icann.org [mailto: cwg-stewardship-bounces@icann.org] *On Behalf Of *
on rereading the 1.6 version I see a function of the MRT (was PRT).
o Managing a rebidding process in the case of performance deficiencies or at regular rebidding intervals;
this comes real close to what I mean by Periodic RFPs. Was looking too narrowly for identical text instead of reading what was actually there.
I think it is necessary and I am glad to see this there.
apologies.
avri
_______________________________________________ CWG-Stewardship mailing list CWG-Stewardship@icann.org https://mm.icann.org/mailman/listinfo/cwg-stewardship
-- *Gregory S. Shatan **ï* *Abelman Frayne & Schwab* *666 Third Avenue **ï** New York, NY 10017-5621* *Direct* 212-885-9253 *| **Main* 212-949-9022 *Fax* 212-949-9190 *|* *Cell *917-816-6428 *gsshatan@lawabel.com <gsshatan@lawabel.com>* *ICANN-related: gregshatanipc@gmail.com <gregshatanipc@gmail.com> * *www.lawabel.com <http://www.lawabel.com/>*
From: Greg Shatan [mailto:gregshatanipc@gmail.com] (I have seen lengthy articles written about the use of "or" in agreements, which boil down to discussions of when and if "or" means "and" under certain circumstances. Agreement drafters hate "and/or" for some reason.) ☺ I come at it from a logician’s standpoint. “Or” means Boolean or. The length of those intervals, and whether there would be intermediate "options" for Contract Co. to extend the agreement within those intervals, is still under discussion. (Current IANA Contract is 3+2+2 (3 year initial Agreed.
On 01-Dec-14 20:41, Milton L Mueller wrote:
JI come at it from a logician’s standpoint. “Or” means Boolean or.
Well from a logicians point of view, 'Or' can either be understood as VEL, a weak disjunction, aka 'and/or' or AUT which is exclusive, aka 'either .. or'. English does not distinguish the two and linguistically overloads the the use of a simple 'or' resulting in ambiguity. To use the Symbolic Logic definition used in mathematical expressions instead of the Classical Logic is the source of much confusion. In terms of the document we should make sure that the we are using the VEL and not the AUT. avri
participants (14)
-
Alan Greenberg -
Avri Doria -
Bertrand de La Chapelle -
Burr, Becky -
Eduardo Diaz -
Gomes, Chuck -
Greg Shatan -
Holly Raiche -
Jaap Akkerhuis -
Maarten Simon -
Matthew Shears -
Milton L Mueller -
Olawale Bakare -
Seun Ojedeji