Subject: Re: [netmod] Y45-04 and ietf-yang-library

From: Andy Bierman <[email-masked]>
Date: Wed, 1 Jul 2015 17:44:55 -0700

Hi,

I am going to update the draft so the conformance leaf
is an enumeration with 'implement' and 'import' enums.
The 'none' enum is not needed because the deviations are
listed inside the module entry.  A module server would return
the conformance for the proxied server, not itself.

No new objects will be added.
Only item # is being addressed.

Every module the server implements with be listed once
with conformance=implement.  Every module and revision
that those modules import (rippled through all imports) will be listed
in the library, with conformance=import, except of
course if the imported module is also an implemented module.
No other modules will be listed.

Andy

On Tue, Jun 30, 2015 at 11:10 AM, Andy Bierman <[email-masked]> wrote:

>
>
> On Tue, Jun 30, 2015 at 5:45 AM, Juergen Schoenwaelder <
> [email-masked]> wrote:
>
>> Writing as technical contributor...
>>
>> On Tue, Jun 30, 2015 at 10:44:49AM +0200, Martin Bjorklund wrote:
>> > Hi,
>> >
>> > Here's a short summary, and then some questions for the WG.
>> >
>> > The ietf-yang-library module is designed to serve two purposes:
>> >
>> >   1.  A protocol-independent advertisement mechanism for YANG 1.1
>> >       modules.
>> >
>> >   2.  A list of the YANG modules stored in a server.
>> >
>> >
>> > Q1.  Do you agree with these goals?
>>
>> I primarily care about goal 1.
>>
>> > Q2.  Should this module be designed to work with both YANG 1.0 and
>> >      YANG 1.1 servers - i.e., should it have yang-version 1.1 or not?
>> >
>> >      If it should not be defined using YANG 1.1, why is this module
>> >      special?
>>
>> I assume this module will sooner or later be YANG 1.1 anyway.
>>
>> > Q3.  Should the /modules/module list be designed to store both YANG
>> >      1.0 and YANG 1.1 modules?
>>
>> Yes. Even if YANG 1.1 hits the street tomorrow, we will not have
>> revised all published YANG data models that were written using YANG
>> 1.0. So a server needs to be able to announce both YANG 1.0 and YANG
>> 1.1 modules.
>>
>
>
> Yes -- We also agreed that we would not be republishing modules
> just to change the yang-version to 1.1.
>
> There are lots of YANG modules in progress at this time.
> Perhaps 3 out of 100 are relying on YANG 1.1 statements.
> It seems rather disruptive to declare all module must be YANG 1.1
> since it has not even made it through WGLC yat, let alone
> be published as an RFC, let alone be implemented
> in real tool-chains.
>
> I suspect if people find out the only think YANG 1.1 in their module
> (preventing their existing tools from working) is a yang-version-stmt,
> they might not be too happy.
>
>
> Andy
>
>
>>
>> > Q4.  Consider these modules, which both import foo without revision:
>> >
>> >        module a { ... import foo; ... }
>> >        module b { ... import foo; ... }
>> >
>> >      Do we require a server that implements both a and b to use the
>> >      same revision of foo?
>> >
>> >      If the answer is yes, we need to indicate the default revision
>> >      that the server uses in the model:
>> >
>> >        container modules {
>> >          ...
>> >          list module {
>> >            ...
>> >            leaf default-revision {
>> >              type boolean;
>> >              default false;
>> >              description
>> >                "Indicates that this revision is used by the server if
>> >                 this module is imported without a specific revision
>> >                 date.";
>> >            }
>> >          }
>> >        }
>> >
>> >      If the answer is no, note that this puts an implementation burden
>> >      on the client.  A client cannot simply download all listed
>> >      modules, and load/compile/process them as one set.
>> >
>> >      If the anwser is no, I propose that we extend the module as such:
>> >
>> >        container modules {
>> >          ...
>> >          list module {
>> >            ...
>> >            list imported-without-revision {
>> >              key "name revision";
>> >              ...
>> >            }
>> >          }
>> >        }
>> >
>> >      A server could then list:
>> >
>> >       <module>
>> >         <name>a</name>
>> >         <revision>2015-01-01</revision>
>> >         <imported-without-revision>
>> >           <name>foo</name>
>> >           <revision>2002-02-02</revision>
>> >         </imported-without-revision>
>> >       </module>
>> >       <module>
>> >         <name>b</name>
>> >         <revision>2015-01-01</revision>
>> >         <imported-without-revision>
>> >           <name>foo</name>
>> >           <revision>2001-01-01</revision>
>> >         </imported-without-revision>
>> >       </module>
>>
>> I believe truth is advertisement is a good thing. In the SNMP world,
>> not all pieces of the instrumentation were moving at the same pace and
>> I would be somewhat surprised if this would be the case for all
>> implementations in the NETCONF world. Hence, I rather accept that an
>> import of foo without revision may resolve to different versions of
>> foo for different imports.
>>
>> /js
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>>
>> _______________________________________________
>> netmod mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 03 Jul 2015 22:45:27 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> listed inside the module entry.

Don't we have to list the deviation module's revision as well?  As you
noted, the revision is needed in <get-schema>.

If we don't list the deviation module in the main list, it won't be
possible to download such modules over RESTCONF.

> A module server would return

This is up to the WG to decide.  So far, three people (myself
included) have said that they want to solve the advertisement problem,
"indicate the import tree" as you put it, and the two proposed
solutions require new nodes in the module.

It would be good to hear from more people.

I think your objection to addressing this problem is that if import
w/o revision is used, the client by design cannot/should not know
which revision the server used.  Did I get that right?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Jul 2015 14:12:30 -0700

> possible to download such modules over RESTCONF.
That means that the deviation leaf-list has to be a list
to include name and revision.  Then there can be a schema leaf
in each of those entries.

If the deviations module also has other definitions
(a bad practice) then it can be present in the 'module' list
for 'implements' or 'imports'.  This should be rare.

> solutions require new nodes in the module.
I should say no new objects to this release.
The WG can always decide another revision is needed.

> which revision the server used.  Did I get that right?
I propose this text in the conformance leaf:

               For import statements that do not specify a revision
               date, the most recent revision in the library SHOULD
               be used by the server.";

It seems like a lot of data will be needed to model the dependency tree
for every import-stmt in every module.  Don't forget every include-stmt
as well, since submodules can import with or without revision.

IMO "SHOULD use latest" is good enough.
Perhaps modules should use import-by-revision when they
are published as RFCs (as Lada suggested).

As Jeff pointed out, the only time it is safe to use
import/include without revision is if you are sure the imported
module (or included submodule) is the one and only
revision that has, or ever will exist.

Even within a single naming organization this might be
a bad assumption to make.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 3 Jul 2015 14:16:43 -0700

> possible to download such modules over RESTCONF.

I will add 'none' to the enumeration for deviations
It would be bad if any file was listed for download more than once

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jul 2015 08:57:55 +0200

> are published as RFCs (as Lada suggested).

This sounds like "lets pretend the world is simple so we have less
work to do".

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 6 Jul 2015 00:39:21 -0700

> This sounds like "lets pretend the world is simple so we have less
No -- YANG currently says if there is no revision date
then the implementation can use any revision,
This is also good enough.  Prove that this is causing interoperability
problems.  I don't think it is -- especially not such that the server
has to model all its imports so the client can retrieve the data.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jul 2015 09:45:58 +0200

> then the implementation can use any revision,

Exactly - any revision.

> has to model all its imports so the client can retrieve the data.

Did I say all imports? No. I think a server should announce which
revision was picked to resolve imports without a revision.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 6 Jul 2015 07:59:29 -0700

> revision was picked to resolve imports without a revision.
But it could be any revision.

   A imports B.1 imports C
   D imports B.4 imports C
   E imports F imports G imports C

C can be imported many times without revision.
Any import in the chain can be with out without a revision date.

IMO "SHOULD use latest revision of C advertised" is best because
the latest revision is generally the most correct and supports the
most product features.

If the import of C really depends on specific revisions of
some typedefs, groupings, etc. then import by revision MUST
be used everywhere in the dependency chain (C and all its imports).

If no revision-stmt is present the server can pick whatever revision
it wants.  If this is a problem, then fix this problem, don't add
some complex monitoring requirements for servers to implement
and clients to process.  Let's make import-by-revision mandatory
if import-without-revision is a such a problem.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 6 Jul 2015 17:04:30 +0200

>    E imports F imports G imports C

Can we agree on "all imports without a revision fixed in the data
model"?
 
> C can be imported many times without revision.

Yes.

> Any import in the chain can be with out without a revision date.

Yes.
 
> the latest revision is generally the most correct and supports the

But I thought the goal was to know precisely what a device implements,
not what it _could_ implement.

> if import-without-revision is a such a problem.

If the data model leaves it open, then indeed the implementor can
choose.  What is wrong with reporting what was chosen?

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 6 Jul 2015 08:16:32 -0700

On Mon, Jul 6, 2015 at 8:04 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > > > > > It seems like a lot of data will be needed to model the
> dependency
> > > tree

That's not what the RFC 6020 says (not sure about bis)

> choose.  What is wrong with reporting what was chosen?

If there is just a leaf that says 'default-revision=true'
like I proposed, then no problem.  If I have to reproduce the
entire imports/include->imports tree with filled in revision dates,
then this is overkill, too much memory/data, and it is a problem.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 7 Jul 2015 09:53:32 +0200

On Mon, Jul 06, 2015 at 08:16:32AM -0700, Andy Bierman wrote:
> like I proposed, then no problem.

But this assumes that there is a single revision that has been used by
all imports. Are we sure this will be true for all implementations?
Benoit just posted some numbers - OpenDaylight Lithim shipped with 473
YANG modules, about 155 YANG modules that can be extracted in I-Ds for
the upcoming IETF, and other SDOs are on their way as well to produce
YANG modules. If I assume that products will in a couple of years
implement hundreds of YANG modules, do we believe that imports without
revision can all be kept at a specific revision throughout the whole
system?

> If I have to reproduce the entire imports/include->imports tree with
> filled in revision dates, then this is overkill, too much
> memory/data, and it is a problem.

It seems to be a trade-off. If a vendor manages to manage his software
very well, then 'default-revision=true' may do its job. If not, then
we have no standard way to find out what was actually implemented.
So we have the following scenarios:

a) Import by revision de-factor disappears. Problem disappears.

b) Import by revision does not disappear.

   1) Vendor manages to keeps all modules aligned to a single revision,
      then 'default-revision=true' works.
   2) Vendor does not manage to keep all modules aligned to a single
      revision (btw, this can also be forced on the vendor by modules
      from differnet SDOs), then we apparently need additional
      complexity to report what precisely was implemented.

One option out could be to strongly recommend a), to provide the
'default-revision=true' possibility, to provide b.2) as a feature for
systems where 'default-revision=true' is not workable.

/js