Hi Jeff, > On Jan 14, 2025, at 3:03 PM, Jeffrey Haas <[email protected]> wrote: > > Mahesh, > > On Tue, Jan 14, 2025 at 11:52:58AM +0530, Mahesh Jethanandani wrote: >>> On Jan 14, 2025, at 12:20 AM, Jeffrey Haas <[email protected]> wrote: >>> Two points from Mahesh linger pending his response: >>> 1. I don't think we should discuss padding contents in the YANG module, and >>> await his justification for why he thinks it belongs in there. >> >> It is not so much that I was suggesting that the padding contents be >> discussed. My point was that you have the following description for >> bfd.PaddedPduSize in Section 3 and it says: >> >> The BFD transport protocol payload size (in bytes) is increased to this >> value. The contents of this additional payload MUST be zero. The contents of >> this additional payload SHOULD NOT be validated by the receiver. >> >> My suggestion was that the YANG model reflect similar text. The reasoning >> behind it is that once the YANG module is stripped off the RFC, an >> implementor may not see the text reflected in the document. The text in the >> YANG model reads as follows: >> >> "If set, this configures the padded PDU size for the >> Asynchronous mode BFD session. By default, no additional >> padding is added to such packets.”; > > I understand that. > > YANG models are for operators, not implementors of underlying protocol > extensions. For normative behaviors, it's appropriate to have a single > point of truth - the RFC document - describe what to do. > > From an operational standpoint, we could informationally say that the > padding contents are zero and otherwise ignored by the protocol. Is this > helpful to the operator? Probably not. It also creates a maintenance > touchpoint in the YANG module if the underlying contents and validation of > the padding is adjusted in a future extension for BFD large. > > Considering we've gone back and forth on such things several times over the > life of what should have been a trivial draft, I'm now sensitive to not > create unnecessary entanglements. > > If you insist, I can add such text there. But it's another thing I'll be > treating as a #pragma to silence the IESG warnings and not because I think > it improves document quality.
I do not agree with everything you say here, but this is not a hill I am prepared to die on. > >>> 2. While the YANG security considerations boilerplate update request seems >>> otherwise reasonable, the desired format creates a MISREF. This is a more >>> general issue than just this specific document and is unlikely to be an >>> intended side effect. We await his advice on how to reconcile that issue. >> >> What aspect creates a MISREF? The contents of the template or where the >> template reside? The latter can be an informative reference. No? > > Your request was to "adjust my text to reflect those changes". The updated > document and section referenced leads with content in its CODE, again: > > "This section is modeled after the template described in Section 3.7 > of [RFCAAAA]." > > We call this sort of thing "boilerplate" because the expectation is you work > from the content verbatim rather than "by inspiration". > > If your request is "go ahead and replace RFCAAAA with the current version of > the draft text and cite it informationally, but otherwise use that format" - > I can do so. However, what I would expect the procedure to be is to copy > the RFCAAAA and cite the draft normatively which would create a MISREF until > the document is published as an RFC. The problem we have is that the template text in Section 3.7 of RFC 8407 is wrong. For example, it cites Secure Shell (SSH) as [RFC6242], which is incorrect. SSH is [RFC4252], whereas RFC6242 is “Using the NETCONF Protocol over Secure Shell (SSH)." That is what the template in rfc8407-bis is trying to correct. RFCAAAA has been cited as informative [1] by plenty of documents, but none of them are RFCs as yet. Besides, some cite it normatively also. As such, I will have to defer to the more experienced ADs on this thread to see if they think that it can be cited informatively. If not, then unfortunately, we have no option but to go with MISSREF as the only option. Cheers. [1] https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/referencedby/ > > -- Jeff Mahesh Jethanandani [email protected]
