Subject: [Netmod-ver-dt] deprecated-nodes-present obsolete-nodes-present

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 25 Feb 2019 11:00:28 +0000

The deprecated-nodes-present obsolete-nodes-present leaves are currently defined per module.  I think that we previously agreed that these should be moved to being top level YANG library leaves rather than per module.

Does anyone disagree, or object to me making this change?

I'm also considering whether their names would be better specified as "deprecated-nodes-implemented" and "obsolete-nodes-implemented".  Any opinions on this one as well?

Thanks,
Rob

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 25 Feb 2019 11:12:06 +0000

OK, but:

We have the open issue that we would like to make it mandatory to
implement deprecated nodes. How will we handle that? Ask about  it
in the group? In the meeting?

I would like to have it mandatory for all module-revisions
supporting semver. IMO it is not an change to rfc7950, as it is
only a requirement on modules that support semver. During
transition when you start to support semver, all deprecated but
not implemented nodes need to be obsoleted.

If deprecated nodes must be implemented we do not need the
deprecated-nodes-implemented.

regards Balazs

On 2019. 02. 25. 12:00, Rob Wilton
(rwilton) wrote:

The deprecated-nodes-present
obsolete-nodes-present leaves are currently defined per
module.  I think that we previously agreed that these should
be moved to being top level YANG library leaves rather than
per module.

Does anyone disagree, or object to me
making this change?

I’m also considering whether their names
would be better specified as “deprecated-nodes-implemented”
and “obsolete-nodes-implemented”.  Any opinions on this one as
well?

Thanks,

Rob

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

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 25 Feb 2019 13:55:32 +0000

Prefer -present to -implemented but won’t lose sleep over this.

+1 to what Balazs said.

Regards,
Reshad.

From: Netmod-ver-dt <[email-masked]> on behalf of Balázs Lengyel <[email-masked]>
Date: Monday, February 25, 2019 at 6:12 AM
To: "Rob Wilton (rwilton)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Netmod-ver-dt] deprecated-nodes-present obsolete-nodes-present

OK, but:

We have the open issue that we would like to make it mandatory to implement deprecated nodes. How will we handle that? Ask about  it in the group? In the meeting?

I would like to have it mandatory for all module-revisions supporting semver. IMO it is not an change to rfc7950, as it is only a requirement on modules that support semver. During transition when you start to support semver, all deprecated but not implemented nodes need to be obsoleted.

If deprecated nodes must be implemented we do not need the deprecated-nodes-implemented.

regards Balazs
On 2019. 02. 25. 12:00, Rob Wilton (rwilton) wrote:
The deprecated-nodes-present obsolete-nodes-present leaves are currently defined per module.  I think that we previously agreed that these should be moved to being top level YANG library leaves rather than per module.

I’m also considering whether their names would be better specified as “deprecated-nodes-implemented” and “obsolete-nodes-implemented”.  Any opinions on this one as well?

Thanks,
Rob

[email-masked]<mailto:[email-masked]>

--

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 25 Feb 2019 14:42:53 +0000

At the moment I’ve gone with “-implemented” and “-absent”, and changed the types to “empty”, but could revert.   My aim here is that the flags only have meaning if they are present.  If the flags are absent then it means that the behaviour is unspecified, i.e. to match the behaviour of an existing server that wouldn’t know about these flags.

Making deprecated nodes mandatory to implement we should track as an issue, raise with the WG and perhaps track as a YANG.Next issue.  Although, I completely agree with the sentiment of why this would be good to change, we must have a way that this is achieved in a backwards compatible way.  E.g. even if we changed the definition for modules defined as YANG 1.2/2.0 then I’m not sure how much that would help, and I’m not sure that the WG would sanction a breaking change here.

FWIW, I’ve included the current text that I have for the YANG library section (but I’ve not updated the module definition yet).  This also includes proposed text for how to handle ambiguous import resolution.  I’ve tried to make the text more concise in places, but have also made it more explicit that these flags MUST be implemented for SEMVER to make sense.

Text is inline below.  Comments are of course welcome.

NEW:

5.  Updates to ietf-yang-library

   YANG library [RFC7895] [I-D.ietf-netconf-rfc7895bis] is modified to
   support semantic versioning in three ways.

   The ietf-semver YANG module augments the 'module' list in ietf-yang-
   library with a 'version' leaf to optionally declare the YANG semantic
   version of each module.

5.1.  Resolving ambiguous module imports

   A YANG datastore schema, defined in [I-D.ietf-netconf-rfc7895bis],
   can specify multiple revisions of a YANG module in the schema using
   the 'import-only' list, with the requirement from [RFC7950] that only
   a single revision of a YANG module may be implemented.

   If a YANG module import statement does not specify a specific version
   or revision withim the datastore schema then it could be ambigous as
   to which module revision the import statement should resolve to.
   Hence, a datastore schema constructed by a client using the
   information contained in YANG library may not exactly match the
  datastore schema actually used by the server.

   The following rules remove the ambiguity:

   If a module import statement could resolve to more than one module
   revision defined in the datastore schema, and one of those revisions
   is implemented (i.e., not an 'import-only' module), then the import
   statement MUST resolve to the revision of the module that is defined
   as being implemented by the datastore schema.

   If a module import statement could resolve to more than one module
   revision defined in the datastore schema, and none of those revisions
   are implemented, but one of more modules revisions specify a YANG
   semantic version, then the import MUST resolve to the module with the
   greatest version number, according to the rules in Section 3.

   If a module import statement could resolve to more than one module
   revision defined in the datastore schema, none of those revisions are
   implemented, and none of the modules revisions have a YANG semantic
   version number, then the import MUST resolve to the module that has
   the most recent revision-date.

5.2.  Reporting how deprecated and obsolete nodes are handled

   The ietf-semver YANG module augments YANG library with two leaves to
   allow a server to report how it handles status 'deprecated' and
   status 'obsolete' nodes.  The leaves are:

   deprecated-nodes-implemented:  If present, this leaf indicates that
      the server implements all status 'deprecated' nodes, or otherwise
      uses deviations to explicitly remove 'deprecated' nodes from the
      schema.  If this leaf is absent then the behavior is unspecified.

   obsolete-nodes-absent:  If present, this leaf indicates that the
      server does not implement any status 'obsolete' nodes, or
      otherwise uses devations to explicitly add implemented 'obsolete'
      nodes back into the schema.  If this leaf is absent then the
      behaviour is unspecified.

   Implementations that implement the YANG semantic versioning scheme
   defined in this document MUST set both the 'deprecated-nodes-
   implemented' and 'obsolete-nodes-absent' leaves because the refined
   module update rules in Section 4 assume that this is how servers
   handle 'deprecated' and 'obsolete' nodes to comply with YANG module
   semantic versioning.

   If a server does not set the 'deprecated-nodes-implemented' leaf,
   then clients MUST NOT rely solely on the YANG module semantic version
   number to determine whether two modules versions are backwards
   compatible, and MUST also consider whether the status of any nodes
   has changed to 'deprecated' and whether those nodes are implemented
   by the server.

OLD TEXT:

7.  Updates to ietf-yang-library

   The ietf-semver YANG module also specifies additional ietf-yang-
   library [RFC7895] [I-D.ietf-netconf-rfc7895bis] leafs to be added at
   the module and submodule levels.  The first is module-version, which
   augments /yanglib:yang-library/yanglib:module-set/yanglib:module.
   This specifies the current semantic version of the associated module
   and revision in a given module-set.  The related submodule-version
   leaf is added at /yanglib:yang-library/yanglib:module-
   set/yanglib:module/yanglib:submodule to indicate the semantic version
   of a submodule.

   In order to satisfy the requirements 4.1 and 4.3 of
   [I-D.verdt-netmod-yang-versioning-reqs] that deprecated and obsolete
   node presence and operation are easily and clearly known to clients,
   ietf-semver also augments the ietf-yang-library with two additional
   boolean leafs at /yanglib:yang-library/yanglib:module-set/
   yanglib:module.  A client can make one request of the ietf-yang-
   library and know whether or a not a module that has deprecated or
   obsolete has those nodes implemented by the server, as opposed to
   making multiple requests for each node in question.

   deprecated-nodes-present :  A boolean that indicates whether or not
      this server implements deprecated nodes.  The value of this leaf
      SHOULD be true; and if so, the server MUST implement nodes within
      this module as they are documented.  If specific deprecated nodes
      are not implemented as documented, then they MUST be listed as
      deviations.  This leaf defaults to true.

   obsolete-nodes-present :  A boolean that indicates whether or not
      this server implements obsolete nodes.  The value of this leaf
      SHOULD be false; and if so, the server MUST NOT implement nodes
      within this module.  If this leaf is true, then all nodes in this
      module MUST be implemented as documented in the module.  Any
      variation of this MUST be listed as deviations.  This leaf
      defaults to false.

   If a module does not have any deprecated or obsolete nodes, the
   server SHOULD set the corresponding leaf above to true.  This is
   helpful to clients, such that if the MAJOR version number has not
   changed, and these booleans are true, then a client does not have to
   check the status of any node for the module.

   Module compatibility can be affected if values other than the default
   are used for the leafs described here.  For example, if a server does
   not implemennt deprecated nodes, then a given module revision may be
   incompatible with a previous revision where the nodes were not
   deprecated.  When calculating backward compatibility, the default
   values of these leafs MUST be considered.  From a client's point of
  view, if two module revisions have the same MAJOR version but the
   run-time value of deprecated-nodes-present (as read from the ietf-
   yang-library) is false, then compatibility MUST NOT be assumed based
   on the module-version alone.

Thanks,
Rob

From: Reshad Rahman (rrahman) <[email-masked]>
Sent: 25 February 2019 13:56
To: Balázs Lengyel <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] deprecated-nodes-present obsolete-nodes-present

+1 to what Balazs said.

Regards,
Reshad.

From: Netmod-ver-dt <[email-masked]<mailto:[email-masked]>> on behalf of Balázs Lengyel <[email-masked]<mailto:[email-masked]>>
Date: Monday, February 25, 2019 at 6:12 AM
To: "Rob Wilton (rwilton)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Netmod-ver-dt] deprecated-nodes-present obsolete-nodes-present

OK, but:

regards Balazs

Thanks,
Rob

--

Senior Specialist

---

From: Balázs Lengyel <[email-masked]>
Date: Mon, 25 Feb 2019 17:21:03 +0000

Hello,

MY point is we do not change the rfc7950 definition. What we
should say is

"If a module's specific revision includes the
semver:module-version statement as a substatement to the latest
revision statement of the module, all then all deprecated schema
nodes MUST be implemented as defined by the module."

This does NOT contradict
https://tools.ietf.org/html/rfc7950#section-7.21.2

"deprecated" indicates an obsolete definition, but it permits
new/continued implementation in order to foster interoperability
with older/existing implementations.

Please explain if I am wrong. Why would this be considered a
change to rfc7950?

regards Balazs

On 2019. 02. 25. 15:42, Rob Wilton
(rwilton) wrote:

At the
moment I’ve gone with “-implemented” and “-absent”, and
changed the types to “empty”, but could revert.   My aim
here is that the flags only have meaning if they are
present.  If the flags are absent then it means that the
behaviour is unspecified, i.e. to match the behaviour of an
existing server that wouldn’t know about these flags.

Making
deprecated nodes mandatory to implement we should track as
an issue, raise with the WG and perhaps track as a YANG.Next
issue.  Although, I completely agree with the sentiment of
why this would be good to change, we must have a way that
this is achieved in a backwards compatible way.  E.g. even
if we changed the definition for modules defined as YANG
1.2/2.0 then I’m not sure how much that would help, and I’m
not sure that the WG would sanction a breaking change here.

FWIW, I’ve
included the current text that I have for the YANG library
section (but I’ve not updated the module definition yet).
This also includes proposed text for how to handle ambiguous
import resolution.  I’ve tried to make the text more concise
in places, but have also made it more explicit that these
flags MUST be implemented for SEMVER to make sense.

Text is
inline below.  Comments are of course welcome.

NEW:

5.  Updates to
ietf-yang-library

YANG library [RFC7895]
[I-D.ietf-netconf-rfc7895bis] is modified to

support semantic versioning
in three ways.

The ietf-semver YANG module
augments the 'module' list in ietf-yang-

library with a 'version'
leaf to optionally declare the YANG semantic

version of each module.

5.1.  Resolving ambiguous
module imports

A YANG datastore schema,
defined in [I-D.ietf-netconf-rfc7895bis],

can specify multiple
revisions of a YANG module in the schema using

the 'import-only' list, with
the requirement from [RFC7950] that only

a single revision of a YANG
module may be implemented.

If a YANG module import
statement does not specify a specific version

or revision withim the
datastore schema then it could be ambigous as

to which module revision the
import statement should resolve to.

Hence, a datastore schema
constructed by a client using the

information contained in
YANG library may not exactly match the

datastore schema actually
used by the server.

The following rules remove
the ambiguity:

If a module import statement
could resolve to more than one module

revision defined in the
datastore schema, and one of those revisions

is implemented (i.e., not an
'import-only' module), then the import

statement MUST resolve to
the revision of the module that is defined

as being implemented by the
datastore schema.

If a module import statement
could resolve to more than one module

revision defined in the
datastore schema, and none of those revisions

are implemented, but one of
more modules revisions specify a YANG

semantic version, then the
import MUST resolve to the module with the

greatest version number,
according to the rules in Section 3.

If a module import statement
could resolve to more than one module

revision defined in the
datastore schema, none of those revisions are

implemented, and none of the
modules revisions have a YANG semantic

version number, then the
import MUST resolve to the module that has

the most recent
revision-date.

5.2.  Reporting how deprecated
and obsolete nodes are handled

The ietf-semver YANG module
augments YANG library with two leaves to

allow a server to report how
it handles status 'deprecated' and

status 'obsolete' nodes.
The leaves are:

deprecated-nodes-implemented:  If present, this leaf
indicates that

the server implements all
status 'deprecated' nodes, or otherwise

uses deviations to
explicitly remove 'deprecated' nodes from the

schema.  If this leaf is
absent then the behavior is unspecified.

obsolete-nodes-absent:  If
present, this leaf indicates that the

server does not implement
any status 'obsolete' nodes, or

otherwise uses devations
to explicitly add implemented 'obsolete'

nodes back into the
schema.  If this leaf is absent then the

Implementations that
implement the YANG semantic versioning scheme

defined in this document
MUST set both the 'deprecated-nodes-

implemented' and
'obsolete-nodes-absent' leaves because the refined

module update rules in
Section 4 assume that this is how servers

handle 'deprecated' and
'obsolete' nodes to comply with YANG module

semantic versioning.

If a server does not set the
'deprecated-nodes-implemented' leaf,

then clients MUST NOT rely
solely on the YANG module semantic version

number to determine whether
two modules versions are backwards

compatible, and MUST also
consider whether the status of any nodes

has changed to 'deprecated'
and whether those nodes are implemented

by the server.

OLD TEXT:

The ietf-semver YANG module also specifies
additional ietf-yang-

library [RFC7895]
[I-D.ietf-netconf-rfc7895bis] leafs to be added at

the module and submodule levels.  The
first is module-version, which

augments
/yanglib:yang-library/yanglib:module-set/yanglib:module.

This specifies the current semantic
version of the associated module

and revision in a given module-set.  The
related submodule-version

leaf is added at
/yanglib:yang-library/yanglib:module-

set/yanglib:module/yanglib:submodule to
indicate the semantic version

of a submodule.

In order to satisfy the requirements 4.1
and 4.3 of

[I-D.verdt-netmod-yang-versioning-reqs]
that deprecated and obsolete

node presence and operation are easily and
clearly known to clients,

ietf-semver also augments the
ietf-yang-library with two additional

boolean leafs at
/yanglib:yang-library/yanglib:module-set/

yanglib:module.  A client can make one
request of the ietf-yang-

library and know whether or a not a module
that has deprecated or

obsolete has those nodes implemented by
the server, as opposed to

making multiple requests for each node in
question.

deprecated-nodes-present :  A boolean that
indicates whether or not

this server implements deprecated
nodes.  The value of this leaf

SHOULD be true; and if so, the server
MUST implement nodes within

this module as they are documented.  If
specific deprecated nodes

are not implemented as documented, then
they MUST be listed as

deviations.  This leaf defaults to
true.

obsolete-nodes-present :  A boolean that
indicates whether or not

this server implements obsolete nodes.
The value of this leaf

SHOULD be false; and if so, the server
MUST NOT implement nodes

within this module.  If this leaf is
true, then all nodes in this

module MUST be implemented as
documented in the module.  Any

variation of this MUST be listed as
deviations.  This leaf

defaults to false.

If a module does not have any deprecated
or obsolete nodes, the

server SHOULD set the corresponding leaf
above to true.  This is

helpful to clients, such that if the MAJOR
version number has not

changed, and these booleans are true, then
a client does not have to

check the status of any node for the
module.

Module compatibility can be affected if
values other than the default

are used for the leafs described here.
For example, if a server does

not implemennt deprecated nodes, then a
given module revision may be

incompatible with a previous revision
where the nodes were not

deprecated.  When calculating backward
compatibility, the default

values of these leafs MUST be considered.
From a client's point of

view, if two module revisions have the same
MAJOR version but the

run-time value of deprecated-nodes-present
(as read from the ietf-

yang-library) is false, then compatibility
MUST NOT be assumed based

Thanks,

Rob

From:
Reshad Rahman (rrahman) <[email-masked]>

To: Balázs Lengyel
<[email-masked]>; Rob Wilton
(rwilton) <[email-masked]>;
[email-masked]

Subject: Re: [Netmod-ver-dt]
deprecated-nodes-present obsolete-nodes-present

Prefer -present to -implemented but won’t lose
sleep over this.

+1 to what Balazs said.

Regards,

Reshad.

From:
Netmod-ver-dt <[email-masked]> on
behalf of Balázs Lengyel <[email-masked]>

Subject: Re: [Netmod-ver-dt]
deprecated-nodes-present obsolete-nodes-present

OK, but:

We have the
open issue that we would like to make it mandatory to
implement deprecated nodes. How will we handle that? Ask
about  it in the group? In the meeting?

I would like to
have it mandatory for all module-revisions supporting
semver. IMO it is not an change to rfc7950, as it is only a
requirement on modules that support semver. During
transition when you start to support semver, all deprecated
but not implemented nodes need to be obsoleted.

If deprecated
nodes must be implemented we do not need the
deprecated-nodes-implemented.

regards Balazs

On 2019. 02. 25. 12:00, Rob Wilton (rwilton)
wrote:

The deprecated-nodes-present
obsolete-nodes-present leaves are currently defined per
module.  I think that we previously agreed that these
should be moved to being top level YANG library leaves
rather than per module.

Does anyone disagree, or object to me making
this change?

I’m also considering whether their names
would be better specified as
“deprecated-nodes-implemented” and
“obsolete-nodes-implemented”.  Any opinions on this one as
well?

Thanks,

Rob

[email-masked]

--

Senior Specialist

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Mon, 25 Feb 2019 17:28:57 +0000

Hi Balazs,

I think that we should take this issue to the WG.

This sounds like an implicit backdoor version of YANG 1.2.

Besides, I’m not convinced that changing the meaning of status on a per module basis is really helpful.  I think that defining it per schema/server makes more sense.

Thanks,
Rob

From: Netmod-ver-dt <[email-masked]> On Behalf Of Balázs Lengyel
Sent: 25 February 2019 17:21
To: Rob Wilton (rwilton) <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] deprecated-nodes-present obsolete-nodes-present

Hello,

MY point is we do not change the rfc7950 definition. What we should say is

"If a module's specific revision includes the semver:module-version statement as a substatement to the latest revision statement of the module, all then all deprecated schema nodes MUST be implemented as defined by the module."

This does NOT contradict https://tools.ietf.org/html/rfc7950#section-7.21.2

Please explain if I am wrong. Why would this be considered a change to rfc7950?

regards Balazs
On 2019. 02. 25. 15:42, Rob Wilton (rwilton) wrote:
At the moment I’ve gone with “-implemented” and “-absent”, and changed the types to “empty”, but could revert.   My aim here is that the flags only have meaning if they are present.  If the flags are absent then it means that the behaviour is unspecified, i.e. to match the behaviour of an existing server that wouldn’t know about these flags.

NEW:

OLD TEXT:

Thanks,
Rob

From: Reshad Rahman (rrahman) <[email-masked]><mailto:[email-masked]>
Sent: 25 February 2019 13:56
To: Balázs Lengyel <[email-masked]><mailto:[email-masked]>; Rob Wilton (rwilton) <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [Netmod-ver-dt] deprecated-nodes-present obsolete-nodes-present

+1 to what Balazs said.

Regards,
Reshad.

OK, but:

regards Balazs

Thanks,
Rob

--

Senior Specialist

--

Senior Specialist

---

From: Joe Clarke <[email-masked]>
Date: Mon, 25 Feb 2019 16:28:22 -0500

On 2/25/19 12:28, Rob Wilton (rwilton) wrote:
> Besides, I’m not convinced that changing the meaning of status on a per
> module basis is really helpful.  I think that defining it per
> schema/server makes more sense.

I agree with this last sentence.  We had talked about a
deprecated-nodes-implemented flag or knob before, and I thought that was
a reasonable thing to do from a server schema standpoint.

Joe

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 27 Feb 2019 09:29:54 +0000

Hello,

I was just thinking about where this deprecated-nodes-present leaf belongs.

In one of our products we use a 3PP toolkit to implement the 
YANG/Netconf stack. The toolkit implements some models itself 
(ietf-yang-library, ietf-netconf-acm). Other models are implemented by 
Ericsson's own SW. If the toolkit vendors decide not to implement 
deprecated nodes that must not force their customer (Ericsson) to do the 
same. However if we would have the deprecated-nodes-present leaf on 
server/schema level that would force Ericsson to follow the behavior of 
the 3PP Netconf stack. Now imagine if we buy e.g. an SNMP stack with a  
YANG interface from another vendor which has an opposite idea about 
deprecated. It does not work.

IMHO deprecated-nodes-present must be on the module level.

regards Balazs

P.S. Personally I like booleans much better then empty types. I don't 
like the idea of using to different names for the same item whether it 
is present or not. Also a boolean is much more explicit in my view.)

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 27 Feb 2019 09:44:29 +0000

Hi Balazs,

The solution for your toolbit case is to force the vendor toolkit to also publish deviations for the deprecated nodes that they don't implement. :-)

But think of this from a client perspective.  If they have to track individual deprecated/obsolete flags per module that will just cause them pain, and becomes something else that a client has to track like whether features are supported.  I.e. it makes it more complicated to define the schema associated with the device.

I think that everyone on the DT wants all deprecated nodes to be implemented, and obsolete nodes to be absent, so this is what we should push for.  If we allow this to be specified on a per module basis then it just makes everything more complex.

Regarding "Booleans" vs "Empty" then I also generally prefer booleans because they are explicit.  But in this specific case, I don't want someone to interpret "deprecated-nodes-implemented=false (or not present)" as meaning that the deprecated nodes are not implemented!  Instead, to maintain backwards compatibility with existing servers and YANG library, if the leaf is not set we need it to mean then the behaviour is unspecified.  I.e. deprecated nodes might be all implemented, none of them implemented, or any combination between the two.  I.e. the RFC 7950 behaviour.  To cover this ambiguity, I think that the "empty" leaf expresses this intent more clearly.

Thanks,
Rob

-----Original Message-----
From: Netmod-ver-dt <[email-masked]> On Behalf Of Balázs Lengyel
Sent: 27 February 2019 09:30
To: Joe Clarke (jclarke) <[email-masked]>; Rob Wilton (rwilton) <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; [email-masked]
Subject: [Netmod-ver-dt] deprecated-nodes-present per module or per server

Hello,

In one of our products we use a 3PP toolkit to implement the YANG/Netconf stack. The toolkit implements some models itself (ietf-yang-library, ietf-netconf-acm). Other models are implemented by Ericsson's own SW. If the toolkit vendors decide not to implement deprecated nodes that must not force their customer (Ericsson) to do the same. However if we would have the deprecated-nodes-present leaf on server/schema level that would force Ericsson to follow the behavior of the 3PP Netconf stack. Now imagine if we buy e.g. an SNMP stack with a YANG interface from another vendor which has an opposite idea about deprecated. It does not work.

regards Balazs

P.S. Personally I like booleans much better then empty types. I don't like the idea of using to different names for the same item whether it is present or not. Also a boolean is much more explicit in my view.)

On 2019. 02. 25. 22:28, Joe Clarke wrote:
>> Besides, I’m not convinced that changing the meaning of status on a 
>> per module basis is really helpful.  I think that defining it per 
> deprecated-nodes-implemented flag or knob before, and I thought that 
> was a reasonable thing to do from a server schema standpoint.
>
> Joe
>

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 27 Feb 2019 09:49:05 +0000

A boolean actually has 3 values:

deprecated-nodes-implemented=false   the nodes are definitely not there
deprecated-nodes-implemented=true    the nodes are definitely there
deprecated-nodes-implemented=not present in the data   I do not tell you if the nodes are there, so the behavior is unspecified

Balazs

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 27 Feb 2019 09:54:19 +0000

Yes, if the leaf doesn't specify a default then I agree that it can be used to implement tri-state logic.

But do we want to encourage servers to be able to specify "the nodes are definitely not there"?  My understanding is that we don't actually want servers to adopt this behaviour, or move in this direction, so why provide it as an option?

I *think* that we are only trying to move from "unspecified" => "always implemented".

Thanks,
Rob

-----Original Message-----
From: Netmod-ver-dt <[email-masked]> On Behalf Of Balázs Lengyel
Sent: 27 February 2019 09:49
To: Rob Wilton (rwilton) <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; [email-masked]
Subject: [Netmod-ver-dt] Boolean or empty [was: Re: deprecated-nodes-present per module or per server]

Balazs

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 27 Feb 2019 10:04:09 +0000

My means of forcing the toolkit vendor are severely limited. Maybe I 
will ask for some enforcers from the godfather :-)

If we really want such deviations, that should become a guideline in 
some later chapter.

regards Balazs

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 27 Feb 2019 10:22:02 +0000

At least for obsolete we do need and support all tree behaviors.

Balazs

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 27 Feb 2019 11:25:23 +0000

For obsolete, RFC 7950 already states:
     "obsolete" means that the definition is obsolete and SHOULD NOT be
      implemented and/or can be removed from implementations.

So, really I was meaning for the flag to mean that all obsolete data nodes are not present, unless they are deviated to add them back into the schema.  But "deviate" doesn't actually allow this.  You can't add a data node, and you can't change the status from "obsolete" to "deprecated or current".  So there is no current way in YANG to achieve this (but I've raised it on the YANG.Next issue tracker).

But I'm wondering whether we need to say anything about obsolete nodes at all, and whether the 7950 text isn't entirely sufficient.  I.e. clients cannot rely on them being there, so shouldn't configure anything that is obsolete.  Clients should also ignore unexpected data in <get-data> requests against operational, so if a server returns obsolete nodes that it should effectively do no harm.

So, in the case of obsolete, is there anything that we actually need to fix.  Or is the problem really only about how deprecated nodes are handled?

Thanks,
Rob

-----Original Message-----
From: Netmod-ver-dt <[email-masked]> On Behalf Of Balázs Lengyel
Sent: 27 February 2019 10:22
To: Rob Wilton (rwilton) <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Boolean or empty [was: Re: deprecated-nodes-present per module or per server]

Balazs

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 27 Feb 2019 11:31:58 +0000

At least we should add a guideline:

Mandatory config nodes MUST NOT be obsolete. Because ...  Rather just 
remove them...

Balazs

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 27 Feb 2019 11:42:53 +0000

I'm not convinced that even that is required.  I think that the intuitive thing is to just ignore this node.

Although that question is interesting in the context of a "deprecated mandatory node", but at least with the semver draft it is clear what the behaviour should be. :-)

Thanks,
Rob

-----Original Message-----
From: Netmod-ver-dt <[email-masked]> On Behalf Of Balázs Lengyel
Sent: 27 February 2019 11:32
To: Rob Wilton (rwilton) <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Boolean or empty [was: Re: deprecated-nodes-present per module or per server]

Mandatory config nodes MUST NOT be obsolete. Because ...  Rather just remove them...

Balazs

On 2019. 02. 27. 12:25, Rob Wilton (rwilton) wrote:
> To: Rob Wilton (rwilton) <[email-masked]>; Joe Clarke (jclarke) 
> <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; 
> [email-masked]
> Subject: Re: [Netmod-ver-dt] Boolean or empty [was: Re: 
> deprecated-nodes-present per module or per server]
>
>> To: Rob Wilton (rwilton) <[email-masked]>; Joe Clarke (jclarke) 
>> <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; 
>> [email-masked]
>> Subject: [Netmod-ver-dt] Boolean or empty [was: Re: 
>> deprecated-nodes-present per module or per server]
>>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Feb 2019 13:31:51 +0100

> Mandatory config nodes MUST NOT be obsolete. Because ...  Rather just remove

Since everything is implicitely exported, removing is a no go as it
can break modules you have never heard of. This is why we have status
obsolete. (This also prevents an accidental reuse of the name for a
new definition, which I understand some of the people here think is
not a problem once we have 3-digit version numbers.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Balázs Lengyel <[email-masked]>
Date: Wed, 27 Feb 2019 13:08:49 +0000

leaf myTimer {
mandatory true;
config true;
status obsolete;
type string;
}

So should I configure myTimer or not? Today whatever I do, it
might come back with an error. IMHO YANG should make it possible
to write a correct config.

I know this is not the most important point for semver, so we
might skip it, but it is not correct. Maybe keep it as an open
issue.

regards Balazs

On 2019. 02. 27. 13:31, Juergen
Schoenwaelder wrote:

Mandatory config nodes MUST NOT be obsolete. Because ...  Rather just remove
them...

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Feb 2019 14:19:35 +0100

Is there not a yang-next issue to clarify these things?

/js

On Wed, Feb 27, 2019 at 01:08:49PM +0000, Balázs Lengyel wrote:
>  leaf myTimer {
>    mandatory true;
>    config true;
>    status obsolete;
>    type string;
>  }
> 
>    So should I configure myTimer or not? Today whatever I do, it might come
>    back with an error. IMHO YANG should make it possible to write a correct
>    config.
> 
>    I know this is not the most important point for semver, so we might skip
>    it, but it is not correct. Maybe keep it as an open issue.
> 
>    regards Balazs
> 
>    On 2019. 02. 27. 13:31, Juergen Schoenwaelder wrote:
> 
>  On Wed, Feb 27, 2019 at 11:31:58AM +0000, Bal�zs Lengyel wrote:
> 
>  Mobile: +36-70-330-7909              email: [1][email-masked]
> 
> References
> 
>    Visible links
>    1. mailto:[email-masked]

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 27 Feb 2019 13:19:43 +0000

It’s obsolete, the client should not set it, the server SHOULD NOT implement it.  If a server does decide to implement it, then I would suggest that it would also be wise to deviate the “mandatory true” statement.  Do we really need text to state this?  It seems pretty obvious to me.

I’ve raised https://github.com/netmod-wg/yang-ver-dt/issues/3 to track this.

Thanks,
Rob

From: Balázs Lengyel <[email-masked]>
Sent: 27 February 2019 13:09
To: Juergen Schoenwaelder <[email-masked]>
Cc: Rob Wilton (rwilton) <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Boolean or empty [was: Re: deprecated-nodes-present per module or per server]

leaf myTimer {

  mandatory true;

  config true;

  status obsolete;

  type string;

}

So should I configure myTimer or not? Today whatever I do, it might come back with an error. IMHO YANG should make it possible to write a correct config.

I know this is not the most important point for semver, so we might skip it, but it is not correct. Maybe keep it as an open issue.

regards Balazs

them...

/js

--

Senior Specialist

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Wed, 27 Feb 2019 13:24:22 +0000

https://github.com/netmod-wg/yang-next/issues/27

I've updated the top comment to include this as an example.  I also agree that would seem to be a good place to clarify this behaviour, if required.

Thanks,
Rob

-----Original Message-----
From: Netmod-ver-dt <[email-masked]> On Behalf Of Juergen Schoenwaelder
Sent: 27 February 2019 13:20
To: Balázs Lengyel <[email-masked]>
Cc: Rob Wilton (rwilton) <[email-masked]>; Reshad Rahman (rrahman) <[email-masked]>; Joe Clarke (jclarke) <[email-masked]>; [email-masked]
Subject: Re: [Netmod-ver-dt] Boolean or empty [was: Re: deprecated-nodes-present per module or per server]

/js

On Wed, Feb 27, 2019 at 01:08:49PM +0000, Balázs Lengyel wrote:
>  On Wed, Feb 27, 2019 at 11:31:58AM +0000, Bal zs Lengyel wrote:
> 
>  Mobile: +36-70-330-7909              email: [1]Balazs.Lengyel@ericsson..com
> 
> References
> 
>    Visible links