Authors,
While reviewing your document during Final Review, please reply to the issues
in the GitHub repository
(https://github.com/rfc-editor-drafts/FinalReview-rfc10031/issues), which are
listed below for backup. The numbers below correspond to issue numbers.
2) a) We have edited instances of "OTS signatures" to "OTSs" in order to avoid
the repetitive expansion "one-time signature signatures". Alternatively, it
could be simply written out when plural. What is your preference? There are two
instances; for example:
Original:
Additional operational complexity arises when part of the
available OTS signatures are allocated ...
Current (abbreviation with 's'):
Additional operational complexity arises when part of the
available OTSs are allocated ...
Perhaps (written out when plural):
Additional operational complexity arises when part of the
available One-Time Signatures are allocated ...
b) May we update two instances as follows (abstract and introduction)?
Original: One-Time Signatures (OTS)
Perhaps: One-Time Signatures (OTSs)
We note
- NIST SP 800-208, Section 2.2, lists "OTS" as "One-time signature".
- RFC 9802 used "One-Time Signatures (OTS)" without an 's' on the
abbreviation. However, "OTSs" is more accurate for the plural.
3) May we rephrase the following sentence for clarity?
Current:
Note that in particular, implementations of Stateful HBS or in alternative
signature mechanisms, the state and private key might be inseparable.
Perhaps:
In particular, the state and private key might be inseparable in
implementations
of Stateful HBS or in alternative signature mechanisms.
4) Does "This" refer to involvement or training?
(The preceding sentence is included for context.)
Original:
Many of the prescribed state management options require a high degree
of operator involvement which means one should consider the costs
associated with training the operator element. This is needed to
ensure processes and procedures are adhered to and failures caught
early and corrected before ...
Perhaps:
Many of the prescribed state management options require a high degree
of operator involvement, so one should consider the costs
associated with training the operator element. This training is needed to
ensure processes and procedures are adhered to and failures are caught
early and corrected before ...
5) May this be rephrased as follows? This is to avoid repeating
"mechanisms" and to clarify that the listed items (rather than just one)
ensure that multiple parties would have to collude.
Original:
Mechanisms also should be put in place to mitigate the ever-present
insider threat via mechanisms such as M-of-N controls, ensuring
least-privileges amongst participants, and enforcing a segregation of
duties to ensure multiple parties are required to collude to
undermine a solution's security.
Perhaps:
Mechanisms should be put in place to mitigate the ever-present
insider threat; these include M-of-N controls, least-privileges
amongst participants, and a segregation of duties, which
ensure that an attack would require collusion of multiple parties.
6) FYI - We have updated the following sentence to use "Stateful HBS key"
instead of "S-HBS key" for consistency.
Current:
In theory, multiple signing devices can utilize reservation intervals to
carve out portions of signing space so that a single Stateful HBS key can be
shared
amongst multiple devices, leading to potential performance and
disaster-recovery benefits.
7) 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.
Thank you.
Alice Russo
RFC Production Center
On Aug 6, 2026, [email protected] wrote:
*****IMPORTANT*****
RFC Author(s):
--------------
Your document has now entered Final Review (previously AUTH48).
The document was edited in kramdown-rfc as part of the RPC pilot test (see
https://www.rfc-editor.org/rpc/wiki/doku.php?id=pilot_test_kramdown_rfc).
Final Review is being handled in GitHub as part of the GitHub pilot test
(see
https://www.rfc-editor.org/rpc/wiki/doku.php?id=rpc-github-phase-0-pilot-test).
Your document is available for review at:
https://github.com/rfc-editor-drafts/FinalReview-rfc10033
Please do the following:
a) accept your invitations to join the repo as collaborators.
b) see the README for details on the Final Review process:
https://github.com/rfc-editor-drafts/FinalReview-rfc10033/blob/Approved/README.md
c) review the edits in the RPC-edits pull request:
https://github.com/rfc-editor-drafts/FinalReview-rfc10033/pulls
d) address the issues:
https://github.com/rfc-editor-drafts/FinalReview-rfc10033/issues
Once the content of the .md file is stable, we will convert it to .xml
and provide the .html, .pdf, .txt, and .xml files for review.
You and your coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Once the document has been reviewed and approved by all of the authors,
it will be published as an RFC. If an author is no longer available,
there are several remedies; see the Unavailable Authors section
(https://authors.ietf.org/rfc-publication-process#unavailable-authors).
Details on the status of your Final Review are here:
https://queue.rfc-editor.org/final-review/rfc10033/
Please let us know if you have any questions.
Thank you for your cooperation,
Madison Church and Alice Russo
RFC Production Center
--
auth48archive mailing list -- [email protected]
To unsubscribe send an email to [email protected]
