[CWG-Stewardship] Initial Discussion Draft on Transition Models

Avri Doria avri at acm.org
Wed Apr 8 02:28:06 UTC 2015


Hi,

That, though, is not for us to decide but them.

And it is the ICG that needs to deal with that detail.  We have already
had our virtual wrists slapped for presuming anything about what the
other operational communities might or might not be willing to do.  Any
proposal we come up can have options, but we cannot presume that they
will do anything.

avri



On 07-Apr-15 19:38, Milton L Mueller 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
> <mailto: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 removed by sender. Avast logo <http://www.avast.com/>
>
>     	
>
>     This email has been checked for viruses by Avast antivirus software.
>     www.avast.com <http://www.avast.com/>
>
>      
>
>
>     _______________________________________________
>     CWG-Stewardship mailing list
>     CWG-Stewardship at icann.org <mailto: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



---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150407/9b1ec9c8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 823 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20150407/9b1ec9c8/attachment-0001.jpe>


More information about the CWG-Stewardship mailing list