[DT-F] REVISED: Design Team F kickoff

[Suzanne Woolf]

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