[DT-F] Design Team F kickoff

[Milton L Mueller]

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.

MM: The difference is not operational, it is about the incentives of the organizational actor that runs the operations.
As you probably know, organizational incentives trump operational procedures. But this is a secondary issue at this time.

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.

MM: We agree on this.

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.

MM: We don't know. The NTIA-led RZ Maintainer transition process is entirely untransparent. But again, we can leave this aside for now

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).

MM: Totally agree.

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"?

MM: No problem with it.

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.

MM: Well, as you may know I spoke up on the last CWG call on this issue and seem to have succeeded in bringing Chuck and possibly also Suzanne Wolf into the DT. As for the deadline, if as you say we don't have sufficient participation/expertise on the group yet it reinforces my tendency to not take April 10 deadline seriously.


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