Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.500.181\))
From: Sasha Romijn <sasha@reliablycoded.nl>
In-Reply-To: <7df2aa45-63c8-4e02-bc19-f2934c249cc3@hxr.us>
Date: Fri, 10 Apr 2026 15:01:37 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <73C1828F-7AE1-4692-A3B7-4E8813FA7A8D@reliablycoded.nl>
References: 
 <177577575604.707.5002143833129803545@dt-datatracker-647897bf7-7f2k5>
 <91CA5BCA-3790-45E3-94E3-07C9DCCE633A@reliablycoded.nl>
 <7df2aa45-63c8-4e02-bc19-f2934c249cc3@hxr.us>
To: Andy Newton <andy@hxr.us>
Message-ID-Hash: TVSMCFLVETONYFVA7OVBK2XICBQAU5Z3
CC: The IESG <iesg@ietf.org>, draft-ietf-grow-nrtm-v4@ietf.org,
 grow-chairs@ietf.org, grow@ietf.org
Precedence: list
Subject: =?utf-8?q?=5BGROW=5D_Re=3A_Andy_Newton=27s_No_Objection_on_draft-ietf-grow-n?=
 =?utf-8?q?rtm-v4-09=3A_=28with_COMMENT=29?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/grow/G2q4fT1FUntRgQST0CXnVygUpaw>

Hello Andy,

On 10 Apr 2026, at 12:46, Andy Newton <andy@hxr.us> wrote:
>>> 982        It is RECOMMENDED that IRR Database operators rotate the =
signing key
>>> 983        on their mirror server about once per year.  ....
>>>=20
>>> The "about" leaves a lot of room for interpretation. Can a range be =
specified,
>>> such as between 8 months and 16 months?
>>=20
>> 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.
>=20
> 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.
>=20
> "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.
>>=20
>> This has not come up before. It's a valid point, but we feel this =
change would be too impactful at this time.
>=20
> Understood. My thought was that with just a little more =
generalization, NRTMv4 could be easily adapted to RDAP mirroring, etc...=20=

> something I know some people have mused about. Maybe for NRTMv5=E2=80=A6=


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=