[CWG-Stewardship] Initial Discussion Draft on Transition Models

Seun Ojedeji seun.ojedeji at gmail.com
Wed Apr 8 05:32:38 UTC 2015


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 at 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 at 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: Image removed by sender. Avast logo] <http://www.avast.com/>
>
> This email has been checked for viruses by Avast antivirus software.
> www.avast.com
>
>
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150408/f10dff07/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD000.jpg
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150408/f10dff07/WRD000-0001.jpg>


More information about the CWG-Stewardship mailing list