[DT-F] REVISED: Design Team F kickoff

[Alan Greenberg]

At 09/04/2015 08:40 AM, Suzanne Woolf wrote:

>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.

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.

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.

Alan



>best,
>Suzanne