[DT-F] REVISED: Design Team F kickoff

Gomes, Chuck cgomes at verisign.com
Fri Apr 10 21:58:59 UTC 2015


Please see my responses below Suzanne.

Chuck

-----Original Message-----
From: Suzanne Woolf [mailto:suzworldwide at gmail.com] 
Sent: Friday, April 10, 2015 5:21 PM
To: Gomes, Chuck
Cc: Alan Greenberg; CWG DT-F
Subject: Re: [DT-F] REVISED: Design Team F kickoff


On Apr 10, 2015, at 2:54 PM, "Gomes, Chuck" <cgomes at verisign.com> wrote:

> I agree that RSSAC involvement on issues such as DNSSEC and IPv6 implementation is needed but I don't think that CSC would have any role there, at least not as I think DT-C is envisioning the CSC.  If I am correct that it will not be CSC, then I guess we need to decide who it would be.
> 
Right, apologies if I misunderstood the scope of DT-C or the CSC-- just trying to make sure the bases are covered.
[Chuck Gomes] No problem.  I have the advantage of probably being more familiar with where I think the CSC is going.  At the same time, I agree that we need to cover all the bases.

The concern about authorizing process or technology changes is a general one, not only having to do with issues that touch on the technical details of the content of the zone. It's simplified vastly by the assumption that policy is developed elsewhere, and the concern here is oversight of implementation, but there's still a need to make sure we're not either dropping pieces of NTIA's role or creating new constraints inadvertently. (There may be new constraints we want to enable, but I'm assuming we'd need a clear rationale.)

Assuming our whole scope is "NTIA as authorizer disappears" and we're assuming all else remains equal, what attributes/responsibilities of the other two partners change? 
[Chuck Gomes] I think this is a very good question for us to answer and may guide our work.

As a related but perhaps less direct question, do we need to look more specifically at the impact of new accountability mechanisms? Not that we can do so in detail while they're still under development, but can/should we suggest some guidelines for evaluating their effects on this core of IANA's role in the root zone? The budget one is obvious to me, are there others?
[Chuck Gomes] Good point on the budget.  Once the FY15 budget analysis is given to the full CWG, we may want to carefully review it as well as the FY16 draft budget to make sure that adequate funding is projected for FY16 got ongoing IANA expenses and any expected new IANA expenses.  Along this line, DT-O recommends that ". . . once the CWG-Stewardship proposal is finalized for SO/AC approval and again after the ICG has approved a proposal for IANA Stewardship Transition: . . . 2. Projection of any new cost elements that may be incurred as a result of the IANA Stewardship Transition and in order to provide the ongoing services after the transition."

I hope these are helpful questions. I may not be not entirely clear on what questions are in scope.


best,
Suzanne


> -----Original Message-----
> From: cwg-dtf-bounces at icann.org [mailto:cwg-dtf-bounces at icann.org] On Behalf Of Suzanne Woolf
> Sent: Friday, April 10, 2015 12:41 PM
> To: Alan Greenberg
> Cc: CWG DT-F
> Subject: Re: [DT-F] REVISED: Design Team F kickoff
> 
> 
> On Apr 9, 2015, at 10:31 PM, Alan Greenberg <alan.greenberg at mcgill.ca> wrote:
> 
>> 
>> Thanks for this Suzanne,
>> 
>> No way would I disagree with you and Chuck about wanting to keep all useful communications paths open. Nothing that we will likely do in this DT should impact this, although I think that going forward (post this DT), we may want to do a bit of documentation. Since changing the Root Zone Maintainer is both out of our scope and nothing that we would want to do in parallel with the change to remove NTIA, I think that we can safely say that it will be business-as-usual regarding the Root operators.
> 
> Agreed on this, and agreed on the exception:
>> 
>> One issue that we probably SHOULD be looking at though, is whether we need to replace whatever role NTIA has played (if any) in the critical decisions/changes such as DNSSEC or IPv6.
> 
> Oh indeed, and this was IMHO the argument in favor of including representation for RSSAC on the CSC, as additional insight as IANA services need to be monitored and might need to evolve. I'm not coming from a position of deep conviction on the question, it just seems to me something that should be explored, partly because I'm not fully sure of the scope of the CSC in regards to such a decision process. (IOW my interest isn't in "representation" per se, it's in making sure that stakeholders who have to deploy and live with an operational change are able to provide feedback on planning and implementation.)
> 
> There's no documented process of which I am aware for such decisions, so I don't know exactly what NTIA's role has been. I know they've informally consulted root server operators, including via their RSSAC liaison.
> 
> New constraints on IANA's budget, either its structure or oversight, should be reviewed to make sure they're not inadvertently taking away the ability to investigate, plan, implement, or monitor the impacts of such changes-- not just for consulting the root server operators, but more generally.
> 
> 
> thanks,
> Suzanne
> _______________________________________________
> cwg-dtf mailing list
> cwg-dtf at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-dtf



More information about the cwg-dtf mailing list