Ketan Talaulikar 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 the authors and the WG for this important document for Internet Routing operations. I have a couple of points that I would like to discuss. <discuss-1> Section 4.3.2 says "The mirror server SHOULD continue to produce Delta Files during this window, which means that the server may publish a Snapshot File with a version number older than the most recent Delta File at the time of publication." The scenario being described before that text is definitely possible and defining the behavior is helpful. I am concerned why it is SHOULD and not a MUST to provide deterministic behavior to clients. Also, I would have expected that an incremental version number at the start of the snapshot process is "reserved" for use with that snapshot and further increments be done for the delta files such that the delta files version numbers are larger than the snapshot. Alternately, to keep things simple, why not just suspend the delta file generation while snapshot is in progress, and then do a "one larger catch-up Delta file" as indicated in section 4.3.1 ? Perhaps I am not interpreting that text correctly? <discuss-2> Section 4.3.3 does not talk about the version number and incrementing/update that the server needs to do for the Update Notification file. The use of this version number by the client is specified in Sec 5.4 though and it would be good to specify the server side aspects in 4.3.3? This section is very thin and seems to lack the details on how the server generates/updates and publishes the Update Notification file as compared to the snapshot and delta files. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Please also find below some comments/suggestions: 1) In section 2, "NRTMv3 serials can also contain gaps, NRTMv4 versions may not." ... shouldn't the "may not" be "do not" ? 2) Section 4.3.1, "The URL where the Delta File is published MUST contain the session ID and version number to allow it to be indefinitely cached." Is this caching done by the Mirror Server or someone else? If it is done by the Mirror Server, then this seems to contradicts with section 9.5 "After publishing a new Update Notification File, and absent local policy, a mirror server SHOULD remove any Snapshot and Delta Files that are no longer referenced." and also much of the "Cache Concerns" sections and other text in section 6, 7 and 8 ... or am I missing something? There is also a similar "indefinitely cached" for snapshot in section 4.3.2. 3) Section 5.2, "Mirror clients MUST NOT check more than once per minute." - what does the server do if this happens? _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
