Subject: Re: [netmod] Does the YANG "status" statement inherit from its parent node?

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

Martin Bjorklund writes:
>But marking definition as obsolete in one module cannot automatically
>make definitions in *other* modules obsolete.
>
>(*) _maybe_ 7950 can be interpreted in this way when it says:
>
>   If a definition is "current", it MUST NOT reference a "deprecated" or
>   "obsolete" definition within the same module
>
>If you're in a good mood, you could argue that a child always
>"references" its parent.

That's a massively deforming interpretation of "references".

I'm not even sure this is a good rule at all.  Consider:

    leaf old-stuff {
        status deprecated;
        must not(../new-stuff);
    }
    leaf new-stuff {
        must not(../old-stuff);
    }

My new-stuff definitely references old-stuff which is deprecated,
but this is a _good_ data model and should not be "MUST NOT"d out
of existence.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Jan 2017 14:53:06 -0800

Hi,

The reason the status-stmt is broken is because status=obsolete is not
inherited from the parent.  The status obsolete means it is gone from the
server.
Since YANG data is hierarchical, any descendants of the obsolete node
are no longer accessible in any way.

Andy

On Wed, Jan 18, 2017 at 1:32 PM, Phil Shafer <[email-masked]> wrote:

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2017 00:11:42 +0100

> are no longer accessible in any way.

I am not convinced yet that the status-stmt is broken:

- Not all references in YANG are hierarchical nested nodes.

- References can cross module boundaries and also organizational
  boundaries.

- Tools can create warnings if non-obsolete definitions reference an
  obsolete definition so that editors can make proper updates.

/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: Andy Bierman <[email-masked]>
Date: Wed, 18 Jan 2017 15:42:07 -0800

>   obsolete definition so that editors can make proper updates.
yangdump-pro has warnings. pyang ignores the status-stmt.

The text that is broken is in sec. 7.21.2

    If a definition is "current", it MUST NOT reference a "deprecated" or
   "obsolete" definition within the same module.

   If a definition is "deprecated", it MUST NOT reference an "obsolete"

      definition within the same module.

We do not seem to have any agreement on what it means to reference an
object.

It seems obvious that our intention was to disallow current child nodes
within an obsolete or deprecated parent node.

IMO we need Errata to clarify what it means.
The YANG compiler MUST generate errors for these 'MUST NOT' violations in
the YANG syntax.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2017 01:00:21 +0100

> The YANG compiler MUST generate errors for these 'MUST NOT' violations in

But:

 - References can cross module boundaries and thereby also
   organizational boundaries.

I think we have to accept that at least temporarily the MUST NOT may
be violated in reality. I think the errata should actually modify the
MUST NOT to a SHOULD NOT in the quoted text.

I also note that obsolete does not _require_ to remove implementation:

   o  "obsolete" means that the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

If I have something worthwhile referencing something marked obsolete,
I may decide to keep the referenced obsolete something.

/js

---

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

>inherited from the parent.  The status obsolete means it is gone from the

No: '"obsolete" means that the definition is obsolete and SHOULD NOT be
implemented and/or can be removed from implementations.'  It's not
gone, just that it _can_ be removed.

>are no longer accessible in any way.

This is not true.  "deprecated" and "obsolete" nodes can continue
to exist for decades.  They are accessible by normal mechanisms.
The "status" affects expectations, not implementations, which
tend to not remove features that might affect paying customers.

In any case, my main contention is that the rule:

is not workable, since nodes may need to reference deprecated and
obsolete nodes to block the interactions between new and old nodes,
as depicted in my example.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Wed, 18 Jan 2017 20:36:08 -0800

> gone, just that it _can_ be removed.
OK.  If the parent object gets removed, then NETCONF and RESTCONF can
no longer access the descendant nodes.

> tend to not remove features that might affect paying customers.

I mean in a given server, if that server has removed obsolete /foo
then you cannot access and descendants of /foo

The status-stmt is for the benefit of the client developer, not just
the server developer.  They are forewarned that servers SHOULD
remove obsolete nodes, and it might be wise to find a different data node
to use.

> as depicted in my example.
OK

Andy

---

From: Robert Wilton <[email-masked]>
Date: Thu, 19 Jan 2017 10:40:26 +0000

Hi Phil,

Wouldn't you just write this without the back reference to the 
deprecated/obsolete leaf.

E.g. wouldn't the following be sufficient to enforce the desired constraint?

     leaf old-stuff {
         status deprecated;
         must not(../new-stuff);
     }
     leaf new-stuff {
     }

Thanks,
Rob

On 18/01/2017 21:32, Phil Shafer wrote:
> .

---

From: Phil Shafer <[email-masked]>
Date: Thu, 19 Jan 2017 16:23:02 -0500

>E.g. wouldn't the following be sufficient to enforce the desired constraint?

Very True.  But imagine if the deprecated bits are in one module
and the new-stuff is in another.  The old-stuff cannot refer to the
new-stuff.

Thanks,
 Phil