Hello Andy, Thank you for your review.
We've adopted several of your suggestions in: https://github.com/mxsasha/nrtmv4/commit/5d4918454b3fcc3902ccb797f11d33bb58e82c5c More responses inline: On 10 Apr 2026, at 01:02, Andy Newton via Datatracker <[email protected]> wrote > 315 server publishing NRTMv4 for RIPE and RIPE-NONAUTH, will generate > two > > Would "RIPE and RIPE-NONAUTH (two separate IRR databases)" make it clearer > to the reader that RIPE and RIPE-NOAUTH refer to separate databases? Yes, that would be clearer. Adopted. > 416 ... It is RECOMMENDED to > 417 modify objects in such a way that this change is evident to humans > 418 reading the object text, for example, by adding remark lines or > 419 comments. > > Without a specific action to take, is this RECOMMENDED normative? Can the > advice to add remarks or comments be made THE action to take? This RECOMMENDED is meant to refer to the action of marking a server-modified object as such. We changed the language to make this clearer. > 934 It is RECOMMENDED for mirror clients to be flexible where possible > [..] > > This is good advice, but it is unclear what action is to be taken to be > flexible. I think this should be a non-normative "recommended". I agree, this is now non-normative. > 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. > 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. > I know this is a nit, but I think the objects are "respresented using RPSL", > where storage could be done by any means... such as a denormalized SQL db. Entirely agreed. We changed it to represented. Thanks, Sasha _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
