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. > > 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. -- Jeff
