BFD Encapsulated in Large Packets
draft-ietf-bfd-large-packets-16

Section 6, Security Considerations:  As both Brian Trammell and Joe Salowey suggest, please add a sentence for implementers to take care when there are dynamic packet sizes.  Also add a link to the BFD RFC (RFC 5880).

Nicely written document.

Section 5.2, paragraph 21
>        leaf pdu-size {
>          if-feature "padding";
>          type padded-pdu-size;
>          description
>            "If set, this configures the padded PDU size for the
>             Asynchronous mode BFD session. By default, no additional
>             padding is added to such packets.";
>        }

The description should say that the padded data is all zeroes, just as it says in the content of the draft. Once the YANG module is stripped from the document, implementors are only looking at the YANG module for guidance.

Section 6.1, paragraph 1
>    The YANG module specified in this document defines a schema for data
>    that is designed to be accessed via network management protocols such
>    as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
>    is the secure transport layer, and the mandatory-to-implement secure
>    transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
>    is HTTPS, and the mandatory-to-implement secure transport is TLS
>    [RFC8446].  The NETCONF Access Control Model (NACM) [RFC8341]
>    provides the means to restrict access for particular NETCONF or
>    RESTCONF users to a preconfigured subset of all available NETCONF or
>    RESTCONF protocol operations and content.

This particular paragraph of the template has undergone a few updates. See Section 3.7.1 of draft-ietf-netmod-rfc8407bis-21. Please adjust the text here to reflect those changes.

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

These URLs point to tools.ietf.org, which has been taken out of service:

 * http://tools.ietf.org/wg/bfd

Section 8, paragraph 1
>    The authors would like to thank Les Ginsberg, Mahesh Jethandani,
>    Robert Raszuk, and Ketan Talaulikar, for their valuable feedback on
>    this proposal.

s/Jethandani/Jethanandani/

Section 4.1, paragraph 3
> d follow normal BFD procedures with regards to not having received control p
>                                ^^^^^^^^^^^^^^^
Use "in regard to", "with regard to", or more simply "regarding".

Section 4.3, paragraph 3
> able MTU for the session is able to be used. 4.5. Equal Cost Multiple Paths (
>                                     ^^^^^^^
Avoid the passive voice after "to be able to".

Thank you to Dan Romascanu for the GENART review.

What John said, which is what Warren said, which is what Jim said.

Copying Jim's "Nicely written document."

The -15/-16 version addresses my discuss point well, thanks for this.