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]
