Subject: [netmod] Comment on draft-clacla-netmod-yang-model-update-02

From: Balazs Lengyel <[email-masked]>
Date: Wed, 15 Nov 2017 00:51:22 +0800

Hello,

First of all Ericsson very strongly supports this draft. This is
a problem we definitely have, and for which we had to create our
own internal solution. So we would love to see an IETF solution!

General)

The document does not mention some other problems with the
current versioning. These stem from

we should allow non-backward compatible (NBC) changes in some
limited cases

it should be possible to determine two module versions'
compatibility without a line-by-line comparison

Whenever a client OSS implements some higher level logic for a
network function, something that can not be implemented in a
purely model driven way, it is always dependent on a specific
version of the Yang Module (YAM). If the client finds that the
module has been updated on the network node, it has to decide if
it tries to handle it as it did the previous version of the model
or if it just stops to avoid problems. To make this decision the
client needs to know if the module was updated in a backward
compatible way or not. This is not addressed with the current
versioning.

While having PYANG based checks for backward compatibility is a
very good idea, a  comparison based check will never be a complete
check. It is quite possible to change just the behavior of an
rpc/action/etc.  without changing the YANG definition.  This will
only show up as a change of the description statement that can not
be analyzed by PYANG.

When upgrading a network node we might introduce non-backward
compatible (NBC) changes. Today we need to introduce a new module
for this. That means during the upgrade process the node must
convert stored configuration instance data from ietf-routing to
ietf-routing-2 format. Instead of solving this data
transformation/transfer problem just for a few NBC data nodes, we
will have to do it for the full model. This is complicated. In
many cases the transformation of a few NBC leafs can be handled by
good defaults or with a small script. Transferring the full data
set is more complicated. If we allow NBC updates in some cases
this problem is avoided.

If we update the module from ietf-routing to ietf-routing-2 ? Do
we keep the prefix?  In one sense it should be kept as it is the
same module "logically"; we also might have stored data including
the prefix (identityrefs, instance-identifiers). On the other hand
having multiple modules with the same prefix is a problem. The
only good solution is to allow incompatible updates in some cases.

CH 1)

You write

"The YANG data modeling language [RFC7950] specifies strict rules
for updating..."

and again

"When the same YANG module name is kept, the new YANG module
revision must always be updated in a backward-compatible way."

I strongly disagree. While we have strict rules about even small
modifications to existing schema, but you are allowed to
deprecate/obsolete big parts of the model, thereby possibly
deleting complete subtrees from the schema. That is anything but
strict backward compatibility.

I find this aspect of YANG inconsistent to the level that it would
need an errata.

So practically the current rules allow backward incompatible
changes that can only be detected by a line by line comparison of
the yang modules. In a system with semantic versioning, you could
determine backward compatibility just by reading the version
numbers.

CH 2.3)

As we need to create a new Yang Module (YAM) even for the smallest
incompatible modification, this increases the number of modules.

CH 2.5)  We already have vendor modules depending on ietf-routing

CH3.1)

I propose that the semantic version should be a mandatory
substatement of the YANG revision statement. It should be updated
every time, and it would be good to see the older semantic
versions as well.

I would propose to have 3 separate statements for x,y,z. I don't
like structured strings. It would be much easier to compare simple
integers.

I can if needed provide some more detailed rules for x,y,z e.g.
if x is stepped y and z MUST be set to 0.

IMHO YANG package definition should be a separate issue, left out
of this document. Andy has already provided some very good ideas
about this topic.

I also think the current definition of deprecated and obsolete in
YANG 1.1 is near useless, as all it says that both deprecated and
obsolete items may or may not be there. We need something better.

regards Balazs

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 14 Nov 2017 22:22:10 +0100

On Wed, Nov 15, 2017 at 12:51:22AM +0800, Balazs Lengyel wrote:
>    Whenever a client OSS implements some higher level logic for a network
>    function, something that can not be implemented in a purely model driven
>    way, it is always dependent on a specific version of the Yang Module
>    (YAM). If the client finds that the module has been updated on the network
>    node, it has to decide if it tries to handle it as it did the previous
>    version of the model or if it just stops to avoid problems. To make this
>    decision the client needs to know if the module was updated in a backward
>    compatible way or not. This is not addressed with the current versioning.

The current rules aim at guaranteeing that definitions (with status
current) remain backwards compatible. Do you have an example what the
current rules fail to achieve this? Definitions with status deprecated
or obsolete may not be present. But if they are present, they have the
same semantics. This is the promise made to a client. (Note also that
objects may be absent for reasons document in deviations or simply not
accessible due to access control.)

>    While having PYANG based checks for backward compatibility is a very good
>    idea, a  comparison based check will never be a complete check. It is
>    quite possible to change just the behavior of an rpc/action/etc.  without
>    changing the YANG definition.  This will only show up as a change of the
>    description statement that can not be analyzed by PYANG.

The problem is to decide whether a change can break client
expectations or not. Even 'bug fixes' can cause a client written to
expect the old 'buggy' behaviour to fail. Also tricky are situations
where behaviour was not clearly enough described and this is 'fixed'
in a module update.

Semantic versioning assumes that one always can clearly distinguish
between incompatible updates and compatible updates. This may not be
so clearly cut in practice, see above. (But then, we have the same
judgement call at the end with today's update rules.)

>    When upgrading a network node we might introduce non-backward compatible
>    (NBC) changes. Today we need to introduce a new module for this. That
>    means during the upgrade process the node must convert stored
>    configuration instance data from ietf-routing to ietf-routing-2 format.
>    Instead of solving this data transformation/transfer problem just for a
>    few NBC data nodes, we will have to do it for the full model. This is
>    complicated. In many cases the transformation of a few NBC leafs can be
>    handled by good defaults or with a small script. Transferring the full
>    data set is more complicated. If we allow NBC updates in some cases this
>    problem is avoided.

In XML land, this is mostly a change of the namespace (not of the
prefix) if one keeps the same structure, no? In JSON land, the change
of the module name more directly becomes visible in instance data; but
this is all encoding details.

>    If we update the module from ietf-routing to ietf-routing-2 ? Do we keep
>    the prefix?

I guess you mean the namespace, not the prefix. You can use any prefix
you like.

>    In one sense it should be kept as it is the same module
>    "logically"; we also might have stored data including the prefix
>    (identityrefs, instance-identifiers). On the other hand having multiple
>    modules with the same prefix is a problem. The only good solution is to
>    allow incompatible updates in some cases.

If we move towards allowing incompabile updates, then we need to have
a mechanism to tell which versions of modules can work together and
which combinations are affected by an incompatible update. We probably
need to require strict import by revision or at least 'import by
compatible revision' (whatever this means at the end).

>    CH 1)
> 
>    You write
>    "The YANG data modeling language [RFC7950] specifies strict rules for
>    updating..."
>    and again
>    "When the same YANG module name is kept, the new YANG module  revision
>    must always be updated in a backward-compatible way."
> 
>    deprecate/obsolete big parts of the model, thereby possibly deleting
>    complete subtrees from the schema. That is anything but strict backward
>    compatibility.
>    I find this aspect of YANG inconsistent to the level that it would need an
>    errata.

Marking something deprecated / obsolete means you can not be sure this
is implemented. But then, even definitions with status current may not
be implemented (see deviations) or they may not be accessible to a
client due to access control. However, if implemented and accessible,
the guarantee today is that the semantics stay the same and don't
change unexpectedly.

>    So practically the current rules allow backward incompatible changes that
>    can only be detected by a line by line comparison of the yang modules. In
>    a system with semantic versioning, you could determine backward
>    compatibility just by reading the version numbers.

I do not see why you need a line by line comparison. With semantic
versioning, you _hope_ the semantic version number is a good enough
indicator. It might also be that your client is only using a subset
that did not really change even though the semantic version number
changed. Or the semantic version number indicates only minor changes
that sill break your client.

>    incompatible modification, this increases the number of modules.

So it seems to boil down to the question whether foo and foo2 is
significantly more expensive than foo { semver 1.x.y } and foo {
semver 2.x.y }. The main argument seems to be that the later keeps
references that involve module names or namespaces unchanged (but
they may or may not mean different things).

>    IMHO YANG package definition should be a separate issue, left out of this
>    document. Andy has already provided some very good ideas about this topic.

I think it is necessary to think about how the semantic version
numbers are used. See my remark above about imports. If we allow
incompatible changes, than this has side effects and I think we are
not done by just adding a semantic version number without going
working throught the implications.

/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, 14 Nov 2017 14:04:39 -0800

> accessible due to access control.)

There are lots of independent variables here.
The use of augment vs. new-module-version has a big impact on this problem.
But the IETF prefers to work on a module for several years, rather
than produce a base model that is extended by many other modules.
This approach has not produced a stable base of modules.
I think the idea is to worry less about stability and just iterate faster,
which might produce better results in the end.

> judgement call at the end with today's update rules.)

In "real" code, we never remove or change an API. Never.
This is what Balazs is talking about.  You make new APIs,
perhaps using wrapper functions, but you do not break code
that depends on the existing APIs.

I would rather have code break immediately and very visibly,
rather than having it appear compatible but in fact changed
behavior silently breaks functionality.  These bugs are harder to find.

I guess if the compiler keep track of the major version for every import
somehow,
then it could issue a warning that "major version changed in import"
if a module diff is done.

> compatible
> need an

I realized years ago that deprecated and obsolete definitions would create
the need for a compatible revision range (minver .. maxver) for every
import,
and the compatibility matrix would get increasing harder as the module
count grew

People called "package maintainers" do this work now in Linux-land.
The YANG Packages draft was an attempt to standardize a file format
that package maintainers would write and keep up-to-date.
Real testing and verification (with pyang and other tools) would be done
before a package can be released.  The common import mode would
be "greater-or-equal minver"  If a package maintainer decides the version
of "bar"
breaks module "foo", then an inclusive range is needed instead (minver ..
broken-1).

The current import-by-revision is too fragile and needs to be enhanced.

> /js
Andy

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

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 15 Nov 2017 11:33:18 +0800

See bellow!

> accessible due to access control.)
BALAZS: My point is that I do not want to check the full YAM (Yang 
Module) for status commands to understand compatibility. That is not 
better then doing a full analysis of the module. The goal that the 
module name is still the same but it can become incompatible due to 
deprecation is not good enough.
> judgement call at the end with today's update rules.)
BALAZS: Semantic versioning gives the editor the possibility to indicate 
that a change is non backward compatible(NBC). Even if the Yang Model 
type/restrictions/valuespace/etc. does not change, but I, the human 
model designer, know that the expected behavior of the SW implementing 
the model changes, I can still indicate that the model is changing in an 
NBC way. That's one reason I like, I need semantic versioning.
> this is all encoding details.
BALAZS: Even in XMLland we store the prefix as part of any leaf with 
type instance-identifier or identityref and potentially CLI scripts.
> I guess you mean the namespace, not the prefix. You can use any prefix
BALAZS: No, I mean the prefix. Prefix is part of the instance data (see 
above), potentially part of CLI scripts etc. It is also part of human 
communication. In email we never refer to
urn:ietf:params:xml:ns:yang:ietf-yang-library:/modules-state instead we 
just write yanglib:/modules/state.
> compatible revision' (whatever this means at the end).
BALAZS: We already  have this problem today. We allow incompatible 
updates for deprecated/obsolete. When you import a module, the importing 
module will not check for status statements. For "augment" or "must" 
referencing a deprecated and thus removed part will already today cause 
problems.
> the guarantee today is that the semantics stay the same and don't
BALAZS: Access control can be set by the operator, deviations are at 
least viewable, checkable in design time. However something (possibly) 
removed due to status just disappears. In my view the current status 
deprecated  is similar to deviation not-supported .
> that sill break your client.
BALAZS: Line by line comparison is needed, because today anywhere in the 
model you might find a new status deprecated statement. You are forced 
to do the line by line comparison and even that is no guarantee of 
compatibility due to behavior changes.
Yes you might set the semantic version incorrectly, but that's a bug. 
You might use other parts of YANG incorrectly too.
> they may or may not mean different things).
BALAZS: For SMALL NBC changes, I propose to keep the original module 
name. Now while agree it is possible to misuse this, and that SMALL is 
subjective, however we already have this situation. Removing stuff by 
deprecation is not much  better then just deleting the same.
In ericsson our internal definition of deprecation follows what e.g. 
JAVA does:
"Deprecated schema nodes MUST still work as defined by the YAM. The 
deprecated status serves only as a a warning that the schema node will 
be removed or obsoleted in the future."
This allows continued compatible usage while still warning the client, 
that the marked parts will go away soon.
> working throught the implications.
BALAZS: I don't object, although I would prefer to handle them separately.
I do object to the word "if". Due to YANG's current rules for status we 
already allow incompatible changes.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 15 Nov 2017 06:30:46 +0100

Another thing to consider is that foo and foo2 allows an
implementation to support both during transition, with foo {semver
1.x.y} and foo {semver 2.x.y} this may be harder.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 15 Nov 2017 06:50:09 +0100

On Wed, Nov 15, 2017 at 11:33:18AM +0800, Balazs Lengyel wrote:
> type/restrictions/valuespace/etc. does not change, but I, the human model
> designer, know that the expected behavior of the SW implementing the model
> changes, I can still indicate that the model is changing in an NBC way.
> That's one reason I like, I need semantic versioning.

You have several possible cases:

a) The semver indicates an non-compatible change and the change does
   affect your client.

b) The semver indicates an non-compatible change but the change does not
   affect your client.

c) The semver indicates no non-compatible change and your client happily
   continues to work.

d) The semver indicates no non-compatible change but there is a change
   that does affect your client.

It seems semantic versioning focuses on a) and c) but b) and d) may
still happen in practice.

> BALAZS: Even in XMLland we store the prefix as part of any leaf with type
> instance-identifier or identityref and potentially CLI scripts.

Which is risky since in principle there is no guarantee that the prefix
always remains the same.
 
> urn:ietf:params:xml:ns:yang:ietf-yang-library:/modules-state instead we just
> write yanglib:/modules/state.

See above.

> BALAZS: We already  have this problem today. We allow incompatible updates
> for deprecated/obsolete. When you import a module, the importing module will
> not check for status statements. For "augment" or "must" referencing a
> deprecated and thus removed part will already today cause problems.

There is in general a difference between the status of a definition
and which objects are implemented and which objects are accessible.

> BALAZS: Access control can be set by the operator, deviations are at least
> viewable, checkable in design time. However something (possibly) removed due
> to status just disappears. In my view the current status deprecated  is
> similar to deviation not-supported .

The status is known at compile time. Deviations are known at run-time,
not at design-time.

> model you might find a new status deprecated statement. You are forced to do
> the line by line comparison and even that is no guarantee of compatibility
> due to behavior changes.
> Yes you might set the semantic version incorrectly, but that's a bug. You
> might use other parts of YANG incorrectly too.

Semantic versioning gives you a hint, it does not tell for sure your
client fails not does it tell for sure your client will continue to
work.

> BALAZS: For SMALL NBC changes, I propose to keep the original module name.
> Now while agree it is possible to misuse this, and that SMALL is subjective,
> however we already have this situation. Removing stuff by deprecation is not
> much  better then just deleting the same.
> In ericsson our internal definition of deprecation follows what e.g. JAVA
> does:
> deprecated status serves only as a a warning that the schema node will be
> removed or obsoleted in the future."
> This allows continued compatible usage while still warning the client, that
> the marked parts will go away soon.

The difference is that Java releases are published regularly but IETF
published modules likely won't be republished to go from deprecated to
obsolete. The deprecated status leaves it to implementors to decide
whether they remove something. And implementors usually have little
interest to break clients.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Nov 2017 08:00:29 +0100 (CET)

> type instance-identifier or identityref and potentially CLI scripts.

This would be a broken implementation.  Since the prefix might change
you cannot store them as is.  You have to translate the prefix to
namespace/module name, and store that.

That said, this encoding rule is really unfortunate.  We fixed it in
the JSON encoding, and I wish we had the same in XML...

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 15 Nov 2017 15:13:00 +0800

> namespace/module name, and store that.

I agree. In XML land, there was a lot of software that relied on specific
prefixes, and it turned out to be a big problem.

> the JSON encoding, and I wish we had the same in XML...

Prefixes still give you some flexibility, for example the ability to import two
different revisions of the same module.

Lada

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Nov 2017 08:24:24 +0100 (CET)

> different revisions of the same module.

Sure, but that's not reflected in the encoding on-the-wire.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 15 Nov 2017 15:46:57 +0800

> Sure, but that's not reflected in the encoding on-the-wire.

XML has its own rules, so unless tools take a specific prefix for granted,
everything should be OK. One can also declare full module names as NS prefixes
in XML encoding to make it closer to JSON encoding.

The only minor problem is the paragraph in sec. 7.1.4 of RFC 7950 stating that
XML and XPath SHOULD use the prefix defined in YANG. IMO, this should be removed
(but, after all, it is only a SHOULD).

Lada

---

From: Joe Clarke <[email-masked]>
Date: Wed, 15 Nov 2017 03:44:26 -0500

> 1.x.y} and foo {semver 2.x.y} this may be harder.

I'm not convinced this a bad thing.  If a server supports multiple
versions of a given module, which should a client use?  Did the server
vendor test each one?

I suppose my gut reaction to Lou's question as to whether a server
should support multiple versions was, "no."  A client may have multiple
versions loaded to support servers that support different versions.  I
may be convinced otherwise, but I feel that this will become untenable
over time (even if module names change).

Joe

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Nov 2017 09:53:41 +0100 (CET)

Joe Clarke <[email-masked]> wrote:
> should support multiple versions was, "no."

Exactly.  With the current solution, the sever can still implement the
deprecated or obsolete nodes in order to support old clients.

With a MAJOR update in a semver world, it means that the old nodes are
removed (or rather, possibly, that the old nodes have new syntax
and/or semantics).

> A client may have multiple

I think the proposed solution will make it even harder for clients,
since the same paths will mean very different things on different
servers.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 15 Nov 2017 18:02:52 +0800

While a server may correctly support multiple versions, the human 
operator on the CLI has a 99% chance of mixing up which version he is 
using. Humans will not check every type and leaf  to check that they 
remember the little differences between model versions. It is a recipe 
for human mistakes. According to some statistics 50% of downtime is 
caused by human errors, so we should not provide the operator with a gun 
to shoot himself. Ericsson has a rule never to have multiple versions of 
the same module on a network node.

regards Balazs

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 15 Nov 2017 18:06:43 +0800

> over time (even if module names change).

There are use cases for modules that are imported (i.e. not
implemented): it could be that a module author wants to use some
definitions from an old version of an imported module while, at the same
time, other definitions from a new version.

The semver-aware "import" statement should be able to deal with this.

Lada

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 15 Nov 2017 18:12:04 +0800

The server MAY implement obsoleted nodes or MAY NOT. This may or may 
not  is not good enough as a contract for the management client.  My 
problem is that the current solution is just not good enough. IMHO we 
need to change it.

Even after semver you can still obsolete the old stuff and provide the 
new stuff with a new name, although that might not be the common 
practice.  Which is a good thing, as I believe it is sometimes better to 
correct existing definitions then to replace them.

regards Balazs

---

From: Joe Clarke <[email-masked]>
Date: Wed, 15 Nov 2017 05:19:33 -0500

> deprecated or obsolete nodes in order to support old clients.

I'm not convinced a vendor would do this in reality.  Though I suppose
they could advertise this with a deviation.  There would still be
additional burden on the client.  That is, the client would want to make
sure that the obsolete nodes are actually supported by this server and
not just there returning potentially bogus values.

In a semver world, obsolete nodes could be reintroduced with vendor
modules via augments or in proprietary trees.

> since the same paths will mean very different things on different

I agree there is burden on the client, but the client would know of
these differences assuming yang-lib and capabilities report the right thing.

Joe

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 15 Nov 2017 18:20:51 +0800

Hello,

I would like to extend my list of base problems to 3:

Non-backward compatible (NBC) changes should be allowed in
some limited cases

It should be possible to determine two module versions'
compatibility without a line-by-line comparison

It should be possible to indicate that a part of a schema is
deprecated, but is still present, implemented and usable

3) Is needed because we need to be able to warn the consumers of
a YANG module (YAM) that some part will be going away, while at
the same time we need to promise them  that it is still usable. We
need a firm contract not a maybe about this.

regards Balazs

On 2017-11-15 00:51, Balazs Lengyel
wrote:

Hello,

First of all Ericsson very strongly supports this draft. This
is a problem we definitely have, and for which we had to create
our own internal solution. So we would love to see an IETF
solution!

General)

we should allow non-backward compatible (NBC) changes in
some limited cases

Whenever a client OSS implements some higher level logic for a
network function, something that can not be implemented in a
purely model driven way, it is always dependent on a specific
version of the Yang Module (YAM). If the client finds that the
module has been updated on the network node, it has to decide if
it tries to handle it as it did the previous version of the
model or if it just stops to avoid problems. To make this
decision the client needs to know if the module was updated in a
backward compatible way or not. This is not addressed with the
current versioning.

While having PYANG based checks for backward compatibility is a
very good idea, a  comparison based check will never be a
complete check. It is quite possible to change just the behavior
of an rpc/action/etc.  without changing the YANG definition.
This will only show up as a change of the description statement
that can not be analyzed by PYANG.

When upgrading a network node we might introduce non-backward
compatible (NBC) changes. Today we need to introduce a new
module for this. That means during the upgrade process the node
must convert stored configuration instance data from
ietf-routing to ietf-routing-2 format. Instead of solving this
data transformation/transfer problem just for a few NBC data
nodes, we will have to do it for the full model. This is
complicated. In many cases the transformation of a few NBC leafs
can be handled by good defaults or with a small script.
Transferring the full data set is more complicated. If we allow
NBC updates in some cases this problem is avoided.

If we update the module from ietf-routing to ietf-routing-2 ?
Do we keep the prefix?  In one sense it should be kept as it is
the same module "logically"; we also might have stored data
including the prefix (identityrefs, instance-identifiers). On
the other hand having multiple modules with the same prefix is a
problem. The only good solution is to allow incompatible updates
in some cases.

CH 1)

You write

"The YANG data modeling language [RFC7950] specifies strict
rules for updating..."

and again

I strongly disagree. While we have strict rules about even
small modifications to existing schema, but you are allowed to
deprecate/obsolete big parts of the model, thereby possibly
deleting complete subtrees from the schema. That is anything but
strict backward compatibility.

I find this aspect of YANG inconsistent to the level that it
would need an errata.

So practically the current rules allow backward incompatible
changes that can only be detected by a line by line comparison
of the yang modules. In a system with semantic versioning, you
could determine backward compatibility just by reading the
version numbers.

CH 2.3)

As we need to create a new Yang Module (YAM) even for the
smallest incompatible modification, this increases the number of
modules.

CH 2.5)  We already have vendor modules depending on
ietf-routing

CH3.1)

I propose that the semantic version should be a mandatory
substatement of the YANG revision statement. It should be
updated every time, and it would be good to see the older
semantic versions as well.

I would propose to have 3 separate statements for x,y,z. I
don't like structured strings. It would be much easier to
compare simple integers.

IMHO YANG package definition should be a separate issue, left
out of this document. Andy has already provided some very good
ideas about this topic.

I also think the current definition of deprecated and obsolete
in YANG 1.1 is near useless, as all it says that both deprecated
and obsolete items may or may not be there. We need something
better.

regards Balazs

---

From: Joe Clarke <[email-masked]>
Date: Wed, 15 Nov 2017 05:27:20 -0500

> The semver-aware "import" statement should be able to deal with this.

I think it could be, but I also think importing from different versions
of the same module feels messy.  How would this work with different
module names today?  Just use different prefixes?  Are there defined use
cases for this in the wild today?

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 15 Nov 2017 11:29:03 +0100

> modules via augments or in proprietary trees.

This obviously does not fix a client that got broken (without updating
the client). Is it generally true that clients always move at least as
fast as servers?

/js

---

From: Joe Clarke <[email-masked]>
Date: Wed, 15 Nov 2017 05:34:17 -0500

> the client). Is it generally true that clients always move at least as

In my experience, it depends.  It may sometimes be quicker to apply
patches to a client versus update a server (or a collection of servers).

Joe

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 15 Nov 2017 18:38:36 +0800

> cases for this in the wild today?

Let's say a new version of a module adds new enums to two different enumeration
types, but an implementor (for some reason) is only able to update one of them
in the back-end and not the other.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 15 Nov 2017 18:53:07 +0800

> problem is that the current solution is just not good enough. IMHO we 

I agree. My observation has been that the YANG contract is often interpreted in
a very server-centric way: clients just have to be prepared to any surprises.
(This reminds me of the contracts I have with insurance companies.)

Yet I think it is quite important to also support dumb clients that are written
to do some job, and may easily break if a node suddenly disappears.

Lada

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 15 Nov 2017 18:59:02 +0800

Hello,

https://tools.ietf.org/html/rfc7950#section-7.21.2

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

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

As I understand this both means that a node that is either
deprecated or obsolete MAY be

not implemented. In both cases it is allowed not-to-implement the
node.

This really works as if there would be an if-feature statement on
each deprecated schema node

where the server does not advertise whether the feature is supported
of not. Why is it not advertised?

YANG is considered an interface contract,  however a "maybe
implemented" is unusable in a contract.

I would like to propose an alternate definition:

o "deprecated" schema nodes MUST still work as defined by the YANG module.
The deprecated status serves only as a a warning that the schema node
will be removed or obsoleted in the future."

I know this is a
significant change, but I consider the current definition of
deprecated not really usable,

so we need to do something.

YANG already has a feature
to make some schema parts optional,  based

on the decision of the implementer: its called feature. Lets use
that one.

This would allow the client to understand if the relevant parts
are still there.

As an example what I would
do is:

module ietf-system {
feature pre-nmda-support ;

container system {...}

container system-state {
if-feature pre-nmda-support ;
status deprecated;
}
}

regards Balazs

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Nov 2017 12:17:16 +0100 (CET)

> problem is that the current solution is just not good enough. IMHO we

Note that if a server implements version 1 of a module, and then the
module doesn't change, but the server in the next sw version drops
support for the module, the client will also be unhappy.  We (the
IETF) can't have rules for these kinds of things.

> practice.  Which is a good thing, as I believe it is sometimes better
> to correct existing definitions then to replace them.

But you still want to require servers to implement even obsolete
nodes?

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 15 Nov 2017 21:06:35 +0800

> IETF) can't have rules for these kinds of things.

If the server drops support for a module, then that module has to disappear from
YANG library, so it is a priori known that it happened. With deprecated/obsolete
nodes, a server may drop their support without any notice, within the same
module&revision. 

> But you still want to require servers to implement even obsolete

I think with semver support there will be no need for the "status" statement -
the nodes just get removed and version number bumped.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 15 Nov 2017 14:20:17 +0100 (CET)

> nodes, a server may drop their support without any notice, within the same

I agree that *that* is a problem, but that's not what Balazs asked about.

/martin

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 16 Nov 2017 01:41:29 +0800

On 2017-11-15 21:20, Martin Bjorklund
wrote:

/martin

BALAZS: Actually this exactly one of my problems. See other letter
for my 3 problems. This is one cause of 2)

Lada

BALAZS: You still need at leaast deprecated: my proposal

---

From: Randy Presuhn <[email-masked]>
Date: Wed, 15 Nov 2017 11:07:27 -0800

Hi -

> the same module on a network node.

Does this mean that they require all line cards in a chassis to have
exactly the same firmware revision level?  If so, when a card with a
newer firmware revision level is swapped in, does that require all other
cards of the same type in that chassis to also be replaced concurrently?
Sounds like even a fairly routine/minor update/repair would effectively
result in a system outage.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 Nov 2017 10:11:01 +0800

> result in a system outage.

To be fair, there is no good solution to this in the current state of
affairs either. The limiting factor is the document-oriented nature of
YANG. It is a good use case for schema mount though.

Lada

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 16 Nov 2017 12:35:18 +0800

Hello Randy,
I agree that the problem can not be eliminated, however it is still a 
nasty problem which we should try to avoid whenever possible. So if we 
can avoid it 75% of the time I am happy. (I don't often _configure_ 
firmware, so I am less worried about that :-)  )
regards Balazs

On 2017-11-16 03:07, Randy Presuhn wrote:
>> remember the little differences between model versions. It is a 
>> recipe for human mistakes. According to some statistics 50% of 
>> downtime is caused by human errors, so we should not provide the 
>> operator with a gun to shoot himself. Ericsson has a rule never to 
>> have multiple versions of the same module on a network node.
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 16 Nov 2017 14:49:33 +0800

On Thu, 2017-11-16 at 12:59 +0800, Balazs Lengyel wrote:
> Hello Lada,
> Yes it is necessary. Just have a look at how Java uses it.  It is formulated: 
> XXX deprecated, use YYY instead.

But the data, at the end of the day, have to correspond to what is implemented
in the device. So even if an IETF WG decides to roll out a shiny new version of
module X, a vendor may still want to keep the old version, possibly forever, and
then the deprecated status information from the old version of X may be false
alarm. It would seem more appropriate for the vendor to do this kind of
signalling before a new release is coming.

On the other hand, it would IMO be too much to require that a node can be
removed only after being deprecated.

Lada

> We want to give client OSS implementers an advance warning that XXX will be
> removed, they better start planing to use YYY instead. This revision is still
> compatible, it still supports XXX, but the next one won't. This way for OSS
> the migration from XXX to YYY is less painful.
> regards Balazs
> 
> On 2017-11-16 10:04, Ladislav Lhotka wrote:
> > But is this really necessary? As long as the new (incompatible) version
> > doesn't get pulled in automatically, implementors needn't care too
> > much. And if they decide to upgrade to the new version, they have to
> > check the differences anyway - as you said, they may not be in the
> > schema.
> > 
> > Lada
> > 
> 
>

---

From: Joe Clarke <[email-masked]>
Date: Thu, 16 Nov 2017 21:55:45 -0500

> in the back-end and not the other.

I read implementor to be "vendor" here.  And if a vendor cannot
implement one of the enums, would they not just add a deviation?  I
don't see why they'd have to keep the old module around for this.

Joe

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Nov 2017 13:14:51 +0100

> I read implementor to be "vendor" here.  And if a vendor cannot

Instead of "implementor" I should have said "module author" - it could be a
vendor or IETF WG or whatever. A realistic example might be a module for certain
IANA parameters such as

https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

If IANA updates this registry, the author of a module that uses it might want to
update some enumerations while keeping others in the old version. The reason for
doing so may be, for example, that some cipher has to be removed for security
reasons, but migrating completely to the new registry version is a long shot
that needs more time.

> implement one of the enums, would they not just add a deviation?  I

Vendors generally don't like to declare deviations, and I think it would be
really weird if an IETF standard track module contained a deviation.

Lada