Subject: [GROW] Mike Bishop's Discuss on draft-ietf-grow-nrtm-v4-09: (with DISCUSS and COMMENT)
From: Mike Bishop via Datatracker <[email-masked]>
To: "The IESG" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Date: Mon, 13 Apr 2026 19:04:50 -0700
List-Id: Grow Working Group Mailing List <grow.ietf.org>

Mike Bishop has entered the following ballot position for
draft-ietf-grow-nrtm-v4-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-grow-nrtm-v4/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to Julian Reschke for the HTTP Directorate review
(https://datatracker.ietf.org/doc/review-ietf-grow-nrtm-v4-08-httpdir-lc-reschke-2026-02-27/).

-------------------------------------------------------------------------------
DISCUSS
-------------------------------------------------------------------------------

Section 2, paragraph 7
>    object in large files can be parsed independently.  Files MAY be
>    compressed with GZIP [RFC1952].

What is the motivation for specifying GZIP only? You're using HTTP -- why not
do normal content negotiation and allow clients and servers to select any
mutually acceptable content encoding? (See
https://www.rfc-editor.org/rfc/rfc9110.html#name-accept-encoding)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

Section 4.3.2, paragraph 3
>    *  The mirror server MUST generate a new Snapshot File between once
>       per hour and once per day, if there have been changes to the IRR
>       objects.

What value does the lower bound serve? Is this intended to be read as "MUST NOT
generate a snapshot more frequently than once per hour"? If so, what do clients
do if they notice too-frequent updates?

Section 4.3.2, paragraph 3
>    *  The version number of the new snapshot MUST be equal to the last
>       Delta File version.

Given the last bullet, it might be worth specifying that it's the last Delta
File as of the time the server begins generating the snapshot.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 3
>    some concepts in [RFC8182], as there are overlaps between the two
>    protocols.

It might be nice to name the protocol in that RFC.

Section 2, paragraph 8
>    [RFC7515] format, where the payload is in the JavaScript Object
>    Notation (JSON) format [RFC8259].  The Snapshot File and Delta Files

JSON is on the well-known abbreviations list; you don't need to spell it out.

Section 7.3, paragraph 10
>  and object class name are not case sensitive and therefore mirror clients M
>                                ^^^^^^^^^^^^^^
This word is normally spelled with a hyphen. [EN_COMPOUNDS_CASE_SENSITIVE]

Section 7.3, paragraph 10
> efore mirror clients MUST use case insensitive matching against their local
>                               ^^^^^^^^^^^^^^^^
This word is normally spelled with a hyphen. [EN_COMPOUNDS_CASE_INSENSITIVE]

Section 8.1, paragraph 1
> ECOMMENDED to use NTP [RFC5905] synchronisation to avoid timing discrepancies
>                                 ^^^^^^^^^^^^^^^
Do not mix variants of the same word ("synchronisation" and "synchronization")
within a single text. [EN_WORD_COHERENCY]