Yeah that's correct and it's based on the assumption that RIR/IETF would want to contract with PTI. So even if they accept, the principle already says IANA operator is a "unit providing the service", on what basis would PTI then be recognised as the operator? Considering the duo will most likely be interested in dealing with IANA then I presume the contract could as well be signed with the unit.

All that said, I hope we do remember the scope of work is to transition oversight of NTIA and not to transition the IANA operator; The practical application of section of the principle that implies everything is fine with IANA at the moment needs to be evident in our proposal.

Regards
sent from Google nexus 4
kindly excuse brevity and typos.

On 8 Apr 2015 00:39, "Milton L Mueller" <mueller@syr.edu> wrote:

Let me reiterate an important detail that many seem to be overlooking.

 

The RIRs CRISP team proposed the following:

 

“The Internet Number Community proposes that a new contract be established between the IANA Numbering Services Operator and the five RIRs. The following is a proposal to replace the current NTIA IANA agreement with a new contract that more directly reflects and enforces the IANA Numbering Services Operator’s accountability to the Internet Number Community…. It is expected that the RIRs, as the contractual party of this agreement, will draft the specific language of this agreement.”

 

New. Contract. Therefore it would not be difficult at all for the RIRs to develop this new contract in a way that named PTI, rather than ICANN Inc., as the contractor. Since the proposed PTI is the same unit as the current ICANN IANA department, and they are happy with that service, I see no reason why the RIRs would have a problem with this.

 

--MM

 

 

1. ICANN retains the contracts with the RIRs and IETF, with a minor amendment allowing ICANN to offer the service, but have the service fulfilled by its wholly-controlled affiliate (or wholly-owned subsidiary) PTI.

2. ICANN enters into an "assignment and assumption" agreement whereby PTI takes over ICANN's position in the agreements.

3, ICANN and the RIRs/IETF terminate the current agreements, and PTI enters into new agreements with the RIRs and IETF.

 

The first option fits the principle of "change as little as possible (and explain any change you make".

The second option fits the principle of "make PTI as easily separable from ICANN as possible."

The third option fits the principle of "let's make everything messy and complicated."

 

​Greg​


 

On Tue, Apr 7, 2015 at 7:16 PM, Avri Doria <avri@acm.org> wrote:

Hi,

One of my comment for the Sidley report is this assumption that the contracts would move to IANA.

I see no reason for this to happen unless the IETF/IAB & RIRs/CRISP want them to.  It seems to me that the contracts could remain with ICANN and that ICANN would use the affiliate to do the work.

avri

On 07-Apr-15 15:29, Andrew Sullivan wrote:

Hi,
 
On Mon, Apr 06, 2015 at 11:04:14AM +0200, Lise Fuhr wrote:
Please see the attached initial discussion draft of the two models from our legal counsel.
Thanks for this.  I've read it.  I have some questions.  Questions for
Sidley are listed, and then some observations for our own discussion
(which needn't take up Sidley's time) follow when appropriate in
square brackets.
 
In I.A, particularly in numbers 4 and 6, I can't tell whether the
assumption is that there are new agreements between PTI and the RIRs,
and PTI and IETF.  I think the fact that PTI is a new legal entity
means that new agreements would be required.  Is that correct?  [The
reason I ask this is because there is a possible risk of things coming
apart if the other operational communities need to be engaged in a new
negotiation.  If PTI just takes the existing agreements and does a
global search and replace for ICANN with PTI, that's nice, but it
doesn't solve everything.  For instance, the IETF would have to
publish a new version of RFC 2860.  It's worth remembering that every
grievance everyone has with an existing document comes into play once
the document is opened for editing.]
 
By way of comparison, in II.B, does using Functional Separation permit
ICANN to continue working under its existing MoUs?  I'd assume yes,
because AFAIK none of the existing agreements specify the internal
arrangements of how ICANN delivers the service.  [Notwithstanding
Milton's point about getting it "right", given the timeline there is a
significant advantage to not having to negotiate, I think, no?]
 
III.C talks about CSC.  In the case of a full legal separation with
independent governance, would the CSC be needed at all?  Presumably
the arrangements between PRI and their customers would be a
contractual one, and as such the management of such contractual
disputes ought to be via those contracts, and not through an extra
body.  Or is the point that the way such a contractual arrangement
would solve such disputes ought to be along the lines of the CSC?
 
In III.D.2 there is a question about "ultimate accountability over
ICANN's stewardhip".  I'm not entirely sure which cases this applies
to.  If there is a legal separation, how is this question relevant for
CWG?  Under the legal separation described, PTI becomes the new IANA
functions operator.  If there's full independent governance of PTI,
for instance, isn't ICANN's stewardship completely gone -- it has only
responsibility for policy, and not for IANA operation at all, right?
Is that part of the point of this question?
 
On III.I, I'm not sure what the difference is between CSC and IRP.
Why are both things needed?  
 
Best regards,
 
A
 



Image removed by sender. Avast logo

This email has been checked for viruses by Avast antivirus software.
www.avast.com

 


_______________________________________________
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