Re: [netmod] missing YANG versioning requirements

[Andy Bierman]

On Mon, Nov 12, 2018 at 9:20 AM, Robert Wilton  wrote:

>
>
> On 12/11/2018 16:15, Andy Bierman wrote:
>
>
>
> On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton  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:
>
>
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.



> Are there two version entirely independent of are they connected (i.e.
> updating one, updates the other)?
>

no


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

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  and  datastores would have the configured values,
and 
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.






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


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.



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

Re: [netmod] missing YANG versioning requirements

[Robert Wilton]

On 12/11/2018 16:15, Andy Bierman wrote:



On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton > 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

Re: [netmod] missing YANG versioning requirements

[Andy Bierman]

On Mon, Nov 12, 2018 at 7:01 AM, Robert Wilton  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

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.


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

Andy


>
>
>
> Andy
>
>
>
> ___
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] missing YANG versioning requirements

[Robert Wilton]

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


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.





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.


Thanks,
Rob





Andy



___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod