Re: [tcpm] Comments for draft-ietf-tcpm-yang-tcp-00

[tom petch <[e-mail]>]

From: Joseph Touch <[e-mail]>
Sent: 05 November 2020 15:30
> On Nov 5, 2020, at 3:04 AM, tom petch <[e-mail]> wrote:
>
> From: tcpm <[e-mail]> on behalf of Joseph Touch <[e-mail]>
> Sent: 04 November 2020 21:36
> Is there a convention in YANG for such situations?
>
> I personally would not expect all values to have “default=true” or “on" everywhere. Sometimes you’re actively turning on something that is typically disabled (default=false or off).
>
> I think the “include-tcp-options” matches the way it’s described in the doc (TCP option flag, where true implies includdd) and the default=true would match better.
>
> <tp>
> From a YANG, rather than TCPM, perspective, I am not clear what you are asking.

The question is whether toggles are typically true by default or false by default. It doesn’t appear so.

<tp>
Ah yes, clear now.  I agree that there is no such convention in YANG.  Simplifying, if you want a default, then the default must be explicitly specified in the model.  If there is no default and the leaf is not set to a value e.g. by Netconf, then the leaf does not exist in the YANG data tree, for Booleans as for anything else.  If you want the leaf always to be present, then YANG constraints allow you to enforce that.  As I said, given the wording in the RFC I would see default true as appropriate here.
As an aside the issue of defaults caused much discussion in Netconf as to whether or not they should be returned in a get and this led to three different processing options for retrieval but the YANG side of things has stayed the same.

Tom Petch

>  In this case RFC5925 - which the leaf would benefit from as a reference to - seems clear to me
> 'by default including options'
> in which case I would expect the YANG to default true.
> I think it good practice to be explicit in any YANG description clause of a boolean as to what true means or false or ideally both).
> Also, I think the choice of 'include' in the leaf identifier unfortunate given that 'include' is a YANG technical term that appears in every YANG module.

It doesn’t need to be; the term could be “options-covered-by-MAC”, default=true

>  I know that it used in RFC5925 but still see it as unfortunate.

The YANG model and TCP-AO had overlapping development periods. It’s impossible to expect either to have taken the other completely into account.

Joe