[DT-F] REVISED: Design Team F kickoff

[Milton L Mueller]

I think Suzanne is raising a number of really good questions. To me, they highlight the arbitrariness, if not the impracticality, of trying to break some of these issues into fragmented "design teams" that provide proposals after a week of discussion. 

Suzanne is right that the post-NTIA relationship between IANA, RZ Maintainer, and a possible appeals or auditing process is intimately linked with general IANA-specific accountability measures, with the role and functions of the CSC, and so on. To me it seems to lend support to the idea of having an IANA-specific governance structure and a PTI board that includes representation from names, numbers and protocols as well as Rootserver operators. 

Can someone remind me of what this DT is actually going to accomplish by Thursday? 

--MM

> -----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 5:21 PM
> To: Gomes, Chuck
> Cc: 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.
> 
> 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
> 
> _______________________________________________
> cwg-dtf mailing list
> cwg-dtf at icann.org
> https://mm.icann.org/mailman/listinfo/cwg-dtf