Mahesh Jethanandani has entered the following ballot position for draft-ietf-bfd-large-packets-14: No Objection
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-large-packets/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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".
