Dear Sandy, First of tall, many thanks to you and your colleagues for the editing services you provide. It is always a joy to see there is a team of friendly people to who help get things across the finish line! :-)
On Mon, Jul 07, 2025 at 08:51:11AM -0700, Sandy Ginoza wrote: > Thank you for your review. We have posted the updated files for review: > https://www.rfc-editor.org/authors/rfc9829.xml > https://www.rfc-editor.org/authors/rfc9829.txt > https://www.rfc-editor.org/authors/rfc9829.pdf > https://www.rfc-editor.org/authors/rfc9829.html I've reviewed rfc9829.txt and have a few small nits. Please see below. > We will wait to hear further regarding items 2 and 7. > >> 2) <!-- [rfced] RFC 9286 defines "fileList" rather than "FileList". We > >> have updated the document accordingly. Please let us know any > >> corrections. I think one instance was missed: OLD: The hash in the manifest's FileList provides a cryptographic guarantee on the Certification Authority's intent that this is the most recent CRL and removes possible replay vectors. NEW: The hash in the manifest's fileList provides a cryptographic guarantee on the Certification Authority's intent that this is the most recent CRL and removes possible replay vectors. > >> In addition, note that the following terminology appears to be used > >> inconsistently throughout the document. Please review these > >> occurrences and let us know if/how they may be made consistent. > >> > >> Manifest FileList vs manifest's FileList (note that we will > >> lowercase FileList as noted above.) > >> > >> Manifest vs manifest (6487 and 9286 seem to use "manifest" except where > >> it's part of a specific name.) Personally I think "Manifest" would be clearer for the reader, because lower-case manifest can also be a verb. But, I also understand a desire for some consistency with 6487/9286. If 9286 wouldn't exist, what would've been the recommended approach from your professional editing perspective? There also is another RFC publication coming down the pipeline (draft-ietf-sidrops-manifest-numbers), this provides an opportunity to establish a new 'norm' (should we opt to go for Manifest in this document). > >> 7) <!-- [rfced] Please review the "Inclusive Language" portion of the > >> online Style Guide > >> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > >> and let us know if any changes are needed. Updates of this nature > >> typically result in more precise language, which is helpful for readers. > >> > >> Note that our script did not flag any words in particular, but this should > >> still be reviewed as a best practice. I reviewed the document and did not spot anything that seems to warrant changes in relationship to the "Inclusive Language" portion of the online Style Guide. I agree and appreciate that carefully considering words often results in more precise language. Kind regards, Job -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
