Hi Reshad, Thanks for combing through the changes.
> On Jul 22, 2020, at 4:10 PM, Reshad Rahman (rrahman) <rrah...@cisco.com> > wrote: > > Mahesh, thanks for addressing my comments. > > I will update the shepherd write-up based on my comments below. > > General: both "BFD control packet" and "BFD packet" are used. I think we > should stick to "BFD control packet". > General: s/BFD Control packet/BFD control packet/ Done. > > Introduction, next-to last paragraph. Instead of "The interval of this > non-state change frame can be...", I'd suggest "The interval of these BFD > packets can be..." or "The interval of the BFD packets without a significant > change can be...". Anyway remove "frame" as previously discussed and avoid > use of "non-state change" now that you've defined what a significant change > is. Done. > > Section 1.2. The new table could be incorrectly interpreted as having 1 > entry. Suggest changing this to bullet form would make it clearer. Ok. > > Section 1.2 introduces the term "configured interval" but section 2 uses the > term "configured period". Also for the description, what about "interval at > which BFD control packets are authenticated in the UP state". > Also wondering if instead we should have a new bfd.AuthUpStateInterval state > variable (see 6.8.1 of RFC5880) since having this value may not always be > configured (implementation specific)? Changed all “configured period” to “configured interval” and updated the description. > > Section 2. Replace "frame" by "packet" or "BFD control packet" as > appropriate. Ok. > > Section 2. Thanks for modifying the table as per our discussions. Regarding > adding AdminDown to the table, I believe I misled you. Our discussion was > based on "what happens if we're UP and receive a packet which says > AdminDown"? As per 6.2 of RFC5880, the receiver would go to DOWN state. > However the rows/columns in the table are for the local state (new and old), > and not for state in received packet. Since we can't go to AdminDown state or > leave AdmnDown state based on a packet received, AdminDown state should be > removed from this table . I think it'd be good to add a reference to the BFD > FSM (6.8.2 of RFC5880) in the paragraph before the table. You mean Section 6.2 of RFC 5880. > > Section 2. For configured period (or whatever we decide to call it) add a > reference to section 1.2. > > Section 4. s/to to/to/ Done. Will post the draft with these changes shortly. > > Regards, > Reshad. > > On 2020-07-13, 4:56 PM, "Rtg-bfd on behalf of Mahesh Jethanandani" > <rtg-bfd-boun...@ietf.org on behalf of mjethanand...@gmail.com> wrote: > > This version of the draft addresses some of the shepherd comments. Welcome > any feedback. > >> On Jul 13, 2020, at 12:07 PM, internet-dra...@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Bidirectional Forwarding Detection WG of >> the IETF. >> >> Title : Optimizing BFD Authentication >> Authors : Mahesh Jethanandani >> Ashesh Mishra >> Ankur Saxena >> Manav Bhatia >> Filename : draft-ietf-bfd-optimizing-authentication-10.txt >> Pages : 8 >> Date : 2020-07-13 >> >> Abstract: >> This document describes an optimization to BFD Authentication as >> described in Section 6.7 of BFD RFC 5880. This document updates RFC >> 5880. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-bfd-optimizing-authentication/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-bfd-optimizing-authentication-10 >> https://datatracker.ietf.org/doc/html/draft-ietf-bfd-optimizing-authentication-10 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-bfd-optimizing-authentication-10 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> > > Mahesh Jethanandani > mjethanand...@gmail.com > > > >
