Subject: [netmod] missing YANG versioning requirements

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Nov 2018 10:35:19 -0800

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.

2) if existing protocol and YANG solutions exist then they MUST be used
in favor of developing new solutions.

Andy

---

From: Robert Wilton <[email-masked]>
Date: Mon, 12 Nov 2018 15:01:03 +0000

> of people affected when finding a balance between client and server 
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? :-)

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.

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

Thanks,
Rob

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Nov 2018 08:15:49 -0800

> selection, instead pushing the problem on to the client? :-)

I support some aspects of this work:
  - SEMVER
  - import-stmt
  - status-stmt

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.

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.

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

> 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

It would help to have real examples where deprecate-and-replace was an
unworkable solution.
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.

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.

Thanks,

Andy

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

---

From: Robert Wilton <[email-masked]>
Date: Mon, 12 Nov 2018 17:20:03 +0000

On 12/11/2018 16:15, Andy Bierman wrote:
>
>
> On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>>     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? :-)
>
>
>
OK

>
> For any given buggy data node, a replacement sibling can be created so 
> the new node and the deprecated
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

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.

>     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.
>
>
>
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).
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

>>     [email-masked] <mailto:[email-masked]>
>>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 12 Nov 2018 16:02:17 -0800

On Mon, Nov 12, 2018 at 9:20 AM, Robert Wilton <[email-masked]> wrote:

> 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.
>
I think model transformation is a flawed solution and not worth doing,
especially since the goal is to map NBC changes that do not work well with
this solution.
It is designed to map 1 disjoint subtree to another one, not really 2
revisions of the same nodes.
To be clear: I am not proposing that this solution be standardized at all.

> updating one, updates the other)?

no

> If they are dependent then does writing one value also update the other

no

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

The <running> and <intended> datastores would have the configured values,
and <operational>
would have the value in use.

   start: foo = bar = 5
   config: foo=5, bar=5
   operational: foo=5, bar=5

  set bar to 10
  config: foo=5, bar=10
  operational: foo=10, bar=10

the 'origin' value is 'intended' for bar.
Not sure what it should be for foo.

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

If the transformation is 2-way then get-config can return the outer model.
You have to do that if the client implements only the
outer model and the server does not even advertise the inner model.

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

Agreed.
It depends on the bugfix.
With the ip-address pattern example, a correct client would only be
sending valid addresses that match the new pattern.  I understand that
sometimes a vendor wants to let the client send invalid values.
IMO this is a case where deprecate-and-replace is needed.

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

Nobody is pretending code or YANG will be perfect in the first release.
The issue is how you fix the module and support existing clients at the
same time.
Since the new client has to know about the new revision anyway (even if
/restconf is
changed to /restconf2) is is usually OK to deprecate and replace the buggy
node.

Thanks,
Andy