[CWG-Stewardship] Service Level Expectations Design Team Template
Robert Guerra
rguerra at privaterra.org
Mon Mar 2 15:16:51 UTC 2015
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
More information about the CWG-Stewardship
mailing list