Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

From: Balázs Lengyel <[email-masked]>
Date: Sun, 4 Nov 2018 12:26:27 +0000

Hello,

Deprecate and startover today, with the current definition of 
deprecated, allows: remove and startover. The server is not mandated to 
support deprecated nodes.

Deprecating/Removing stuff is not just backwards incompatible, it also 
leads to the client not knowing whether deprecated stuff is supported or 
not. So IMHO anything is better then the current deprecated.

regards Balazs

On 2018. 10. 27. 20:50, Andy Bierman wrote:
> IMO the current "deprecate and start over" is actually the easiest and 
> most robust
> solution path, and it requires no changes to YANG or the protocols.

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Balázs Lengyel <[email-masked]>
Date: Sun, 4 Nov 2018 12:39:04 +0000

Implementing 3.2 will be very costly. IMHO Ericsson will not
implement it. We will do our utmost to avoid NBC changes, but if
they do happen, I don't believe we would support multiple
versions.

If the data models are sufficiently NBC e.g. changing a boolean
to an integer 3.2 may not even be possible. The underlying data
that drives the device may be an integer or a boolean, but not
both. (Strange mapping may be possible to imagine, but they will
not always work.)

regards Balazs

On 2018. 10. 27. 1:15, Robert Wilton
wrote:

On 26/10/2018 17:35, Andy Bierman
wrote:

On Fri, Oct 26, 2018 at 2:33 AM,
Juergen Schoenwaelder <[email-masked]>
wrote:

Let me add that
there was large disagreement what a bug fix is in the

design team. Hence, any text that talks about 'bug
fixes' is ambiguous

and of limited value to achieve consensus. (Or we may
find consensus

but then not agree on what we have found consensus
on.)

To be more concrete, I learned that Rob's notion of a
bug fix is very

different from my notion of a bug fix. I think it is
important for

having a productive discussion to be aware of this.

For me, a bug fix is rather limited, i.e., fixing
something where the

correct intention was clear but the model did not
properly capture the

intention correctly, i.e., roughly what we can do with
errata in the

IETF. I think Rob understands bug fixes in a much
broader sense,

including fixes to what essentially are in my view
module design

errors.

With my narrow definition of bug fixes, bug fixes are
essentially

backwards compatible (even if they may violate RFC
7950 rules - but as

long as the original intention was clear, we can be
flexible).

With Rob's notion of bug fixes, we have to handle them
as part of the

versioning system since they may be non-backwards
compatible.

IMO requirements 3.1 and 3.2 are the most
important and have the most impact

on the solution space. I do not agree with either
of these requirements.

OK.

For 3.1, I think that just means that the solution has to be
backwards compatible with existing clients (e.g. don't change the
protocols in a non backwards compatible way).

Implementing multiple non-compatible revisions of a
module on a server sounds hard,

not to mention that it breaks RFC 7950 rules.

Completely agree that it will be hard.  I envisage that it will
optional for servers to implement this.

The current protocols do not support the

ability to specify different versions of the same
QName. This change makes YANG validation

much to difficult to specify and implement (as that
has to be rewritten as well).

The way that I think of one solution for this problem is using
datastore schema (as per the NMDA definition):

Say for release X, the server natively supports Module [email-masked] and [email-masked], call this schema X.

For release Y, the server natively supports Module [email-masked] and [email-masked], call this schema Y.

When a client connects it chooses which schema it wants to use, X,
Y, or latest.  If it doesn't specify then perhaps it uses the
earliest schema (to handle requirement 3.1).

If the client wants to use X, then the server has to translate the
request into the equivalent request using schema Y instead.
Perhaps the server has to validate the config both in the context
of X and Y.

If the clients wants to use Y then it just talks to the server
normally, i.e. as it does today.

I think that this is logically the equivalent model mapping that
clients would have to do to support multiple server revisions.
Yes, I think that it is complex.  No, I'm not sure how many
vendors will decide to implement this, but I think that it is OK
to require the solution to specify how this is done, so that
servers that do want to support this, and clients that want to use
this, can do so.

But all the QNames, validations, etc, I think would be constrained
to a particular schema.

It is one thing to deploy rapidly changing, buggy
YANG modules in order to

gain experience quickly..  It is quite another to
complicate YANG and the protocols

to preserve these interim mistakes, and bake into
the standards the notion that this

is good engineering.

Thanks,

Rob

/js

Andy

On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert
Wilton wrote:

> Hi Chris,

> On 25/10/2018 18:42, Christian Hopps wrote:

> > Hi Rob,

> > We've more privately discussed the bug-fix
scenario and I'm sympathetic

> > to it; however, the requirement as written
does not restrict itself to

> > fixing module definition bugs (e.g., a
pattern or other value

> > constraint) in some small but incompatible
way -- instead it's wide open

> > and it will be [ab]used that way.

> I think that everyone on design team agrees that
non-backwards-compatible

> changes should be minimized and should really
only to used for bug fixes

> where it is anticipated that clients should not
be affected.

> We want to allow non-backwards-compatible changes
at the head of the

> development tree, but again, I think that
everyone agrees that keeping it

> backwards compatible where possible is a good
goal.

> However, I think that there will be cases where a
vendor decides that it is

> right for an enhancement or non backwards
compatible change to be made to an

> already released module.  I agree that this is
highly undesirable and an

> abuse of the rules, but I don't believe that
whatever versioning scheme we

> come up with will prevent vendors from doing
this.  So then the question

> becomes: Is it better to pretend that this
scenario will never happen,

> design the versioning scheme so that it cannot be
expressed, which probably

> just means that clients will not be able to
detect when vendors do this by

> cheating the rules!  Or is it better to accept
that this will sometimes

> occur, provide strong guidance as to why this is
bad practice and should be

> avoided, but have a versioning scheme that still
allows this to be expressed

> (in a bounded way)?  I.e. even if the vendors are
doing something that is

> less than ideal, at least the clients can spot
where they have done this.

> ---

> A separate concern that we had about ties this
strictly to bug fixes is that

> some one will ask for a definition of a bug fix.
The design team tried this

> but we couldn't even agree what a bug fix is, let
alone agree with a single

> definition of a bug fix as it related to a YANG
module.  So our conclusion

> was that perhaps it is better not to tie the
requirements themselves to bug

> fix vs enhancement, because the boundary between
the two is too vague, and

> module writers will bend the rules.

> So I see that the rules should be:

>  - backwards compatible bug fix  - this is fine.

>  - non backwards compatible bug fix - this is
fine if it is pragmatically

> expected to not impact any clients, but careful
consideration is required if

> it might break clients.

>  - backwards compatible enhancement - not ideal,
but pragmatically OK.

>  - non backwards compatible enhancement - this is
bad and should be avoided.

> But if we don't want to define the difference
between a bug fix vs

> enhancement then I think that you end up with the
most general requirement

> being that we do want to allow for
non-backwards-compatible changes in

> released modules to accommodate the bug fix
scenario, but the expectation

> (and guidance) will be that they should only be
used for bug fixes.

> > For example:

> > > Here is what I am afraid the vendors
want here: A developer on

> > > release train X can easily change some
data structure and then push

> > > the change into an automated system
which generates a new YANG

> > > module definition and revs a version
number -- all done! They don't

> > > have to deal with the inertia of making
this change in their release

> > > train Y or Z and they don't have to
treat modules as a stable API

> > > they are exporting, b/c they now have
these new wonderful versions

> > > from this work. Meanwhile we the users
now have to deal with N forks

> > > with all the various little
incompatible changes random developers

> > > at the company wanted to make without
having to coordinate with

> > > their coworkers/other internal teams.
Now multiply this by M

> > > vendors. It's a nightmare. It shouldn't
be what we are optimizing

> > > for, let alone making a requirement.

> > Regarding enhancements, these are features,
and are naturally

> > augmentative. I find it hard to believe we
have a pressing

> > need/requirement to support non-backward
compatible changes to existing

> > modules in order to support enhancements.

> I agree.  It was a backwards compatible
enhancement that I was considering.

> Thanks,

> Rob

> > Thanks,

> > Chris.

> > Robert Wilton <[email-masked]>
writes:

> > > Hi Chris,

> > > I think that there are two things
driving this requirement:

> > > What I regard as the key one, is that
we want to be able to support

> > > the software

> > > that we have shipped. In particular, we
may need to fix bugs

> > > (perhaps at the

> > > operators request) to a YANG model that
has already been released.

> > > I.e. I think

> > > that there are some scenarios, where
forking a YANG module, although

> > > undesirable

> > > is the right thing to do to include a
fix. I don't believe that

> > > features or

> > > deviations help solve this problem.

> > > The two alternative solutions to being
able to fix bugs, neither of

> > > which I

> > > think is pragmatic, that I can think of
are:

> > > (i) Vendors ensure that their YANG
modules are perfect before they

> > > ship in a

> > > release.

> > > (ii) If a bug is reported, operators
are happy to wait until the bug

> > > has been

> > > fixed in the current development
release, and will migrate to that

> > > latest

> > > release to pick up the fix.

> > > The second thing driving this
requirement is that vendors sometimes

> > > get asked

> > > for enhancements to existing releases,
perhaps because the latest

> > > development

> > > release is too far out, or ask for an
enhancement on the current

> > > train to be

> > > back ported to an older release.

> > > So, aiming to have stable YANG modules,
trying a lot harder to avoid

> > > non-backwards-compatible changes, and
keeping new functionality to

> > > the head of

> > > the development I completely agree with
you on. But I still believe

> > > that there

> > > are some valid scenarios, that should
be limited as much as

> > > possible, where it

> > > is necessary to make changes that
sometimes break these rules, and

> > > having a

> > > limited scheme that clearly indicates
where such breakages have

> > > occurred is

> > > probably better that the status quo of
where the modules get

> > > changed, but the

> > > operator doesn't get any useful
indication of what type of changes

> > > are being

> > > made.

> > > Thanks,

> > > Rob

> > > On 25/10/2018 16:26, Christian Hopps
wrote:

> > > > > On Oct 20, 2018, at 1:55 PM,
Joe Clarke <[email-masked]>
wrote:

> > > > > * New requirement 1.4 for
supporting over-arching software releases

> > > > [ I read this as supporting
various different module versions

> > > > based on a vendor's different
software release trains. If this

> > > > is wrong then the rest of this
doesn't apply and I would just

> > > > ask for the text to be update to
clarify what it means. ]

> > > > How many operators/users have
asked for this or indicated it's a

> > > > requirement for them?

> > > > What problem is intractable
without this requirement being met,

> > > > and what is the cost of this
requirement on the actual users?

> > > > I have pushed back multiple times
on this b/c I believe this

> > > > "requirement" is really being
pushed to make it easier for

> > > > vendors (a small affected group)
to develop their software at

> > > > the cost of their users (the much
larger affected group) who

> > > > would then have to deal with
multiple trains of the same module.

> > > > We already have features and
deviations why are they not enough

> > > > to deal with functionality that is
present or not in various

> > > > software release/devices?

> > > > FWIW I'm not against making it
easier to develop software, but

> > > > we have to be mindful if we are
just pushing the cost (and

> > > > magnifying it greatly) to other
people in the community..

> > > > Thanks,

> > > > Chris.

> > > > _______________________________________________

> > > > netmod mailing list

> > > > [email-masked]

> > > > https://www.ietf.org/mailman/listinfo/netmod

> > > > .

> > .

> _______________________________________________

> netmod mailing list

> [email-masked]

> https://www.ietf.org/mailman/listinfo/netmod

--

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 list

[email-masked]

https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netmod

---

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Nov 2018 15:21:34 -0800

On Sun, Nov 4, 2018 at 4:39 AM, Balázs Lengyel <[email-masked]>
wrote:

> Implementing 3.2 will be very costly. IMHO Ericsson will not implement it.
> We will do our utmost to avoid NBC changes, but if they do happen, I don't
> believe we would support multiple versions.
>
> If the data models are sufficiently NBC e.g. changing a boolean to an
> integer 3.2 may not even be possible. The underlying data that drives the
> device may be an integer or a boolean, but not both. (Strange mapping may
> be possible to imagine, but they will not always work.)
>

IMO the requirements and solutions drafts are both too abstract.
It would help if the authors could point to existing RFCs or I-Ds where a
published module needs specific NBC changes.

The intended usage of the status-stmt in YANG 1.1 seems to be for NBC
changes
to be made by introducing a replacement (maybe sibling) node and changing
the replaced
node status to deprecated.

The requirements draft is not clear at all when this practice should be
followed
and when it is OK to simply change the data node and not deprecate it at
all.
IMO the latter is only OK if the change is truly a bugfix and implementation
of the previous version SHOULD NOT be done.

Even though this means a server MAY implement the old bugfixed version,
that does not
mean an operator gets to choose both versions active at once in a given
server.
It is reasonable to let the operator configure which version to use.

The solution proposal does not indicate how a protocol would support REQ.
3.2.
E.g., how to say "I mean foo the integer not foo the boolean"

regards Balazs
Andy

> On 2018. 10. 27. 1:15, Robert Wilton wrote:
>
>
>
> On 26/10/2018 17:35, Andy Bierman wrote:
>
>
>
> On Fri, Oct 26, 2018 at 2:33 AM, Juergen Schoenwaelder <
> [email-masked]> wrote:
>
>> Let me add that there was large disagreement what a bug fix is in the
>> design team. Hence, any text that talks about 'bug fixes' is ambiguous
>> and of limited value to achieve consensus. (Or we may find consensus
>> but then not agree on what we have found consensus on.)
>>
>> To be more concrete, I learned that Rob's notion of a bug fix is very
>> different from my notion of a bug fix. I think it is important for
>> For me, a bug fix is rather limited, i.e., fixing something where the
>> correct intention was clear but the model did not properly capture the
>> intention correctly, i.e., roughly what we can do with errata in the
>> IETF. I think Rob understands bug fixes in a much broader sense,
>> including fixes to what essentially are in my view module design
>> errors.
>>
>> With my narrow definition of bug fixes, bug fixes are essentially
>> backwards compatible (even if they may violate RFC 7950 rules - but as
>> long as the original intention was clear, we can be flexible).
>>
>> With Rob's notion of bug fixes, we have to handle them as part of the
>> versioning system since they may be non-backwards compatible.
>>
>>
>
> IMO requirements 3.1 and 3.2 are the most  important and have the most
> impact
> on the solution space. I do not agree with either of these requirements.
>
> OK.
>
> For 3.1, I think that just means that the solution has to be backwards
> compatible with existing clients (e.g. don't change the protocols in a non
> backwards compatible way).
>
>
> Implementing multiple non-compatible revisions of a module on a server
> sounds hard,
> Completely agree that it will be hard.  I envisage that it will optional
> for servers to implement this.
>
> ability to specify different versions of the same QName. This change makes
> YANG validation
> much to difficult to specify and implement (as that has to be rewritten as
> well).
>
> The way that I think of one solution for this problem is using datastore
> schema (as per the NMDA definition):
>
> When a client connects it chooses which schema it wants to use, X, Y, or
> latest.  If it doesn't specify then perhaps it uses the earliest schema (to
> handle requirement 3.1).
>
> If the client wants to use X, then the server has to translate the request
> into the equivalent request using schema Y instead.  Perhaps the server has
> to validate the config both in the context of X and Y.
>
> If the clients wants to use Y then it just talks to the server normally,
> i.e. as it does today.
>
> I think that this is logically the equivalent model mapping that clients
> would have to do to support multiple server revisions.  Yes, I think that
> it is complex.  No, I'm not sure how many vendors will decide to implement
> this, but I think that it is OK to require the solution to specify how this
> is done, so that servers that do want to support this, and clients that
> want to use this, can do so.
>
> But all the QNames, validations, etc, I think would be constrained to a
> particular schema.
>
>
> It is one thing to deploy rapidly changing, buggy YANG modules in order to
> gain experience quickly..  It is quite another to complicate YANG and the
> protocols
> to preserve these interim mistakes, and bake into the standards the notion
> that this
> is good engineering.
>
> Thanks,
> Rob
>
>
>
> /js
>>
>
> Andy
>
>
>>
>> On Fri, Oct 26, 2018 at 10:17:48AM +0100, Robert Wilton wrote:
>> > Hi Chris,
>> >
>> >
>> > > We've more privately discussed the bug-fix scenario and I'm
>> sympathetic
>> > > to it; however, the requirement as written does not restrict itself to
>> > > fixing module definition bugs (e.g., a pattern or other value
>> > > constraint) in some small but incompatible way -- instead it's wide
>> open
>> > changes should be minimized and should really only to used for bug fixes
>> > where it is anticipated that clients should not be affected.
>> >
>> > We want to allow non-backwards-compatible changes at the head of the
>> > development tree, but again, I think that everyone agrees that keeping
>> it
>> > backwards compatible where possible is a good goal.
>> >
>> > However, I think that there will be cases where a vendor decides that
>> it is
>> > right for an enhancement or non backwards compatible change to be made
>> to an
>> > already released module.  I agree that this is highly undesirable and an
>> > abuse of the rules, but I don't believe that whatever versioning scheme
>> we
>> > come up with will prevent vendors from doing this.  So then the question
>> > becomes: Is it better to pretend that this scenario will never happen,
>> > design the versioning scheme so that it cannot be expressed, which
>> probably
>> > just means that clients will not be able to detect when vendors do this
>> by
>> > cheating the rules!  Or is it better to accept that this will sometimes
>> > occur, provide strong guidance as to why this is bad practice and
>> should be
>> > avoided, but have a versioning scheme that still allows this to be
>> expressed
>> > (in a bounded way)?  I.e. even if the vendors are doing something that
>> is
>> > less than ideal, at least the clients can spot where they have done
>> this.
>> >
>> > ---
>> >
>> > A separate concern that we had about ties this strictly to bug fixes is
>> that
>> > some one will ask for a definition of a bug fix.  The design team tried
>> this
>> > but we couldn't even agree what a bug fix is, let alone agree with a
>> single
>> > definition of a bug fix as it related to a YANG module.  So our
>> conclusion
>> > was that perhaps it is better not to tie the requirements themselves to
>> bug
>> > fix vs enhancement, because the boundary between the two is too vague,
>> and
>> >  - non backwards compatible bug fix - this is fine if it is
>> pragmatically
>> > expected to not impact any clients, but careful consideration is
>> required if
>> > it might break clients.
>> >  - backwards compatible enhancement - not ideal, but pragmatically OK.
>> >  - non backwards compatible enhancement - this is bad and should be
>> avoided.
>> >
>> > But if we don't want to define the difference between a bug fix vs
>> > enhancement then I think that you end up with the most general
>> requirement
>> > being that we do want to allow for non-backwards-compatible changes in
>> > released modules to accommodate the bug fix scenario, but the
>> expectation
>> > (and guidance) will be that they should only be used for bug fixes.
>> >
>> >
>> > >
>> > > For example:
>> > >
>> > > > Here is what I am afraid the vendors want here: A developer on
>> > > > release train X can easily change some data structure and then push
>> > > > the change into an automated system which generates a new YANG
>> > > > module definition and revs a version number -- all done! They don't
>> > > > have to deal with the inertia of making this change in their release
>> > > > train Y or Z and they don't have to treat modules as a stable API
>> > > > they are exporting, b/c they now have these new wonderful versions
>> > > > from this work. Meanwhile we the users now have to deal with N forks
>> > > > with all the various little incompatible changes random developers
>> > > > at the company wanted to make without having to coordinate with
>> > > > their coworkers/other internal teams. Now multiply this by M
>> > > > vendors. It's a nightmare. It shouldn't be what we are optimizing
>> > > Regarding enhancements, these are features, and are naturally
>> > > augmentative. I find it hard to believe we have a pressing
>> > > need/requirement to support non-backward compatible changes to
>> existing
>> > I agree.  It was a backwards compatible enhancement that I was
>> considering.
>> >
>> > Thanks,
>> > Rob
>> >
>> >
>> > >
>> > > Thanks,
>> > > Chris.
>> > >
>> > >
>> > > Robert Wilton <[email-masked]> writes:
>> > >
>> > > > Hi Chris,
>> > > >
>> > > > I think that there are two things driving this requirement:
>> > > >
>> > > > What I regard as the key one, is that we want to be able to support
>> > > > the software
>> > > > that we have shipped. In particular, we may need to fix bugs
>> > > > (perhaps at the
>> > > > operators request) to a YANG model that has already been released.
>> > > > I.e. I think
>> > > > that there are some scenarios, where forking a YANG module, although
>> > > > undesirable
>> > > > is the right thing to do to include a fix. I don't believe that
>> > > > features or
>> > > > The two alternative solutions to being able to fix bugs, neither of
>> > > > which I
>> > > > think is pragmatic, that I can think of are:
>> > > > (i) Vendors ensure that their YANG modules are perfect before they
>> > > > ship in a
>> > > > release.
>> > > > (ii) If a bug is reported, operators are happy to wait until the bug
>> > > > has been
>> > > > fixed in the current development release, and will migrate to that
>> > > > latest
>> > > > The second thing driving this requirement is that vendors sometimes
>> > > > get asked
>> > > > for enhancements to existing releases, perhaps because the latest
>> > > > development
>> > > > release is too far out, or ask for an enhancement on the current
>> > > > train to be
>> > > > So, aiming to have stable YANG modules, trying a lot harder to avoid
>> > > > non-backwards-compatible changes, and keeping new functionality to
>> > > > the head of
>> > > > the development I completely agree with you on. But I still believe
>> > > > that there
>> > > > are some valid scenarios, that should be limited as much as
>> > > > possible, where it
>> > > > is necessary to make changes that sometimes break these rules, and
>> > > > having a
>> > > > limited scheme that clearly indicates where such breakages have
>> > > > occurred is
>> > > > probably better that the status quo of where the modules get
>> > > > changed, but the
>> > > > operator doesn't get any useful indication of what type of changes
>> > > > are being
>> > > > made.
>> > > >
>> > > > Thanks,
>> > > > Rob
>> > > >
>> > > >
>> > > > On 25/10/2018 16:26, Christian Hopps wrote:
>> > > > >
>> > > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke <[email-masked]>
>> wrote:
>> > > > > >
>> > > > > > * New requirement 1.4 for supporting over-arching software
>> releases
>> > > > > [ I read this as supporting various different module versions
>> > > > > based on a vendor's different software release trains. If this
>> > > > > is wrong then the rest of this doesn't apply and I would just
>> > > > > ask for the text to be update to clarify what it means. ]
>> > > > >
>> > > > > How many operators/users have asked for this or indicated it's a
>> > > > > requirement for them?
>> > > > >
>> > > > > What problem is intractable without this requirement being met,
>> > > > > and what is the cost of this requirement on the actual users?
>> > > > >
>> > > > > I have pushed back multiple times on this b/c I believe this
>> > > > > "requirement" is really being pushed to make it easier for
>> > > > > vendors (a small affected group) to develop their software at
>> > > > > the cost of their users (the much larger affected group) who
>> > > > > would then have to deal with multiple trains of the same module.
>> > > > >
>> > > > >
>> > > > > We already have features and deviations why are they not enough
>> > > > > to deal with functionality that is present or not in various
>> > > > > FWIW I'm not against making it easier to develop software, but
>> > > > > we have to be mindful if we are just pushing the cost (and
>> > > > > magnifying it greatly) to other people in the community..
>> > > > >
>> > > > > Thanks,
>> > > > > Chris.
>> > > > >
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
>
>
> netmod mailing [email-masked]://www.ietf.org/mailman/listinfo/netmod
>
> --

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Nov 2018 22:39:57 +0100 (CET)

Hi,

> long as the original intention was clear, we can be flexible).

I agree with this interpretation of a bug fix.  For example
fixing incorrect patterns (e.g. errata 3957 that Andy mentioned).

/martin

> > > We've more privately discussed the bug-fix scenario and I'm sympathetic
> > > constraint) in some small but incompatible way -- instead it's wide open
> > I think that everyone on design team agrees that non-backwards-compatible
> > development tree, but again, I think that everyone agrees that keeping it
> > However, I think that there will be cases where a vendor decides that it is
> > right for an enhancement or non backwards compatible change to be made to an
> > abuse of the rules, but I don't believe that whatever versioning scheme we
> > design the versioning scheme so that it cannot be expressed, which probably
> > just means that clients will not be able to detect when vendors do this by
> > occur, provide strong guidance as to why this is bad practice and should be
> > avoided, but have a versioning scheme that still allows this to be expressed
> > (in a bounded way)?  I.e. even if the vendors are doing something that is
> > less than ideal, at least the clients can spot where they have done this.
> > 
> > ---
> > 
> > A separate concern that we had about ties this strictly to bug fixes is that
> > some one will ask for a definition of a bug fix.  The design team tried this
> > but we couldn't even agree what a bug fix is, let alone agree with a single
> > definition of a bug fix as it related to a YANG module.  So our conclusion
> > was that perhaps it is better not to tie the requirements themselves to bug
> > fix vs enhancement, because the boundary between the two is too vague, and
> >  - non backwards compatible bug fix - this is fine if it is pragmatically
> > expected to not impact any clients, but careful consideration is required if
> > it might break clients.
> >  - non backwards compatible enhancement - this is bad and should be avoided.
> > 
> > enhancement then I think that you end up with the most general requirement
> > released modules to accommodate the bug fix scenario, but the expectation
> > > need/requirement to support non-backward compatible changes to existing
> > I agree.  It was a backwards compatible enhancement that I was considering.
> > 
> > Thanks,
> > Rob
> > 
> > 
> > > 
> > > Thanks,
> > > Chris.
> > > 
> > > 
> > > > > > On Oct 20, 2018, at 1:55 PM, Joe Clarke <[email-masked]> wrote:
> > > > > > 
> > > > > > * New requirement 1.4 for supporting over-arching software releases
> > > > > magnifying it greatly) to other people in the community.
> > > > > 
> > > > > Thanks,
> > > > > Chris.
> > > > >

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Nov 2018 22:42:20 +0100 (CET)

Juergen Schoenwaelder <[email-masked]> wrote:
> On Sat, Oct 27, 2018 at 06:50:58AM -0700, Andy Bierman wrote:
> > 
> > This is what we have today only if modules are updated in legal ways.
> > The 3.1 requirement says this backward compatibility is maintained even
> > if the module is updated in violation of the module update rules.
> >
> 
> It is stating a requirement. How solutions meet the requirement is for
> the solutions to figure out.
> 
> > How would 3.1 be met if the WG decided to just add a new 'datastore'
> > key leaf to the /modules-state/module list?
> 
> Depends on the solution I guess.
>  
> > IMO the current "deprecate and start over" is actually the easiest
> > and most robust solution path, and it requires no changes to YANG or
> > the protocols.
> 
> Yep. But there are people who think that other solutions can do
> better. The challenge is to find out whether they actually do better
> or for whom they do better (and if someone has to pay a price for it).
> For having this discussions, it is good to write down requirements.
> 
> > >        3.2  The solution MUST provide a mechanism to allow servers to
> > >             simultaneously support clients using different revisions of
> > >             modules.  A client's choice of particular revision of one or
> > >             more modules may restrict the particular revision of other
> > >             modules that may be used in the same request or session.
> > >
> > > Today, the version number is effectively an (implicit) part of the
> > > module name (plus the revision date for backwards compatible changes).
> > > Hence, my understanding is that today's model does satisfy 3.2 as
> > > well.
> > 
> > This is not what we have at all. RFC 7950 says a server can only implement
> > one revision of a module.
> >
> 
> A new version today essentially means a new module name and I do not
> see a conflict with what I wrote.

Then I think this requirement needs clarification.  It says "different
revision of modules", which can be interpreted as different revisions
of *the same* module.

Also the second part of the paragraph seems to indicate multiple
revisions of the same module in the server.

I do not agree with this requirement.

/martin

> 
> > > If we want to increase 'agility' in an attempt to make it easier to
> > > deliver early designs and to fix them on the go, the costs will go up
> > > somewhere. The extreme cases are:
> > >
> > > 1) The server can make changes to YANG modules in arbitrary ways and
> > >    the clients have to adapt, i.e., clients have to pay the bill.
> > >
> > > 2) The server has to provide strict backwards compatibility in order
> > >    to not break clients, i.e., servers have to pay the bill.
> > >
> > >
> > This is not correct. Implementing multiple incompatible revisions of a
> > module
> > (e.g, "module" list keyed 2 different ways) is a huge bill to pay for the
> > server developer.
> 
> Depends on the details and the developer will decide based on the
> impact on the clients and whether a transition period is possible. You
> seem to read that the requirement says one has to implement backwards
> compatibility. This is not what the text says. The text says it must
> be possible.
> 
> > > Unless we go for option 1) above, I believe 3.1 and 3.2 are valid and
> > > important requirements.
> > 
> > I do not agree with the premise that non-compatible data model updates are
> > required.
> > 3.1 can be achieved without such changes. 3.2 violates RFC 7950, requiring
> > a new(much more complicated) version of YANG
> 
> I think you misread the requirements text.
> 
> /js
> 
> --

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 08 Nov 2018 22:46:33 +0100 (CET)

Hi,

After the session today, it seems to me that one fundamental
requirement (or non-requirement) is missing.  How much branching does
the solution have to support?  The current solution (6020/7950) and (if
I understood Rob Shakir correctly) also openconfig have linear
versioning *per module*.  If we can get agreement on this requirement,
I think it will be easier to find a solution.

/martin

---

From: Joe Clarke <[email-masked]>
Date: Thu, 8 Nov 2018 21:07:52 -0500

> I think it will be easier to find a solution.

We discussed this in the DT.  We didn't want to discuss levels of
branching in the requirements as that pointed to certain solutions.  The
point of requirement 1.4 was to say that the DT felt previous versions
of modules needed to support fixes without bringing in elements from head.

We discussed branching to satisfy this requirement as well as protecting
new features with if-feature and using deviations.

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Nov 2018 09:15:57 +0100

> I do not agree with this requirement.

Today, you need to create a new module if you make NBC changes to
existing changes (e.g., you change Bool to Int {0..1} and you are not
creating a new leaf). Since there are now two modules, you _can_
implement both modules if that makes sense.

If we allow to make such changes as part of a module revision, i.e.,
without creating a new module, I think we should not loose the ability
to implement both the old version and the new version.

I think we need to distinguish between the agreement on the
requirement, namely that a server should be able to provide support
for an old and a new definition, and agreement on the solution.

Do you disagree with the requirement? Or do you disagree with the
consequences of implementing multiple versions of the same module
for some of the proposed new versioning schemes? Or both?

/js

---

From: Andy Bierman <[email-masked]>
Date: Fri, 9 Nov 2018 03:38:03 -0800

> implement both modules if that makes sense.

This does not make sense because a node in YANG is identified by a QName,
not just a local-name.   The node oldmod:foo is not the same as newmod:foo.
It never has been and never will be the same node.

> to implement both the old version and the new version.
As Balazs asked, how can the data node be a boolean and an integer at the
same time?
There seem to be plenty of scenarios that cannot be implemented
simultaneously by a server.

> for some of the proposed new versioning schemes? Or both?

I understand the transformation approach (am have implemented something
like it).
This only works if the mapping is complete.  If there are any holes in the
mapping
then the affected nodes are lost.  Vendors have already proven they
can implement this approach without any new standards.

Vendors are already releasing updates to old module revisions by managing
the revision date.
I agree SEMVER is incrementally better than that.

I do not agree that more than 1 revision of a module can be implemented.
A server can have multiple "outside" schema that gets transformed to the
real "inside" schema.
This is fine and breaks no YANG rules.  It also requires no additional
standards unless the
transformation mechanism is going to be standardized.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Nov 2018 14:37:29 +0100 (CET)

> implement both modules if that makes sense.

Yes.

> to implement both the old version and the new version.

I don't think we should allow such changes, and if we did, I don't
think that both revisions should be implemented at the same time.  I
think the overall solution would just be too complex.

> for some of the proposed new versioning schemes? Or both?

I do not agree with the requirement that a server MUST be able to
support multiple revisions of the same module, which is how I
interpret 3.2.  If this is not the intention of 3.2, maybe it can be
clarified.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Nov 2018 14:42:03 +0100 (CET)

Joe Clarke <[email-masked]> wrote:
> branching in the requirements as that pointed to certain solutions.

All requirements point to certain solutions, in a sense.

But if you say that branching is not a requirement on a solution, I'm
happy with that.

> The

I think this means that you require branching.

But is this still the point of the "new 1.4" that was mentioned in the
session?

However, as Rob Shakir mentioned in the session, there are other ways
to do fixes / enhacements than branching a single module.  You can add
new functionality with augment and make changes with deviations.

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 9 Nov 2018 13:46:08 +0000

On 2018-11-09, 8:37 PM, "netmod on behalf of Martin Bjorklund" <[email-masked] on behalf of [email-masked]> wrote:

    Yes.

    

<RR> It says "The solution MUST provide...", so the solution draft MUST provide a solution on how to do this. Whether a server implements the solution or not is a different matter. We realize this is a pain for most servers but some servers may be able to do it.

Regards,
Reshad.
    
    /martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Nov 2018 14:51:06 +0100 (CET)

"Reshad Rahman (rrahman)" <[email-masked]> wrote:
> 
> 
> On 2018-11-09, 8:37 PM, "netmod on behalf of Martin Bjorklund"
> <[email-masked] on behalf of [email-masked]> wrote:
> 
> <RR> It says "The solution MUST provide...", so the solution draft
> MUST provide a solution on how to do this. Whether a server implements
> the solution or not is a different matter. We realize this is a pain
> for most servers but some servers may be able to do it.

I understand.  But I don't agree with this requirement, even if some
server would be able to implement it.  I think it makes the whole
solution much more complex, w/o much gain.  It is complex enough as it
is.

/martin

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 9 Nov 2018 13:54:41 +0000

From: netmod <[email-masked]> on behalf of 'Andy Bierman' <[email-masked]>
Date: Friday, November 9, 2018 at 6:38 PM
To: Juergen Schoenwaelder <[email-masked]>, Martin Bjorklund <[email-masked]>, 'Andy Bierman' <[email-masked]>, NetMod WG <[email-masked]>
Subject: Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Nov 08, 2018 at 10:42:20PM +0100, Martin Bjorklund wrote:
> Juergen Schoenwaelder <[email-masked]<mailto:[email-masked]>> wrote:

This does not make sense because a node in YANG is identified by a QName,
not just a local-name.   The node oldmod:foo is not the same as newmod:foo.
It never has been and never will be the same node.
<RR> I disagree, per https://tools.ietf.org/html/rfc7950#section-4.2.1
   A server may implement a number of modules, allowing multiple views
   of the same data or multiple views of disjoint subsections of the
   server's data.  Alternatively, the server may implement only one
   module that defines all available data.

As Balazs asked, how can the data node be a boolean and an integer at the same time?
There seem to be plenty of scenarios that cannot be implemented simultaneously by a server.
<RR> Correct, but some scenarios can be implemented. IMO we should document the type of changes where this would or would not work.

Regards,
Reshad.
<snip>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 9 Nov 2018 14:07:28 +0000

On 2018-11-09, 8:51 PM, "Martin Bjorklund" <[email-masked]> wrote:

    I understand.  But I don't agree with this requirement, even if some
    server would be able to implement it.  I think it makes the whole
    solution much more complex, w/o much gain.  It is complex enough as it
    is.
I agree that ideally we don't need to have this to solve the problem, but it is a potential solution. If it is removed in the requirements draft but considered in the solutions draft, would you be ok with that?

Regards,
Reshad.
    
    /martin

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Nov 2018 15:24:48 +0100 (CET)

"Reshad Rahman (rrahman)" <[email-masked]> wrote:
>     >     > > > > This is what we have today only if modules are updated in
>     >     > > > > legal
>     >     > > > > ways.
>     >     > > > > The 3.1 requirement says this backward compatibility is
>     >     > > > > maintained
>     >     > > > > even
>     >     > > > It is stating a requirement. How solutions meet the requirement
>     >     > > > is
>     >     > > > for
>     >     > > > > and most robust solution path, and it requires no changes to
>     >     > > > > YANG
>     >     > > > > or
>     >     > > > > the protocols.
>     >     > > > 
>     >     > > > or for whom they do better (and if someone has to pay a price
>     >     > > > for
>     >     > > > it).
>     >     > > > > >        3.2 The solution MUST provide a mechanism to allow
>     >     > > > > >        servers
>     >     > > > > >        to
>     >     > > > > >             modules.  A client's choice of particular
>     >     > > > > >             revision of
>     >     > > > > >             one or
>     >     > > > > >             more modules may restrict the particular
>     >     > > > > >             revision of
>     >     > > > > >             other
>     >     > > > > > Today, the version number is effectively an (implicit) part
>     >     > > > > > of
>     >     > > > > > the
>     >     > > > > > module name (plus the revision date for backwards
>     >     > > > > > compatible
>     >     > > > > > changes).
>     >     > > > > This is not what we have at all. RFC 7950 says a server can
>     >     > > > > only
>     >     > > > > implement
> I agree that ideally we don't need to have this to solve the problem,
> but it is a potential solution. If it is removed in the requirements
> draft but considered in the solutions draft, would you be ok with
> that?

Yes; it should be ok for a solution to solve more problems than what
the requirements doc specify.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Nov 2018 16:13:47 +0100

> interpret 3.2.  If this is not the intention of 3.2, maybe it can be

Here is what 3.2 says:

This does _not_ say servers MUST implement this.

Item 3.2 establishes a requirement and for some solutions it may be
easy to satisfy this requirement, for others it may be more costly to
satisfy this requirement.

The whole requirements exercise becomes a rather pointless exercise if
we remove requirements so that certain solutions look more attractive.
I have not seen a proposal that addresses all requirements and hence
at the end the WG needs to decide which tradeoffs make sense.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 09 Nov 2018 17:31:59 +0100 (CET)

> we remove requirements so that certain solutions look more

Ok, but that's not what I wrote.  I don't agree with this requirement
which says that it MUST be possible for a server to support
different revisions of a given module (again, if this is not the
intention of the text, please clarify).  I simply don't think that
this is a good requirement.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 9 Nov 2018 17:55:12 +0100

> this is a good requirement.

I can't follow you or I do not understand what you are after.

  In some versioning schemes, providing support for different
  'versions' is relatively easy. If I have modules foo-1 and foo-2,
  then I can implement foo-1 and foo-2 (or proper workable subsets of
  them) easily. And older clients expecting foo-1 may continue to work
  while newer clients move to foo-2. In other versioning schemes,
  providing the same possibility to migrate from foo version 1 to foo
  version 2, would lead to the support of foo in two different
  versions.

The requirement tries to express that it must be possible to have a
transition path where old clients can continue to function with the
old version while new clients start using the new version. The idea is
to state this as a requirement without making any assumptions about
the solutions.

Are you saying that a requirement saying that there should be a
possibility of a transition path is in general a bad requirement?

/js

---

From: Robert Wilton <[email-masked]>
Date: Fri, 9 Nov 2018 22:46:05 +0000

On 09/11/2018 11:38, Andy Bierman wrote:
>
>
> On Fri, Nov 9, 2018 at 12:15 AM, Juergen Schoenwaelder 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > Juergen Schoenwaelder <[email-masked]
>     <mailto:[email-masked]>> wrote:
>     legal ways.
>     maintained even
>     YANG or
>     for it).
>     servers to
>     revision of one or
>     revision of other
>     compatible changes).
>     only implement

Yes, not the same node, but both representing the same property.

For "config false", or stuff coming out of operational then I have no 
issues with two nodes reporting different representations of the same 
property (unless default values are not being returned).  This is quite 
a common thing to do anyway, and clients can ignore the data that is not 
being returned.

But I struggle to understand how have two nodes in the same schema that 
both directly manipulate the same underlying config property works.  I 
think that various folks have suggesting that this is a viable way of 
fixing bugs in config nodes, but I would be interested to see an 
explanation of exactly how this works, and what limitations are deemed 
to be acceptable.

> simultaneously by a server.
I think that there are lots of questions if you have two properties 
representing the same underlying configurable node:
  - can they both be configured at the same time with different values?
  - can they both be configured at the same time with the same value?
  - what if the configured value for one data node is not representable 
in the other data node?
  - what if the defaults values differ?

> I understand the transformation approach (am have implemented 
> something like it).
> This only works if the mapping is complete.  If there are any holes in 
> the mapping
> Vendors are already releasing updates to old module revisions by 
> managing the revision date.
> A server can have multiple "outside" schema that gets transformed to 
> the real "inside" schema.

This is the solution that I'm potentially thinking of ... but it may 
require some protocol mechanism for a client to be able to select which 
"outside" schema it is using, if the server supports multiple.

If different revisions of modules exist in different "outside" schema 
then some may argue that the server is implementing two different 
revisions of a module.

For me, one thing is certain, is that there should only be a single 
revision of each module as being implemented in YANG library.

> transformation mechanism is going to be standardized.
No current plans to try and standardize the transformation mechanism.

Thanks,
Rob

>     Fax:   +49 421 200 3103         <https://www.jacobs-university.de/
>     <https://www.jacobs-university.de/>>
>
>
>
>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 9 Nov 2018 22:53:16 +0000

Hi Martin,

> this is a good requirement.
One way to think of this is as YANG data models defining an API between 
client and server.

There seem to be lots of REST APIs that implement versioning of their 
API by having a version number in the URL.  In fact, I think that 
RESTCONF adopts this approach to allow versioning of the protocol.

One solution is as Andy describes.  The underlying server only 
implements one version of the a given YANG module, but they may provide 
other views on to this data using different versions of YANG modules.  
E.g. the same as how Vendor YANG models, IETF YANG models, and 
OpenConfig YANG models might be treated as their own views, mapped to 
the same internal YANG modules.

Thanks,
Rob

---

From: Ebben Aries <[email-masked]>
Date: Sat, 10 Nov 2018 09:49:44 +0700

> new functionality with augment and make changes with deviations.

So we could potentially result in a cleaner set of base model versioning
but augments and deviations that will need somewhat of it's own
branch versioning now.  I often find that consumers/clients make quite a
few assumptions and expectations when one supports model version X (w/o
the realization that it is X+/- for various reasons)

We'll have a namespace problem which will result in namespaces being
inserted (and removed at later dates) which ultimately has an impact on
clients

Possibly a better middle ground but think there are still considerations
here as well as to the overall impact of this approach

/ebben

---

From: Andy Bierman <[email-masked]>
Date: Sat, 10 Nov 2018 23:07:47 -0800

On Fri, Nov 9, 2018 at 2:53 PM, Robert Wilton <[email-masked]> wrote:

> There seem to be lots of REST APIs that implement versioning of their API
> by having a version number in the URL.  In fact, I think that RESTCONF
> adopts this approach to allow versioning of the protocol.
>
> One solution is as Andy describes.  The underlying server only implements
> one version of the a given YANG module, but they may provide other views on
> to this data using different versions of YANG modules.  E.g. the same as
> how Vendor YANG models, IETF YANG models, and OpenConfig YANG models might
> be treated as their own views, mapped to the same internal YANG modules.
>
>

I agree with Martin that this requirement is a bad idea.
It will make YANG too complicated and error-prone.
This is not the same as versioning the entire API (e.g., /restconf2,
/restconf3).
This is conceptually a version number at every node in the tree.

The "outer" models are ignored by the server in this approach.
Only the "inner" model is actually implemented and validated.
A different set of outer models for each client, based on the set of modules
the client wants to see, sounds very complicated to design, implement,
test, and operate.

Thanks,
Andy

>>> at the end the WG needs to decide which t
>>> <https://maps.google.com/?q=the+end+the+WG+needs+to+decide+which+t&entry=gmail&source=g>radeoffs
>>> make sense.
>>>
>>> /js
>>>
>>> --

---

From: Robert Wilton <[email-masked]>
Date: Sun, 11 Nov 2018 20:43:32 +0000

On 11/11/2018 07:07, Andy Bierman wrote:
>
>
> On Fri, Nov 9, 2018 at 2:53 PM, Robert Wilton <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Martin,
>
>
>     One way to think of this is as YANG data models defining an API
>     between client and server.
>
>     There seem to be lots of REST APIs that implement versioning of
>     their API by having a version number in the URL.  In fact, I think
>     that RESTCONF adopts this approach to allow versioning of the
>     protocol.
>
>     implements one version of the a given YANG module, but they may
>     provide other views on to this data using different versions of
>     YANG modules.  E.g. the same as how Vendor YANG models, IETF YANG
>     models, and OpenConfig YANG models might be treated as their own
>     views, mapped to the same internal YANG modules.
>
>
>

That is not what I'm proposing.

The server exposes one or more different schema of it's choosing. When 
the client opens the connection with the server it chooses which schema 
to use.

For example, if the server release history was:

Release 1 , supports schema A
Release 1.1, supports schema B
Release 2, supports schema C

Then in release 2, the server may also support the schema associated 
with release 1 and 1.1 (i.e. it supports schema A, B and C)

If this seems too complex, then the server chooses to just implement  
schema C, associated with release 2, and clients are forced to upgrade 
and use the latest schema.

It is not our intention to force servers to implement this version 
selection, only to specify it for vendors who did wish to implement it.

Thanks,
Rob

>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/netmod>
>         .
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/netmod>
>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Nov 2018 17:21:55 +0100 (CET)

>   version 2, would lead to the support of foo in two different

But module 'foo-2' is not a new revision of module 'foo-1'.  It might
be that 'foo-2' represents a new version of the underlying "function"
that 'foo-1' represents; but that is a different issue.

> possibility of a transition path is in general a bad requirement?

No (but I agree w/ Rob Wilton that it is unclear how this should be
done in non-trivial examples), but again, that is not what I think 3.2
says.  IMO 3.2 doesn't allow a solution that requires a new module for
new NBC stuff, since it says that a client should be able to pick a
particular revision of a module.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 12 Nov 2018 17:26:02 +0100

> that 'foo-1' represents; but that is a different issue.

This depends on the versioning solution or what we consider a versioning
solution.

> particular revision of a module.

We apparently lack words for modules that may be versioned by new
module names.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 12 Nov 2018 17:29:45 +0100 (CET)

Robert Wilton <[email-masked]> wrote:
> API by having a version number in the URL.

Yes, but that doesn't mean that a given server supports more than one
version seamlessly.  As you wrote, it works fine for operational
state, but it is less obvious how it should work in the general case
for config data.

> In fact, I think that
> provide other views on to this data using different versions of YANG
> modules.  E.g. the same as how Vendor YANG models, IETF YANG models,
> and OpenConfig YANG models might be treated as their own views, mapped
> to the same internal YANG modules.

Yes, but this solution is also problematic; it is not always the case
that clients can pick and choose from these different "views" and get
consistent results, simply b/c the mappings are not 100% one-to-one.

/martin

---

From: Robert Wilton <[email-masked]>
Date: Mon, 12 Nov 2018 17:14:20 +0000

On 12/11/2018 16:29, Martin Bjorklund wrote:
> version seamlessly.
I agree.  But if a set of translations are being defined between old and 
new it should be possible to identify those cases where the mapping does 
not work.

At the end of the day, if the schema has been expanded in any way, then 
an old client isn't going to understand new functionality used by a new 
client.

>   As you wrote, it works fine for operational
Even for operational data (if we are discussing mapping different 
versions of a schema) then it is not guaranteed that it is possible to 
map between different representations.  If they are two far apart then a 
good mapping may not be possible.

> consistent results, simply b/c the mappings are not 100% one-to-one.
But a device performing that mapping should be able to report the 
paths/values that it has not been able to map.

Thanks,
Rob