IETF Last Call Review of draft-ietf-sidrops-manifest-numbers-07
review-ietf-sidrops-manifest-numbers-07-rtgdir-lc-dukes-2025-08-04-00
| Request | Review of | draft-ietf-sidrops-manifest-numbers |
|---|---|---|
| Requested revision | No specific revision (document currently at 08) | |
| Type | IETF Last Call Review | |
| Team | Routing Area Directorate (rtgdir) | |
| Deadline | 2025-08-06 | |
| Requested | 2025-07-23 | |
| Requested by | Mohamed Boucadair | |
| Authors | Tom Harrison , George Michaelson , Job Snijders | |
| I-D last updated | 2025-08-21 (Latest revision 2025-08-18) | |
| Completed reviews |
Genart IETF Last Call review of -07
by Ines Robles
(diff)
Rtgdir IETF Last Call review of -07 by Darren Dukes (diff) Opsdir IETF Last Call review of -07 by Daniele Ceccarelli (diff) Secdir Telechat review of -07 by Barry Leiba (diff) |
|
| Assignment | Reviewer | Darren Dukes |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-sidrops-manifest-numbers by Routing Area Directorate Assigned | |
| Posted at | https://mailarchive.ietf.org/arch/msg/rtg-dir/csV3QQvfF38RTKvZli3WZssgT1I | |
| Reviewed revision | 07 (document currently at 08) | |
| Result | Ready | |
| Completed | 2025-08-04 |
review-ietf-sidrops-manifest-numbers-07-rtgdir-lc-dukes-2025-08-04-00
I'm reviewing this draft on behalf of Routing Area Directorate. The draft is well written, and clearly states that it updates RFC9286. I see a few nits (below) but nothing major. #1 The term filename is used throughout to describe the name that, upon change, results in a reset of the manifest number. But "filename" is not defined in RFC9286. Do the authors intend to refer to FileAndHash or the file name in FileAndHash, something else? If FileAndHash or FileList is the target should filename be replaced with FileAndHash to be fully resolved to a defined term? #2 Does the process described in section 2 apply to any change in the FileList associated with a manifest number or just the file name in a single FileAndHash? #3 I had to read the Section 3 "Section 2 contains a specific update to [RFC9286]" to understand that section 2 was in fact the update to RFC9286. That is worth clarifying in Section 2 itself.