Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03

From: Randy Presuhn <[email-masked]>
Date: Tue, 12 Jan 2016 11:24:04 -0800 (GMT-08:00)

Hi -

>From: Martin Bjorklund <[email-masked]>
>Sent: Jan 12, 2016 3:53 AM
>To: [email-masked]
>Subject: Re: [Netconf] review of draft-ietf-netconf-yang-library-03
...
>The problem:
>
>  If module A is imported w/o revision by another module that the
>  server implements, the server MUST somehow inform the client which
>  revision of A is used.
>
>Solution 1:
>
>  Reported implicitly - the server lists all revisions of A that it
>  uses, and the most recent one is the one that is used to resolve
>  import w/o revision.
>
>Solution 2:
>
>  Reported explicitly - the server lists all revisions of A that it
>  uses, and the the one that is used to resolve import w/o revision is
>  marked by setting a leaf "default-revision".
>
>
>The current draft has 1 (but it needs to be clarified).  Lada prefers
>2.  What do others think?

Solution 1 is sufficient if the underlying implementations of all
the importing modules in a system strictly play by the current rules.
I think solution 2 would be *slightly* more robust, particularly in
systems supporting dynamic component updates or components from
multiple vendors.  If we ever get to the realistic state of being
able to support multiple revisions of a particular kind of component
concurrently through a single server, both are inadequate.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Tue, 12 Jan 2016 12:02:46 -0800

> concurrently through a single server, both are inadequate.
IMO, solution 1 is appropriate because IMO nobody is going to
write complex client apps to analyze revision-date trees, so they
can be applied to all the import-stmts without revision found nested
in all the server YANG modules.

We also implemented solution 1 many years ago, and it
has been working fine.  Nobody has ever asked to
use multiple revisions for the default import.

> Randy
Andy

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jan 2016 10:18:04 +0100

> in all the server YANG modules.

Solutions 1 and 2 don't differ on this: all revisions of all modules
used by the server will be listed in yang-library.

> use multiple revisions for the default import.

Also, neither solution 1 nor 2 proposes this. There will be only one
revision available for imports without revision.

The real difference is that solution 1 may force an upgrade in a module
that imports another module without revision as a side effect of
extending the data model, because the maximum revision can change.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 Jan 2016 11:28:43 +0100 (CET)

> revision available for imports without revision.

Let me rephrase Andy's statement: Nobody has ever asked us to be able to
have a different default revision than the latest revision.

> extending the data model, because the maximum revision can change.

It is not an upgrade of the *module*, it is an upgrade of the
instrumentation code for that module.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jan 2016 11:47:03 +0100

> On 13 Jan 2016, at 11:28, Martin Bjorklund <[email-masked]> wrote:
> 

Rephrase? Andy says "use multiple revisions for the default import", not "different than latest".

> instrumentation code for that module.

Correct, and this is what the instrumentation code may not be prepared for. I think it is quite important to be able to keep the default import revision stable. The fact that nobody has asked for it yet isn't IMO very relevant because most modules so far have only one revision.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 Jan 2016 12:04:59 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Correct, and this is what the instrumentation code may not be prepared
> for. I think it is quite important to be able to keep the default
> import revision stable. The fact that nobody has asked for it yet
> isn't IMO very relevant because most modules so far have only one
> revision.

Not true!  Vendors have been writing and updating modules since 2010.

I am just providing one data point.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jan 2016 03:29:33 -0800

> Rephrase? Andy says "use multiple revisions for the default import", not

I meant what Martin said -- using the latest revision supported by the
server as the default has been sufficient.

> for. I think it is quite important to be able to keep the default import
> revision stable. The fact that nobody has asked for it yet isn't IMO very
> relevant because most modules so far have only one revision.
>
>

No -- it is quite the opposite.
If the YANG update rules are followed then the latest revision will
work just fine, and updating the default revision to the latest is
transparent
to old clients.

This would be the point of all those rules in section 10.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jan 2016 12:37:58 +0100

> On 13 Jan 2016, at 12:04, Martin Bjorklund <[email-masked]> wrote:
> 

These don't count - vendors writing both modules and instrumentation are in control of everything. The problem I am talking about is this: I want to use a standard module M, but its author decided to import module X with revision that is greater than the default revision I am currently using in the data model. So I have three options:

1. forget about module M,
2. write a proprietary version of M so that it uses at most my default revision of X,
3. upgrade the instrumentation to use the higher revision of X.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 Jan 2016 12:46:00 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> These don't count - vendors writing both modules and instrumentation
> are in control of everything.

The point is that many vendors follow the upgrade rules, and they have
been doing this for several years.

> The problem I am talking about is this:
> I want to use a standard module M, but its author decided to import
> module X with revision that is greater than the default revision I am
> currently using in the data model.

I think you meant "using in the instrumentation".

> So I have three options:

Correct.

You may run into the same situation if you also want to add the
instrumentation for module N, which also imports X w/o revision, and
this instrumentation uses a higher version of X than your
implementation of M.  The 'default-revision' leaf doesn't solve this.

Our experience, and Andy's experience, is that doing (3) has not been
an issue in implementations.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jan 2016 12:57:24 +0100

> This would be the point of all those rules in section 10.

The rules in sec. 10 protect old clients, not old servers.

Let me expand the example:

module X {
  ...
  revision n;
  grouping grp {
    leaf foo {...}
  }
  ...
}

module X {
  ...
  revision n+1;
  grouping grp {
    leaf foo {...}
    leaf bar {...}
  }
  ...
}

Note that this module update is fully compatible with sec. 10 rules.

My data model imports module X without revision and uses grouping "grp".
I chose to use revision n of X in my data model.

Now, I want to use module M that imports X with revision n+1. How do
sec. 10 rules protect me from rewriting the old parts of my
instrumentation and implementing "bar"?

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jan 2016 13:17:54 +0100

> On 13 Jan 2016, at 12:46, Martin Bjorklund <[email-masked]> wrote:
> 

See my response to Andy, upgrade rules really don't help server implementors.

> I think you meant "using in the instrumentation".

No, I meant the complete and concrete data model in use by the server, in which the decision about revisions of imported modules has to be made. In my example, I would need to make the "bar" leaf a part of the data model schema, and instrumentation as well, of course.

> implementation of M.  The 'default-revision' leaf doesn't solve this.

It does solve this! As the server implementor I am in control of the contents of yang-library, so I can bump "default-revision" any time, and module M is unaffected because it imports X with revision.

The only issue would be with other modules that import X without revision: their instrumentation need to be upgraded at the same time, but that's the deal if we want to have no more than one default revision.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jan 2016 07:28:08 -0800

Hi,

I don't see the point of redoing the debate of the corner-case that started
the entire "conformance drift" discussion several years ago.
In YANG 1.1, the designer can import the same module 67 times,
with 67 different revision dates.  They can add new groupings instead of
extending an existing one.  YANG 1.1 has mechanisms to use
that allow the details to be properly reflected.

We have not seen any desire by vendors to break their own
client code or their customers client code, so even though
YANG 1.0 allows import-without-revision to cause drift,
vendors avoid doing this because it breaks deployed product.

IMO,  a complex solution will not get implemented.
Any solution that requires any YANG modules to be parsed
to discover the imports is even worse than what we have in YANG 1.0.
We will just continue using the <hello> and ignore YANG 1.1 rules
if the solution is worse than what we have now.

Andy

On Wed, Jan 13, 2016 at 4:17 AM, Ladislav Lhotka <[email-masked]> wrote:

> No, I meant the complete and concrete data model in use by the server, in
> which the decision about revisions of imported modules has to be made. In
> my example, I would need to make the "bar" leaf a part of the data model
> schema, and instrumentation as well, of course.
>
> >
> >> So I have three options:
> >>
> It does solve this! As the server implementor I am in control of the
> contents of yang-library, so I can bump "default-revision" any time, and
> module M is unaffected because it imports X with revision.
>
> The only issue would be with other modules that import X without revision:
> their instrumentation need to be upgraded at the same time, but that's the
> deal if we want to have no more than one default revision.
>
> Lada
>
> >
> >

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 13 Jan 2016 16:38:06 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> No, I meant the complete and concrete data model in use by the server,
> in which the decision about revisions of imported modules has to be
> made. In my example, I would need to make the "bar" leaf a part of the
> data model schema, and instrumentation as well, of course.
> 
> > 
> >> So I have three options:
> >> 
> contents of yang-library, so I can bump "default-revision" any time,
> and module M is unaffected because it imports X with revision.

I messed up the module names.  I meant to describe the situation you
describe below.  And the point is that the situation you think is
problematic can happen with both solutions 1 and 2.

> The only issue would be with other modules that import X without
> revision: their instrumentation need to be upgraded at the same time,
> but that's the deal if we want to have no more than one default
> revision.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jan 2016 16:51:19 +0100

> On 13 Jan 2016, at 16:28, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 

No need to redo anything. Y45 resolution declares rough consensus on Y45-04, and I am fine with that.
I thought you weren't, so that's why we started discussing alternatives.

> if the solution is worse than what we have now.

I think we are talking past each other. The solution I would support is:

* List all revisions of all imported modules in yang-library. No YANG modules need to be parsed.

* For each module, tag one of its revisions as default - to be used for all imports without revision.

Is this so complex?

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jan 2016 17:19:18 +0100

> On 13 Jan 2016, at 16:38, Martin Bjorklund <[email-masked]> wrote:
> 

OK, let's see if we agree:

- In both 1 and 2, we have only one default revision for each imported module, so necessarily modules that import it without revision need to be upgraded (i.e. their instrumentation) at the same time.

- Solution 1 may force module upgrades (as side effects of new imports with revision) in cases where solution 2 is able to avoid them.

- Solution 1 has no advantage over 2 except that some existing implementations already use it. 

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jan 2016 08:24:41 -0800

> all imports without revision.

Do you have real examples where the latest module implemented
by the server cannot be the default?

The extra complexity is incremental, but it is for a feature
nobody has ever wanted before, so please explain why
it is needed.

Andy

> > >>>>> Let me rephrase Andy's statement: Nobody has ever asked us to be
> able
> > >>>>> to
> in which the decision about revisions of imported modules has to be made.
> In my example, I would need to make the "bar" leaf a part of the data model
> revision: their instrumentation need to be upgraded at the same time, but
> that's the deal if we want to have no more than one default revision.
> >
> > Lada
> >
> > >
> > >

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 13 Jan 2016 17:41:44 +0100

> On 13 Jan 2016, at 17:24, Andy Bierman <[email-masked]> wrote:
> 
> 
> 

No.

> nobody has ever wanted before, so please explain why

When somebody starts from a clean slate, then IMO the complexity of implementing either 1 or 2 should be comparable. In fact, 1 has to determine the maximum revision for each imported module, so arguably it has to do more work.

Solution 1 relies on a CLR written in the spec while 2 provides the information about the default revision explicitly in yang-library data.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 13 Jan 2016 09:02:09 -0800

On Wed, Jan 13, 2016 at 8:41 AM, Ladislav Lhotka <[email-masked]> wrote:

> When somebody starts from a clean slate, then IMO the complexity of
> implementing either 1 or 2 should be comparable. In fact, 1 has to
> determine the maximum revision for each imported module, so arguably it has
> to do more work.
>
> Solution 1 relies on a CLR written in the spec while 2 provides the
> information about the default revision explicitly in yang-library data.
>
>
It is not a CLR.  Picking 1 standard way to do something is our design goal.

As Martin pointed out, both solutions have the same affect, except #2 is
more complicated
If the vendor changes the default revision from 1 release to the next, then
they just set
the flag to false on foo.yang,R1 and change it to true on foo.yang,R2. The
client has
no guarantee that the default revision will stay the same from 1 server
release
to the next.  You cannot identity any use-cases where the server needs to
use a down-rev as the default.

Andy

> > > >>>> Rephrase? Andy says "use multiple revisions for the default
> import",
> > > >>>> not "different than latest".
> > > >>>>
> > > >> 2. write a proprietary version of M so that it uses at most my
> default
> > > >> revision of X,

---

From: t.petch <[email-masked]>
Date: Thu, 14 Jan 2016 10:40:06 +0000

---- Original Message -----
From: "Ladislav Lhotka" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: "Randy Presuhn" <[email-masked]>; "Netconf"
<[email-masked]>
Sent: Wednesday, January 13, 2016 3:51 PM
> * For each module, tag one of its revisions as default - to be used
for all imports without revision.

I think that tagging is the right approach, less likely to induce
errors.  As has been said already, there is limited experience of
multiple revisions of standard modules with YANG.  In other fields, such
as SNMP, I saw the servers implement the latest revision at the time and
then not be upgraded, so that the server's latest was well behind the
industry view of latest, while clients did get upgraded and so knew of
more recent revisions than the server.

The issue then is that a user of the client needs to be aware that the
server is down level when the client itself is uplevel (probably
concurrently, with other servers), so I like the idea of the server
being explicit about its view of latest, since it will vary from the
client's, user's etc view of latest, and will vary across servers.  You
do not have to have a tag to make this apparent, but I see it as a more
robust way, something that the client can point out to the user, the
differing views of what revisions are in use.

Tom Petch

> > Andy
<snip>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 14 Jan 2016 12:00:51 +0100 (CET)

> more recent revisions than the server.

But the tagging proposed here is different.  It would be useful when
the server upgrades to a new version of a module, but only partly.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 14 Jan 2016 12:36:54 +0100

> On 14 Jan 2016, at 12:00, Martin Bjorklund <[email-masked]> wrote:
> 

Well, partly only because we agreed up-front to use a single default revision, at least for YANG 1.1, and then *by definition* all imports of the same module without revision must be bound to that revision. So saying that my proposal is an incomplete solution seems unfair.

If you want, I am open to discussing ways how the server can indicate actual revisions separately for every import without revision.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 14 Jan 2016 05:29:52 -0800

> more recent revisions than the server.

The latest industry revision is not relevant here.
The server only lists the revisions it uses.
It is not required to change just because the industry published a
new revision of a module.

> differing views of what revisions are in use.
The client knows which revisions are present on the server from examining
the
YANG library contents on that server.

The server is explicit about its view of the latest, simply by listing
N revisions and 1 of the N will have a revision date more
recent than the other entries.

The YANG library is a per-server-instance data structure.  It is not a
collection
of all revisions ever published.

Andy