Re: [NGO] external module properties

[Martin Bjorklund <mbj at tail-f.com>]

Phil Shafer <phil at juniper.net> wrote:
> Martin Bjorklund writes:
> >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.
> 
> 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.

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.


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

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

_______________________________________________
NGO mailing list
NGO at ietf.org
https://www.ietf.org/mailman/listinfo/ngo