[CWG-Stewardship] NTIA's Role in Root Zone Management

[David Conrad]

[Sorry for the slow response ‹ a bit busy]

Milton,

> You are asserting that the RZM (currently, Verisign) can unilaterally change
> the root zone? But of course this is not true because of its cooperative
> agreement with NTIA.

Actually, it is true.  Technically, the only entity on the planet today who
can change the root zone is Verisign.  They

1. Maintain the root zone database ("the root zone file");
2. Hold the Zone Signing Key
3. Run the hidden master from which the root server operators pull the root
zone
This gives the Root Zone Maintainer the unilateral ability to both modify
the root zone and have that zone published.  Currently, there are NO
technical limitations on what they can do with the root zone, only
administrative limitations ‹ if Verisign went stark raving mad and (say)
decided to remove all competing TLDs from the root zone, they could do so
(for those resolvers that query the root servers while the edited zone
remained up).  Of course, it is likely that in very short order, they would
(a) no longer be the Root Zone Maintainer and (b) no longer be a viable
going concern due to the myriad of lawsuits that would instantly appear.
However, pragmatically speaking, the fact that the Root Zone Maintainer
would turn into a smoldering crater is a bit like closing the barn door
after the horse has bolted.

> Perhaps that is what you mean by ³legal repercussions.²

Yes. While it is true that the Root Zone Maintainer is under contractual
terms to get explicit authorization from the Root Zone Administrator prior
to making changes, there is no technical mechanism by which that is
enforced. 

> In terms of how the accountability model changes, I think many of us are
> viewing the Verisign Cooperative Agreement as a legacy arrangement that should
> disappear after the transition.

An interesting assumption.

> Which means that the IANA functions operator would either be the contracter
> for the RZM function, or the Contract Co would contract for it directly.
> Between those two options it¹s clear that there are significant differences in
> the accountability model, and either of those is significantly different from
> the status quo, which relies on the NTIA. So again I don¹t quite grasp what
> you are asking about.

I was asking about Jordan's response to the scenario in which the IANA
Function Operator and the Root Zone Maintainer are merged (which again, I
neither support nor oppose), thus creating a single entity that receives,
validates, and implements change requests.  I gather he feels the
accountability mechanism would be vastly different than if the IFO and RZM
are separate. Since there is a single entity in both scenarios that,
pragmatically speaking, holds all the cards and that entity is restrained
only by contractual terms which would presumably be essentially the same in
both cases, I'm not seeing a whole lot of difference.

Regards,
-drc



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141219/89604745/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4684 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-stewardship/attachments/20141219/89604745/smime.p7s>