[CWG-Stewardship] Contract, Co. and the root zone publisher

Wed Dec 10 04:23:24 UTC 2014

Alan,

Why do you say it is up to the NTIA?  Our charter says it's up to us.  I
don't believe we're adding a new complexity.  I think we are recognizing
that we overlooked an existing complexity that was on our plate.

Greg

*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/>*

On Tue, Dec 9, 2014 at 11:17 PM, Alan Greenberg <alan.greenberg at mcgill.ca>
wrote:

>  We need to specify that for the IANA transition to be effective, there
> must be a requirement that the Root zone maintainer accept change
> instructions from the assigned IANA functions operator. It is up to NTIA to
> arrange its (or perhaps our at some point) contract with the RZM to make
> sure that this happens. Why add new complexity to our already difficult
> task?
>
> Alan
>
>
> At 09/12/2014 11:02 PM, Jordan Carter wrote:
>
> All
>
> I agree with Mathieu's basic concern but would basically put it like this:
>
> ContractCo has no teeth in assigning the IANA functions contract to anyone
> unless it can also direct the Root zone maintainer to accept change
> instructions from the assigned IANA functions operator.
>
> Without the ability to do both those things, then the first power is
> imaginary.
>
> For example, imagine if Contract Co had a contract with ICANN to perform
> the IANA functions, and ICANN as IANA functions operator had a contract
> with the RZM.
>
> If ContractCo issued the contract for IANA functions to a different
> entity, ICANN could still control the root.
>
> So it appears to me that we aren't solving post-NTIA problems if we aren't
> dealing with RZM as well as IANA functions.
>
> Interested in other views and perspectives on this.
>
> cheers,
> Jordan
>
>
> On 9 December 2014 at 03:48, Milton L Mueller <mueller at syr.edu> wrote: I
> agree with you Greg that this is in scope; you are also correct to point
> out that the NTIA language (“related and parallel”) makes it rather
> ambiguous regarding our role relative to NTIA’s role in effecting this
> change.
>
> My take on it is that NTIA will actually take responsibility for modifying
> or ending the Verisign Cooperative Agreement once we have a complete
> proposal, but that our proposal really does need to be based on a clear
> understanding of what we want to happen to the RZM functions. This message
> should be more detailed but I don’t have time for more now.
>
>   From: Greg Shatan [ mailto:gregshatanipc at gmail.com
> <gregshatanipc at gmail.com>] Sent: Monday, December 8, 2014 3:14 AM To:
> Milton L Mueller Cc: Mathieu.Weill at afnic.fr; cwg-stewardship at icann.org Subject:
> Re: [CWG-Stewardship] Contract, Co. and the root zone publisher
>
> I agree that this is another important reason for Contract Co. -- to
> contract with the RZM.
> However, I'm not sure I agree that issues relating to the Cooperative
> Agreement are part of a "Step 2" that is not within the scope of this CWG.
> The Q&A issued along with the NTIA's initial press release on the IANA
> transition said that there a "related and parallel" transition of the
> NTIA's responsibilities relating to the Verisign cooperative agreement.
>
>
> http://www.ntia.doc.gov/other-publication/2014/iana-functions-and-related-root-zone-management-transition-questions-and-answ
>
> A "parallel" transition seems inconsistent with a "Step 2" approach (which
> would be more of a "serial" transition).
>
> In our CWG's Charter, in the section entitled "Scope," there is the
> following paragraph (emphasis added):
> In respect of Function 2. (“Perform Administrative Functions Associated
> With Root Zone Management”), this process currently involves distinct roles
> performed by three different entities through two separate legal
> agreements: the Contractor as the IANA Functions Operator, NTIA as the
> Administrator, and VeriSign (‘or any successor entity as designated by the
> U.S. Department of Commerce”) as the Root Zone Maintainer. The
> accountability function currently performed by NTIA regarding the RZM role,
> as well as the discussion of the RZM management administrative interface
> currently used by NTIA are within the scope of the CWG. The issue of who
> performs the Root Zone Maintainer (RZM) role is not in scope for the CWG
> and should be dealt with in a subsequent effort as needed. Additionally,
> issues related to naming policy e.g. delegation, redelegation or revocation
> of ccTLDs, RAA related policy issues etc. are not within the scope of the
> CWG.
> If I read this correctly, "the accountability function ... regarding the
> RZM role" is within our scope. This means that our proposal does have to
> provide for a transition of the NTIA's role relating to the RZM function.
> It stands to reason that, if the NTIA is no longer in this role, that the
> NTIA should no longer be a party to the Cooperative Agreement, since the
> Cooperative Agreement is a key part of the NTIA's accountability function.
> This also seems to call for a "parallel" transition (like the NTIA Q&A) of
> the NTIA's responsibilities relating to the Verisign cooperative agreement
> to be included in our proposal.
> Perhaps someone from the drafting team can shed some light on the genesis
> and meaning of this paragraph in our Charter.  The only reference I can
> find to this paragraph on the DT wiki is a line from the Call #3 Meeting
> Notes and Action Items:
> Language on Root Zone Maintaining process: re-focus on role of NTIA in
> Root Zone maintainer process. Action: Avri and Chuck to propose language to
> the group. Group aware of Chuck’s role and no objection.
>
> I think we need to get some real clarity on this point very soon, so that
> our Proposal does not fail to deal with part of our mandate.
> Greg
>
> 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
> ICANN-related: gregshatanipc at gmail.com
>
> www.lawabel.com
>
> On Sun, Dec 7, 2014 at 11:11 AM, Milton L Mueller <mueller at syr.edu> wrote:
>
>  Mathieu You are correct to suggest that the status of Verisign as RZM is
> still a bit of a loose end in the transition process. However, the scenario
> you propose isn't a problem with this plan; if it could happen under a new
> regime, too if we are not careful. There would be nothing preventing
> Verisign from refusing to implement IANA change requests from ICANN, for
> example.
> So this is not an argument against any particular plan, it is simply
> identifying a problem that the NTIA has to take care of after the
> transition.
> Currently, Verisign is bound to modify the root zone changes approved by
> the NTIA through a Cooperative Agreement with the Commerce Department.
> Ultimately, that agreement has to go away to complete the IANA transition.
> If Verisign continues to be the Root Zone File implementer, the cooperative
> agreement has to go away otherwise the NTIA will still be in control of the
> root. However, for practical reasons the NTIA has chosen to make that "step
> 2" after they get an agreeable IANA transition plan. My guess is that once
> we have an acceptable plan, then the NTIA-Verisign cooperative agreement
> will be modified and the new IANA contractor will work out an agreement
> with whoever the RZF implementer turns out to be.
> This is another reason why we MUST have a Contract Co.!!!! How are you
> going to have authority over RZF change implementation without a legally
> binding, readily enforceable contract?
> One thing that may put your mind at ease: Verisign does not want to be in
> control of root zone file modifications. That would make it liable for
> antitrust challenges or make it subject to liability for other things that
> might happen related to RZF changes. It is a private, commercial company,
> and putting a private company in charge of a critical resource used by its
> competitors is not a position a company residing in a jurisdiction with
> strong antitrust laws wants to be in. The current arrangement makes
> Verisign the operator but someone else has the responsibility for the
> changes.
>
> > -----Original Message----- > From: cwg-stewardship-bounces at icann.org
> [mailto:cwg-stewardship- > bounces at icann.org] On Behalf Of Mathieu Weill >
> Sent: Sunday, December 7, 2014 7:41 AM > To: cwg-stewardship at icann.org >
> Subject: [CWG-Stewardship] Contract, Co. and the root zone publisher > >
> Dear Colleagues, > > Having now read carefully the proposal document, I
> have a significant > concern to share with all Members and Participants.
> I feel like we are missing > an important part of the puzzle. > > I
> apologize for raising this concern so late, and I hope this concern will be >
> easily dismissed if I have missed something. > > Here is the scenario
> that raised my concern. > > The CWG suggests to create Contract, Co. as
> the contracting party for the > IANA contract in the future. Consider the
> scenario where Contract, Co., upon > instruction from the MRT after a
> fierce debate, contracts with someone else > than Icann, following an
> RFP. > > Consider now that, due to external considerations, the root zone
> publisher > (currently, Verisign) indicates that it does not intend
> accepting requests from > the new IANA operator. We would be facing a
> deadlock, threatening the > ability to maintain the root zone in a secure
> and stable manner. > > Am I missing something here ? Unless I am, I
> believe we would need to > expand our investigations to be able to
> address this scenario, by : > - analyzing the root zone publisher
> function, especially by what mechanisms > it is bound to publish
> IANA-approved changes to to the root zone. > - investigating options in
> our transition proposal, through which to ensure > that the root zone
> publisher remains committed to publish changes in the > root when, and
> only when, they are approved by the IANA Operator. > > Many thanks in
> advance for your replies regarding both the validity of this > scenario
> as well as potential ways to address that risk. > > -- >
> ***************************** > Mathieu WEILL > AFNIC - directeur général >
> Tél: 01 39 30 83 06 > mathieu.weill at afnic.fr >
> ***************************** > ATTENTION : L'Afnic a déménagé le 31 mars
> 2014 ! > Notre nouvelle adresse est : > Afnic - Immeuble Le Stephenson -
> 1, rue Stephenson - 78180 Montigny-le- > Bretonneux > >
> _______________________________________________ > 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
>
>
>
>
> --
> Jordan Carter
>
> Chief Executive
> InternetNZ
>
> 04 495 2118 (office) | +64 21 442 649 (mob)
> jordan at internetnz.net.nz
> Skype: jordancarter
>
> To promote the Internet's benefits and uses, and protect its potential.
>
> _______________________________________________
> 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/20141209/2ba689f5/attachment-0001.html>