Hi Eric, We can discuss this once you've had the opportunity to review the 3-document set and welcome your suggestions.
Thanks, Ketan On Mon, Aug 25, 2025 at 7:38 PM Eric Vyncke (evyncke) <evyn...@cisco.com> wrote: > Hi Ketan, > > > > Thanks for your prompt reply, about the IANA considerations, if the “TBD” > is defined in another document, then the DISCUSS moves to section 7 where > “TBD” is mentioned as there is a need for a normative reference to the > other I-D. I.e., the problem must be solved anyway 😊 > > > > Regards > > > > -éric > > > > *From: *Ketan Talaulikar <ketant.i...@gmail.com> > *Date: *Monday, 25 August 2025 at 15:16 > *To: *Eric Vyncke (evyncke) <evyn...@cisco.com> > *Cc: *The IESG <i...@ietf.org>, > draft-ietf-bfd-optimizing-authenticat...@ietf.org < > draft-ietf-bfd-optimizing-authenticat...@ietf.org>, bfd-cha...@ietf.org < > bfd-cha...@ietf.org>, rtg-bfd@ietf.org <rtg-bfd@ietf.org>, Reshad Rahman < > res...@yahoo.com>, rrah...@cisco.com <rrah...@cisco.com> > *Subject: *Re: Éric Vyncke's Discuss on > draft-ietf-bfd-optimizing-authentication-29: (with DISCUSS and COMMENT) > > 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 < > nore...@ietf.org> 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/ ? > > >
