Hi Madison, You have my approval for this document as well for that change.
Thanks, Ketan On Tue, Jun 2, 2026 at 9:38 PM Madison Church <[email protected]> wrote: > 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]
