Re: [netmod] missing YANG versioning requirements

[Robert Wilton <[e-mail]>]

On 12/11/2018 16:15, Andy Bierman wrote:
>
>
> On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>
>     On 09/11/2018 18:35, Andy Bierman wrote:
>>     Hi,
>>
>>     I think the requirements doc should state that
>>
>>     1) there are many more readers, operators, and client developers than
>>     server developers so the solution MUST take into account the numbers
>>     of people affected when finding a balance between client and
>>     server complexity.
>     OK.  So you would like the solution to be weighted towards
>     clients, but yet you do not want servers to have to implement any
>     sort of version selection, instead pushing the problem on to the
>     client? :-)
>
>
>
> I support some aspects of this work:
>   - SEMVER
>   - import-stmt
>   - status-stmt
OK

>
> I strongly oppose the simultaneous implemented revisions requirement 
> because it is actually
> a solution, not a requirement at all, and a bad solution.
>

>
> For any given buggy data node, a replacement sibling can be created so 
> the new node and the deprecated
> buggy node can both be implemented.
So, I regard this as a potential solution to requirement 3.2.

However, I still do not understand a scheme for how this works for 
config items, either covering all of the various corner cases of clients 
at different versions, or at least states under what assumptions that 
solution works.

Please can someone who thinks that this is a solution explain how this 
solution works.  I think that there are quite a lot of potential 
questions/issues:

Are there two version entirely independent of are they connected (i.e. 
updating one, updates the other)?
If they are dependent then does writing one value also update the other one?
If they are independent they can two different values be written 
(perhaps for a pair of leaves this could be enforced with a must 
statement), but with more complex models this is not possible?
Does this solution support 2 clients interacting with the server using 
different versions of the leaf, or is it assumed that all clients will 
interact using the same version?
What happens if both leaves have different default values (perhaps this 
can just be avoided)?
What happens when the new value cannot be represented in the old leaf 
used by client A?  It now has a configuration that it cannot change 
because it doesn't know about the new leaf.
What leaf values are updated in operational?  Is it both of them, or 
just one of them?


>
> YANG represents a customer-facing API, like the CLI. Vendors 
> understand that customers
> don't like it when CLI keywords change meaning from release to 
> release.  Vendors are careful
> to introduce new keywords so the old ones keep working.

For our CLI, we generally accept the old, but always return the config 
using the new CLI.  However, I would expect that approach would probably 
break clients using YANG.  They would be confused that the configuration 
returned via get-config does not match what they programmed via edit-config.

>
>     More seriously, I'm looking for a solution where we it up to the
>     market to decide whether the complexity should be pushed to
>     client, server, or a 3rd party controller.  I think that some sort
>     of version selection should be able to achieve this.
>
>
>
> I do not agree the standards should be changed to support this 
> solution approach.

>>
>>     2) if existing protocol and YANG solutions exist then they MUST
>>     be used
>>     in favor of developing new solutions.
>     If you replace the "MUST" with a "SHOULD" then I sort of think
>     that this one is obvious.  I think that we are only trying to
>     develop next solutions where the existing ones do not appear to be
>     working well.  There are examples in the earlier text in the
>     requirements draft, and also draft-clacla-netmod-yang-model-update
>     to provide the background and justify why we need to do something
>     different than the status quo.
>
>
>
> It would help to have real examples where deprecate-and-replace was an 
> unworkable solution.
I would happy to start with an example where you think it does work, 
taking into consideration the questions that I provided previously.

> IMO it is OK to update a data node because sub-statements are 
> incorrect (e.g. pattern, type).
> In this case, the old definition is not worth preserving.
This can still break some clients.

>
> Note that changes between I-Ds are not interesting. Only changes from 
> RFC to RFC are interesting.
> Vendors need to review their own modules and do a better job 
> identifying stable vs. unstable releases.
I agree to both of these.

But lets not pretend that all code that we ever produce will be perfect 
the first time, contain no bugs, and never need to be changed.  We have 
seen the industry push for us to be more reactive and get changes out 
more quickly.  I would argue that a natural side effect of that is that 
there are likely to be more bugs that will need fixing.

Thanks,
Rob


>
>
>     Thanks,
>     Rob
>
>
>
> Andy
>
>
>>
>>
>>     Andy
>>
>>
>>
>>     _______________________________________________
>>     netmod mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/netmod
>>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>