[RZERC] Possible scenarios to take up or turn down

[Jim Reid]

> On 21 Aug 2017, at 22:39, Kim Davies <kim.davies at iana.org> wrote:
>>> 	- 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.)

+1

> 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 think that should be considered routine operational detail rather than a major architectural change. Unless of course those new algorithms and digest types are not supported by an RFC.

> - 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)
> - Revisions to the technical check criteria for the root zone.
> - Revisions to the authentication mechanisms for TLD managers.

Ditto. Though I appreciate IANA might well appreciate having RZERC approve/review these sorts of changes to existing processes. Assuming there’s no other appropriate third party which could do that.
 
>> 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”.

See above. If changes to the technical check criteria (say) are to be in scope Kim, so should a change to the location(s) of the root’s KSK repository. And for the same sorts of reasons: ie some sort of notionally independent third party sanity check.

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

OK. I wonder though if we need to think much about this.

An illustrative list of what is and isn’t in scope has the potential to take on a life of its own. Or be seen by others to be a definitive list that lives forever and can never be changed. We should be very careful about that. Particularly once the current RZERC membership has moved on and the institutional memories we have today have either been forgotten or mutated tomorrow.

Straw man suggestion: how about expecting anyone who asks RZERC to do any work provides a justification of why their proposal is in scope?