Subject: Re: [NGO] external module properties

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 May 2008 22:31:55 +0200 (CEST)

Hi,

"Randy Presuhn" <[email-masked]> wrote:
> > From: "Martin Bjorklund" <[email-masked]>
> > Suppose module A rev 1 gets published in an rfc, and module B which
> > imports A rev 1 in another.  Now, A is updated to rev 2.  If a vendor
> > wants to implement A rev 2 and B, that doesn't work, unless B is also
> > updated to rev 2 as soon as A is updated.
> 
> In my opinion, this is a feature, rather than a bug.
> (But there's no "as soon as" requirement.  There's no need to update
> B until someone wants a version that includes the behavioural changes
> that would result from using the newer version of A.)

The problem is when a vendor needs to implement A rev 2 in a device,
and also B.  B imports A rev 1.  So the device needs to implement A
rev 1 *and* A rev 2.   This is something that we have talked about
before, and dismissed as being too complicated in general.

But you talk about behavioural changes.  In the current design of
YANG, the idea has been that a module cannot be updated in a way that
changes the behaviour for importers and includers.  Thus you don't
have to rev B just b/c A is updated.

/martin
_______________________________________________
NGO mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ngo

---

From: Phil Shafer <[email-masked]>
Date: Thu, 01 May 2008 16:45:48 -0400

>before, and dismissed as being too complicated in general.

I'm hoping (having not implemented it yet ;^) that this won't be that
bad.  If I have a hierarchy in my C module that uses a grouping
from B that uses the original revision of A, and another place in
my C that wants to use the new A with a new leaf that has the content
I want, I just need to track the module inclusion and imports to
know which revision of A I am getting the grouping from.

>have to rev B just b/c A is updated.

If I add a new leaf to a grouping in A that B doesn't know about,
B will break if I use the new A.  If I can't say which A I want,
then the grouping in A cannot be allowed to change.  This means
that the contents of groupings, types, etc are locked for all time,
which is a pretty strong limitation.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 01 May 2008 23:26:35 +0200 (CEST)

> know which revision of A I am getting the grouping from.

A YANG module defines types, groupings, data, rpc, and notifications.
All of these can be referenced by an importing modules (types and
groupings are obvious; data can be referenced through keyrefs,
augments, and must expressions; and rpc/notifs can be augmented).  I
agree that supporting multiple versions of a module in order to handle
types and grouping should be fairly straight-forward.  But when it
comes to data/rpc/notifs the device must choose one version to
implement.  It would have to be a version no earlier than the latest
version referenced by any other module implemented on the device.

For example:

  module a {
     revision "2008-04-25";

     container foo { ... }
  }

  module a {
     revision "2008-05-01";

     container foo { ... }
     container bar { ... }
  }

  module b {
     revision "2008-04-26";
     import a { 
       revision "2008-04-25";
       prefix a;
     }
  
     augment "/a:foo" {
       container baz { ... }
     }
  }

A device must be allowed to announce that it implements:

    a:2008-05-01
    b:2008-04-26

Maybe it's not a problem...  but the schema discovery mechanism will
have to support these cases.  There would be two separate lists of
schemas; one list with the data/rpc/notifs that the device implements,
and an extended list which includes older versions and
type/grouping-only modules.

> which is a pretty strong limitation.

Yes.  A couple of solutions have been mentioned already, and another
alternative is to keep this limitation, and force people to define new
groupings in this case; essentially putting the version into the name:

   // original definition
   grouping foo {
     container bar;
   }

   // next revision adds a new item to foo, but since we can't do
   // that we'll define a new grouping:
   grouping foo2 {
     uses foo;
     container baz { ... }
   }

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 1 May 2008 15:09:17 -0600

Hi -

> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Thursday, May 01, 2008 2:31 PM
> Subject: Re: [NGO] external module properties
...
> before, and dismissed as being too complicated in general.

Too complicated for what?   The only case I can think of would be if some
tool were blindly trying to re-use the same code for Arev1 and Arev2, or if some
tool failed to account for the possibility that the same identifier might show
up in different modules.  These are just two ways of describing the same
kind of broken-ness, and are easily handled by scoping (whether in one's
symbol table management or the way one generates labels for use in code).

> have to rev B just b/c A is updated.

If an update to a module can't change behaviour (where behaviour includes
signatures / interface definitions), then why does it matter?

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 1 May 2008 15:21:13 -0600

Hi -

> To: <[email-masked]>
> Cc: <[email-masked]>; <[email-masked]>
> Sent: Thursday, May 01, 2008 3:26 PM
...
...

This is an excellent example of the consequences of choosing (perhaps
unconsiously) a particular meta-model.  Consider, for example, what
happens if RPCs and notifications are associated not with "the device",
but with a particular object class.  (One possible object class is a stand-in
for "the device" which would be appropriate for those few things like
"reboot" which really do apply to the entire device.)
If the module defining a particular class imports a pre-defined notification
or RPC, versioning would work just like for anything else.  Consequently,
a "device" would no longer be limited to implementing just one version
of an RPC.

Ancient use case:  consider a "Rewind" RPC.  System has several tape drives
from various vendors, possibly from different technology generations.  Someone
updates "Rewind" to include a "energy conservation" option.  When a new drive
supporting that option in its Rewind RPC is installed, it should not require changing
the software for all the other drives.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 01 May 2008 15:26:45 -0700

> Phil Shafer <[email-masked]> wrote:

I am strongly opposed to any import or include
mechanism for a specific version of a module.
It seems hard enough to deploy one version of a standard
data model at a time.

I prefer a simple system in which the agent advertises which
version of the module is implemented, and therefore
associated with the module namespace URI.  The manager
must then decide if it can use that version of the module or not.

I don't think this has been a problem in SMIv2, and it has
not been demonstrated (yet) to be a problem in YANG.
This is a good feature to save to YANG 2.0, in the future.

I don't see how multiple sub-agents within a single agent can implement
different versions of the same module, without using different
namespace URIs for each variant.  (Maybe somebody can explain
it to me;-)

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 01 May 2008 22:24:11 -0400

>namespace URIs for each variant.  (Maybe somebody can explain

module A {
    revision 2008-01-01 { ... }
    grouping one {
        leaf foo { ... }
        leaf goo { ... }
    }
}

module A {
    revision 2008-04-01 { ... }
    grouping one {
        leaf foo { ... }
        leaf goo { ... }
        leaf super-cool { ... }
    }
}

module B {
    import A {
        revision 2008-01-01;
    }

    container zed {
        uses A:one;
    }
}

module C {
    import A {
         revision 2008-04-01;
    }
    import B { ... }

    container yancy {
        uses A:one;
    }
}

The use of A's one is a compile time issue, and the revision
on the import makes is clear what contents B and C want.
yancy will contain super-cool, which zed will not.

If there was no revision on import, would zed be forced to
contain super-cool as soon as the 2008-04-01 revision of
A is published?

If you're claiming that this wasn't a problem for MIBs,
could you please point me at a couple of MIBs that were
rev'd and the history of how successful these were?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 01 May 2008 22:36:44 -0400

Martin Bjorklund writes:
>But when it

Right, and it may be "none".  Consider that I may implement
modules that import a module that I simply don't implement.
The data/rpc/notifs in the module are not present in my implementation.

A module imports another module for four reasons:
- to reuse types
- to reuse groupings
- to augment content
- um...  er....  wait, I know there was another one

In all these cases, I want to reuse/augment a specific revision
of the module.  I may even implement both a module that imports
an older revision of the module and the most modern revision of
the module.  But the imported revision will make clear what content
I'm bringing in.

>type/grouping-only modules.

Exactly.  And if module B only used groupings/types/etc from A,
I could implement B without implementing A at all.

>groupings in this case; essentially putting the version into the name:

This becomes an impediment to readability, and readers are our
highest priority.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 01 May 2008 19:48:44 -0700

> contain super-cool as soon as the 2008-04-01 revision of

I don't really think this feature is worth the complexity.
This seems like it would be better handled in a comprehensive
module conformance section, like SMIv2.

> rev'd and the history of how successful these were?

IF-MIB, RMON-MIB, RMON2-MIB, ENTITY-MIB

This is easy in SMIv2 because the MODULE-CONFORMANCE section
can be used to specify the exact leafs in container 'zed' or 'yancy'
that are required, optional, deprecated, or obsolete.  The module
with the uses-stmt needs to specify the conformance for all
the grouping contents.  Nodes added later to grouping 'one'
are not part of the conformance for the 'zed' module.

IMO, this is also the only way 'augment-a-grouping' is ever going to
work in an inter-operable manner.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 01 May 2008 19:57:06 -0700

> work in an inter-operable manner.

Reason:  What if the new 2008-06-01 version of A has another super-cool feature
in the 'one' grouping (or anywhere else in the module) that module 'zed'
wants to use?

The 'import 2008-06-01' would break module zed because it would also pick
up the 'super-cool' leaf from version '2008-04-01', and any other
changes made in the interim.  Explicit module conformance, tied to
each module release, is the only way to maintain the flexibility
needed by agents and the accuracy needed by applications.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 01 May 2008 23:08:32 -0400

>module conformance section, like SMIv2.

Can you walk me thru such a comprehensive module conformance section
for the example I gave?

Thanks,
 Phil

---

From: Phil Shafer <[email-masked]>
Date: Thu, 01 May 2008 23:18:05 -0400

Andy Bierman writes:
>What if the new 2008-06-01 version of A has another super-cool feature

When the module owner wants to rev their module, they'll need to
explicitly update their module to handle it, rev'ing their module
to prevent the change from rippling down the import chain to
unsuspecting modules that don't have a comprehensive module conformance
section.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 03 May 2008 22:40:32 +0200 (CEST)

Hi,

"Randy Presuhn" <[email-masked]> wrote:
> Ancient use case: consider a "Rewind" RPC.  System has several tape
> drives from various vendors, possibly from different technology
> generations.  Someone updates "Rewind" to include a "energy
> conservation" option.  When a new drive supporting that option in
> its Rewind RPC is installed, it should not require changing the
> software for all the other drives.

This is an interesting problem, but I think it is separate from the
issue about importing w/ or w/o versions?  You will have the rewind
problem in a single module with a single rpc, when the module gets
updated with the new parameter.

I don't know if you're suggesting that the client should send version
information in the request (rpc rewind-1.0 vs. rpc rewind-1.1)?  I
don't think this solves the problem anyway.  IMO, the server will
implement the rpc with the new parameter, and then it will
have to translate this into native function calls to the drivers, and
in that process reject requests it cannot handle.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 03 May 2008 22:52:27 +0200 (CEST)

Hi,

Phil Shafer <[email-masked]> wrote:
> of the module.

Yes, except for augment.  What does it mean if B augments version 1 of
A, and a device implements B and version 2 of A?  IMO it is ok, since
the rules for upgrading a module ensures that no nodes are removed and
so on.

So a versioned import is strict for compile time properties like types
and grouping, but for runtime properties the upgrade rules make sure
that a later version of the module can be used.

This means that in runtime, the device implements one specific version
of a module.

> I could implement B without implementing A at all.

Right.

/martin