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] _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
