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

[Bertrand de La Chapelle]

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 at internetjurisdiction.netemail bdelachapelle at 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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141201/2024fc25/attachment.html>