Subject: [Netmod-ver-dt] One more problem with the current YANG versioning - status+referencing

From: Balazs Lengyel <[email-masked]>
Date: Mon, 9 Jul 2018 12:43:29 +0200

Hello,

Maybe we have discussed this, but I don't remember.

I have two models modA and modB. modB has a leafref (leafB)
pointing at modA leaf leafA.

All data nodes are status=current

modA is updated making leafA deprecated, which is fully inline
with https://tools.ietf.org/html/rfc7950#section-11 It is a
compatible change as explicitly stated.

After the modA update modB will not even compile as a current
leaf is not allowed to reference a deprecated leaf according to
https://tools.ietf.org/html/rfc7950#section-7.21.2

regards Balazs

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

---

From: Ebben Aries <[email-masked]>
Date: Mon, 9 Jul 2018 12:45:52 -0600

On Jul 09 12:43 PM, Balazs Lengyel wrote:
>   • I have two models modA and modB. modB has a leafref (leafB) pointing at
>     modA leaf leafA. 
>   • All data nodes are status=current
>   • modA is updated making leafA deprecated, which is fully inline with https:/
>     /tools.ietf.org/html/rfc7950#section-11 It is a compatible change as
>     explicitly stated.
>   • After the modA update modB will not even compile as a current leaf is not
>     allowed to reference a deprecated leaf according to https://tools.ietf.org/
>     html/rfc7950#section-7.21.2
>

While this creates a transition path, the wording in section 7.21.2
enforces dependant modules to be updated otherwise breaking
compatibility

>From a client side, you may not need to alter payloads during this
transition and thus retain backwards compatibility but all models would
need to be collectively updated... this may be a bit strict during a
deprection phase imo

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 10 Jul 2018 10:46:58 +0200

On 7/9/2018 8:45 PM, Ebben Aries wrote:

Hello,

BALAZS: Still this breaks the principle, that
once you have a  module defined, it will always be usable, because
it is always updated in a compatible manner.

If you are a device vendor, you will probably catch this during
design, just as you would catch other clearly non-backward
compatible changes like  a removed typedef or grouping, however
for an NMS this might be a bigger problem.

Even if we introduced some mechanism for the client to check
whether a deprecated node is still implemented or not, it would
still not solve this problem.

Only half the checker tools catch this problem, confdc found it,
but pyang and yanglint missed it..

BALAZS: From a client side we get back to the
problem that you don't know if deprecated/obsolete nodes are still
implemented or not.

---

From: Robert Wilton <[email-masked]>
Date: Wed, 11 Jul 2018 15:45:20 +0100

Hi Balazs,

RFC 7950 sec 7.21.2 only says that it is a error if a "current" node 
references a "deprecated" or "obsolete" node in the same module, which 
seems reasonable, since it must always be possible to update both in the 
same revision.

If your example below, then I would expect a good YANG compiler to 
generate a warning for leafB that it referencing a deprecated or 
obsolete leaf.

In semver terms, I think that this means that going from status current 
to deprecated may be a minor version change, but going from status 
current/deprecated to obsolete must be regarded as a major version change.

Thanks,
Rob

On 09/07/2018 11:43, Balazs Lengyel wrote:
>   * I have two models modA and modB. modB has a leafref (leafB)
>   * All data nodes are status=current
>   * modA is updated making leafA deprecated, which is fully inline
>   * After the modA update modB will not even compile as a current leaf
>     is not allowed to reference a deprecated leaf according to
> Mobile: +36-70-330-7909              email:[email-masked]  
>
>
> _______________________________________________
> Netmod-ver-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 12 Jul 2018 11:25:04 +0200

Hello Rob,

As I see it the two changes

deprecating a used grouping

removing a used grouping

both result in compile time errors and forced updates to all
importer YAMs.

Why is then case 1 allowed while case 2 is prohibited?

Maybe this is out-of-scope for our draft, but it certainly seems
illogical.

regards Balazs

On 7/11/2018 4:45 PM, Robert Wilton
wrote:

Hi Balazs,

RFC 7950 sec 7.21.2 only says that it is a error if a "current"
node references a "deprecated" or "obsolete" node in the same
module, which seems reasonable, since it must always be possible
to update both in the same revision.

If your example below, then I would expect a good YANG compiler
to generate a warning for leafB that it referencing a deprecated
or obsolete leaf.

In semver terms, I think that this means that going from status
current to deprecated may be a minor version change, but going
from status current/deprecated to obsolete must be regarded as a
major version change.

BALAZS: I agree, but only if deprecated stuff
is actually implemented. Following this logic, referencing a
deprecated item should generate warnings, but not errors.

Thanks,

Rob

On 09/07/2018 11:43, Balazs Lengyel
wrote:

Hello,

I have two models modA and modB. modB has a leafref
(leafB) pointing at modA leaf leafA.

modA is updated making leafA deprecated, which is fully
inline with https://tools.ietf.org/html/rfc7950#section-11
It is a compatible change as explicitly stated.

After the modA update modB will not even compile as a
current leaf is not allowed to reference a deprecated leaf
according to https://tools.ietf.org/html/rfc7950#section-7.21.2

regards Balazs

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 12 Jul 2018 11:44:16 +0200

I do not think that 1. should result in an error but in a warning.
In today's YANG, you can't remove a grouping, you can only obsolete
it.

/js

On Thu, Jul 12, 2018 at 11:25:04AM +0200, Balazs Lengyel wrote:
>     1. deprecating a used grouping
>     2. removing a used grouping
> 
>    both result in compile time errors and forced updates to all importer
>    YAMs.
>    On 7/11/2018 4:45 PM, Robert Wilton wrote:
> 
>      Hi Balazs,
> 
>    BALAZS: I agree, but only if deprecated stuff is actually implemented.
>    Following this logic, referencing a deprecated item should generate
>    warnings, but not errors.
> 
>      Thanks,
>      Rob
> 
>            with [1]https://tools.ietf.org/html/rfc7950#section-11 It is a
>            [2]https://tools.ietf.org/html/rfc7950#section-7.21.2
> 
>        regards Balazs
> 
>  --
>  Mobile: +36-70-330-7909              email: [3][email-masked]
> 
>  [4][email-masked]
>  [5]https://www.ietf.org/mailman/listinfo/netmod-ver-dt
> 
>  --
>  Mobile: +36-70-330-7909              email: [6][email-masked]
> 
> References
> 
>    Visible links
>    1. https://tools.ietf.org/html/rfc7950#section-11
>    2. https://tools.ietf.org/html/rfc7950#section-7.21.2
>    3. mailto:[email-masked]
>    4. mailto:[email-masked]
>    5. https://www.ietf.org/mailman/listinfo/netmod-ver-dt
>    6. mailto:[email-masked]

-- 
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/>