[DT-F] Design Team F kickoff

[Gomes, Chuck]

First of all let me say that I definitely agree with this: "power/responsibility to modify/update the root zone is not concentrated in a single entity".  To me that is just simple checks and balances.

Secondly, am I correct that the current system with NTIA involved doesn't deal with mistakes any differently than they would be dealt with when NTIA goes away, i.e., they would probably need to be fixed after they happened if they were not caught in the process?  If I am correct in this assessment, what we are talking about is an improvement to the existing process.

I personally think that the technical checks that both the IANA operator and the Root Zone Maintainer do are very good.  So in my thinking, the kind of mistakes we may want to focus on are mistakes relating to policy implementation.  Is there a change to the process that would increase the chances of catching those before they are implemented without slowing down the process significantly?  I confess that I don't have a solution but I think that may be where we want to focus our attention with regard to mistakes.

Chuck


From: cwg-dtf-bounces at icann.org [mailto:cwg-dtf-bounces at icann.org] On Behalf Of David Conrad
Sent: Tuesday, April 07, 2015 10:33 PM
To: Milton Mueller
Cc: CWG DT-F
Subject: Re: [DT-F] Design Team F kickoff

Milton,

there is a huge difference between a legally separated IANA  having it and today's ICANN having it, as ICANN is currently the policymaker and IANA.

Perhaps the discontinuity here is that I'm looking at this from an operational perspective and I gather you're looking at it from a policy perspective. Operationally, I don't see the difference.  In both cases, it would seem to me there is a single entity that has ultimate control over what gets published in the root zone.  In both cases, if that single entity were to go rogue or make a mistake, there would (presumably) be accountability mechanisms to slap them after the fact.  However, in both cases, the damage would already be done: an out-of-policy zone change would have been made. This seems sub-optimal to me.

In any event, this is somewhat moot as I'm not aware of anyone suggesting the IANA Function Operator and the Root Zone Maintainer actually be merged, regardless of how scary it might or might not be.

What I'm trying to get at is a framework that is applicable to derive operational relationships acceptable to the community in the post-NTIA future.  I'll point out again that "Checks and balances between the IANA Function Operator and Root Zone Maintainer roles are largely implemented via contractual obligations with the Root Zone Administrator." Regardless of the form of the outcome of the transition, the Root Zone Administrator role is going away, thus I believe there will need to be some framework to define the relationship between the entities that provide the IANA Functions and the Root Zone Maintainer (however those functions are partitioned and the entities that provide those functions are structured).

As a first attempt to come up with part of that framework, do you disagree with the my rephrasing of the requirement Jordan proposed:

"power/responsibility to modify/update the root zone is not concentrated in a single entity"?

I don't agree that a separate group at a separate time needs to consider these issues I think we have to consider them now.

My understanding is that the deadline is April 10 and I'm still unclear whether the participants in this Design Team are sufficiently representative of the impacted stakeholder community to fully consider the issues.

Regards,
-drc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150408/5dba0261/attachment.html>