Roman, > On Sep 17, 2025, at 5:44 PM, Roman Danyliw via Datatracker <[email protected]> > wrote: > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > The shepherd report states that there are "no implementations and no known > plans to implement." Why publish this document if there no plans to run the > experiment?
Already answered elsewhere. > I support the DISCUS positions of Deb Cooley and Éric Vyncke. In particular, > Éric emphasizes the need to discuss how an experimental status RFC is making a > normative change to PS status RFC (RFC5880). I believe this was addressed in the other response. These are new authentication types and we're not actually reassigning the "reserved" field. Summarizing to be clear in this thread for the future, the form of the existing authentication types is copied into the new type and noting that the procedures for the existing types are leveraged. If the following text doesn't carry that implication appropriately, any suggested changes to address your concern? "This document repurposes the "Reserved" field as the "Optimized Authentication Mode" field when used for authentication types for optimized BFD procedures." The key phrase being "... when used for". Perhaps "for NEW authentication types"? > > ** idnits reports: > == The document seems to lack the recommended RFC 2119 boilerplate, even if > it appears to use RFC 2119 keywords -- however, there's a paragraph with > a matching beginning. Boilerplate error? > > (The document does seem to have the reference to RFC 2119 which the > ID-Checklist requires). I resolved this by copying the current template verbatim from the referenced authors.ietf.org site. -- Jeff
