Subject: [Netmod-ver-dt] Solution slides

From: Robert Wilton <[email-masked]>
Date: Wed, 7 Nov 2018 16:49:20 +0700

Hi,

My proposed solution discussion slides are attached.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Nov 2018 12:16:17 +0100

Perhaps add a disclaimer that there is not necessarily agreement within
the DT on the solution space.

Note that RFC 7950 is indeed strictly liner _but_ it allows branching
by creating modules with different names, i.e., the version number is
implicitely captured in the module name.

New modules do not break all existing paths. The module name changes,
not necessarily the path.

I guess I am back to "we are simply moving from (module, path) to
(module, version, path)" and it remains unclear what we really have
made simpler and for whom.

/js

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

-- 
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: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 8 Nov 2018 00:08:39 +0000

Rob, looks good, excellent slides IMO. I just went through them and have no comments maybe I will after my coffee.

On 2018-11-07, 4:50 PM, "Netmod-ver-dt on behalf of Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,

    Thanks,
    Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 8 Nov 2018 10:30:48 +0700

> the DT on the solution space.
Yes, I will do.
> implicitely captured in the module name.
I'm not convinced that this is really branching.  Today, there would be 
no formal relationship between nodes defined in say ietf-interfaces-2 vs 
ietf-interfaces.

> not necessarily the path.
I don't understand this point.

With RESTCONF, the module name is embedded in the path, so if the module 
name changes, the path changes, and a client would break unless it can 
still use the old path.

Similarly with the JSON and CBOR encodings of the instance data then the 
module names turn up everywhere.

gRPC apparently doesn't use module name or namespaces at all, just the 
raw name of the data nodes.  They assume that there will be no collisions.

> made simpler and for whom.
For me, I can't see how (module, path) works in the config case.

Specifically, I don't understand how it works to have 2 different config 
leaves, both defined in the same schema, that both control the same 
underlying property.  I think that this causes all sorts of consistency 
problems.  Certainly, I don't think that it can work if you have one 
client configuring the system via the older leaf and another configuring 
it via the new leaf.  Perhaps you could elaborate on how you think that 
this would work, and what the constraints are on client and server 
implementations.

RFC 7950 says that one a single revision of a module can be 
implemented.  For configuration, I think that the underlying key rule 
should be that for a given configurable property, there is only one path 
in a given schema for configuring that property (putting aside 
hierarchical configuration which is fine).

I also don't think that it is really (module, version, path), I see it 
as (schema, path), where schema defines a set of modules and versions.  
YANG module definitions are in many senses just defining an API.  I 
think that there are seemingly quite a few examples in the industry 
where semantic versioning of APIs works well.  I'm far less convinced 
that the versioning strategy in RFC 7950 is working well (or otherwise 
I'm unclear what our goal is as a design team :-)

Thanks,
Rob

---

From: Ebben Aries <[email-masked]>
Date: Thu, 8 Nov 2018 12:48:56 +0700

On Nov 08 10:30 AM, Robert Wilton wrote:
> I'm not convinced that this is really branching.  Today, there would be no
> formal relationship between nodes defined in say ietf-interfaces-2 vs
> ietf-interfaces.
> 
> 
> > 
> name changes, the path changes, and a client would break unless it can still
> use the old path.
> 
> gRPC apparently doesn't use module name or namespaces at all, just the raw
> name of the data nodes.  They assume that there will be no collisions.
> 

gNMI services specifically - raw (unprefixed) name in protobuf elements
that are part of a single origin grouping (e.g. 'openconfig') however
the value will still be encoded as JSON, XML, etc.. so same problem

The grouping of origin in itself poses other problems in this scenario
where multiple modules independent of separate namespaces or module
names could have the same structure naming thus causing conflict

> problems.  Certainly, I don't think that it can work if you have one client
> configuring the system via the older leaf and another configuring it via the
> new leaf.  Perhaps you could elaborate on how you think that this would
> work, and what the constraints are on client and server implementations.
> 
> RFC 7950 says that one a single revision of a module can be implemented. 
> For configuration, I think that the underlying key rule should be that for a
> given configurable property, there is only one path in a given schema for
> configuring that property (putting aside hierarchical configuration which is
> fine).
> 
> I also don't think that it is really (module, version, path), I see it as
> (schema, path), where schema defines a set of modules and versions.  YANG
> module definitions are in many senses just defining an API.  I think that
> there are seemingly quite a few examples in the industry where semantic
> versioning of APIs works well.  I'm far less convinced that the versioning
> strategy in RFC 7950 is working well (or otherwise I'm unclear what our goal
> is as a design team :-)
> 
> Thanks,
> Rob
> 
> 
> > 
> > /js
> > 
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod-2Dver-2Ddt&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=yFig4iknQhW0pOvXQ2xc2S_nog_y6S3cJbkrU7aZnNk&s=GEkD9FX2uv7eDdCCWdAm4rjNf6o1_4TRl8AsJZhxpyc&e=
> > 
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod-2Dver-2Ddt&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=yFig4iknQhW0pOvXQ2xc2S_nog_y6S3cJbkrU7aZnNk&s=GEkD9FX2uv7eDdCCWdAm4rjNf6o1_4TRl8AsJZhxpyc&e=

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Nov 2018 09:16:21 +0100

> formal relationship between nodes defined in say ietf-interfaces-2 vs

Do we have a definitions of branching? Yes, there is no formal
relationship but that would be trivial to add.
 
> I don't understand this point.

So we need to be more clear what 'path' means. You apparently consider
the namespace (prefix or whatever) as part of the path. My point is
the namespace component something that can be easily adjusted, of
course if you hardcode things, your code is harder to adjust.
 
> name of the data nodes.  They assume that there will be no collisions.

So we need to be more clear what 'path' means. You apparently consider
the namespace (prefix or whatever) as part of the path. My point is
the namespace component something that can be easily adjusted, of
course if you hardcode things, your code is harder to adjust.

> configuring that property (putting aside hierarchical configuration which is

So you are arguing that 'deprecated' on a config true node is
broken. But with NMDA during transitions, we create large 'deprecated'
trees. ;-)

> strategy in RFC 7950 is working well (or otherwise I'm unclear what our goal

It might indeed be useful to know what examples you have in your mind
where semantic versioning works well. I think you already argued that
three digits are not good enough. There are likely many situations
where you find 3-digit version numbers but I wonder what the subset is
where people are in fact following strict semver rules. Lets face it,
modules are somewhat arbitrary collections of definitions, clients
often use subsets of these arbitrary collections of definitions,
putting a version number on modules has little value in telling a a
client whether it is affected or not.

There is criticism of semver that you can find on the net. I like
these quotes:

  SemVer tries to compress a huge amount of information — the nature
  of the change, the percentage of users that will be affected by the
  change, the severity of the change (Is it easy to fix my code? Or do
  I have to rewrite everything?) — into a single number. And
  unsurprisingly, it's impossible for that single number to contain
  enough meaningful information.

  Ultimately, SemVer is a false promise that appeals to many
  developers — the promise of pain-free, don't-have-to-think-about-it,
  updates to dependencies. But it simply isn't true. Node doesn't
  follow SemVer, Rails doesn't do it, Python doesn't do it, Ruby
  doesn't do it, jQuery doesn't (really) do it, even npm doesn't
  follow SemVer

/js