Subject: [netmod] Default presence containers

From: "Lange, Jeffrey K (GE Energy Management)" <[email-masked]>
Date: Wed, 26 Mar 2014 14:16:44 +0000

Is there any way in YANG that one can create a presence container with a
default state? 6020 does not list ³default² as a sub statement to
container. If not, perhaps this is a useful feature for YANG 1.1

e.g. (from 6020):

container system {
    description "Contains various system parameters";
    container services {
        description "Configure externally available services";
        container "ssh" {
            presence "Enables SSH";
            description "SSH service specific configuration²;
            default present; // or not-present
        }
    }
}

Thanks!
-Jeff

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Mar 2014 17:12:21 +0100

> container. If not, perhaps this is a useful feature for YANG 1.1

It seems the same effect can be achieved by using either type of container with an additional child leaf “enabled”. Several examples of this arrangement are in the core modules. 

That is:

- on by default

container ssh {     // non-presence
  leaf enabled {
    type boolean;
    default "true”;
  }
  …
}

- off by default

container ssh {
  presence "Enable ssh";
  leaf enabled {
    type boolean;
    default "true”;
  }
  …
}

The advantage of having the extra switch “enabled” is that one can disable the function without wiping out the existing configuration.

Lada

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Mar 2014 17:57:31 +0100

On 28 Mar 2014, at 17:17, Lange, Jeffrey K (GE Energy Management) <[email-masked]> wrote:

> 
> On 3/28/14, 12:12 PM, "Ladislav Lhotka" <[email-masked]> wrote:
> 
>> 
>> It seems the same effect can be achieved by using either type of
>> container with an additional child leaf “enabled”. Several examples of
>> this arrangement are in the core modules.
>> 
>> That is:
>> 
>> - on by default
>> 
>> The advantage of having the extra switch “enabled” is that one can
>> disable the function without wiping out the existing configuration.
> 
> While this is true, using that same logic you should be able to safely
> remove presence containers from YANG all together. But I don’t think you

The nice property of presence containers is that they keep the stuff that’s off by default out of the configuration until it is explicitly configured, no matter what the handling of defaults is.

Things that are on by default can simply use just a non-presence container, and if the modeller wants to offer the option of turning them off, the “enabled” leaf would do.

> are proposing that.  Coming back to the inability to augment in mandatory
> statements, presence containers are currently the only option for adding
> new mandatory statements.

Presence containers provide no such option. Encapsulating mandatory nodes in a presence container makes them optional.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Mar 2014 10:07:45 -0700

On Fri, Mar 28, 2014 at 9:57 AM, Ladislav Lhotka <[email-masked]> wrote:

> >> container with an additional child leaf "enabled". Several examples of
> >>  default "true";
> >> ...
> >>  default "true";
> >> ...
> >> The advantage of having the extra switch "enabled" is that one can
> > remove presence containers from YANG all together. But I don't think you
>
> The nice property of presence containers is that they keep the stuff
> that's off by default out of the configuration until it is explicitly
> configured, no matter what the handling of defaults is.
>
> Things that are on by default can simply use just a non-presence
> container, and if the modeller wants to offer the option of turning them
> off, the "enabled" leaf would do.
>
> Presence containers provide no such option. Encapsulating mandatory nodes
> in a presence container makes them optional.
>
>
Most parameters are not always mandatory.
In fact, top-level mandatory nodes are not allowed in IETF YANG modules
so all mandatory nodes need some sort of optional parent node.

 The mandatory nodes only apply if the SSH service is enabled in this case.

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Mar 2014 18:45:32 +0100

>  The mandatory nodes only apply if the SSH service is enabled in this case.

The case I am most concerned about is a list defined in a “base” module that expects instances of different types and the parameters of each type are left to be defined in separate modules via augments. Examples are: if:interface, rt:routing-instance, rt:routing-protocol, rt:route-filter …

I think this is a very useful pattern that should be recommended in data modelling guidelines, and it has nothing to do with support of old clients. 

The presence container doesn’t help here at all.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Mar 2014 11:08:32 -0700

On Fri, Mar 28, 2014 at 10:45 AM, Ladislav Lhotka <[email-masked]> wrote:

> > Presence containers provide no such option. Encapsulating mandatory
> nodes in a presence container makes them optional.
> >
> >
> The case I am most concerned about is a list defined in a "base" module
> that expects instances of different types and the parameters of each type
> are left to be defined in separate modules via augments. Examples are:
> if:interface, rt:routing-instance, rt:routing-protocol, rt:route-filter ...
>
> I think this is a very useful pattern that should be recommended in data
> modelling guidelines, and it has nothing to do with support of old clients.
>
> The presence container doesn't help here at all.
>
>
We keep going over this point.  Module Y cannot add mandatory nodes to
module X.
It changes the contract for whatever revision of module X is being
advertised.
Otherwise modules are coupled, and that's what we have sub-modules for.

The unit of conformance in YANG is the module.
YANG conformance has no ability whatsoever to describe any conformance
construct larger than a module, which is what you would need
in order to force a server to implement, and a client to support, module X
and Y together.
(But I have been informed YANG conformance works great and there is
no need to change it. ;-)

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Mar 2014 19:21:35 +0100

On 28 Mar 2014, at 19:08, Andy Bierman <[email-masked]> wrote:

> We keep going over this point.  Module Y cannot add mandatory nodes to module X.

The substance of Y26 is to lift this CLR, at least partially. Note this change doesn’t violate any of the restrictions set for YANG 1.1.

Lada

> It changes the contract for whatever revision of module X is being advertised.
> in order to force a server to implement, and a client to support, module X and Y together.

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Mar 2014 11:35:10 -0700

...
> The substance of Y26 is to lift this CLR, at least partially. Note this
> change doesn't violate any of the restrictions set for YANG 1.1.
>
>
It is not a CLR.
This would change the requirements for module X without changing the
revision date for module X.
That is not acceptable.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 28 Mar 2014 19:55:49 +0100

On 28 Mar 2014, at 19:35, Andy Bierman <[email-masked]> wrote:

> This would change the requirements for module X without changing the revision date for module X.
> That is not acceptable.

X+Y isn’t the same as X.

The following augment doesn’t add any mandatory nodes and yet it blatantly changes semantics of the “system” module:

augment "sys:system/sys:authentication/sys:user" { // add fine print
  leaf send-user-and-password-to-nsa {
    type boolean;
    default true;
  }
}

Lada

---

From: Andy Bierman <[email-masked]>
Date: Fri, 28 Mar 2014 13:02:32 -0700

On Fri, Mar 28, 2014 at 11:55 AM, Ladislav Lhotka <[email-masked]> wrote:

> X+Y isn't the same as X.

??

If you make objects from Y mandatory if X is implemented, then that
means the client or server cannot implement X without also implementing
the augmenting objects from Y.  YANG conformance does not support that.

>
> The following augment doesn't add any mandatory nodes and yet it blatantly
> changes semantics of the "system" module:
>

Yes it changes system behavior.
No, it does not change what a client that implements that specific version
of the 'user' node needs to provide to create/merge/delete the user entry.

The rule exists so only objects which are safe for an old client to ignore
can be added via augments.  The only conformance mechanism
the client has to use is tied to a module name and a revision date.

If the server advertises this module/revision-date, then the client
MUST be able to expect that code written to work with this revision
will not fail because mandatory objects were added from some other module
not even mentioned in module A.

Configuration is not as simple as monitoring.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 28 Mar 2014 22:27:28 +0100 (CET)

Hi,

> container. If not, perhaps this is a useful feature for YANG 1.1

I don't understand how it is supposed to work.  With a leaf, the
default value is used if no value is explicitly configured.  For a
P-container that "exists by default", it would mean that if it wasn't
configured, it would work as if it was explicitly configured.  But
then all you can do is create it, and it behaves just as before, and
then you delete it and it still behaves as before:

  container ssh {
    presence "ssh protocol enabled;
    presence-default true;
    ...
  }

If "ssh" is not explicitly set, ssh protocol is, by default, enabled.

If "ssh" is explicitly set, ssh protocol is enabled.

You probably mean that the P-container gets automatically created
*initially* by the server, but then a client can delete it, and it
stays deleted.  So it is more like:

  container ssh {
    presence "ssh enabled;
    initially-created true;
    ...
  }

This might be useful, but we don't have anything like it today.

/martin