[CWG-Stewardship] Service Level Expectations Design Team Template

[Robert Guerra]

David,

IMHO, Your involvement and engagement is most welcome, and would be a 
great addition to one or more of the design teams.

regards

Robert



--
Robert Guerra
Phone: +1 416-893-0377
Twitter: twitter.com/netfreedom
Email: rguerra at privaterra.org
PGP Keys : https://keybase.io/rguerra

On 2 Mar 2015, at 1:24, Chris Disspain wrote:

> Thanks David.
>
> Personally, I’d be delighted if you helped out with this work. Not 
> my decision though.
>
>
> Cheers,
>
> Chris
>
> On 2 Mar 2015, at 13:49 , David Conrad <david.conrad at icann.org> wrote:
>
>> Chris,
>>
>> On Mar 1, 2015, at 6:45 PM, Chris Disspain <ceo at auda.org.au> wrote:
>>> How would you recommend that those changes that must occur are dealt 
>>> with?
>>
>> First, the potential areas of change need to be identified. There are 
>> three obvious ones:
>>
>> 1) NTIA's "Root Zone Administrator" role: authorizing changes to the 
>> root before they are made:
>> a) Changes to the root zone registration database data (i.e., 
>> "Whois"); and
>> b) Proposed changes submitted to the Root Zone Maintainer (Verisign) 
>> for implementation.
>>
>> 2) NTIA's role in vetting/approving/gating systemic changes (e.g., 
>> approving the DNSSEC-signing of the root zone).
>>
>> 3) NTIA's role in specifying/accepting reporting of actions taken by 
>> IANA.
>>
>> There may be others -- my knowledge of IANA is dated and it is 
>> possible there are other actions now being performed by NTIA that 
>> need to be addressed in the post-NTIA world.
>>
>> Once the areas of change are identified, specific decisions need to 
>> be made by the community about how best the IANA Function Operator 
>> will be able to move forward without NTIA. For example (following the 
>> three I mention above):
>>
>> 1) The Root Zone Administrator role could go away, could be replaced 
>> by a single entity, or could be dealt with some other way.  Given 
>> NTIA has never rejected a change request, I'd argue the role should 
>> simply go away, but I may be seen as biased on the topic.
>>
>> 2) Some mechanism will need to be defined by which the IANA Function 
>> Operator can be authorized to make systemic changes. There are a 
>> myriad possible ways in which this can be done, but my recommendation 
>> would be something that would focus on an efficient/timely way to 
>> ensure both technical correctness and abiding by the "do no harm" 
>> principle.
>>
>> 3) Similarly, some mechanism needs to be defined in which the 
>> information that needs to be provided to the community can be 
>> identified and presented in a useful way.  Every piece of data that 
>> is collected and presented has a cost, either in money, time, or 
>> resources, so care must be taken to not over-burden IANA staff with 
>> information requests or folks should be prepared for increases in 
>> costs and/or delays. My recommendation would be to review the 
>> information NTIA currently demands and throw out the stuff no one 
>> cares about and not add anything new unless it can be shown to have 
>> direct benefit to the IANA Function Operator's accountability.
>>
>> I am happy to volunteer to participate in a design team on this 
>> topic, however since I am ICANN staff, I'm unsure whether my 
>> participation would be permitted.
>>
>> Regards,
>> -drc
>>
>
> _______________________________________________
> CWG-Stewardship mailing list
> CWG-Stewardship at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-stewardship