[DT-F] URGENT: Several questions for DT-F

Fri Apr 17 15:03:31 UTC 2015

Let me make it clear why I am insisting on a better articulation of the purpose of the separation.
I actually support the idea intuitively, but feel that unless we clearly state the purpose of the separation we are not providing clear instructions on how to do it, and we could easily fail to achieve our goals.

As an example, there are people in the US who support the separation because they want a U.S. company under U.S. legal jurisdiction to have some control over what goes into the RZF, and to serve as a check should ICANN "escape" California.

There may also be people who support the separation (as Jordan partially does below) because they don't think ICANN or a legally separated IANA affiliate would have the operational capability to run the primary RZ as reliably as Verisign.

In contrast, David Conrad has repeatedly suggested that the separation is a kind of two-factor authentication that can provide a means of preventing errors and abuses of power, both.

Those three rationales above point to completely different requirements for the type of separation we would ask for.

Let me focus on David's rationale, as I think it is the one that has the most support.
If separation between RZM and IANA RZ editing is intended to provide two-factor authentication, then it implies a certain level of autonomy among the parties, does it not? RZM cannot be a passive recipient of IANA instructions that are automatically implemented - can they? Or is there some way to automate the exchange between IANA and VRSN that still allows some kind of additional error or security check or some way to filter out of policy abuses?

--MM

From: cwg-dtf-bounces at icann.org [mailto:cwg-dtf-bounces at icann.org] On Behalf Of Jordan Carter
Sent: Thursday, April 16, 2015 11:28 PM
To: Alan Greenberg
Cc: CWG DT-F
Subject: Re: [DT-F] URGENT: Several questions for DT-F

Hello DT-F colleagues,

I copy the mail I just sent to the CWG in response to the first question, so that it is in the archive etc.

In the operation of the IANA functions and their stewardship, through to the root zone, there are currently three significant parties: the NTIA, ICANN and Verisign.

With the end of the IANA Functions Contract and the CWG's emerging proposal to assign the stewardship responsibility to ICANN, this will reduce the parties involved to two.

If there is not a line of business restriction placed on ICANN to prevent it also being the Root Zone Maintainer, there are two consequences:

- pressure that could emerge over time, from whatever source, for ICANN to develop another portfolio of activity that would divert attention, resources, focus from its core activity

- the concentration of the entire responsibility for operating the root in one entity.

I do not believe ICANN or the IANA functions department within it have the skills and experience, the resources and the need, to deliver the RZM functions.

I do not believe that them developing this capability is required by ICANN's core role.

Even if I could be persuaded on that point, the notion that we should go from three different entities with three different webs of constituency, degrees of power, and expertise (ICANN, NTIA and Verisign) to ONE, is inevitably and totally a future threat to the security and stability of the root.

It would be fundamentally irresponsible to allow such a situation to emerge, in my opinion.

best,
Jordan

On 17 April 2015 at 15:16, Alan Greenberg <alan.greenberg at mcgill.ca<mailto:alan.greenberg at mcgill.ca>> wrote:
The revised text is due at 17:00 UTC on Friday. Quick replies appreciated

1.

Milton has asked (several times) WHY we want to ensure that the IANA Functions Operator and Root Zone Maintainer must be separate entities. The answers I have heard to date do not (in my mind, or presumably Milton's) really explain why the two-party solution is better. With the current architecture, most or all errors that Verisign could catch would also be catchable in a single-party implementation.

Can anyone provide either a general answer or specific scenarios where the two-party solution is better.

2.

1.c.1 Says that we need to consider increasing robustness WITHIN IANA prior to the CWG proposal being submitted.

1.c.2 Says we need to consider robustness everywhere (including within IANA) post transition.

I am not aware of the justification for 1.c.1 other than it was sort of implied by the transfer of tasks from DT-D. But since NTIA did not refuse authorizations and there are no known problems, it is not clear that this is an urgent matter.

Moreover I find it highly unlikely that a proper job of this could be done prior to transition if it occurs in 2015 or early 2016.

Do we want to keep it?

Alan
_______________________________________________
cwg-dtf mailing list
cwg-dtf at icann.org<mailto:cwg-dtf at icann.org>
https://mm.icann.org/mailman/listinfo/cwg-dtf

--
Jordan Carter

Chief Executive
InternetNZ

04 495 2118 (office) | +64 21 442 649 (mob)
jordan at internetnz.net.nz<mailto:jordan at internetnz.net.nz>
Skype: jordancarter

A better world through a better Internet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150417/3cbd44bc/attachment-0001.html>