Subject: Re: [Netmod-ver-dt] Netmod Ver DT - Meeting Agenda 24th May

From: Robert Wilton <[email-masked]>
Date: Fri, 1 Jun 2018 15:47:37 +0100

Hi Reshad,

I think that it depends on who you ask:

Clients would like more stability in the YANG models.  Vendors would 
like to be able to update their software, which for Native YANG models 
that are generated from internal models implies some non backwards 
compatible updates (although I believe that most vendors try hard to 
minimize non backwards compatible updates anyway).

So the question is:  Who is responsible for handling the 
incompatibilities between versions?  Should this be done by the clients 
(or a central controller), or should this be done by the devices themselves?

If you allow a device to support multiple versions then:
  - Each NETCONF/RESTCONF session would only communicate using a single 
version.
  - YANG library would be used to expose the different versions (and 
what modules form the combined schema for those different versions).
  - An RPC or option at session initialization time would be used to 
select which version is to be used for the entirety of that session.
  - The device itself would most likely map between the externally 
exposed versions and the internally implemented version.  This is 
actually a similar, but likely simpler, problem to mapping OpenConfig or 
IETF YANG models into the device native YANG models.

The second question here is that even if it was specified, would any 
vendors actually sign up to implementing it?

Thanks,
Rob

On 31/05/2018 19:06, Reshad Rahman (rrahman) wrote:
> Hi Rob,
>
> I incorrectly thought there was a need to have devices support multiple versions. As Benoit explained to me via jabber, this is not needed (and contravenes 7950 as someone on the call mentioned). So yes I agree that there is no need to include the version in the request, the client/controller will know via YANG lib which version to use for a device.
>
> Regards,
> Reshad.
>
>
> On 2018-05-31, 1:03 PM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]> wrote:
>
>      Hi Reshad,
>      
>      I don't think that there is any proposal or need to include the version
>      in the request.
>      
>      YANG library publishes the set of modules implemented by the server, and
>      today it can only implement a single revision of module.  At the moment
>      this constraint would also apply to semantic versions in the clacla draft.
>      
>      I think that it should always be the case, that for a particular
>      session, the version of a path is well known and hence doesn't need to
>      be included in the request.
>      
>      My interpretation of Juergen's comment is more about data node
>      uniqueness.  He is saying that with the existing YANG rules, uniqueness
>      if guaranteed by (module, path), whereas if non backwards compatible
>      updates are allowed then to achieve uniqueness it would be necessary to
>      track the triple (module, path, version).
>      
>      However, I don't currently agree with Juergen on this, since a data node
>      may get created in a new module revision, or be obsoleted, or be
>      deviated by one or more different servers.  So, I actually think that
>      uniqueness is really bound to a particular device-schema, so it is
>      already the triple (device-schema, module, path), and sem-ver wouldn't
>      change this.
>      
>      I would then define that a schema node in two schemas are equivalent if:
>      (i) they are defined in the same module (with same namespace)
>      (ii) they exist on the same path (including keys)
>      (iii) they have the same type (to ensure encoding is the same)
>      (iv) they support exactly the same set of values
>      (v) they have the same must/when/choice constraints.
>      
>      Thanks,
>      Rob
>      
>      
>      On 31/05/2018 15:15, Reshad Rahman (rrahman) wrote:
>      > Hi,
>      >
>      > My question was when a client sends a request, is the version included in the request? My understanding is yes since the server may support multiple versions for the module, path combo.
>      >
>      > Regards,
>      > Reshad.
>      >
>      > On 2018-05-31, 9:08 AM, "Benoit Claise (bclaise)" <[email-masked]> wrote:
>      >
>      >      On 5/24/2018 5:19 PM, Reshad Rahman (rrahman) wrote:
>      >      > Hi,
>      >      >
>      >      > I joined the meeting 35+ mins late,  so I didn't hear all the discussions.
>      >      >
>      >      > Regarding the semver solution in draft-clacla, the version will have to be included in the requests?
>      >      Not sure I understand the reason why the semver should be part of every
>      >      request? Or maybe I misunderstand the point.
>      >      The IETF-YANG-LIBRARY provides the YANG modules, including the revisions.
>      >      Within a YANG module specific revision, there is one semver (set of) values.
>      >      If we want to make it clean, we could include the semver directly in the
>      >      IETF-YANG-LIBRARY.
>      >      See
>      >      https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-05#section-3.4
>      >
>      >      Regards, Benoit
>      >
>      >      > That's a pretty big change as Juergen mentioned. Also I assume is the expectation is that devices will support multiple versions, otherwise the exercise is futile?
>      >      >
>      >      > Regards,
>      >      > Reshad.
>      >      >
>      >      > On 2018-05-24, 9:56 AM, "Netmod-ver-dt on behalf of Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked] on behalf of [email-masked]> wrote:
>      >      >
>      >      >      I've also created an EtherPad for collaborate meeting notes/minutes.
>      >      >
>      >      >      http://etherpad.tools.ietf.org:9000/p/netmod-ver-dt
>      >      >
>      >      >      Thanks,
>      >      >      Rob
>      >      >
>      >      >
>      >      >      On 24/05/2018 14:06, Robert Wilton wrote:
>      >      >      > Hi,
>      >      >      >
>      >      >      > The proposed agenda for today's meeting is as follows:
>      >      >      >
>      >      >      > 1) Agenda bashing (if required) (5 mins)
>      >      >      > - I will take minutes.  Should we also record meetings?
>      >      >      >
>      >      >      > 2) Cover initial scope and timelines for the DT (5 mins):
>      >      >      > - I would like to focus just on the Problem Statement and Solution
>      >      >      > Requirements, deferring discussion on the actual solution until we
>      >      >      > have got these broadly agreed.
>      >      >      > - It would be nice to aim for an initial draft covering problem
>      >      >      > statement and requirements before IETF 102.  Is this feasible?
>      >      >      >
>      >      >      > 3) Discussion on Problem Statement and Solution Requirements (45 mins)
>      >      >      > - Benoit has proposed using the problem statement from the clacla
>      >      >      > draft as a starting point.  Does anyone disagree, or propose a
>      >      >      > different starting point for the problem statement?
>      >      >      >  - Discussion/refinement on the problem statement and requirements.
>      >      >      >
>      >      >      > 5) Wrap up, next steps. (5 mins)
>      >      >      > - What frequency of meetings?  Weekly running up to IETF?
>      >      >      >
>      >      >      > Thanks,
>      >      >      > Rob
>      >      >      >
>      >      >
>      >      >      _______________________________________________
>      >      >      Netmod-ver-dt mailing list
>      >      >      [email-masked]
>      >      >      https://www.ietf.org/mailman/listinfo/netmod-ver-dt
>      >      >
>      >      >
>      >      > _______________________________________________
>      >      > Netmod-ver-dt mailing list
>      >      > [email-masked]
>      >      > https://www.ietf.org/mailman/listinfo/netmod-ver-dt
>      >
>      >
>      >
>      
>      
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 01 Jun 2018 11:04:12 -0400

FwIW I've seen a need for a server to support multiple versions on a per 
client basis, as well as a willingness for servers to support this.

----------
On June 1, 2018 10:48:33 AM Robert Wilton <[email-masked]> wrote:

>> I incorrectly thought there was a need to have devices support multiple 
>> versions. As Benoit explained to me via jabber, this is not needed (and 
>> contravenes 7950 as someone on the call mentioned). So yes I agree that 
>> there is no need to include the version in the request, the 
>> client/controller will know via YANG lib which version to use for a device.
>>
>> Regards,
>> Reshad.
>>
>>
>>      > My question was when a client sends a request, is the version included in 
>>      the request? My understanding is yes since the server may support multiple 
>>      versions for the module, path combo.
>>      >
>>      > Regards,
>>      > Reshad.
>>      >
>>      >      > That's a pretty big change as Juergen mentioned. Also I assume is 
>>      the expectation is that devices will support multiple versions, otherwise 
>>      the exercise is futile?
>>      >      >
>>      >      > Regards,
>>      >      > Reshad.
>>      >      >
>>      >      > On 2018-05-24, 9:56 AM, "Netmod-ver-dt on behalf of Robert Wilton 
>>      -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked] on 
>>      behalf of [email-masked]> wrote:
>>      >      >

---

From: Joe Clarke <[email-masked]>
Date: Fri, 1 Jun 2018 12:01:11 -0400

On 6/1/18 10:47, Robert Wilton wrote:
>  - YANG library would be used to expose the different versions (and what
> modules form the combined schema for those different versions).

I hadn't thought about this in much detail, but when I mentioned this
yesterday, I was thinking along similar lines.  Because of
interdependencies, I had thought about a bundle or set concept vs.
selecting individual modules, though.

> vendors actually sign up to implementing it?

That's an important question.  And I also think that if we go down this
route, the work could be separate from this versioning work.  I feel
this is a different problem to solve and I think we have enough in scope
currently.

Joe

>> I incorrectly thought there was a need to have devices support
>> multiple versions. As Benoit explained to me via jabber, this is not
>> needed (and contravenes 7950 as someone on the call mentioned). So yes
>> I agree that there is no need to include the version in the request,
>> the client/controller will know via YANG lib which version to use for
>> a device.
>>
>> Regards,
>> Reshad.
>>
>>
>>      > Hi,
>>      >
>>      > My question was when a client sends a request, is the version
>> included in the request? My understanding is yes since the server may
>> support multiple versions for the module, path combo.
>>      >
>>      > Regards,
>>      > Reshad.
>>      >
>>      > On 2018-05-31, 9:08 AM, "Benoit Claise (bclaise)"
>> <[email-masked]> wrote:
>>      >
>>      >      On 5/24/2018 5:19 PM, Reshad Rahman (rrahman) wrote:
>>      >      > Hi,
>>      >      >
>>      >      > I joined the meeting 35+ mins late,  so I didn't hear
>> all the discussions.
>>      >      >
>>      >      > Regarding the semver solution in draft-clacla, the
>> version will have to be included in the requests?
>>      >      Not sure I understand the reason why the semver should be
>> part of every
>>      >      request? Or maybe I misunderstand the point.
>>      >      The IETF-YANG-LIBRARY provides the YANG modules, including
>> the revisions.
>>      >      Within a YANG module specific revision, there is one
>> semver (set of) values.
>>      >      If we want to make it clean, we could include the semver
>> directly in the
>>      >      IETF-YANG-LIBRARY.
>>      >      See
>>      >     
>>      >
>>      >      Regards, Benoit
>>      >
>>      >      > That's a pretty big change as Juergen mentioned. Also I
>> assume is the expectation is that devices will support multiple
>> versions, otherwise the exercise is futile?
>>      >      >
>>      >      > Regards,
>>      >      > Reshad.
>>      >      >
>>      >      > On 2018-05-24, 9:56 AM, "Netmod-ver-dt on behalf of
>> Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)"
>> <[email-masked] on behalf of [email-masked]> wrote:
>>      >      >
>>      >      >      I've also created an EtherPad for collaborate
>> meeting notes/minutes.
>>      >      >
>>      >      >      http://etherpad.tools.ietf.org:9000/p/netmod-ver-dt
>>      >      >
>>      >      >      Thanks,
>>      >      >      Rob
>>      >      >
>>      >      >
>>      >      >      On 24/05/2018 14:06, Robert Wilton wrote:
>>      >      >      > Hi,
>>      >      >      >
>>      >      >      > The proposed agenda for today's meeting is as
>> follows:
>>      >      >      >
>>      >      >      > 1) Agenda bashing (if required) (5 mins)
>>      >      >      > - I will take minutes.  Should we also record
>> meetings?
>>      >      >      >
>>      >      >      > 2) Cover initial scope and timelines for the DT
>> (5 mins):
>>      >      >      > - I would like to focus just on the Problem
>> Statement and Solution
>>      >      >      > Requirements, deferring discussion on the actual
>> solution until we
>>      >      >      > have got these broadly agreed.
>>      >      >      > - It would be nice to aim for an initial draft
>> covering problem
>>      >      >      > statement and requirements before IETF 102.  Is
>> this feasible?
>>      >      >      >
>>      >      >      > 3) Discussion on Problem Statement and Solution
>> Requirements (45 mins)
>>      >      >      > - Benoit has proposed using the problem statement
>> from the clacla
>>      >      >      > draft as a starting point.  Does anyone disagree,
>> or propose a
>>      >      >      > different starting point for the problem statement?
>>      >      >      >  - Discussion/refinement on the problem statement
>> and requirements.
>>      >      >      >
>>      >      >      > 5) Wrap up, next steps. (5 mins)
>>      >      >      > - What frequency of meetings?  Weekly running up
>> to IETF?
>>      >      >      >
>>      >      >      > Thanks,
>>      >      >      > Rob
>>      >      >      >
>>      >      >
>>      >      >      _______________________________________________
>>      >      >      Netmod-ver-dt mailing list
>>      >      >      [email-masked]
>>      >      >      https://www.ietf.org/mailman/listinfo/netmod-ver-dt
>>      >      >
>>      >      >
>>      >      > _______________________________________________
>>      >      > Netmod-ver-dt mailing list
>>      >      > [email-masked]
>>      >      > https://www.ietf.org/mailman/listinfo/netmod-ver-dt
>>      >
>>      >
>>      >
>>          
>

---

From: Robert Wilton <[email-masked]>
Date: Fri, 1 Jun 2018 17:46:59 +0100

> selecting individual modules, though.
I'm definitely thinking of bundles rather than selecting individual modules.

E.g. a release might support "rel-3.8.2", "rel-4.5.1", "rel-4.5.2(s)", 
"rel-4.6.1".  Note, these are just vendor strings and not tied to module 
semantic versioning in any way.

> this is a different problem to solve and I think we have enough in scope
I'm not sure.  It seems like a very closely related problem to me.

Perhaps one option would be to include it in the problem definition, and 
requirements, but ask for WG feedback as to whether it should be 
included in the scope at IETF 102.

Thanks,
Rob

> .

---

From: Joe Clarke <[email-masked]>
Date: Fri, 1 Jun 2018 13:11:39 -0400

> semantic versioning in any way.

This is similar to how I envisioned this working.

> included in the scope at IETF 102.

We could certainly seek WG guidance.  We have a lot already proposed for
the work scope now.  This feels like another, albeit related, document
to me.

Joe

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Fri, 1 Jun 2018 18:22:08 +0000

My take is that the support of multiple versions on a server/device is, although related, lower priority for now. And yes, taking it to the WG makes sense. If we do tackle it, would be good to have expertise of people such as Martin and Andy. 

Regards,
Reshad.

On 2018-06-01, 1:11 PM, "Joe Clarke (jclarke)" <[email-masked]> wrote:

    

    Joe

---

From: Mahesh Jethanandani <[email-masked]>
Date: Fri, 1 Jun 2018 11:26:24 -0700

> On Jun 1, 2018, at 10:11 AM, Joe Clarke <[email-masked]> wrote:
> 

That by definition means that clients would choose one of the many 'module-set’ list of schemas that the server supports. For the server it means having to decide whether it supports a particular operation in a particular module based on a particular request. From a server perspective, that is a lot to support, and I wonder if vendors would be willing to sign up for such a capability.

> the work scope now.  This feels like another, albeit related, document

Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jun 2018 10:16:36 +0200

On Thu, May 31, 2018 at 06:03:16PM +0100, Robert Wilton wrote:
> today it can only implement a single revision of module.  At the moment this
> constraint would also apply to semantic versions in the clacla draft.
>

But today, semantics of objects never changed once published. A server
today can support multiple versions any time since there are multiple
objects. Once you allow semantic changes, then the of course this
falls apart. Are you proposing that a server will never support
multiple versions and that clients will always be able to deal with
the current version provided by the server, i.e., all clients are
always in sync with the server's single version?

/js

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

---

From: Robert Wilton <[email-masked]>
Date: Tue, 5 Jun 2018 10:56:24 +0100

> always in sync with the server's single version?
Where possible, as a vendor, we try and keep changes to modules 
backwards compatible.

For me, I think that non backwards compatible changes fit into two 
categories:

(1) Sometimes there are proper major version changes of a 
protocol/model.  E.g. IPv6 vs IPv4.  For these sorts of changes I expect 
new YANG modules (with different names) to be defined, so that the new 
version can completely coexist with the existing version.  Here, I think 
that keeping the same module namespace, and just changing the major 
revision number would be unhelpful.

(2) At other times, I don't think that the module is being changed in a 
major way at all, just part of the structure is changed to fix a 
mistake, or enable new functionality.  For this scenario, from a client 
perspective, I think that a NETCONF/RESTCONF server can only implement a 
single revision (or version) of a given module.

The other thing that has been discussed recently is version selection by 
a client.  Here, I think that consistent sets of modules are grouped 
together (perhaps as module-sets in in YANG library bis), where each 
module-set only contains a single revision/version of a module, but 
different module sets can contain different revisions/versions of a 
module from the other module-sets.  E.g. the first module-set represents 
version X of the server software, and the second module-set represents 
version Y of the server software.

Each client, at connection time, chooses which module-set it interacts 
with for the entirety of that session (e.g. once chosen the YANG library 
bis datastore references for that session would updated to point to the 
correct per datastore modules for that version).  Or perhaps an 
alternative way would be to run each different version on different port 
number, and redirect the client to the port that supports the chosen 
version.  I think that the key, is that regardless of how this is 
implemented, from a client perspective only a single revision of any 
module is seen/allowed.

I think that this is broadly similar approach to running OpenConfig 
modules in one NETCONF instance, IETF modules in another instance, and 
Native modules in a third instance.  If you put all of these different 
sets of modules in the same NETCONF/RESTCONF instance, then I think that 
you have consistency problems where 3 separate configuration paths/items 
reference the same underlying semantic object.  I think that splitting 
them into separate silos help keep everything sane.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jun 2018 12:07:01 +0200

On Tue, Jun 05, 2018 at 10:56:24AM +0100, Robert Wilton wrote:
> Where possible, as a vendor, we try and keep changes to modules backwards
> compatible.
> 
> (1) Sometimes there are proper major version changes of a protocol/model. 
> E.g. IPv6 vs IPv4.  For these sorts of changes I expect new YANG modules
> (with different names) to be defined, so that the new version can completely
> coexist with the existing version.  Here, I think that keeping the same
> module namespace, and just changing the major revision number would be
> unhelpful.
> 
> major way at all, just part of the structure is changed to fix a mistake, or
> enable new functionality.  For this scenario, from a client perspective, I
> think that a NETCONF/RESTCONF server can only implement a single revision
> (or version) of a given module.
> 
> The other thing that has been discussed recently is version selection by a
> client.  Here, I think that consistent sets of modules are grouped together
> (perhaps as module-sets in in YANG library bis), where each module-set only
> contains a single revision/version of a module, but different module sets
> can contain different revisions/versions of a module from the other
> module-sets.  E.g. the first module-set represents version X of the server
> software, and the second module-set represents version Y of the server
> software.
> 
> Each client, at connection time, chooses which module-set it interacts with
> for the entirety of that session (e.g. once chosen the YANG library bis
> datastore references for that session would updated to point to the correct
> per datastore modules for that version).  Or perhaps an alternative way
> would be to run each different version on different port number, and
> redirect the client to the port that supports the chosen version.  I think
> that the key, is that regardless of how this is implemented, from a client
> perspective only a single revision of any module is seen/allowed.
> 
> I think that this is broadly similar approach to running OpenConfig modules
> in one NETCONF instance, IETF modules in another instance, and Native
> modules in a third instance.  If you put all of these different sets of
> modules in the same NETCONF/RESTCONF instance, then I think that you have
> consistency problems where 3 separate configuration paths/items reference
> the same underlying semantic object.  I think that splitting them into
> separate silos help keep everything sane.
>

Whether you package things or not, at the end you have moved to a
naming triple (module, path, 'silo') or (module, path, 'package
release') or whatever.

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 5 Jun 2018 11:42:05 +0100

> naming triple (module, path, 'silo') or (module, path, 'package
I think that this may be one of our disconnects, since I think that many 
clients exist in a naming triple world today:

For standards based models: vendors are using deviations (which may vary 
depending on hardware, s/w version, etc).
For native models that are generated, vendors do not always faithfully 
follow the backwards compatibility update rules.

So, I think that using (module, path) is really just an optimization 
that can only be used under some circumstances (i.e. modules revisions 
are all 100% backwards compatible, and no per server deviations).

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jun 2018 12:51:17 +0200

On Tue, Jun 05, 2018 at 11:42:05AM +0100, Robert Wilton wrote:
> So, I think that using (module, path) is really just an optimization that
> can only be used under some circumstances (i.e. modules revisions are all
> 100% backwards compatible, and no per server deviations).
>

Yes, I do not see deviations as another naming system dimension. Anyway,
if you do, simply add 1 and the result is the same - the proposal is to
add a new component to the naming system, moving form a triple to a
quadrupel.

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 5 Jun 2018 14:11:44 +0100

> add a new component to the naming system, moving form a triple to a
I agree that if you care to only uniquely define the behaviour of a node 
then you can use (module, path, deviation).

But if you care whether that node is actually defined in a particular 
schema then you already require (module, path, revision, deviation).  
This is also required today if not all revisions of the data models are 
backwards compatible.

Whereas with sem-ver you would have (module, path, version, deviation) 
instead.

But if I was implementing this in a client, then I would try using 
(datastore-schema, path) for each device (which also matches what comes 
back from YANG library bis), and then rely of a layer of data node 
mapping between the client's native schema and each of the devices that 
it is interacting with.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jun 2018 16:56:04 +0200

On Tue, Jun 05, 2018 at 02:11:44PM +0100, Robert Wilton wrote:
> 
> But if you care whether that node is actually defined in a particular schema
> then you already require (module, path, revision, deviation).  This is also
> required today if not all revisions of the data models are backwards
> compatible.

Today definitions have to be backwards compatible, they do not change
semantically. Hence the above statement is not correct.
 
> Whereas with sem-ver you would have (module, path, version, deviation)

Yes, you add 'version' to the name (since above is incorrect).

> (datastore-schema, path) for each device (which also matches what comes back
> from YANG library bis), and then rely of a layer of data node mapping
> between the client's native schema and each of the devices that it is
> interacting with.

But this is broken. You can have /a/b in two different modules, a path
is never guaranteed to be unique. Or perhaps better said, I have no
clue what 'datastore-schema' means to you.

/js

---

From: Robert Wilton <[email-masked]>
Date: Tue, 5 Jun 2018 16:24:53 +0100

> semantically. Hence the above statement is not correct.
Consider you are programming a new feature that is only present in 
revision 2018-06-05.  I think that the management client needs to track 
which module revision a node exists in, otherwise the configuration is 
going to fail when it attempts to program that new feature against an 
older revision that doesn't support it.

I appreciate that RFC 7950 states that all updates are backwards 
compatible, but the vendors are not all following that today.  A client 
could choose to only buy from vendors who are strictly following the 
update rules, but that may leave them with very few vendors to choose 
from ...

Similarly, OpenConfig YANG models are seemingly getting traction, and 
they don't follow the YANG update rules, but use semantic versioning 
instead.

If the existing rules were working well then I don't see that this 
design team would be happening at all.

Note, even if YANG generically allows non backwards compatible updates, 
that does not mean that IETF YANG modules necessarily have to follow 
suit, it could decide to keep all module updates backwards compatible.

> clue what 'datastore-schema' means to you.
By path, I mean a "schema node identifier" (RFC 7950).

For datastore-schema, I mean the definition from RFC8342:

    o  datastore schema: The combined set of schema nodes for all modules
       supported by a particular datastore, taking into consideration any
       deviations and enabled features for that datastore.

My assertion is that the (datastore-schema, schema-node-identifier) pair 
uniquely identifies a schema node, because the datastore-schema embeds 
the revision/version/deviation information for all modules. If this 
isn't the case then it would seem to imply that YANG library is broken.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 5 Jun 2018 18:52:05 +0200

On Tue, Jun 05, 2018 at 04:24:53PM +0100, Robert Wilton wrote:
> Consider you are programming a new feature that is only present in revision
> 2018-06-05.  I think that the management client needs to track which module
> revision a node exists in, otherwise the configuration is going to fail when
> it attempts to program that new feature against an older revision that
> doesn't support it.

Yes, you can't configure something that does not yet exist in the
server. Yes, a client can look into the YANG library to figure out
whether the server supports the specific object or it can simply try
and handle the failure. (And there are other possible failure reasons,
e.g. access control prevents the client to access the object in
question.)
 
> I appreciate that RFC 7950 states that all updates are backwards compatible,
> but the vendors are not all following that today.  A client could choose to
> only buy from vendors who are strictly following the update rules, but that
> may leave them with very few vendors to choose from ...

I understand that.

> Similarly, OpenConfig YANG models are seemingly getting traction, and they
> don't follow the YANG update rules, but use semantic versioning instead.
> 
> If the existing rules were working well then I don't see that this design
> team would be happening at all.

Fine. But all I want is that people stop saying "we add a version
number to YANG modules and we have solved the problem". You have not
even touched to solve the problem. I want to see a solution proposal
that is complete. And I believe this involves way more than adding a
three digit number.

> Note, even if YANG generically allows non backwards compatible updates, that
> does not mean that IETF YANG modules necessarily have to follow suit, it
> could decide to keep all module updates backwards compatible.

Whatever. I am saying you need a major revision of YANG and likely also
protocol changes to have a complete solution.

> uniquely identifies a schema node, because the datastore-schema embeds the
> revision/version/deviation information for all modules. If this isn't the
> case then it would seem to imply that YANG library is broken.

Not today. Or if it does, are we done already?

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 6 Jun 2018 11:22:44 +0100

> that is complete. And I believe this involves way more than adding a
OK, can you please list what you think the extra stuff is please.  I 
would think that this could either form part of a problem definition, or 
feed into an enumerated list of requirements for a solution.

> Not today. Or if it does, are we done already?
The only thing that YANG library is missing is the semantic version 
number for each module, and that in itself doesn't appear to be 
difficult to add.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 6 Jun 2018 12:56:52 +0200

On Wed, Jun 06, 2018 at 11:22:44AM +0100, Robert Wilton wrote:
> 
> OK, can you please list what you think the extra stuff is please.  I would
> think that this could either form part of a problem definition, or feed into
> an enumerated list of requirements for a solution.
>

I thought I did already. For me, adding version numbers extends the
naming system from tuples (module, path) to triples (module, path,
version) and this means that all places where YANG and the protocols
assume a (module, path) tuple may need changes to support (module,
path, version) triples. This does not mean that every reference has to
carry an explicit version number; the version number (or version
number ranges or version number range sets) may be provided by the
context in which a reference is interpreted. But then it needs to be
defined how the version context is obtained.
 
> The only thing that YANG library is missing is the semantic version number
> for each module, and that in itself doesn't appear to be difficult to add.

So is support of multiple versions an agreed on requirement or not?

/js

PS: I do have a work related scheduling conflict tomorrow so I won't
    be able to join the call.