Subject: Re: [netmod] top-level mandatory nodes

From: Phil Shafer <[email-masked]>
Date: Wed, 18 Jan 2017 16:35:51 -0500

Ladislav Lhotka writes:
>>> 6087bis says in sec. 5.10:
>>>  Top-level database data definitions MUST NOT be mandatory.
>Right - I think the following should do:
>OLD
>  Top-level database data definitions MUST NOT be mandatory.
>NEW
>  Top-level data nodes that represent configuration MUST NOT be mandatory.

[old news, but...]

I guess I'm missing the use case for mandatory top-level config=false
data models.  Can you please describe one?  I imagine that just because
my device implements a non-config data model, I should not be forced
to generate data for it when/if that data is not needed.  What's the
scenario where I need to be forced to make this data?

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Jan 2017 13:57:43 -0800

> scenario where I need to be forced to make this data?
mandatory for config=false means it must exist in an <rpc-reply> for a <get>
operation retrieval.  It is by definition "server-supplied", so there is no
server validation to worry about.

YANG constraints are used on clients.
Not that we are super-server-centric here, but client software
uses YANG, not just server software.

>  Phil

Andy

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

---

From: Alex Campbell <[email-masked]>
Date: Wed, 18 Jan 2017 22:46:33 +0000

The purpose of a mandatory config=false node is to say that the data is _always_ needed.

In the case where the node is also top-level, if your server fails to provide that data, then your server is not compliant with the YANG.

If the data is sometimes not needed, then the module author should not have marked it as mandatory.

Alex

________________________________________
From: netmod <[email-masked]> on behalf of Phil Shafer <[email-masked]>
Sent: Thursday, 19 January 2017 10:35 a.m.
To: Ladislav Lhotka
Cc: NETMOD WG
Subject: Re: [netmod] top-level mandatory nodes

[old news, but...]

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Wed, 18 Jan 2017 18:51:05 -0500

I was really looking for a use case.  What's is a specific scenario
where one would want a device to always report data even when there
is no interesting data to report (since interesting data would mean
the device would want to report it)?

I've seen this misused where the modeler wants the device to say
"I've got no TLA data", where the model should be happy that being
implicit in the lack of data.

Thanks,
 Phil

Alex Campbell writes:
>In the case where the node is also top-level, if your server fails to provide that data,
> then your server is not compliant with the YANG.
>

---

From: Phil Shafer <[email-masked]>
Date: Wed, 18 Jan 2017 18:53:01 -0500

>uses YANG, not just server software.

I must be missing your meaning here.  Can you please give a
use case for when the data modeler would use "mandatory true"
for a "config false" top-level node?

Thanks,
 Phil

---

From: Alex Campbell <[email-masked]>
Date: Thu, 19 Jan 2017 00:04:47 +0000

Here's a straightforward, hypothetical use case where a mandatory top-level non-config leaf makes sense (in my opinion anyway):

    module example-uptime {
        prefix uptime;
        namespace urn:X-example:example-uptime;

        import ietf-yang-types {
            prefix yang;
        }

        leaf uptime {
            type yang:timeticks;
            config false;
            mandatory true;

            description "The amount of time since the server was last powered on or restarted.";
        }
    }

- Alex

________________________________________
From: Phil Shafer <[email-masked]>
Sent: Thursday, 19 January 2017 12:51 p.m.
To: Alex Campbell
Cc: Ladislav Lhotka; NETMOD WG
Subject: Re: [netmod] top-level mandatory nodes

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Jan 2017 13:57:53 +0100

> for a "config false" top-level node?

An existing use case is the NACM module in RFC 6536:

      +--rw nacm
         +--rw enable-nacm?            boolean
         +--rw read-default?           action-type
         +--rw write-default?          action-type
         +--rw exec-default?           action-type
         +--rw enable-external-groups? boolean
         +--ro denied-operations       yang:zero-based-counter32
         +--ro denied-data-writes      yang:zero-based-counter32
         +--ro denied-notifications    yang:zero-based-counter32
         ...

The top-level node "nacm" contains three mandatory counters, and this
makes it mandatory as well. My understanding is that if a client asks
for complete state data, these counters must always be present in the
reply.

The situation here is a bit trickier because "nacm" is configuration but
I guess it is just an artefact caused by putting configuration and state
data inside the same container.

Lada

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