[DT-F] REVISED: Design Team F kickoff

Suzanne Woolf suzworldwide at gmail.com
Fri Apr 10 21:21:28 UTC 2015


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.

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? 

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?

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