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

[Suzanne Woolf]

On Apr 16, 2015, at 11:16 PM, Alan Greenberg <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.

I do not believe we need to institutionalize this. I do believe we need to leave it alone as much as possible for the transition. Andrew Sullivan's message to the CWG on the subject was consistent with my own views only way better written than I could do, so I'll just add one additional point:

There is nothing inherent in the DNS or the root zone that requires multiple parties share day-to-day control. Many, many (most?) DNS zones are not under split management; it's considered an operational weakness in many cases to separate DNS zone management responsibility among multiple organizations. The primary reason for sharing control of a DNS zone in the real world is that outsourcing distribution of the data provides better resources for an organization that needs DNS to work but doesn't have top-end network resources and expertise to do it themselves-- and where control is split, a lot of contractual and operational activity is devoted to making sure there's *one* organization clearly in charge. Generation and distribution of the data are split; authority is not-- the operator does what the zone administrator tells them to do, or it's a procedural (and probably contractual) violation.

A requirement for actual split authority-- concurrence of multiple parties, all having some discretion over the outcome, is procedurally necessary for an operational change to occur-- is different.

It seems to me that such a requirement only makes sense here if it's set up to provide clear benefit in the management specifically of the root zone. 

I know people have come to believe over time that such benefit exists, and it may be true. (For instance, I respect Jordan's conviction on the subject, and understand that "people like it that way" is necessary and may be sufficient as justification.) But it's not why we have the multi-party arrangement we do. As best I can recall from "back then," there was no such "original intent" in the decision to have IANA located in one organization in one place and the machines that distributed the root zone located in another organization and another place. It was undertaken, IIRC, for roughly the same reasons as you'd hire Dyn or Verisign or CloudFlare to do your corporate DNS today-- operational (including financial) practicality. Rationales having to do with "governance" came later.

A couple of other replies have appeared in my mailbox while I've been writing mine-- different perspectives but, I think, demonstrating Milton's point (as I understand it) that we don't have agreed-upon goals for institutionalizing such a requirement.



best,
Suzanne

> 
> 
> 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<DT-F_Rec-v07.pdf>_______________________________________________
> cwg-dtf mailing list
> cwg-dtf at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-dtf