On Wed, Jan 20, 2021 at 02:41:39PM +0000, Italo Busi wrote: > > What about the case the leaf is not conditional (but still mandatory false > since a YANG default statement is defined)? > > May the server still decide not to use/implement this leaf in the operational > datastore? > > For example, in appendix C.1 of RFC8342, auto-negotiation is enabled by > default. > What should be the behavior of a system which does not implement > auto-negotiation? > Return the value false or no value (in the operational datastore)? >
Here are some of the rules I personally like: - <operational> is the ground truth about what a system has and does - do not implement leafs that do not apply Hence, interfaces supporting auto-negotiation have either auto-negotiation/enabled = true or auto-negotiation/enabled = false in <operational>. And interfaces not supporting auto-negotiation have nothing to report about auto-negotiation. Yes, I do not want to see auto-negotiation/enabled = false on a loopback interface. My historic Ethernet interface from the last century would also not report auto-negotiation/enabled in <operational>. You may hit applications that love to have auto-negotiation/enabled available on all Ethernet interfaces and then you end in a debate where the application developers tell you that no information in <operational> may have many reasons (instrumentation not implemented, access control rules, whatever and by reporting enabled=false you do them a favor) but the true answer in such a debate is often that modeling things as a boolean is simplistic since there are often more than exactly two states (in this case, enabled, disabled, failed, not-available, ...). So you settle on blaming the model writer. ;-) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
