Hi Authors, *Ketan *Ketan - We have noted your approval for updates to Section 15.2; see https://queue.rfc-editor.org/final-review/rfc9986/.
Thank you all for your replies! We have updated the document as requested. Please see inline for followup questions and comments. (In an attempt to consolidate email threads, please note that we have also added keywords for this document according to Mahesh’s reply on May 27). > On May 22, 2026, at 5:27 PM, Jeffrey Haas <[email protected]> wrote: > > [Speaking as an author] > On 5/22/26 16:08, [email protected] wrote: >> >> 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 >> --> > Accepted. >> >> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >> the title) for use on https://www.rfc-editor.org/search. >> --> > I have nothing further to add. >> >> 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). >> --> > I am unclear what notes we're discussing. The RFC Editor markup on what > we're reviewing? [rfced] Apologies for being unclear! There are a few instances in the document where <aside> could be applied (for example, the text below in Section 3). To see the use of <aside> in a recently published RFC, see the last paragraph in Section 4.10.1 of RFC 9989: https://www.rfc-editor.org/info/rfc9989/. Let us know if you would like to utilize this element; otherwise, we will leave the text as is. Section 3: Note that BFD Control Packets with the less computationally intensive ISAAC authentication format type are NOT signed or authenticated. Therefore, this format MUST NOT be used to signal BFD state changes. >> 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. >> --> > The new version is clearer. >> >> 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... >> --> > Splitting these into subsections might be better. >> >> 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. >> --> > I think this is fine. >> >> 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. >> --> > Removing the author comments is fine. >> 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. >> --> > Section 9 (Security Considerations) is the appropriate reference. >> 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. >> --> > As long as all formats make it clear that mathematical exponentiation is > being used, this would be good. >> >> 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. >> --> > This question should be directed to Mahesh. >> 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]. >> --> > The update is fine. >> 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 >> --> > This question is for Mahesh, but I believe it is 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 >> --> > For the text updates, I think this is fine. > It would be good to get external review to ensure that the YANG uses, which > are currently "sha1", are consistent with how this cipher is referenced in > other IETF YANG work. Mahesh, and perhaps the SEC-ADs might have suggestions. >> 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. > Consistency with the referenced RFC is best here. >> >> 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? >> --> > I have no specific references to add for these. Perhaps the SEC-ADs might > have appropriate references. >> >> 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. >> --> > This seems better. >> >> 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]"? >> --> > This question to be answered by Alan and the SEC-ADs. [rfced] We will wait for further guidance from Alan before proceeding with any updates for the "[ISAAC_]" reference. >> 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 [rfced] After further review, we have decided to use "sequence number" and "secret key" in this document for consistency across RFC 5880 and RFC-to-be 9985 (this excludes instances where the terms are paired with another noun, e.g., "Sequence Number field"). Please let us know any objections. >> 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 > We are looking for consistency using RFC 5880 for the sequence number > capitalization. > For the optimized authentication, consistency vs. the impending RFC 9985 is > our goal here. > The nouns above perhaps cover slightly different contexts requiring editorial > judgment: > - BFD Optimized Authentication is the broad set of procedures we are > specifying. > - BFD Optimized Authentication Mode is a form of BFD Authentication (c.f. RFC > 5880) that may be selected, and is implemented by this specification. > - Optimized BFD in most of the contexts above are likely forms of BFD > Optimized Authentication. I do see in the current document that this > manifests primarily in the PDU format (section 4.1) as a bare-named field > lacking the BFD designation. In that context, the BFD is redundant. However, > if consistency makes for cleaner reading we can consider expanding the full > name. It is important that the forms be consistent between this RFC-to-be > and RFC 9985-to-be. >> Meticulous Keyed ISAAC Authentication >> Meticulously Keyed ISAAC authentication > The forms of the second sentence above can be changed to "Meticulous Keyed". >> >> Meticulous Keyed ISAAC authentication mode > There is a single use of this in the document. The trailing "mode" can > perhaps be dropped, as long as the context is clear. >> >> Meticulous Keyed ISAAC Auth Type > This form is appropriate. >> >> Meticulous Keyed ISAAC >> Meticulous keyed ISAAC > The forms I see these in are paired to the sha-1 and md-5 forms of the mode. > We are looking for consistency for those pairings. The capitalization for > keyed can match the other instances. >> Meticulous Keyed ISAAC Keyed >> [Note: Is the second "Keyed" correct here? There are 4 instances.] > These instances look like a search and replace issue. I believe the > intention here is that each of these instances is intended to be "Meticulous > Keyed ISAAC, ISAAC format". This should be audited by Alan. [rfced] We will wait for further guidance from Alan before making the updates as described above for "Meticulous Keyed ISAAC Keyed". We have updated all other terms for consistency. >> Meticulous Keyed ISAAC MD5 Authentication Format > There are three distinct formats we're trying to get consistency with. These > are identified by the subsections of section 4. They are the MD5, SHA-1, and > ISAAC formats. >> >> Meticulous Keyed ISAAC Authentication Format > I think this is intended to be the ", ISAAC format". >> >> ISAAC authentication format > Ditto. >> >> >> 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.] >> --> > The instance of this and the SHA-1 entry likely should be the ", MD5 format" > and ", SHA-1 format" forms. [rfced] We note that there are multiple instances of "Optimized MD5 Meticulous Keyed ISAAC Authentication" and "Optimized SHA-1 Meticulous Keyed ISAAC Authentication" in the document . Should all instances of "Optimized MD5 Meticulous Keyed ISAAC Authentication" and "Optimized SHA-1 Meticulous Keyed ISAAC Authentication" be updated to "Optimized Meticulous Keyed ISAAC Authentication, MD5 Format" and "Optimized Meticulous Keyed ISAAC Authentication, SHA-1 Format", respectively? The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9986.txt https://www.rfc-editor.org/authors/rfc9986.pdf https://www.rfc-editor.org/authors/rfc9986.html https://www.rfc-editor.org/authors/rfc9986.xml Updated diff files have been posted here: https://www.rfc-editor.org/authors/rfc9986-diff.html https://www.rfc-editor.org/authors/rfc9986-rfcdiff.html (side by side) https://www.rfc-editor.org/authors/rfc9986-auth48diff.html https://www.rfc-editor.org/authors/rfc9986-auth48rfcdiff.html (side by side) For the Final Review (formerly AUTH48) status page, see: https://queue.rfc-editor.org/final-review/rfc9986/. Thank you! Madison Church RFC Production Center >> 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. >> --> > At first glance, these all seem fine. I'll finish a deeper audit as part of > final approval. >> >> 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. >> --> > I believe nothing is applicable here. > Thanks! > -- Jeff > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
