Re: I-D Action: draft-ietf-bfd-optimizing-authentication-10.txt

["Reshad Rahman (rrahman)" <[e-mail]>]

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/

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.

Section 1.2. The new table could be incorrectly interpreted as having 1 entry. Suggest changing this to bullet form would make it clearer.

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)?

Section 2. Replace  "frame" by "packet" or "BFD control packet"  as appropriate.

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.

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/

Regards,
Reshad.

On 2020-07-13, 4:56 PM, "Rtg-bfd on behalf of Mahesh Jethanandani" <[e-mail] on behalf of [e-mail]> wrote:

    This version of the draft addresses some of the shepherd comments. Welcome any feedback.

    > On Jul 13, 2020, at 12:07 PM, [e-mail] 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
    [e-mail]