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. > >>> 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! -- Jeff -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
