Hi Jeff, Can you please check question #16 and let me know your views from the authors' perspective? Even though the question was directed to the AD, I would like to understand the reasons (if any) for deviating from the authors' perspective.
Thanks, Ketan On Sat, May 23, 2026 at 3:57 AM 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? > > 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. > > 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 > > 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. > > 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. > > 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> > <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]
