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