Re: [NGO] external module properties

Martin Bjorklund wrote:
> Phil Shafer <phil@juniper.net> wrote:
>> Martin Bjorklund writes:

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

>>> 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@ietf.org
> https://www.ietf.org/mailman/listinfo/ngo
> 
> 
> 

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