Perhaps you are mistaking my intention here? I want a simple solution. I
advocated for *not* introducing a new major version component. I don't want
models changing all the time. I don't believe there is a large need for
incompatible changes.
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 think for
these there are non-standard solutions (e.g., a server could be configured to map a set
(or all) clients to new module name/namespace if the operator/user decides its safe to do
so). Naming conventions (e.g., a version suffix) can identify lineage to earlier
"major" versions of a module as well.
Joe Clark mentioned one thing to me that I do think is missing and needed in YANG and
that is some form of a "import after" so that module designers/users have the
ability to select a version of the module that includes additions that have shown up in
later revisions. I believe this can utilize the current revision (date) semantics.
It seems one place seeing a lot of "major" changes is with vendor models. I
think internal development processes are driving these, and the vendors need to fix these
processes, and not just make it easier to push these changes out to the operators/users.
I expressed this multiple times to the design team this last week.
Thanks,
Chris.
Andy Bierman <[email protected]> writes:
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
