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

[Mathieu Weill]

Dear Milton,

Thanks for your words of comfort ;-) I'd feel better though if the 
statements below were documented, in the CWG report or elsewhere. So 
far, I haven't seen any mention of these aspects in the report, or in 
public declarations by the NTIA, or anywhere else.

I also realized through our discussion that, in terms of Service levels, 
the root zone publisher is part of the delivery of a change into the 
root. An IANA customer may not have the necessary information to 
determine whether a change was delayed because of IANA Operator delay or 
the PUblisher's delay. So would we also agree that the CSC should 
oversee the performance of the root zone publisher ?

Best
Mathieu


Le 07/12/2014 17:11, Milton L Mueller a écrit :
> 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

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