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

[Ladislav Lhotka <[e-mail]>]

Balazs Lengyel <[e-mail]> writes:

> On 2017-11-15 21:20, Martin Bjorklund wrote:
>
>  Ladislav Lhotka <[e-mail]> wrote:
>
>  On Wed, 2017-11-15 at 12:17 +0100, Martin Bjorklund wrote:
>
>  Balazs Lengyel <[e-mail]> wrote:
>
>  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.
>
>
> 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.
>
>
> 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. 
>
>
> I agree that *that* is a problem, but that's not what Balazs asked about.
>
>
> /martin
>
> BALAZS: Actually this exactly one of my problems. See other letter for
> my 3 problems. This is one cause of 2)

Thank you, Balazs, I was getting confused. ;-)

>
>  
>
>  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.
>
>
> But you still want to require servers to implement even obsolete
> nodes?
>
>
> I think with semver support there will be no need for the "status" statement -
> the nodes just get removed and version number bumped.
>
> Lada
>
> BALAZS: You still need at leaast deprecated: my proposal
> 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."

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

> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: [phone]              email: [e-mail] 

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67
-------------------- End of forwarded message --------------------

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