Hi Eric, I'll try to clarify and the authors can update/correct as well.
On Mon, Aug 25, 2025 at 4:36 PM Éric Vyncke via Datatracker < [email protected]> wrote: > Éric Vyncke has entered the following ballot position for > draft-ietf-bfd-optimizing-authentication-29: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > > # Éric Vyncke, INT AD, comments for > draft-ietf-bfd-optimizing-authentication-29 > CC @evyncke > > Thank you for the work put into this document. > > Please find below blocking DISCUSS points, some non-blocking COMMENT > points/nits (replies would be appreciated even if only for my own > education). > > Special thanks to Reshad Rahman for the shepherd's detailed write-up > including > the WG consensus *and* the justification of the intended status. > > I hope that this review helps to improve the document, > > Regards, > > -éric > > ## DISCUSS (blocking) > > As noted in > > https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/ > , > a DISCUSS ballot is a request to have a discussion on the points below; I > really think that the document would be improved with a change here, but > can be > convinced otherwise. > > ### Sections 6 & 7 > > Should this document formally update RFC 5880 ? Especially based on > section 7 > `This document repurposes the "Reserved" field as the "Optimized > Authentication > Mode" field when used for authentication types for optimized BFD > procedures.` > KT> Please check https://datatracker.ietf.org/doc/html/rfc5880#section-4 for the optional authentication section. Further the sections 4.2/3/4 define the authentication sections for their respective types. This document lays the framework for a new set of optimized authentication types (which are specified in the accompanying sequence number document) and hence defines a new common authentication section layout for those optimized auth types. Hence, I don't think this qualifies as an "update" (but that is a grey area). More importantly though, this being experimental is not matured enough to "update" RFC588 that is PS. So perhaps the "updates" debate can be kicked down the road if/when this document gets promoted to PS? > > ### Section 7 > > s/excepting that Auth Type is *still* TBD and that *Reserved* is set to > 1/excepting that Auth Type is TBD and that *"Optimized Authentication > Mode"* is > set to 1/ > > As 'Reserved' has just been reused, then the new field name must be used. > > ### Section 7.1 > > The text is about OptMode being 1 or 2 while the previous section > introduced > these values with "For example" and restricting it to MD-5-related > authentication. It is either an example (like section 7) or normative (like > section 7.1). > > ### Section 9 > > Even more critical, there is no request to the IANA to allocate the `TBD` > authentication type in > > https://www.iana.org/assignments/bfd-parameters/bfd-parameters.xhtml#bfd-parameters-2 KT> For the above 3 points, I will let the authors respond. However, the context is that the specific types are defined in the accompanying sequence number documents while this document provides the common framework. So, the IANA allocation happens in https://www.ietf.org/archive/id/draft-ietf-bfd-secure-sequence-numbers-23.html#name-bfd-auth-types . There were a lot of discussions during the AD evaluation of these 3 documents, and the contents of the document is an outcome of that. Welcome any text suggestions to clarify the structure that I just described. Thanks, Ketan > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > ## COMMENTS (non-blocking) > > ### Section 3 > > In `If optimized authentication mechanisms are in use` the 'optimized > authentication mechanisms' have not been formally specified as 'the > mechanisms > described in this document'. Suggest adding it either here '(i.e., this > specication)' or in the terminology section. > > Unsure whether this draft is the right place to say "SHA-2 is left for > future > study" (if BFD does not support it). > > ### Section 3.1 > > s/do not require a poll sequence, such as a bfd.DetectMult are/do not > require a > poll sequence, such as a bfd.DetectMult*,* are/ ? > > ### Section 4 > > Readers (including me) will welcome an expansion of ISAAC. > > ### Section 5 > > Is it about "reauthentication" or "authentication refresh" ? > > ### Section 8 > > s/Optimizing Authentication YANG Model/Optimizing Authentication YANG Data > Model/ ? > > > >
