[RZERC] Possible scenarios to take up or turn down
Kim Davies
kim.davies at iana.org
Mon Aug 21 21:39:02 UTC 2017
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?
> > - 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.)
> > - 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.
- 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.
> 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 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.
kim
More information about the RZERC
mailing list