[DT-F] Design Team F kickoff

[Alan Greenberg]

I was occupied on a personal matter since yesterday afternoon, so I 
am a bit behind on e-mail, but will be going through all of the DT-F message.

On this subject, is there any history of IANA not following policy, 
with or without NTIA catching it?

Alan


At 08/04/2015 10:10 AM, Gomes, Chuck wrote:

>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
>
>_______________________________________________
>cwg-dtf mailing list
>cwg-dtf at icann.org
>https://mm.icann.org/mailman/listinfo/cwg-dtf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150408/b86ce19e/attachment.html>