[DT-F] Design Team F kickoff

[David Conrad]

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/44ce8ea9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4673 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150408/44ce8ea9/smime.p7s>