On Thu, Feb 3, 2022 at 10:14 PM Acee Lindem (acee) <acee= [email protected]> wrote:
> Hi Ketan, > > Do you remember who this comment came from? I definitely think anyone who > reads the abstract of the draft wouldn’t be confused and don’t agree with > the comment. > > > > Also, this is meant to be a per-interface sub-option of the existing BFD > configuration – right? > That's why I was asking whether multi-hop BFD is in scope (multi-hop BFD is not enabled per interface). If so, then some suggestions: https://mailarchive.ietf.org/arch/msg/lsr/wffR6A6Vq-wtKYPiLE2wuVyJDNY/ Regards, Muthu > There is at least one place that would lead one to believe it is pre-node. > > > > Thanks, > Acee > > > > *From: *Ketan Talaulikar <[email protected]> > *Date: *Thursday, February 3, 2022 at 10:31 AM > *To: *Acee Lindem <[email protected]> > *Cc: *"Acee Lindem (acee)" <[email protected]>, " > [email protected]" <[email protected]>, " > [email protected]" < > [email protected]> > *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for > BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 > > > > Hi Acee, > > > > The authors had picked the term "*OSPF BFD Strict-Mode*" originally - > please refer to > https://datatracker.ietf.org/doc/html/draft-ketant-lsr-ospf-bfd-strict-mode-01. > However, post IETF presentation, we got feedback from WG members that the > term was misleading and gave an impression that the proposal was > introducing a "strict-mode" in BFD. What we are doing is introducing a > "strict-mode" of operation in OSPF for BFD usage. > > > > We are open to any suggestions for change/clarity. > > > > Thanks, > > Ketan > > > > > > On Thu, Feb 3, 2022 at 2:07 AM Acee Lindem (acee) <[email protected]> wrote: > > Speaking as Document Shepherd: > > > > I have some editorial comments that I will pass on to the authors offline. > One change I didn’t suggest since it was a big change was from “Strict-Mode > for BFD” to simply “BFD Strict-Mode”. What are your thoughts on this? > > > > We’ve had some good discussion and an updated version is coming with some > updates based on that discussion. Remember that we don’t necessarily have > to incorporate every suggested change but simply need to conclude the > discussion. > > > > Thanks, > > Acee > > > > *From: *"Acee Lindem (acee)" <[email protected]> > *Date: *Friday, January 28, 2022 at 7:24 AM > *To: *Acee Lindem <[email protected]>, "[email protected]" <[email protected]> > *Cc: *"[email protected]" < > [email protected]> > *Subject: *Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for > BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04 > > > > Speaking as WG member: > > > > I support publication of the document. As indicated by the Albert Fu, it > has been implemented by two vendors. I will provide WG Last Call comments > when I prepare the Shepherd’s report. > > > > Thanks, > > Acee > > > > *From: *Lsr <[email protected]> on behalf of "Acee Lindem (acee)" > <[email protected]> > *Date: *Thursday, January 27, 2022 at 12:09 PM > *To: *"[email protected]" <[email protected]> > *Cc: *"[email protected]" < > [email protected]> > *Subject: *[Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - > draft-ietf-lsr-ospf-bfd-strict-mode-04 > > > > LSR WG, > > > > This begins a two week last call for the subject draft. Please indicate > your support or objection on this list prior to 12:00 AM UTC on February 11 > th, 20222. Also, review comments are certainly welcome. > > Thanks, > Acee > > > > _______________________________________________ > Lsr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lsr >
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
