Subject: [netmod] Y45: conformance-stmt proposal

From: Andy Bierman <[email-masked]>
Date: Wed, 7 Jan 2015 13:08:10 -0800

Hi,

I hope we can resolve this issue on the mailing list, since
it was skipped in the interim meeting.

IMO import-by-revision is fatally flawed.
The problem with representing the conformance dependency chain
in the import-stmt is that not every module is using import-by-revision,
and if A.1 imports B.1 and B.1 imports C.any, then the dependency
chain for module A.1 is not deterministic.

import-by-revision everywhere is going to be unmanageable,
even if all the effort to update every YANG module in existence
was made.

Instead, a conformance-stmt much simpler than the SMIv2
MODULE-COMPLIANCE macro is needed:

module foo {
   ...
   import ietf-yang-types { prefix yang; }
   import ietf-inet-types { prefix inet; }
   import ietf-interfaces { prefix if; }

   revision 2014-01-05;
   ....

   conformance 2014-01-05 {
      module ietf-inet-types@2013-07-15;
      module ietf-yang-types@2013-07-15;
      module ietf-interfaces@2014-05-08;
   }
}

Tools can generate this stmt or can be fairly easily generated by hand.
Import-by-revision would no longer be used.

There would be 1 or more conformance-stmts in descending
date order, like the revision-stmt history.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 08 Jan 2015 10:51:39 +0100

> even if all the effort to update every YANG module in existence

Why is it necessary to do such updates? If module A imports
B@2014-01-08, then it can continue using definitions from that
particular revision of B forever, even if B is updated.

>       module ietf-interfaces@2014-05-08;

I don't understand: how is this different from the case when the
revisions of imported modules are specified directly in import statements? 

Lada

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

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

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Jan 2015 07:40:34 -0800

> particular revision of B forever, even if B is updated.

IMO (from a couple decades of dealing with MIB module updates
it is much easier to just make sure the latest revision of any module
in use does not change the definition of any other modules.
SMIv2 never needed import-by-revision.

> revisions of imported modules are specified directly in import statements?

I picked a bad example.
The idea is the conformance macro flattens out the dependency
tree for each module.

module foo {
    ...
    import ietf-ip { prefix ip; }

    revision 2014-01-05;
    ....

    conformance 2014-01-05 {
       use-module ietf-ip@2014-06-16;
       use-module ietf-interfaces@2014-05-08;
       use-module ietf-yang-types@2013-07-15;
       use-module ietf-inet-types@2013-07-15;
    }
}

Note that none of these published modules use import-by-revision.
The only way to capture the dependency chain for these imported
modules is to add some statement to the importing module.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 8 Jan 2015 17:04:25 +0100

> On 08 Jan 2015, at 16:40, Andy Bierman <[email-masked]> wrote:
> 

Oh, it’s 2015 already. :-)

> in use does not change the definition of any other modules.

It’s easier for module users but such a requirement significantly raises the bar for the module development process.

> modules is to add some statement to the importing module.

OK, but what if ietf-ip also has a conformance statement and its revision of ietf-interfaces is different?

Lada

---

From: Andy Bierman <[email-masked]>
Date: Thu, 8 Jan 2015 08:37:38 -0800

> OK, but what if ietf-ip also has a conformance statement and its revision of ietf-interfaces is different?

In this example, the ietf-interfaces info is derived from the ietf-ip module.
The "foo" module cannot pick which modules and revisions that the
"ietf-interfaces" module imports.

But you are correct that flattening out the dependency chain either has
to pick the most recent common version, list duplicates, or list a set of trees.
The conformance-stmt will not really help, except to capture the
revision dates where import-by-revision is not used.

IMO changing every YANG module to use import-by-revision
is not feasible, or a good idea.  And import-by-revision everywhere
still doesn't work.  (Cannot have multiple revisions of an augmented
object for example).  It would be better to say that exported static typedefs
(not identityref) MUST NOT be expanded, and exported groupings MUST NOT
be expanded.  They can be corrected, which is a case-by-case judgement call.

BTW, include-by-revision SHOULD be used everywhere.
There is currently a hole in conformance because submodules
are not supported in the <hello> or in the 'schema' list.

Andy