I approve these changes. I'll also comment separately on the other issues.
> On Jun 2, 2026, at 12:08 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 >> >> >
signature.asc
Description: Message signed with OpenPGP
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
