rev:status-description

[Reshad-Rahman]

From Martin Bjorklund on draft-ietf-netmod-yang-module-versioning-00:

o 3.4

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated {
     rev:status-description
       "Imperial measurements are being phased out in favor
        of their metric equivalents.  Use metric-temperature
        instead.";
   }
   description
     "Temperature in degrees Fahrenheit.";
 }

I don't think rev:status-description is necessary / worth it. This
can easily be written with the normal description statement instead:

 leaf imperial-temperature {
   type int64;
   units "degrees Fahrenheit";
   status deprecated;
   description
       "Imperial measurements are being phased out in favor
        of their metric equivalents.  Use metric-temperature
        instead.

        Temperature in degrees Fahrenheit.";
 }

[Reshad-Rahman]

Proposal is to wait until yang-next

=========================

[As an individual contributor]

I'm not keen on the idea of adding information related to deprecation/obsoletion to the data node description.

I think that this will cause problems for schema comparison, since tooling cannot easily understand the semantic difference in changes in description and hence will probably need extra annotations to indicate whether such changes are BC or NBC. Whereas I think that such tooling could probably reasonably handle a description statement under status differently (e.g., perhaps treat all such status description changes as BC or insignificant changes).

However, I'm more sympathetic to the argument that this is not worth fixing now, and that this issue could be deferred to YANG.Next.

Regards,
Rob

-----Original Message-----
From: netmod netmod-bounces@ietf.org On Behalf Of Martin Björklund
Sent: 04 May 2020 19:15
To: Reshad Rahman (rrahman) rrahman@cisco.com
Cc: netmod@ietf.org
Subject: Re: [netmod] status-description

"Reshad Rahman (rrahman)" rrahman@cisco.com wrote:

What are your thoughts on having description statement under status in
yang-next?

No problem! In fact, "description" could be allowed under any
statement...

/martin

Is it the same as what you’ve stated on status-description
extension?

I believe the extension is useful, although I do see the point made
that an extra statement leads to extra complexity. But using
description statement in yang-next should not be an issue?

Regards,
Reshad.

From: 'Andy Bierman' andy@yumaworks.com
Date: Monday, May 4, 2020 at 1:32 PM
To: Martin Björklund mbj+ietf@4668.se
Cc: Balazs Lengyel balazs.lengyel@ericsson.com, "Reshad Rahman
(rrahman)" rrahman@cisco.com, NetMod WG netmod@ietf.org
Subject: Re: [netmod] status-description

On Mon, May 4, 2020 at 9:38 AM Martin Björklund
<mbj+ietf@4668.semailto:mbj%2Bietf@4668.se> wrote:
Hi,

Balázs Lengyel
<balazs.lengyel@ericsson.commailto:balazs.lengyel@ericsson.com>
wrote:

Hello,
While status-description is not a critical part of this work, it is
still useful, does not harm and is such a small addition, I do not
understand why Martin objects.

Every additional statement adds to the overall complexity. As Jason
explained, this particular statement doesn't really help much.

+1

We should not start down the path of specialized description
statements.

I was part of a design team many years ago that was trying to
figure out why engineers were having so much trouble writing MIB
modules.
One significant finding: people disliked working on MIBs because there
were so
many special little rules (CLRs) for every little detail in the
module.

IMO we are starting to make the same mistake with YANG.

/martin

Andy

So why is status-description good:
Sometimes additional information is needed about deprecation,
obsolescence:

• is the item still fully functional?
• when will its functionality be removed?
• when will the schema node itself be removed?
• is there a replacement or workaround that could/should be used
  instead
• of deprecated/obsolete item?
  The text can be used by tools. Using a separate statement to provide
  this
  information is a method to separate the main description from this
  status specific description.
  In most cases both in the CLI and on NMS GUIs only the description is
  displayed.
  However there is a possibility to display the status information too.

In a way it is similar why we have separate description, contact,
reference, organization statements under module.
All these are just text, they could all be pushed under a single
description statement. Tools can't act on these automatically, still
it is good to separate them.

Regards Balazs

-----Original Message-----
From: netmod <netmod-bounces@ietf.orgmailto:netmod-bounces@ietf.org>
On Behalf Of Sterne, Jason
(Nokia - CA/Ottawa)
Sent: 2020. április 29., szerda 23:38
To: Reshad Rahman (rrahman)

<rrahman=40cisco.com@dmarc.ietf.orgmailto:40cisco.com@dmarc.ietf.org>;

Martin Björklund <mbj+ietf@4668.semailto:mbj%2Bietf@4668.se>;
netmod@ietf.orgmailto:netmod@ietf.org
Subject: Re: [netmod] status-description (WAS Re: mbj review of
draft-verdt-netmod-yang-module-versioning-01)

I think we could wait until YANG 2.0 to add a description to the
status.

Without a status description, an intelligent "YANG diff" of the models
would produce this:
a) new status deprecated statement
b) change to a description

With a status description we'd identify this:
a) new status deprecated statement
b) new status description

In both cases it is (a) that identifies the most clear information.

In both cases (b) provides no additional information that can be acted
upon in an automated fashion. The tool could only flag that (b)
occurred in both cases and a human would then have to go look at it.

If the only change between two versions of a module was a status
description change, then again a human would have to take a look. If
we add some sort of "nbc" tag to the leaf for tooling, then it also
doesn't matter which description changed.

Jason

[Reshad-Rahman]

Fixed by Balazs in this commit:
38beb58

[Reshad-Rahman]

status-description has been removed in https://www.ietf.org/id/draft-ietf-netmod-yang-module-versioning-01.txt