Subject: [netmod] 'status' statement needed on every node

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Sep 2017 17:40:23 +0000

With all the deprecating of "-state" trees going on these days,
the 'status' statement is getting lots of use.  

I understand that some feel that the status statement needs to be
placed on every node, since it is not inherited.  This sentiment
likely stems from RFC 7950 stating "If no status is specified, 
the default is current" and, of course, it not stating that status
is inherited.

I appreciate that this is just following rules, but it seems
excessive and I don't understand how any other interpretation
makes sense.

Also I question how it's supposed to work for a grouping that 
is used once in a deprecated tree and again in a not deprecated 
tree.  What if the grouping is defined in another RFC?  Would
we need to copy the grouping into the current module in order
to set status deprecated on all of its nodes?

Kent // contributor

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Sep 2017 20:14:44 +0200

> excessive and I don't understand how any other interpretation

There is in my view no problem worth to be solved and today's YANG
rules are clear.

<outing>
  I am a big fan of definitions that can be copied and moved around
  without changing meaning just because they appear in a different
  context. I would even prefer to have config true/false not inherited
  down the schema tree but rather have no config statement default to
  config true and everything config false needs an explicit
  statement. Side effect free cut and paste is a feature that is for
  me worth the price of a few more explicit statements. Even a human
  reader can skip over these statements very quickly.
</outing>
 
> to set status deprecated on all of its nodes?

It would be nice to simply use refine but unfortunately section 7.13.2
of RFC 7950 does not allow to refine the status (which in my view is
an oversight but the RFC says what it says).

/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: Tue, 5 Sep 2017 11:44:29 -0700

>   reader can skip over these statements very quickly.

Blind cut-and-paste is not a good design goal.

I still don't know what it means to define hierarchical data and say the
parent is deprecated but not the descendant nodes.

This is rather non-intuitive, as is the idea that all descendant nodes need
to
be manually edited (status is not inherited).  It also means the objects
expanded from
groupings cannot ever be changed (clearly a bug in YANG).

We have not seen these issues yet because this is the first time 'status
deprecated'
is being used.

> an oversight but the RFC says what it says).
Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Sep 2017 21:01:51 +0200

> Blind cut-and-paste is not a good design goal.

Definitions that stand on their own since they are not context
sensitive is IMHO a plus. If I am n pages down a YANG tree and I want
to know whether I look at config false or config true leaves,
searching backwards is really painful if you read on paper (oh, how
old school I am - perhaps this is the issue). Copying a definition
into an email and it stands on its own is a feature I appreciate. Of
course, I understand that others have different preferences.

> parent is deprecated but not the descendant nodes.

It is odd but can happen anyway. A current augmentation of something
that got deprecated likely stays current. I would hope that tools warn
if they see this but that's it.

> This is rather non-intuitive, as is the idea that all descendant
> nodes need to be manually edited (status is not inherited).

Not a big deal. The benefit is that a reader like me knows clear that
the definition I am look at is deprecated, no need to search backwards
to find out.

> It also means the objects expanded from groupings cannot ever be
> changed (clearly a bug in YANG).

Yes, bug in YANG.

> We have not seen these issues yet because this is the first time
> 'status deprecated' is being used.

Yes.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Sep 2017 13:51:48 -0700

> if they see this but that's it.

OK

> the definition I am look at is deprecated, no need to search backwards

OK -- this does not happen too often so it is not a huge impact of writers.

> > changed (clearly a bug in YANG).

With no way to fix it in RFC 7950

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 5 Sep 2017 22:50:03 +0000

> if they see this but that's it.

This example seems to provide support for saying status should be
inherited.  But, to be clear, you agree that if a parent is deprecated,
than its decedents should be deprecated as well, right? 

> the definition I am look at is deprecated, no need to search backwards

tree diagrams do this too, though I like Martin's approach of removing
the deprecated -state trees from the tree diagram altogether.

>> changed (clearly a bug in YANG).

Is this the same issue I raised?

  import ietf-foo {
    prefix f;
  }

  container bar {
    uses f:foo;
  }

  container baz {
    status deprecated;
    uses f:foo;            <-- oops, descendants not deprecated!
  }                           (not a problem if status inherited)

K.

---

From: Andy Bierman <[email-masked]>
Date: Tue, 5 Sep 2017 16:36:10 -0700

> than its decedents should be deprecated as well, right?
right -- the RFC says this has to be done manually.
A missing status-stmt means status=current.

>   }                           (not a problem if status inherited)
According to my interpretation of 7.21.2, this is a MUST NOT:

   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.

   For example, the following is illegal:

     typedef my-type {
       status deprecated;
       type int32;
     }

     leaf my-leaf {
       status current;
       type my-type; // illegal, since my-type is deprecated
     }

The term "reference" is not really defined above.
It should also clearly apply to "uses" (e.g., your example) and  leafref
path-stmt.

   leaf foo {
     type string;
     status deprecated;
  }

  leaf bar {
    type leafref { path /foo; }
  }

If it apples to path-stmt, then why not all XPath?
Why doesn't "reference" include descendant nodes?

The text in 7950 is too strict and can cause a massive ripple-effect when
any status-stmt is changed.
 At the same time it is too vague to be useful to implementors.

Andy

---

From: heasley <[email-masked]>
Date: Wed, 6 Sep 2017 01:47:57 +0000

> searching backwards is really painful if you read on paper (oh, how

Isn't this something that is fixed with display (human representation)
tools?

> if they see this but that's it.

How is anything ever expunged if parsing tools do not refuse to load
a module that depends on a deprecated node that it is attempting to
augment?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Sep 2017 08:44:40 +0200

On Tue, Sep 05, 2017 at 10:50:03PM +0000, Kent Watsen wrote:
> inherited.

No, I do not support your conclusion. I think it is crucial that
whoever maintains an augmenting module is actually aware that his
module depends on something deprecated. Silently deprecating (and
eventually obsoleting) definitions maintained by other parties is in
my view not a good idea. It is far better to clearly indicate that
there is some work to do by the augmenting module maintainer.

> But, to be clear, you agree that if a parent is deprecated,

Yes.
 
>   }                           (not a problem if status inherited)

I think I look at this very differently. If something is defined in
f:foo that is current, then this is inherited where f:foo is
used. What we need is a way to refine that if the usage context has
differnet requirements, like we allow to refine other properties of a
grouping to adapt it to the usage context.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Sep 2017 08:52:22 +0200 (CEST)

> >   }                           (not a problem if status inherited)

As Andy explains below, this should be:

   container baz {
     status deprecated;
     uses f:foo {
       status deprecated;
     }
   }

> If it apples to path-stmt, then why not all XPath?

B/c in XPath it is even ok to refer to non-existing nodes.  And you
might have things like /baz/*.

>  At the same time it is too vague to be useful to implementors.

While I agree that it is not clear what it means to have a "current"
child to a "deprecated" node, I don't think this is a big issue.  If a
node is deprecated, it is ok for an implementation to not implement
it.  Obviously this means that no child nodes to that node is
implemented either, regardless of their status, if they are augmented
in, or comes from a grouping.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Sep 2017 08:54:21 +0200 (CEST)

> grouping to adapt it to the usage context.

I think that marking the uses statement with status deprecated should
mean that all nodes in the grouping are "auto-refined" with status
deprecated.  Listing them all in explciit refine doesn't help
anyone imo.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Sep 2017 08:57:23 +0200

> Isn't this something that is fixed with display (human representation)

I often work with the original definitions. And if the original
definitions depend on context, I have to do another lookup (whether
this is inside the original definition or some tool generated human
representation does not matter). With the old /foo and /foo-state
approach this was really bad since you had often objects with the same
name and it was often not at all clear whether I have been looking at
the config true or the config false definition without an additional
search operation. Perhaps I could program my favourite editor to
generate explicit config statements and status statements on the fly
but I think we would be better off if readers would not have to
program editors or use special tools to easily understand what a
definition really means.

> a module that depends on a deprecated node that it is attempting to

Expunged? Deprecating a definition does not expunge anything. Tools
that refuse to load a module that depends on deprecated nodes are in
my view broken. It was one of YANG's design goals to support
augmentations such that definitions and be augmented by independent
organizations. Hence, we must face reality that it is impossible to
determine how many augmentations of a definition are out there and
hence it is impossible to have them all updated at the same time.

/js

---

From: Radek Krejčí <[email-masked]>
Date: Wed, 6 Sep 2017 10:02:21 +0200

> As Andy explains below, this should be:

despite I see this explanation of status in uses as useful, I don't see anything in RFC that would support this.

> in, or comes from a grouping.

what about the mandatory nodes inside a deprecated container? Formally, they are not deprecated (default status is current) so still mandatory, right?

Radek

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 06 Sep 2017 10:49:36 +0200 (CEST)

Radek Krejčí <[email-masked]> wrote:
> despite I see this explanation of status in uses as useful, I don't
> see anything in RFC that would support this.

I'm just saying that also "uses" can, and should be in this case,
marked as deprecated.

> what about the mandatory nodes inside a deprecated container?
> Formally, they are not deprecated (default status is current) so
> still mandatory, right?

mandatory or not doesn't matter; mandatory doesn't mean "must
implement", but "must exist if the parent exists".

/martin

---

From: Robert Wilton <[email-masked]>
Date: Wed, 6 Sep 2017 10:34:33 +0100

I would prefer if it status was inherited (as an errata to 6020, 7950).  
It seems that when it comes to implementation that is what is going to 
happen regardless.   If a server chooses to not support a deprecated 
node then any children nodes will also not be supported.  Hence, 
regardless of what the YANG module states, their real status is that 
they are deprecated since they won't necessarily be present in all 
servers that implement the module.

However, I do get Juergen's point about clarity.  Given the lengthy 
regex discussion, I suspect others may not agree, but this part could 
potentially be solved via YANG Author Guidelines.  I.e. something 
roughly along the lines of "If a node is marked as deprecated/obsolete 
in a YANG module then all descendant nodes SHOULD also be explicitly 
marked as deprecated/obsolete".

Thanks,
Rob

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Sep 2017 11:42:14 +0200

> I'm just saying that also "uses" can, and should be in this case,

But it also affect augments, and the author of the module where something is
being deprecated may not have access to the augmenting module.

Lada

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

---

From: Radek Krejčí <[email-masked]>
Date: Wed, 6 Sep 2017 12:15:21 +0200

> implement", but "must exist if the parent exists".

that's not true in case of non-presence containers:

container x {
  status deprecated;
  leaf foo {
    type string;
    mandatory true;
  }
}

or with groupings:

grouping g {
  leaf foo {
    type string;
    mandatory true;
  }
}

container x {
  status deprecated;
  uses pre:g;
}
   
Radek

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Sep 2017 13:10:07 +0200

> I would prefer if it status was inherited (as an errata to 6020, 7950).

Erratas are not a tool to change a specification. You have to write
and RFC that updates 6020 and 7950 in order to change what these RFCs
say. This requires full WG / IETF consensus since the change affects
implementations.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 06 Sep 2017 13:32:19 +0200

> say. This requires full WG / IETF consensus since the change affects

A current node with a deprecated ancestor doesn't make sense, so it looks like
an omission. IMO, a technical erratum is then appropriate.

Regarding the documentation needs, 6087bis could recommend not to rely
completely on the inheritance of deprecated status, and put it to other places
for documentation purposes (using common sense).

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Sep 2017 15:53:09 +0200

On Wed, Sep 06, 2017 at 01:32:19PM +0200, Ladislav Lhotka wrote:
> A current node with a deprecated ancestor doesn't make sense, so it
> looks like an omission. IMO, a technical erratum is then
> appropriate.

You can make status work recursively via an erratum. It clearly does
not work recursively in the YANG specifications.

And as explain before, given that we have augmentations, current
definitions below deprecated definitions cannot be avoided.

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 6 Sep 2017 17:28:04 +0100

> definitions below deprecated definitions cannot be avoided.
It seems like there are two different meanings (or interpretations) of 
what the "status" of a node is:

The first is in the module definition, where the author of the YANG 
model indicates whether they think the definition is still current or not.

The second is within a set of modules on a device, where the status of 
the node depends both on the YANG "status" statement for the given node, 
but also the actual status of the parent node.

Thanks,
Rob

---

From: Andy Bierman <[email-masked]>
Date: Wed, 6 Sep 2017 10:04:26 -0700

> deprecated.  Listing them all in explciit refine doesn't help
Lifecycle status of abstract definitions (identity, typedef, grouping)
should only
be changed it applies to all possible usage of the definition. Modules that
use
these external definitions should only override the deprecated or obsolete
status
with extreme caution.

The uses-stmt should not even have a status-stmt since conformance is only
for the
conceptual grouping expansion, not for the grouping or the uses statements.
The only useful interpretation is that it applies to actual data nodes
(after all
nested groupings have been expanded).

I would refine your "auto-refine" a bit :-)
It does not increase the status enum, just lower it to the uses-stmt status
value
   uses(current) -> do not convert any status during expansion
   uses(deprecated) --> convert current to deprecated; leave obsolete
unchanged
   uses(obsolete) --> convert current and deprecated to obsolete

There is still no ability to say that an expanded data node is deprecated,
e.g., deprecate some but not all of the nodes from the uses expansion.

Andy