[DT-F] REVISED: Design Team F kickoff

Fri Apr 10 01:35:04 UTC 2015

Agreed...

*Cheryl Langdon-O**rr ...  *(CLO)

about.me/cheryl.LangdonOrr
[image: Cheryl Langdon-Orr on about.me]
  <http://about.me/cheryl.LangdonOrr>

On 10 April 2015 at 00:03, Gomes, Chuck <cgomes at verisign.com> wrote:

> Thanks Suzanne for what I think is a very helpful explanation of the root
> zone server operators involvement.  It seems to me that it is a no brainer
> decision that, as you say below, that we want the existing ability for the
> root server operators to collaborate on issues as you describe to continue
> as is with the one caveat that there would be no root zone administrator
> involved after the transition.
>
> Chuck
>
> -----Original Message-----
> From: cwg-dtf-bounces at icann.org [mailto:cwg-dtf-bounces at icann.org] On
> Behalf Of Suzanne Woolf
> Sent: Thursday, April 09, 2015 8:40 AM
> To: Alan Greenberg
> Cc: CWG DT-F
> Subject: Re: [DT-F] REVISED: Design Team F kickoff
>
>
> On Apr 8, 2015, at 10:32 PM, Alan Greenberg <alan.greenberg at mcgill.ca>
> wrote:
>
> > At 08/04/2015 09:10 PM, David Conrad wrote:
> >
> >> Jaap,
> >>
> >> >> The current procedure is documented at a high level in SAC067,
> >> >> figure #1
> >> > > (and its description) on pages 13 and 14. In the near term, the
> >> > > authorization step (step 3 in figure #1) can probably most simply
> >> > > be addressed by having ICANN instead of NTIA "push the button" to
> >> >authorize
> >> > > the change.
> >> >
> >> >I was actually triggered by the phrase "architecture for publication
> >> >of the Root Zone" in Alan's mail. I read that as a slightly bigger
> >> >task (including root zone server operators etc.) then just the
> >> >threeway exchange we have currently.
> >>
> >> My interpretation was that the focus of this Design Team was on the
> >> relationships that are directly impacted by the removal of NTIA. In
> >> my view that would be the IANA Function Operator and the Root Zone
> >> Maintainer relationships. However, I could be wrong...
> >
> > That was my original intent.
>
> I'm still getting my head around the other material (have been also
> juggling some other commitments) but I can comment fairly directly on this.
>
> TL;DR version: "directly impacted by the removal of NTIA" mostly doesn't
> include root server operators, but under a few conditions it does and we
> don't want to inadvertently ignore or close off needed flexibility there.
>
> Elaborating a little....My views only, since there's no time to run back
> through review by RSSAC or a similar process; speaking only for myself,
> etc-- but David and Chuck both have insight here too.
>
> In terms of day-to-day operations, the root zone distribution system
> relies on interaction among all of the participants with the Root Zone
> Maintainer. That is, part of the work of the Maintainer is to operate
> network resources and servers, and participate in associated procedures,
> that the root server operators use to obtain the root zone so they can
> redistribute it in turn. Almost all of this interaction is automated, as
> DNS provides reliable, well-understood mechanisms for distributing the zone
> among the servers, catching operational errors in that process, and so on.
> There is interaction among staff, but typically that occurs in the context
> of RSSAC, or interactions among operations staff as routine changes are
> made to hardware or software or procedures. Most of the root server
> operators have been on record for many years now that they don't perform
> their own checks on the root zone and assume no authority over it; "we
> serve what we're given" by the Root Zone Maintainer.
>  There's no direct interaction between IANA staff and root server
> operators in the course of normal operations, or between NTIA and root
> server operators. All three of the current Root Zone Management partner
> organizations have liaisons to RSSAC, who participate in the work there,
> and we're happy to have them-- but RSSAC isn't an operational body and has
> no direct authority over anyone.
>
> However, historically, there have been two areas where somewhat ad-hoc
> interaction between root server operators and all of the Root Zone
> Management Partners may occur:
>
> 1. It  has occasionally been the case that security concerns arise
> somewhere in the system for generating and distributing the root zone, and
> it's been considered good practice to share information across
> organizations and operations in order to respond effectively.
>
> 2. In a few cases in the past, there's been an identified need for basic
> changes to certain technical parameters in the root zone itself, with a
> corresponding need to assess risks, review options, plan deployment, and
> monitor results. The easy examples include deployment of DNSSEC, the
> addition of IPv6 resource records to the root zone to enable IPv6
> reachability of root servers and TLD servers, and assessment of the impact
> of a larger root zone on DNS operations as part of the new gTLD effort. In
> those cases, root server operators have been consulted, through both RSSAC
> and operational relationships. I have always understood that the specific
> decisions on those matters were made by the Root Zone Management partners
> together, although I'm not aware of documentation of a process. I suspect
> David and Chuck have more insight on that than I do.
>
> It seems to me that we need to be sure that the post-NTIA regime still has
> a way to raise such questions and make decisions about them.  However, that
> seems reasonable to leave "TBD," in that mostly for now we want to make
> sure that future organizations involved in root zone management aren't
> unnecessarily constrained from doing these aspects of the job.
>
> Otherwise, I think interaction with root server operators is contained
> within the Maintainer function.
>
>
> best,
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/cwg-dtf/attachments/20150410/e9f27e55/attachment-0001.html>