On Sat, Jul 21, 2018 at 9:00 AM, Christian Hopps <[email protected]> wrote:
> As I pointed out at the mic @102 this requirement derives directly from > the 1.x requirement of not changing the name of the module/namespace. If > you allow for changing the namespace/module name for "major" (i.e., > incompatible) changes (i.e., like today) then this 3.1 requirement goes > away. > > I think the plan is to reword some of these to get closer to the intention > which I believe is to allow for smoother transition from one module to the > next while making incompatible but mostly non-impacting changes. > > You may find that reality interferes with your requirement. The term "incompatible" should be a clue. If the change is genuinely incompatible then the underlying system change may be incompatible as well. Passive operations like <get> are not a problem, but configuration datastores are a problem. There are good reasons that RFC 7950 says only 1 revision of a module can be advertised by a server. There is already a practical solution that is available today. A vendor can implement the server in a way that allows their customer to select the appropriate revision for their use-cases and tools environment. So how does YANG validation work? There is only 1 instance of <intended>. E.g., i there are 3 versions of module A and 2 versions of module B, then which versions does module C use for XPath validation that reference modules A and B? Is a new version of XPath needed for YANG? It is possible to make a standard so complicated that nobody implements it. Thanks, > Chris. > > Andy > Andy Bierman <[email protected]> writes: > > Hi, >> >> I strongly object to requirement 3.1: >> >> >> 3.1 The solution MUST provide a mechanism to allow servers to >> support existing clients in a backward compatible way. >> >> >> >> This is not what servers do today at all. >> They provide only one version of an implemented module, as specified in >> RFC >> 7950. >> >> It is a vendor and operator decision when to upgrade a server such that >> non-backward compatible changes are made. They must decide if/when it is >> ok >> based on the client applications in use. >> >> This requirement says you cannot make backward-incompatible changes >> which completely contradicts requirements 1.1 and 1.2. >> >> IMO requirement 3.1 should be removed, or change MUST to MAY >> >> >> Andy >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
