Re: [netmod] YANG 1.1 issue: enabled leaf design pattern

[Andy Bierman <[e-mail]>]

On Sun, May 4, 2014 at 2:45 AM, Ladislav Lhotka <[e-mail]> wrote:

>
> On 04 May 2014, at 10:33, Andy Bierman <[e-mail]> wrote:
>
> >
> >
> >
> > On Sun, May 4, 2014 at 12:40 AM, Ladislav Lhotka <[e-mail]> wrote:
> >
> > On 03 May 2014, at 21:31, Andy Bierman <[e-mail]> wrote:
> >
> > >
> > >
> > >
> > > On Sat, May 3, 2014 at 11:50 AM, Ladislav Lhotka <[e-mail]>
> wrote:
> > >
> > > On 03 May 2014, at 18:42, Andy Bierman <[e-mail]> wrote:
> > >
> > > > Hi,
> > > >
> > > > Problem:
> > > >
> > > > The use of a leaf in the data model (such as the
> /interfaces/interface/enabled
> > > > leaf in the ietf-interfaces module) does not account for YANG
> validation rules
> > > > for many statements that can reference the disabled subtree from
> outside
> > > > of that subtree:
> > > >
> > > >     - must
> > > >     - when
> > > >     - unique
> > > >     - min-elements
> > > >     - max-elements
> > > >     - leafref (valid instances)
> > > >     - choices (disabled case is still the active case, so no other
> can be used)
> > >
> > > In my view, an "enabled false" leaf *operationally* disables a
> particular instance or function. For all other purposes related to
> datastore validation, the value of the enabled leaf doesn't matter. In
> other words, "enabled false" is not the same as commenting out the
> corresponding instance in the configuration.
> > >
> > >
> > > OK -- they may be different, but the enabled leaf is ad-hoc,
> > > and YANG designers must know about this leaf.  Adding or removing
> > > this leaf could break other YANG statements.
> > >
> > > E,g,
> > >
> > >
> > >    leaf active-foo-interface {
> > >        type  if:interface-ref;
> > >        mandatory true;
> > >    }
> > >
> > >
> > > By YANG validation rules, the  leafref test for interface name
> > > will include all disabled interfaces.
> >
> > Yes.
> >
> > >
> > > Doesn't every object that uses the interface-ref typedef need
> > > to have a must-stmt making sure the enabled leaf is set,
> > > if they want to activate a service on only enabled interfaces?
> > >
> > > (Is this the must-stmt to use?)
> > >
> > >    leaf active-foo-interface {
> > >        type  if:interface-ref;
> > >        must "/if:interfaces/if:interface[if:name=current()]/enabled";
> > >        mandatory true;
> > >    }
> > >
> > > Don't all must/when/leafref validation statements that want only
> > > active interfaces need to be written this way?
> >
> > I don't think so. An operator may want to pre-configure an interface in
> the disabled state, set up all references to it etc., so that everything
> will be up and running after setting the single "enabled" leaf to true.
> >
> > I said "this is what has to be written to identity active interfaces"
> > and you respond "maybe they want to select disabled interfaces".
>
> It's up to the server to interpret the entire configuration, so if a
> service is enabled in configuration but it depends on an interface that is
> currently disabled, the server might keep that service operationally
> disabled as well.
>
> Section 6 in the routing draft deals with exactly these interactions.
>
> If this situation has to be avoided for some reason, then yes, a "must"
> statement can be used to enforce, e.g., that a leafref only refers to an
> enabled interface. I don't see it as a problem though.
>
> I think it is OK that the "enabled" leafs are ad hoc because their
> semantics may be specific, too.
>
>

This is the part I really don't like.
These mechanisms should not be ad-hoc and different for every module.
There should be a standard way to operationally enable/disable config
and a standard way to comment/uncomment config.

IMO, we are making a big mistake by not standardizing a solution like the
xpath1.0
typedef in ietf-yang-types.yang.  If there was a reusable type for this
leaf, then tools
could use that to identify the design pattern and handle the enable/disable
edits
within the validation engine and the system instrumentation.

Sometimes following the CLI too closely leads to bad API decisions


Andy



> That said, I am not against introducing the "inactive" attribute but, as I
> understand it, its meaning will be different.
>
> > The complex must/when statements will be required to select
> > active interfaces.  In my example, the active-foo-interface MUST
> > be active. The foo service does not work when it is configured to
> > use a disabled interface.  I suspect very few services function correctly
> > using disabled interfaces.
>
> My point is that even if a service looks like being enabled in
> configuration, it may not be the case because some dependencies are not met
> - and this can be anticipated, as in the routing data model.
>
> Lada
>
> >
> >
> > Lada
> >
> >
> > Andy
> >
> >
> > >
> > > I agree this notion of "operationally disabled" is not the
> > > same as commenting out.  I don't think N/Y properly supports
> > > either one.
> > >
> > >
> > >
> > > Lada
> > >
> > > Andy
> > >
> > >
> > > >
> > > > The behavior for all of these statements needs to be clarified
> > > > when disabled nodes are involved.
> > > >
> > > > The 'enabled' leaf is like SMIv2 RowStatus TC, except that
> > > > it is ad-hoc and used randomly. SMIv2 does not have any
> > > > validation statements that can be affected by a 'notInService' row,
> > > > so RowStatus is not broken in SNMP.
> > > >
> > > > Solution:
> > > >
> > > > YANG 1.1 must define a "metadata plane" that applies to
> > > > configuration datastores.  Global attributes that are specific
> > > > to configuration datastores (e.g. with-defaults) will be included
> > > > in the standard metadata library. It is expected that protocols
> > > > using YANG will define operations for reading and writing
> > > > global attributes.
> > > >
> > > > YANG 1.1 must define an "enabled" global attribute that must
> > > > be supported in all YANG 1.1 tools. The YANG validation rules
> > > > must be adjusted to properly account for disabled subtrees.
> > > >
> > > > Side issue: should 'enabled' leafs be removed when converting
> > > > a YANG 1.0 module to YANG 1.1?
> > > >
> > > >
> > > > Andy
> > > >
> > > > _______________________________________________
> > > > netmod mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/netmod
> > >
> > > --
> > > Ladislav Lhotka, CZ.NIC Labs
> > > PGP Key ID: E74E8C0C
> > >
> > >
> > >
> > >
> > >
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
> >
> >
> >
> >
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>