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]
