[RZERC] Possible scenarios to take up or turn down

[Howard Eland]

> On Aug 22, 2017, at 9:44 AM, Howard Eland <heland at afilias.info> wrote:
> 
> 
>> On Aug 21, 2017, at 4:39 PM, Kim Davies <kim.davies at iana.org> wrote:
>> 
>> Hi folks,
>> 
>> Quoting Jim Reid and others on Monday August 21, 2017:
>>>> 
>>>> - Introduction of RRTYPEs not previously included in the root zone (this would cover DNSSEC in the past).
>>>> - Changes which would cause a “significant” change in size to the root zone (Significant TBD).
>>>> - Significant changes to the operation of the root zone, such as
>>>> 	- Change in root zone operator
>> 
>> What do we envisage RZERC's role is in this scenario?
> 
> Perhaps a review of any new potential operator’s history as it pertains to DNS operations?  Impact study of how the new operator’s network coverage could potentially change query paths?
> 
>> 
>> 
>>>> 	- Change in DNSSEC key algorithm or size
>>>> 	- KSK roll?
>> 
>> Assuming this KSK roll concludes in a normal fashion, it seems to me
>> performing a key rollover will become perfunctory (i.e. rolling every x
>> years). I don't see a KSK roll being elevated to this group unless
>> it meets the other criteria above (i.e. new algorithm, possibly new
>> size.)
> 
> What about emergency KSK rolls?  I’m not saying we bless a roll before it occurs, but should we look at the procedures for this type of activity to ensure they are in line with keeping the stability of the root zone?
> 
>> 
>>>> - Changes in operational policy
>>>> 	- Significant change in root DPS (Significant TBD)
>>>> 
>>>> 
>>>> Possible list of topics the RZERC committee should decline to review:
>>>> 
>>>> - Daily “standard” changes to the root zone (Standard TBD).
>>>> - Introduction of new TLDs into the root zone (subject to the size bullet above).
>> 
>> A couple of other scenarios I had in mind that don't reflect architectural
>> changes to the root zone content itself:
>> 
>> - Support for additional algorithms and digest types for delegations.
> 
> I believe I mentioned this above for the root zone, but yes, the same could be said for delegations.
> 
>> - Upgrades to the software used to manage the root zone and root zone workflow
>> (except as it pertains to other characteristics deemed to be in-scope)
> 
> Not sure I want to do work every time there’s a patch to an operator’s software.  Would that also include network gear upgrades?  This seems intractable to me.

Please ignore my nonsense immediately above.  I mis-read Kim’s list as the “yes” list, not the “no” list.  Apologies to all of the confusion (and thanks to Peter for quietly pointing out my error!).  I agree this is out of scope.

> 
>> - Revisions to the technical check criteria for the root zone.
> 
> +1 

As part of my misread - I actually think we should be looking at this.

> 
>> - Revisions to the authentication mechanisms for TLD managers.
> 
> Not sure exactly what you mean on this last one.

Since I’m not sure what this is, I can’t say one way or the other here.

> 
>> 
>>> One thing that I think could/should be added to the list is getting
>>> a root key repository outside the USA. Suppose US airspace gets closed
>>> down. Or immigration policies make it impractical for foreigners to
>>> serve as TCRs.
>> 
>> What would be the scope of RZERC's consideration of such a change? Where
>> the root management partners keep their physical facilities seems to me
>> beyond "architectural changes to the content of the DNS root zone”.
> 
> I’m concerned that this moves us more into Layer 9 - are we going to look into International policy changes?
> 
>> 
>>> I assume that RZERC is not going to do any work on whatever ends up
>>> on the list we compile. Until of course someone approaches us with a
>>> proposal that’s in scope for RZERC.
>> 
>> I think that's correct. What we discussed on the call was having illustrative
>> scenarios that would inform thinking about what is in-scope and out-of-scope.
> 
> +1
> 
> -Howard
> 
>> 
>> kim
>