Hi Jeff,

> On Jan 14, 2025, at 12:20 AM, Jeffrey Haas <[email protected]> wrote:
> 
> Éric and the rest of the IESG:
> 
> On Fri, Jan 10, 2025 at 04:39:27PM +0000, Eric Vyncke (evyncke) wrote:
>> The IESG telechat of the 9th of January has reviewed [1] 
>> draft-ietf-bfd-large-packets-14 and decided that a revised I-D is required. 
>> The key issue is about the padding, both in the YANG leaf (per Mahesh’s 
>> comment) and in the section 3 about the expected “receiver” behavior (i.e., 
>> check or ignore that the optional padding is full of 0, if no check, then 
>> mention a potential covert channel in the security section).
>> 
>> This should be an easy update for a revised I-D :-)
> 
> Version -15, just uploaded, has addressed the majority of the critical
> points in the DISCUSSes.
> 
> 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.”;


> 
> 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?

Cheers.

> 
> -- Jeff
> 


Mahesh Jethanandani
[email protected]






Reply via email to