[CWG-Stewardship] Do we really need a Contracting Co.?

[Greg Shatan]

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 at 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 at internetjurisdiction.netemail bdelachapelle at 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 at 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 at icann.org [mailto:
>> cwg-stewardship-bounces at icann.org] *On Behalf Of *Avri Doria
>> *Sent:* Monday, December 01, 2014 11:19 AM
>> *To:* cwg-stewardship at 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 at 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 at icann.org
>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>
>>
>>
>>
>>
>> _______________________________________________
>> CWG-Stewardship mailing list
>> CWG-Stewardship at icann.org
>> https://mm.icann.org/mailman/listinfo/cwg-stewardship
>>
>>
>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at 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 at lawabel.com <gsshatan at lawabel.com>*

*ICANN-related: gregshatanipc at gmail.com <gregshatanipc at gmail.com> *

*www.lawabel.com <http://www.lawabel.com/>*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141201/3b9b4c8d/attachment.html>