Re: [NGO] external module properties

Hi,

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

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.

> >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.
> 
> Exactly.  And if module B only used groupings/types/etc from A,
> I could implement B without implementing A at all.

Right.

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