Subject: [netmod] review of draft-bierman-netmod-yang-conformance-04

From: Phil Shafer <[email-masked]>
Date: Tue, 18 Nov 2014 21:38:07 -0500

Here's my review of draft-bierman-netmod-yang-conformance-04:

Section 3 implies there are problems, but the only ones it
lists are strawmen.  If a module does import without specifying
the revision of the imported module, bad things can happen.
Fortunately this isn't a problem when one uses import by
revision.  All standard modules and most serious externally
published ones will use import-by-revision.

The drift issues are not related to import-by-revision, since two
modules importing distinct revisions of a module can _expect_
different contents for typedefs, groupings, etc.  Tools will need
to support this concept, and will need to understand that when
module 'A' adds leaf 'g2l' to grouping 'g2' at revision 'xxxx-yy-zz',
then modules that import that revision will see that leaf where
modules importing an earlier version will not.  These means that
YANG compilers will need to understand this.  But it does not
mean that there is a 'drift' issue.

Similarly, implementing a module that imports a second module is
_not_ the same thing as implementing that second module.  Anyone
seeing that a device advertises the first module can inspect it
to see revision information for imported modules.  But the device
doesn't need to implement or advertise the second module.

So when that second module is revised, the device advertisement
doesn't need to change.  If the device implements 10 modules which
each import distinct revisions of that second module, it does not
need to implement that module.  If it does, it will advertise the
revision that _it_ implements, not the one imported by one of the
10 other modules.

If import-by-revision did not work this way, then we run into the
lock-step problem I mentioned in the WG meeting, where an update to
a widely imported module is impossible, since every module that imports
it must move to the new revision immediately, and every device that
implements those modules must move to the modern revision in lock-step.
All the vendor's various teams must ship new code in the same release.
Both scenarios are simply unworkable.

Fortunately, we have import-by-revision, which handles the problem
nicely.

4.4 claims "Import and Include By Revision Do Not Really Help" by
stating:

    Any new YANG statements would cause duplication of the module
    or submodule name and revision date information. However, this
    solution is not workable because the ripple effect will require
    constant updating of many YANG modules just to change the
    revision-date clause.

By this is not true.  If the importing module does not need
anything in the new revision, it can continue to import the
old one.  There is not need to update it.

Also it says:

    Multiple concurrent revisions of YANG datastore contents are
    not supported in a NETCONF server.

Nothing about import-by-revision requires "Multiple concurrent
revisions of YANG datastore contents".  Each container, leaf, list,
or leaf-list defined by a module is constructed with the groupings
and typedefs defined in a particular revision of imported modules.

----------

Consider this example:

module red {
    revision 1111-11-11;

    grouping red-one {
        leaf one { ... }
    }
}

module red {
    revision 2222-22-22;

    grouping red-one {
        leaf one { ... }
        leaf two { ... }
    }
}

module blue {
    revision 3333-33-33;

    import red {
        revision 1111-11-11;
    }

    container top {
        uses red-one;
    }
}

module green {
    revision 3333-33-33;
    import red {
        revision 2222-22-22;
    }

    container top {
        uses red-one;
    }
}

One expects to find the following valid:

    <green:top>
        <green:one>data</green:one>
        <green:two>data</green:two>
    </green:top>
    <blue:top>
        <blue:one>data</blue:one>
    </blue:top>

But <blue:two> would not be valid.   The device would advertise

  blue?revision=3333-33-33
  green?revision=3333-33-33

but would not be required to advertise red unless it actually
implements some construct defined in red.

You could add something like:

module red {
    revision 3333-33-33;

    grouping red-one {
        leaf one { ... }
        leaf two { ... }
    }

    container top {
        uses red-one;
    }
}

Then device could implement a modern red, but still continue
to support the existing green and blue modules.  It would
advertise the following:

  blue?revision=3333-33-33
  green?revision=3333-33-33
  red?revision=3333-33-33

blue:two would contine to be invalid.

I don't think this draft demonstrates a real problem, and might
be caused by a misunderstanding of how import-by-revision works.
The idea of lock-step revision updates is unworkable in any sort
of distributed development arena, including the IETF and most
vendors.

I would be strongly opposed to the working group adopting this work.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Nov 2014 10:17:45 +0100 (CET)

Hi,

Phil Shafer <[email-masked]> wrote:
> lists are strawmen.

I agree.

For YANG 1.1, we have been discussing moving conformance out of the
base document, and put it in a separate document.  IMO this would be a
new document, with some text/ideas from
draft-bierman-netmod-yang-conformance, some from restconf
(ietf-yang-library) and some new text.

Specifically, I think section 6 and possibly 5 (*) should be re-used
from this document.

(*) section 5 might be needed unless we make include-by revision
mandatory.  But I think I am the only one that thinks that would be a
good solution.

> _not_ the same thing as implementing that second module.

+1.  A lot of the confusion comes from this.  Obviously, the spec is
not clear on this - it doesn't specify what it means to "implement" a
module.

In your argument below you miss the fact that import-by revision is
not mandatory.  As long as it is not mandatory, the rules cannot
depend on it being used.  If it was mandatory, some of these problems
would go away - but we would have other problems.  Also, remember that a
module can import for other reasons than using typedefs/groupings etc.

Suppose you have this:

  module a {
    revision 2014-04-01;
    container x;
  }
  module a {
    revision 2014-05-01;
    container x;
    container y;
  }

  module b {
    import a {
      revision-date 2014-04-01;
      prefix a;
    }
    augment /a:x { ... }
  }

  module c {
    import a {
      revision-date 2014-05-01;
      prefix a;
    }
    augment /a:y { ... }
  }

It must be ok to advertise b and a@2014-05-01.

[...]

> of distributed development arena, including the IETF and most

I think everyone agrees w/ this.

But this also imposes a problem for import-by revision - if all your
modules (can be > 100) use import-by revision, updating them for a new
version of your product becomes a tedious, error-prone and
administrative complicated manual task.

A very simple alternative would be to not allow updated typedefs and
groupings at all.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 19 Nov 2014 01:37:49 -0800

Hi,

In previous virtual interim meetings it was determined that not one
single server implementation exists which allowed multiple revisions
of the same module.

So if import-by-revision is so great then why don't people use it?

So if multiple revisions of a YANG module is so easy and so useful,
then why isn't there at least 1 server that supports it?

It is trivial to find examples of import-by-revision that are impossible
to implement (e.g. foo is current is v1 and obsolete in v2) just as it
is trivial to find examples that do work.

Andy

On Wed, Nov 19, 2014 at 1:17 AM, Martin Bjorklund <[email-masked]> wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---

From: Phil Shafer <[email-masked]>
Date: Wed, 19 Nov 2014 10:20:31 -0500

>mandatory.  But I think I am the only one that thinks that would be a

I wouldn't say make it mandatory, but certainly mandatory for
anything externally published, including IETF work.  Using
revision agnostic imports might be suitable for internal and
development work, but once a spec is supposed to be fixed and
hardened, all imports should be by-revision.

>not clear on this - it doesn't specify what it means to "implement" a

Yes, this should be clarified.

>It must be ok to advertise b and a@2014-05-01.

Yes, since the contract for 'a' remains in place.

>A very simple alternative would be to not allow updated typedefs and

This shifts the version tracking task on to the author and
reader.  "foo_v2", "foo_v3", "foo_v2014-04-01", etc.  The
updating costs and possibility of errors would be significant.

Thanks,
 Phil