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