Hi Jeffrey, *Ketan, *Ketan - Similar to RFC-to-be 9985, note that we have moved RFC 8341 to the Normative References section per https://wiki.ietf.org/group/ops/yang-security-guidelines. Please review and approve this change. Once we receive confirmation, we will make note of it here: https://queue.rfc-editor.org/final-review/rfc9986/.
Jeffrey - Thank you for your approval! We have updated your email and noted your approval here: https://queue.rfc-editor.org/final-review/rfc9986/. 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) Once we receive approval from Alan, Mahesh, Sonal, and Ashesh (and once we receive guidance on questions 17 and 18b), we will move this document forward in the publication process. Thank you! Madison Church RFC Production Center > On Jun 1, 2026, at 2:49 PM, Jeffrey Haas <[email protected]> wrote: > > My email address requires updating to "[email protected]", although jhaas > will get there. :-) > > Beyond that small update and pending review of any changes others would > suggest on 18b, I approve publication. > > -- Jeff > > >> On Jun 1, 2026, at 14:47, Madison Church <[email protected]> >> wrote: >> >> Hi Jeffrey, >> >> We have updated the document and posted files below. See followup responses >> inline. >> >>> On May 29, 2026, at 4:39 PM, Jeffrey Haas <[email protected]> wrote: >>> >>> Madison, >>> >>> On May 29, 2026, at 16:47, Madison Church <[email protected]> >>> wrote: >>>>>> >>>>>> 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. >>> >>> After reviewing the various "note" blocks in the text, I would recommend >>> that we do NOT use the aside element. >>> >>> My justification is that we're using the "this is important and normative" >>> sense rather than "this is a descriptive form of something you can >>> otherwise glance at for additional context". If you'd prefer to suggest a >>> different phrasing than "note" for that sense, we're happy to review other >>> forms that add clarity. >> >> [rfced] Noted! We will leave the text as is. >> >>>>>> 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? >>> >>> There is a distinction here and the length of the articles and modifiers is >>> making this less clear than it might be: >>> >>> "Optimized MD5 Meticulous Keyed ISAAC Authentication" is an authentication >>> type that pairs md5 as the MCI and isaac as the LCI. >>> >>> When using this authentication type: >>> "Optimized Meticulous Keyed ISAAC Authentication, MD5 Format" refers to the >>> PDU format for the MCI >>> "Optimized Meticulous Keyed ISAAC Authentication, ISAAC Format" refers to >>> the PDU format for the LCI >>> >>> Given this construction and intent, if you have suggestions on how to >>> represent each of these forms in a clearer way, we're happy to consider >>> that! >> >> [rfced] Thank you for the clarification. To avoid inserting any technical >> errors, we have left the terms "Optimized MD5 Meticulous Keyed ISAAC >> Authentication" and "Optimized SHA-1 Meticulous Keyed ISAAC Authentication" >> as is for now. If there are any instances of these terms in particular that >> should be replaced with "Optimized Meticulous Keyed ISAAC Authentication, >> MD5 Format" and/or "Optimized Meticulous Keyed ISAAC Authentication, SHA-1 >> Format", please let us know and we will make those updates! >> >> 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 >> >>> >>> -- Jeff > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
