[RZERC] Possible scenarios to take up or turn down
Howard Eland
heland at afilias.info
Tue Aug 22 14:44:14 UTC 2017
> 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.
> - Revisions to the technical check criteria for the root zone.
+1
> - Revisions to the authentication mechanisms for TLD managers.
Not sure exactly what you mean on this last one.
>
>> 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
More information about the RZERC
mailing list