Mahesh,
On Sun, Jan 05, 2025 at 08:10:38AM -0800, Mahesh Jethanandani via Datatracker
wrote:
> ----------------------------------------------------------------------
> 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.
Very similarly, since the contents of the padding aren't operationally
significant, I'd prefer that they do not go into the YANG. You can neither
set the contents of the padding, nor can you view the contents of the
padding from the module. The module isn't normative for how the extension
should behave.
What's the motivation to talk about the padding here beyond making any
maintenance of the future RFC have to be in sync with this?
> 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.
Beyond the "well, this is tedious so late in the process", we've
unfortunately hit a point that I object to taking this action. The
referenced section of that draft begins:
"This section is modeled after the template described in Section 3.7
of [RFCAAAA]."
Embedding this text as a normative reference in this
almost-to-the-finish-line draft creates a blocking dependency to
publication. I suspect that's not your intent?
I'm happy to otherwise update boilerplate text. I suspect that the issue
I'm flagging impacts other documents. Please consider how that should be
addressed until the considerations boilerplate is published in an RFC.
> -------------------------------------------------------------------------------
> 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.
Note that the git page for ietf-reviewtool doesn't suggest on how it should
be run to flag things.
> These URLs point to tools.ietf.org, which has been taken out of service:
>
> * http://tools.ietf.org/wg/bfd
I've updated this to be https://datatracker.ietf.org/wg/bfd.
An interesting question is why the WG's default URL lands as a redirect on
"documents" rather than "about"? Possibly a point to raise with the tools team.
> 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/
Fixed.
> 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".
I've chosen regarding. I'd also place money on the RFC editor having
differing opinions here.
> 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".
While I find the voice here fine, I've changed this to be "can be used". As
usual, I expect the RFC editor will have an opinion.
-- Jeff
