Subject: [netmod] Y45 - imports

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Mar 2015 16:51:53 -0500

Hi,

as a follow-up to today’s discussion about Y45, I propose the following change to the semantics of imports:

Sec. 7.1.5:

OLD

   When the optional "revision-date" substatement is present, any
   typedef, grouping, extension, feature, and identity referenced by
   definitions in the local module are taken from the specified revision
   of the imported module.  It is an error if the specified revision of
   the imported module does not exist.  If no "revision-date"
   substatement is present, it is undefined from which revision of the
   module they are taken.

NEW

   When the optional "revision-date" substatement is present, all
   typedefs and groupings referenced by definitions in the local module
   are taken from the specified revision of the imported module. It is
   an error if the specified revision of the imported module does not exist.
   If no "revision-date” substatement is present, they are taken from the highest
   revision of the imported module that is less or equal to the revision
   of the importing module.

   When referencing extensions, features, identities and target nodes for augments,
   the “revision-date” statement, if present, is ignored - the revision of the
   imported module that is implemented by the server is always used. 

In other words, for groupings and typedefs the revision is always fixed and controlled by the importing module. For other entities the revision is determined from the server’s advertisement.

As a consequence, if a module is imported only for groupings and typedefs, it needn’t be advertised by the server. In all other cases (augments, …) the imported module must also be advertised. In the latter case, the import statement is only used for defining a prefix corresponding to the imported module.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Mon, 23 Mar 2015 17:20:41 -0500

>    imported module that is implemented by the server is always used.

IMO this does not work because there is no requirement that
the server have all available revisions of all imported modules.
The best match revision may be different from server to server.
Even within 1 server, the best match can change from 1 day
to the next.

The problem cannot be fixed with import-by-revision because
the revision must apply to the whole module:

module A {
    ...
   revision 2015-01-01;
   ...

   typedef foo-range {
      type int32 { range "1..10"; }
   }
}

module B {
   ...
   import A {
      prefix A;
      revision-date 2015-01-01;
   }

  leaf X { type A:foo-range; }
}

Great -- now leaf X is always "1..10".  Problem solved.
But later the designer of module B needs to use the
new 'bar-type' that was added to module A.
Unfortunately, 'foo-range' was also changed.

module A {
    ...
   revision 2015-03-01;
   ...

   typedef foo-range {
      type int32 { range "1..20"; }
   }

   typedef bar-type {
     type string;
   }

}

module B {
   ...
   import A {
      prefix A;
      revision-date 2015-03-03;
   }

  leaf X { type A:foo-range; }
  leaf Y { type A:bar-type; }

}

Now the conformance for leaf X  changed from 1..10
to 1..20.  Import by revision does not really work 100%
unless each YANG module has only 1 exported definition in it.
This is unworkable, especially if the designer of module A
has no reason to separate foo-range and bar-type (because
they don't know or care about module B)

Andy

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 23 Mar 2015 17:37:12 -0500

> On 23 Mar 2015, at 17:20, Andy Bierman <[email-masked]> wrote:
> 

If the server implements a module that asks for a specific revision of a module, then the implementor should have that particular revision. If he cannot get it, then something is broken.

> Even within 1 server, the best match can change from 1 day

No, the revision is fixed by the importing module, ideally form the revision-date. It doesn’t differ from server to server, and server implementors should use that revision.

> they don't know or care about module B)

If foo-range changed, then presumably there must have been a reason for such a change, and all users should sooner or later accommodate to this change. If a server *temporarily* cannot implement the extended range, it can copy-and-paste the old version.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 24 Mar 2015 20:23:36 +0100

> If foo-range changed, then presumably there must have been a reason for such a change, and all users should sooner or later accommodate to this change. If a server *temporarily* cannot implement th…

I believe this is to be avoided for two reasons:

(1) It is unrealistic to expect that model maintainers will go and
    check whether any definition that they *use* was semantically
    modified in the all the modules they import from. (Note that often
    *used* << *defined* - you import yang-types but only use a small
    subset of it.)

(2) The value of common definitions is that tools can understand them.
    For example, tools may know what an inet:ip-address is and so they
    know how to represent such data efficiently. If we have to support
    IPv8, then a copy of inet:ip-address into my-module:ip-address
    will loose all tool support (and having from there on N similar
    definitions that start their own lifecycle will be horrible).

The only robust and backwards compatible way to lets say add IPv8
support to inet:ip-address is to create inet:ip-address-v8. For all
the alternatives considered, see the various meeting notes and the
I-Ds Martin and Andy wrote.

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