Subject: [netmod] rfc7223bis Backward compatibility in YANG - BAD !!!

From: Balazs Lengyel <[email-masked]>
Date: Thu, 9 Nov 2017 17:59:49 +0100

Hello,
In draft-ietf-netmod-rfc7223bis-00 I read

The "/interfaces-state" subtree with "config false" data nodes is
    deprecated.  ...

    Servers that do not implement NMDA, or that wish to support clients
    that do not implement NMDA, MAY implement the deprecated
    "/interfaces-state" tree.

This means that a server MAY simply remove a big branch 
(interfaces-state). If I have a network management system (NMS) and the 
YANG server upgrades to a new revision of the module suddenly my NMS SW 
breaks.

I find it really strange that, on a one hand YANG has very strict rules 
about updating a module, on the other hand just by deprecating something 
you can remove anything. Are we taking backward compatibility seriously 
or not? It seems not.

Earlier we had discussions about the definition of deprecated and 
obsolete in https://tools.ietf.org/html/rfc7950#section-7.21.2.
 From an NMS point of view the current definition just states: Anything 
can be deprecated/obsoleted anytime. If something has a status different 
from current there is no guarantee its usable or even that it exists.

IMHO these definitions are unusable for an NMS. Ericsson needed to 
introduce its own rules. IETF should do something about this! I have 
proposals if there are people interested.

As a minimum I would propose, that a server that does not implements a 
fully functional /interfaces-state" subtree MUST obsolete it, not just 
deprecate it.

regards Balazs

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 9 Nov 2017 09:36:13 -0800

On Thu, Nov 9, 2017 at 8:59 AM, Balazs Lengyel <[email-masked]>
wrote:

> you can remove anything. Are we taking backward compatibility seriously or
> not? It seems not.
>
>

Ironically, the NMDA approach was sold as the solution path without any
disruption to the data models.

Customers will pressure vendors to fix "stuff that used to work" and
generally
vendors avoid breaking it in the first place.  3rd party NMS has never been
a priority
anywhere, including the IETF.

Earlier we had discussions about the definition of deprecated and obsolete
> in https://tools.ietf.org/html/rfc7950#section-7.21.2.
> From an NMS point of view the current definition just states: Anything can
> be deprecated/obsoleted anytime. If something has a status different from
> current there is no guarantee its usable or even that it exists.
>

how does this help?
Duplicate read-only data does not break anything.
An old client can keep reading /interfaces-state and a new client
can use <get-data>.

There are some problems with NMDA that break old clients (e.g., rpc and
action)
but this isn't one of them.

> regards Balazs

Andy

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

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 9 Nov 2017 13:19:37 -0800

Hi -

On 11/9/2017 8:59 AM, Balazs Lengyel wrote:
...
> from current there is no guarantee its usable or even that it exists.

Robust NMS software needs to take this stance anyway.  Deprecation and
obsolescence are not the only reasons something may become unusable or
disappear.  Consider, for example, changing access control policies,
hot swap / insertion, and outright failures or bugs.  A management
application that cannot deal with these possibilities isn't ready
for the real world, IMO.

Randy