On Tue, Jul 24, 2018 at 8:32 AM, Robert Wilton <rwil...@cisco.com> wrote:
> > > On 24/07/2018 16:11, Andy Bierman wrote: > > > > On Tue, Jul 24, 2018 at 2:29 AM, Juergen Schoenwaelder < > j.schoenwael...@jacobs-university.de> wrote: > >> On Sat, Jul 21, 2018 at 05:47:45PM -0400, Christian Hopps wrote: >> >> > There are actual instances where small perhaps non-disruptive but >> > incompatible changes are required. The example given to me for this >> > type of change was when the original specification had an obvious >> > bug (e.g., a range was incorrectly specified). >> >> I strongly believe that fixing bugs is not a reason to change the >> current versioning rules. Bugs come essentially in three flavors: >> >> - A definition is messed up (i.e., a range, a pattern, a must >> expression) but the original intention of the definition is clear >> from the context (description clauses, references, ...). In this >> case, implementors will likely have done the right thing (or when >> they observed the problem they will likely have done the right >> thing). >> >> - A definition is messed up but it is not clear from the context what >> the original intention of the definition was. In this case, there is >> a true ambiguity and implementors can rightfully have come to >> different conclusions how to deal with the conflict in the >> definition. >> >> In the first case, I believe there is no issue with simply fixing the >> messed up definition. I believe this kind of bug fixes is not >> constrained by the YANG update rules. >> >> In the second case, there is true ambiguity what implementations may >> do and hence the safest approach is to deprecate the messed up >> definition and to create a replacement. >> >> Of course, in reality, things are often not so clear cut and hence it >> takes some informed judgement what is the reasonable way to deal with >> things. (A type two bug caught very early may be different from a type >> two bug caught after several months of implementation and deployment.) >> >> Sometimes we also have situations where a definition that was >> originally OK turs out over time to be problematic as technology has >> evolved. So after some time, the original definition starts to look >> like a bug but it actually is not. The safe path forward is again to >> create new definitions and to deprecate the old ones. >> >> Now, for those in favour of moving from (module, path) to (module, >> path, version), you loose the deprecated definition. So if you wan't >> to allow for a transition period, there is a need to allow an old >> client to work with the old definition and a new client to work with >> the new definition. In the current naming scheme, this is not a >> problem, with a (module, path, version) naming scheme this requires >> some extra complexity. >> >> > > The problem with versioning the "YANG API" is that it is not possible to > isolate > individual modules and say "I pick version 1.0.3 of module foo and version > 2.1.1 > of module bar". And every client can pick a different arbitrary subset of > mix-and-match YANG modules. > > Well YANG does not work that way. There is no concept of a YANG package. > There is no concept of a group of modules/versions/features that are > not divisible within a server implementation. > > The other problem is what you are pointing out.. > It would be far easier to just fix the clients and the servers, not just > the servers. > Why is it OK for the client developer to decide "we are sticking with the > defective version of the module and not going to upgrade to > the fixed version like the server developers have done." > > > One of the aims of the YANG versioning work is to give more information to > the client about whether they are likely to be impacted by upgrading to a > new set of modules. For me, I think that the most useful thing is if this > is done by comparing the full schema between old and new releases > (including module versions, enabled features, and deviations), and then > identifying the data nodes that have been changed in a backwards compatible > way, and those that have been changed in a non backwards compatible way (if > that is allowed). > > E.g. even it is a change is an obvious bugfix, it still makes sense to > flag that change so that client implementations can be checked to ensure > that they don't break. > > But if fixing a definition requires a whole new module name then I think > that causes lots of problems (e.g. consider needing to change > ief-interfaces to ietf-interfaces-v2 because of changing one random leaf). > The YANG 1.1 way is to define a new definition and then deprecate the > broken one. But this has negative consequences as well, e.g. does writing > to the old leaf automatically also write to the new leaf at the same time? > Are both returned in a get request? What if a different client only writes > to the new leaf? > > I agree a new module is not required. I like SEMVER. It is still better to follow the YANG update rules, but I am OK with using the major version to indicate a non-backward-compatible change. IMO it should not be fine-grained (e.g., SEMVER per object). The scope of the standard should just be to identify versions with SEMVER and fix import-stmt. I think a server could version the API (all modules, not client-picked). Not convinced this is a high priority at all, or that it would be easy to standardize. Thanks, > Rob > > Andy > > > > /js >> > > Andy > > >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >> Fax: +49 421 200 3103 <https://www.jacobs-university.de/> >> > > > > _______________________________________________ > netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod > > >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
