[DT-F] REVISED: Design Team F kickoff

Alan Greenberg alan.greenberg at mcgill.ca
Sun Apr 12 18:31:11 UTC 2015


Sorry, I have had a number of personal functions this weekend which 
have keep me away from e-mail.

What we WILL accomplish by Thursday clearly remains to be seen. What 
we were charged with accomplishing was to recommend changes to the 
Root Zone management process as needed or desired for the transition 
to take place.

Currently the NTIA must approve all changes before they are released 
to be RZ Maintainer (Verisign) for implementation.

Since the NTIA will now be "out of the loop", we need to recommend:

- How the authorization function is to be replaces, if at all
- What other changes do we recommend, if any, to compensate for the 
removal of the NTIA authorization
- What other improvements do we recommend making to address perceived 
weaknesses in the present process (despite the NTIA presence).

The NTIA has made it clear that any proposal officially submitted 
must be ready for implementation - no further design post-acceptance, 
so we MUST cover these areas before formal submission.

We have been requested to flesh this out as much as possible in time 
for the publication of the next report, with an absolute cutoff by 
this coming Thursday.

I am hoping that we can make such a proposal, and you will see more 
from me in this later today.

In my mind, we do not have to reach closure on such a proposal, but 
we should have SOMETHING for the communities to comment on.

Alan

At 12/04/2015 12:30 PM, Gomes, Chuck wrote:
>I am asking myself the same question Milton.
>
>Chuck
>
>-----Original Message-----
>From: Milton L Mueller [mailto:mueller at syr.edu]
>Sent: Saturday, April 11, 2015 11:41 AM
>To: Suzanne Woolf; Gomes, Chuck
>Cc: CWG DT-F
>Subject: RE: [DT-F] REVISED: Design Team F kickoff
>
>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
>_______________________________________________
>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