Hi Madison/Karen, In general, I am good with Jeff’s responses. For any additional comments, see inline.
> On May 22, 2026, at 1:08 PM, [email protected] wrote: > > Authors and *AD, > > While reviewing this document during AUTH48, please resolve (as necessary) > the following questions, which are also in the source file. > > *AD, please see question #16. > > 1) <!-- [rfced] FYI - We have updated the title as shown below to expand > "BFD". > Please review and let us know any objections. > > Current: > Meticulous Keyed ISAAC for Bidirectional Forwarding > Detection (BFD) Optimized Authentication > --> > > > 2) <!-- [rfced] Please insert any keywords (beyond those that appear in > the title) for use on https://www.rfc-editor.org/search. > --> Perhaps: - secure BFD - replay packets - spoofing - pseudo-random number > > > 3) <!-- [rfced] Please review whether any of the notes in this document > should be in the <aside> element. It is defined as "a container for > content that is semantically less important or tangential to the > content that surrounds it" > (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > --> > > > 4) <!-- [rfced] May we rephrase the sentence below as follows for clarity? > > Original: > An instance of ISAAC is created for transmission and one for > reception. > > Perhaps: > Two instances of ISAAC are created: one for transmission and one for > reception. > --> > > > 5) <!-- [rfced] Would it be helpful for readers to have the definition list in > Section 7 reformatted as two subsections after Section 7? > > Perhaps: > 7. Procedures for BFD Authentication using Meticulous Keyed ISAAC, > ISAAC Format > ... > > 7.1. Transmission Using Meticulous Keyed ISAAC Authentication, ISAAC Format > > The Auth Type field MUST be set to one of two values... > > 7.2. Receipt Using Meticulous Keyed ISAAC Authentication, ISAAC Format > > If the received BFD Control packet does not contain an Authentication > Section... > --> > > > 6) <!-- [rfced] FYI - We have removed the lone quotation mark from this > sentence. If there was an intended quote here, let us know and > we will update the text. > > Original: > That is, there is no "length field which indicates how > long the Secret Key is, and there is no trailing zero or NUL byte > which indicates the end of the Secret Key. > > Current: > That is, there is no length field that indicates how > long the Secret Key is and there is no trailing zero or NUL byte > that indicates the end of the Secret Key. > --> > > > 7) <!-- [rfced] Some author comments are present in the XML. Please confirm > that no updates related to these comments are outstanding. Note that the > comments will be deleted prior to publication. > --> > > > 8) <!-- [rfced] The following citation refers to Section 10 of RFC 5880, > which is the References section. Please review and let us know > how this sentence should be updated to include the correct > section number. > > Current: > For security, each implementation SHOULD randomize their discriminator > fields at the start of a session, as discussed in [RFC5880], Section > 10. > --> > > > 9) <!-- [rfced] Would you like to make use of <sup> for superscript in this > document? In the HTML and PDF outputs, it will appear as superscript. In the > text output, <sup> generates a^b, which was used in the original document. > --> > > > 10) <!--[rfced] We have received guidance from Benoit Claise and the YANG > Doctors that "YANG module" and "YANG data model" are preferred. > We have updated the text to use these forms. Please review. > --> That change is fine. > > > 11) <!-- [rfced] RFC 8177 does not use the term "IETF Keychain Model" (it > does use "YANG key chain model"). Please let us know how we > should update this sentence (or if any updates are needed). > > Current: > This YANG module adds two identities defined in this document to the > IETF Keychain Model [RFC8177]. > > Perhaps: > This YANG module adds two identities defined in this document to the > YANG key chain model described in [RFC8177]. > --> > > > 12) <!--[rfced] The YANG module (Section 13) has been updated as shown > below per the formatting option of pyang. Please let us know of > any concerns. > > - Removed the quote marks from the prefix "bfd-mki" > - Removed the quote marks from the revision date > --> Again, if you used pyang to generate the new format, it should be fine. > > > 13) <!--[rfced] We have updated "SHA1" to "SHA-1" throughout this document > for consistency with the companion document. This includes the > following Auth Type registered with IANA (note that we will > communicate this change to them, if agreeable). Please let us know > of any objection. > > Current (Section 14.4): > 8: Optimized SHA-1 Meticulous Keyed ISAAC Authentication > --> > Agree with Jeff that when it is used in text, the suggested changes are fine. However, in RFC 8177, in the YANG module, its identity is referred to as “sha-1”. > > 14) <!-- [rfced] We have a few questions regarding this sentence. > > a) RFC 8439 uses "ChaCha" rather than "CHACHA". May we update as > follows? Also, is this a list of three items as shown below? > > Current: > Alternative solutions could be AES with hardware acceleration in > Output Feedback Mode (OFB) (FIPS 197, SP 800-38A), or CHACHA > in software [RFC8439], or other well-understood techniques. > > Perhaps: > Alternative solutions could be AES with hardware acceleration in > Output Feedback Mode (OFB) (see FIPS 197 and SP 800-38A), ChaCha in > software [RFC8439], or other well-understood techniques. > > b) Would you like to add citations for "FIPS 197" and "NIST SP > 800-38A" in this sentence with corresponding entries in the > Informative References section? > --> > > > 15) <!-- [rfced] May we rephrase the sentence below for readability and to > specify > what is being protected? > > Original: > Meticulously Keyed ISAAC authentication protects vs. the spoofing of > BFD Up packets and keeping the BFD session Up when it would otherwise > be reset. > > Perhaps: > Meticulously Keyed ISAAC authentication protects the session against the > spoofing of BFD Up packets and keeps the BFD session Up when it would > otherwise be reset. > --> > > > 16) <!--[rfced] *AD, we note that the YANG Security Considerations > (Section 15.2 in this document) varies from the template > in Section 3.7.1 of RFC 9907. We updated the first > three paragraphs in this document to match the template. Please > review and also provide guidance for the following questions: > > a) Paragraph 4 from the template is missing in this document. Should > "There are no particularly sensitive writable data nodes." be included > in this document to address this? > > b) Paragraph 5 from the template is missing in this document. Should > "There are no particularly sensitive readable data nodes." be included > in this document to address this? > > c) Paragraph 6 from the template is missing in this document. Should > "There are no particularly sensitive RPC or action operations." be > included in this document to address this? > > d) Paragraph 4 in this document almost matches paragraph 8 in the > template (which begins with "The YANG module defines a set of > identities, types, and groupings."). Note that "types" and "groupings" > haven been omitted. Please let us know if this is okay or if any > updates are needed for consistency with the template. > --> > > > 17) <!-- [rfced] For the "[ISAAC_]" reference, we recommend changing the > citation > tag since "[ISAAC]" and "[ISAAC_]" may be easily confused. May we update > "[ISAAC_]" to "[ISAAC+]" or "[ISAAC-Plus]"? > --> > > > 18) <!-- [rfced] Terminology > > a) Please review the following terms and let us know how we should update > for consistency. If there are no objections, we will use the form on > the right. > > Sequence number vs. sequence number vs. Sequence Number > secret key vs. secret Key vs. Secret Key Ok. Thanks. > > b) Throughout the text, we note the following variances. > Are these forms okay as is, or are any updates needed for > consistency? Please review. > > BFD Optimized Authentication > BFD Optimized Authentication Mode > BFD optimized authentication modes > Optimized BFD > Optimized BFD authentication modes > Optimized Authentication Mode field > Optimized Authentication mode > Optimization Mode > > Meticulous Keyed ISAAC Authentication > Meticulously Keyed ISAAC authentication > Meticulous Keyed ISAAC authentication mode > Meticulous Keyed ISAAC Auth Type > Meticulous Keyed ISAAC > Meticulous keyed ISAAC > Meticulous Keyed ISAAC Keyed > [Note: Is the second "Keyed" correct here? There are 4 instances.] > > Meticulous Keyed ISAAC MD5 Authentication Format > Meticulous Keyed ISAAC Authentication Format > ISAAC authentication format > > Optimized MD5 Meticulous Keyed ISAAC Authentication > [Note: Are any of the instances above referring to this > Auth Type, which is registered with IANA? Please let us > know if any updates are needed for consistency.] > --> > > > 19) <!-- [rfced] FYI - We have added expansions for abbreviations upon first > use > per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each > expansion in the document carefully to ensure correctness. > --> > > > 20) <!-- [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. > --> > > > Thank you. > > Madison Church and Karen Moore > RFC Production Center > > > > On May 22, 2026, at 1:04 PM, [email protected] wrote: > > *****IMPORTANT***** > > RFC Author(s): > -------------- > > Instructions for Completing AUTH48 > > Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. > If an author is no longer available, there are several remedies > available as listed in the FAQ (https://www.rfc-editor.org/faq/). > > You and you coauthors are responsible for engaging other parties > (e.g., Contributors or Working Group) as necessary before providing > your approval. > > Planning your review > --------------------- > > Please review the following aspects of your document: > > * RFC Editor questions > > Please review and resolve any questions raised by the RFC Editor > that have been included in the XML file as comments marked as > follows: > > <!-- [rfced] ... --> > > These questions will also be sent in a subsequent email. > > * Changes submitted by coauthors > > Please ensure that you review any changes submitted by your > coauthors. We assume that if you do not speak up that you > agree to changes submitted by your coauthors. > > * Content > > Please review the full content of the document, as this cannot > change once the RFC is published. Please pay particular attention to: > - IANA considerations updates (if applicable) > - contact information > - references > > * Copyright notices and legends > > Please review the copyright notice and legends as defined in > RFC 5378 and the Trust Legal Provisions > (TLP – https://trustee.ietf.org/license-info). > > * Semantic markup > > Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> > and <artwork> are set correctly. See details at > <https://authors.ietf.org/rfcxml-vocabulary>. > > * Formatted output > > Please review the PDF, HTML, and TXT files to ensure that the > formatted output, as generated from the markup in the XML file, is > reasonable. Please note that the TXT will have formatting > limitations compared to the PDF and HTML. > > > Submitting changes > ------------------ > > To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > > * your coauthors > > * [email protected] (the RPC team) > > * other document participants, depending on the stream (e.g., > IETF Stream participants are your working group chairs, the > responsible ADs, and the document shepherd). > > * [email protected], which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion > list: > > * More info: > > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > > * The archive itself: > https://mailarchive.ietf.org/arch/browse/auth48archive/ > > * Note: If only absolutely necessary, you may temporarily opt out > of the archiving of messages (e.g., to discuss a sensitive matter). > If needed, please add a note at the top of the message that you > have dropped the address. When the discussion is concluded, > [email protected] will be re-added to the CC list and > its addition will be noted at the top of the message. > > You may submit your changes in one of two ways: > > An update to the provided XML file > — OR — > An explicit list of changes in this format > > Section # (or indicate Global) > > OLD: > old text > > NEW: > new text > > You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > > We will ask a stream manager to review and approve any changes that seem > beyond editorial in nature, e.g., addition of new text, deletion of text, > and technical changes. Information about stream managers can be found in > the FAQ. Editorial changes do not require approval from a stream manager. > > > Approving for publication > -------------------------- > > To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, > as all the parties CCed on this message need to see your approval. > > > Files > ----- > > The files are available here: > https://www.rfc-editor.org/authors/rfc9986.xml > https://www.rfc-editor.org/authors/rfc9986.html > https://www.rfc-editor.org/authors/rfc9986.pdf > https://www.rfc-editor.org/authors/rfc9986.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9986-diff.html > https://www.rfc-editor.org/authors/rfc9986-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9986-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9986 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC 9986 (draft-ietf-bfd-secure-sequence-numbers) > > Title : Meticulous Keyed ISAAC for BFD Optimized Authentication > Author(s) : A. DeKok, > M. Jethanandani, > S. Agarwal, > A. Mishra, > J. Haas > WG Chair(s) : Jeffrey Haas, Reshad Rahman > Area Director(s) : Jim Guichard, Ketan Talaulikar, Gunter Van de Velde Mahesh Jethanandani [email protected]
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
