[GROW] Re: Andy Newton's No Objection on draft-ietf-grow-nrtm-v4-09: (with COMMENT)

[Sasha Romijn <[e-mail]>]

Hello Andy,

On 10 Apr 2026, at 12:46, Andy Newton <[e-mail]> wrote:
>>> 982        It is RECOMMENDED that IRR Database operators rotate the signing key
>>> 983        on their mirror server about once per year.  ....
>>> 
>>> The "about" leaves a lot of room for interpretation. Can a range be specified,
>>> such as between 8 months and 16 months?
>> 
>> We can, but I do not feel that is a real improvement. The range is intentionally vague, the intended boundaries are: not so often that it becomes annoying; not so rarely that it becomes an unfamiliar procedure.
> 
> Would it make sense that this be a non-normative "recommended"? It seems that once the community has operational experience this advice would change anyway.
> Or maybe change the advice to what you have stated above.
> 
> "It is recommended that the IRR Database operators rotate the signing key on their mirror
> server with a frequency that is not disruptive to operations but preserves the familiarity of
> the practices to accomplish key rotation. Many organizations have settled on annual cycles."

I see your point, making it non-normative and explained like you suggest, serves the purpose better. We will adopt that suggestion.

>>> Has the working group considered using media types to describe the type of
>>> content in the files, instead of relying on file name suffixes? That might
>>> offer some flexibility for switching to different compression types, etc..., in
>>> the future.
>> 
>> This has not come up before. It's a valid point, but we feel this change would be too impactful at this time.
> 
> Understood. My thought was that with just a little more generalization, NRTMv4 could be easily adapted to RDAP mirroring, etc... 
> something I know some people have mused about. Maybe for NRTMv5…

That would be interesting. I do imagine RDAP mirroring might have other requirements that aren't well accommodated now. More something for the future.

Sasha