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

Greg Shatan gregshatanipc at gmail.com
Mon Dec 8 08:13:43 UTC 2014


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 <gsshatan at lawabel.com>*

*ICANN-related: gregshatanipc at gmail.com <gregshatanipc at gmail.com> *

*www.lawabel.com <http://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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141208/8f8df0bd/attachment-0001.html>


More information about the CWG-Stewardship mailing list