Subject: [netmod] ietf-yang-groupings proposal

From: Andy Bierman <[email-masked]>
Date: Sun, 17 Mar 2013 12:40:22 -0700

Hi,

Here is a first pass at the YANG module that Juergen asked for....

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Mar 2013 10:08:16 +0100

> Here is a first pass at the YANG module that Juergen asked for....

Thanks. Perhaps the example should not be NTP specific, e.g. something
like this?

          ... XYZ {
            ...
            uses yang-grp:disabled {
              refine disabled {
	        description
                  'Indicates whether the service XYZ is disabled 
		   for use or not.';
              }
            }
          }

Anyway, it would be nice if others can comment on the proposal to see
whether we have concensus that this is the direction we want to go.
Note that we have a number of 'enabled' leafs in the IDs we just
shipped to Benoit.

My understanding is that the enabled leafs are kind of explicit since
they are visible while the disabled leafs are kind of invisible; they
require to read the data model to know where they can be placed. Is
this is a fair statement?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Per Hedeland <[email-masked]>
Date: Mon, 18 Mar 2013 13:15:48 +0100

> this is a fair statement?

Well (assuming that with "enabled leafs" you mean leafs named "enabled"
of type boolean), if the enabled leaf has a default, it depends on the
default-handling mode - with "explicit" or "trim", they are as semi-
invisible as type-empty leafs, although unlike type-empty, they can of
course always be "found" with default-handling mode "report-all". I'm
not sure how important this aspect is though, I would say that knowledge
of the data model is required in any case.

IMO the big difference between boolean "enabled" and type-empty
"disabled" is that the latter *enforces* a "default" of enabled, since a
type-empty leaf can't "exist by default". That might be a desirable
property, but I don't think so - I believe we will see cases where a
default of disabled is more "natural"/useful. With a boolean, the
default can be 'refine'd in the 'uses', whether there is an existing
default or not.

Another thing to consider is the "operational" aspect, i.e.

1. How do you disable XYZ when it is enabled?

a) Set the 'enabled' leaf to "false".

b) Create the 'disabled' leaf.

2. How do you enable XYZ when it is disabled?

a) Set the 'enabled' leaf to "true".

b) Delete the 'disabled' leaf.

Personally I have a strong preference for the 'a's here, in particular
2b) is rather "weird" I think.

That said, I think this whole idea of having a "standard" grouping just
to standardize the name and type of a single leaf is pretty... - well,
silly. Can't we just decide on one alternative and stick to it? I guess
it's good if it's written down somewhere - maybe it should go into an
update of RFC 6087?

--Per Hedeland

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 18 Mar 2013 14:05:50 +0100

> of the data model is required in any case.

I agree. The advantage of the empty "disabled" leaf is that it works always the same, no matter what the default-handling mode is.

> default can be 'refine'd in the 'uses', whether there is an existing

This is a valid point, although the modeller can do one of the following things to overcome this limitation:

1. Define the parent container as "presence". The client can then enable the subtree/service by including the container element, but also disable it secondarily by using <disabled/> while still keeping the subtree in the configuration.

2. One can simply forget about the existence of the grouping and define an "enabled" leaf from scratch. Refining a grouping that contains only one leaf makes little sense to me. 

> a) Set the 'enabled' leaf to "true".

Or delete it. In fact, the "trim" defaults-handling mode will delete it anyway.

> 2b) is rather "weird" I think.

Weirdness is subjective, one could also argue that "a" is weird - Phil has already pointed out that the "enabled" element will mostly be seen in the config in the form <enabled>false</enabled>, i.e. to *disable* the parent subtree.

> it's good if it's written down somewhere - maybe it should go into an

Given the ubiquity of this leaf, the grouping would IMO help readability of modules.

I have actually a proposal, namely to provide two groupings: one with the empty "disabled" leaf, and another with boolean "enabled" leaf but with the default of "false". This way, the modeller can choose the semantics (also in combination with presence containers) that is more apropriate for a given situation.

Lada

> 
> --Per Hedeland
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Per Hedeland <[email-masked]>
Date: Mon, 18 Mar 2013 15:21:31 +0100

> 2. One can simply forget about the existence of the grouping and define an "enabled" leaf from scratch. Refining a grouping that contains only one leaf makes little sense to me. 

We are already required to refine it to provide a description. And now
we have 3 completely different "standard" ways of modeling "enablement",
just to be able to choose the default.

> Or delete it. In fact, the "trim" defaults-handling mode will delete it anyway.

Assuming the default is (known to be) "true", yes. Setting it to "true"
always works (though of course there is a distinction between that and
deleting in "explicit" mode).

> Weirdness is subjective,

Yes, that is what wording like "personally" and "I think" was intended
to convey.

> one could also argue that "a" is weird - Phil has already pointed out that the "enabled" element will mostly be seen in the config in the form <enabled>false</enabled>, i.e. to *disable* the parent subtree.

Again assuming that the default is (known to be) "true" - and your
version of enable for "weird".:-) (I do subjectively agree about the
weirdness of that perfectly valid operation.)

> Given the ubiquity of this leaf, the grouping would IMO help readability of modules.

Hm, so let's say we have consensus for type-empty "disabled". Without
grouping:

  ... XYZ {
    leaf disabled {
      type empty;
      description

With grouping:

  ... XYZ {
    uses yang-grp:disabled {
      refine disabled {
        description

Looks like more text with less information to me, I really can't see how
that helps readability. The only value (if any) *I* can see with a
grouping is standardization, and as we both have pointed out, you don't
get a standard that covers all use cases with type-empty "disabled".

> I have actually a proposal, namely to provide two groupings: one with the empty "disabled" leaf, and another with boolean "enabled" leaf but with the default of "false". This way, the modeller can…

So, from my point of view, I'm afraid I can't see any value at all with
such a proposal.

--Per

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 18 Mar 2013 15:53:05 +0100

> just to be able to choose the default.

Oh yes, at first I didn't notice the specific description is a MUST. With it, the grouping is IMO pretty much useless. I guess the following generic description (to be included in the grouping) could suffice for 90 % of cases:

"Indicates whether the subsystem/service represented by the parent node is disabled for use or not."

…

>          'Indicates whether the service XYZ is disabled

Sure, the second version is really clumsy and would certainly mean a serious confusion for non-expert readers. I assumed the standard use would be just

uses yang-grp:disabled;

If not, I agree with you that the grouping is silly, and doubly so because it is the only content of that module.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Mar 2013 08:57:52 -0700

Hi,

I was wondering if it would be better to mandate:
   * disabled MUST NOT appear as a top-level leaf
   * disabled just affects its parent container or list

But since the name 'disabled' is going to be in the XML
namespace of the modules using the grouping,
there is really no way to identify this leaf as special
other than reserving the name 'disabled'.
So any vendor leaf that happens to match the name
we pick will be incorrectly assumed to be this special leaf.

Maybe a YANG extension to identify such a leaf would
be better:

   leaf disabled {
      yang:disable-leaf;
      type empty;
      .....
   }

Or maybe we punt and say there is nothing machine-readable.
Just a bunch of unrelated ad-hoc leafs and not have any
grouping.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 18 Mar 2013 17:24:19 +0100

>   * disabled just affects its parent container or list

Yes to both, and one more would be needed:

    * If the parent node is a container with presence, then the "disabled" element overrides its presence.

(A funny sentence indeed.:-)

> we pick will be incorrectly assumed to be this special leaf.

Right. In a standard XML context, a global namespaced attribute would be a perfect fit.

> Maybe a YANG extension to identify such a leaf would

Hmm, how could this extension help? 

> Just a bunch of unrelated ad-hoc leafs and not have any

Yes, maybe we should just make it a matter of good style, as Per suggested.

Lada

---

From: Per Hedeland <[email-masked]>
Date: Mon, 18 Mar 2013 17:31:31 +0100

> Yes, maybe we should just make it a matter of good style, as Per suggested.

Although I must admit that I missed the point about machine-readableness
- but if it isn't fulfilled anyway...

--Per

>>> &

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Mar 2013 09:36:57 -0700

>     * If the parent node is a container with presence, then the "disabled" element overrides its presence.

This will not affect any client looking for a P-container and
does not know about special leafs.  This breaks old managers.
I am liking this solution less and less by the minute.

> Right. In a standard XML context, a global namespaced attribute would be a perfect fit.

So it would be better to punt on this and wait for
conditional config features adding in the future
if the solution is to invent new XML attributes.

> Hmm, how could this extension help?

There are no special XML attributes that can be used.
There is only the leaf itself.  The extended-name is useless
since it is a leaf from a grouping.  Only the local-name
or some other tag (YANG extension) can identify this as
a special leaf.

> Yes, maybe we should just make it a matter of good style, as Per suggested.

Maybe it isn't good style at all.
We dumped SMIv2 because of lame design limitations
like peppering the data with action buttons.
This is starting to look like RowStatus reinvented.
Kent's draft is a much better design approach.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 18 Mar 2013 17:55:37 +0100

> Maybe it isn't good style at all.

OK, but we have a number of such leaves spread across the core modules, so at least we should use the same definition where possible. It seems the boolean "enabled" leaf with the default of "true" is used in most cases, so perhaps we should just stick to this. 

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Mar 2013 10:18:47 -0700

Hi,

We could use the xpath1.0 typedef hack.
Not sure why I didn't think of this fist.
(Blaming it on the flu...)

   typedef parent-enabled {
      type boolean;
      default true;
      description
        "Indicates whether the parent container is enabled or not.";
   }

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 18 Mar 2013 10:42:06 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
...
> Sent: Monday, March 18, 2013 10:18 AM
> Subject: Re: [netmod] ietf-yang-groupings proposal
...
>         "Indicates whether the parent container is enabled or not.";

s/ or not//

Otherwise the only possible value would be "true".  :-)

Randy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Mar 2013 14:37:25 -0700

Hi,

4th try:

   typedef parent-enabled {
      type boolean;
      default true;
      description
        "Indicates whether the parent container or list is enabled.";
   }

Issues:
   1) Is definition of 'enabled' needed?
   2) Is it clear that top-level leafs using this type
       do not affect anything?  Cannot disable the entire
       config with a top-level enabled leaf.
   3) Special text needed for P-containers?
   4) Cannot constrain to config=true leafs using typedef.
       OK to use in config=false for reporting?
   5)  Add to ietf-yang-types module ASAP?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Mar 2013 23:06:30 +0100

>    5)  Add to ietf-yang-types module ASAP?

If you make this a typedef, why not simply call it 'enabled'? The usage
would be like this anyway:

  leaf enabled {
    type yang:enabled;
    description
      "bla bla bla";
  }

There is going to be a description statement and it will state what is
enabled/disabled.

Now, how much added value does this new typedef provide? What is the
automation this type achieves compared to simply a boolean given that
is enabled (in all cases I have seen so far) is kind of subject to a
description clause (and thus to arbitrary creativity).

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 18 Mar 2013 15:26:50 -0700

> description clause (and thus to arbitrary creativity).

Automation tools could use it because it is a QName and there
can only be 1 yang:enabled type. (*  see below) The description-stmt is
irrelevant because it enables the parent container or list.
Automation tools can ignore the description-stmt.

What if there are 2+ of these in the same subtree?
That may be a broken design but automation tools would
need to check for it.

This is a little problem -- not worth spending time on.
The ad-hoc enabled leafs can be deprecated if and when
conditional config mechanisms are adopted later.

I posted these things to move the discussion forward.
It does not appear that solving this short-term problem
is such a good idea after all. Next.

Even little IETF hacks take too long and last forever
(RFC 2856 taught me that :-).

Andy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Mar 2013 08:41:51 -0700

> description clause (and thus to arbitrary creativity).

The more I think about this, the more it looks like we
are repeating the mistakes of SNMP.

I would like to get rid of the enabled leafs in
the new NETMOD YANG modules and use Kent's
simple-expr proposal instead.

We can do conditional enablement in phases, starting
with the simple nc:enabled=<boolean> attribute.
That will not take that long because we will agree in advance
there will be no feature-creep, just the 'enabled' attribute.

The enabled leaf is not a true config leaf.  It is an on/off
button for its parent subtree.  We should try to keep N/Y
clean, and keep actions on the config in XML attributes,
and the config contents in XML elements,
like we do with the nc:operation, yang:insert, key, value
attributes.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Mar 2013 16:59:43 +0100

> simple-expr proposal instead.

But Kent's proposal will need some work and time, and I am afraid we cannot couple the core models with it.
 
> there will be no feature-creep, just the 'enabled' attribute.

Some discussion will be needed wrt its precise semantics and other details, so I am not that optimistic. 

> like we do with the nc:operation, yang:insert, key, value

I don't think this is always true - sometimes there are also side effects that differ from case to case. For example, setting "enabled" to "false" for a routing protocol instance means that, e.g., peer sessions have to be terminated, routes removed from routing tables etc. 

Lada

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Mar 2013 09:26:15 -0700

> But Kent's proposal will need some work and time, and I am afraid we cannot couple the core models with it.

Then we should not encourage this design and we should
deprecate those leafs in the future.

> I don't think this is always true - sometimes there are also side effects that differ from case to case. For example, setting "enabled" to "false" for a routing protocol instance means that, e.g.,…

XPath must/when exprs have to check this enabled flag before
using the affected siblings.

I still think database operations belong in the meta-data,
and these leafs will get in the way in the near future.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Wed, 20 Mar 2013 14:26:40 -0400

>        "Indicates whether the parent container or list is enabled.";

Why did this move from "disabled" back to "enabled"?
Why isn't "parent-" implicit?  Disable itself would be pointless.

Thanks,
 Phil