Re: [NGO] external module properties

[Andy Bierman <[e-mail]>]

Andy Bierman wrote:
> Phil Shafer wrote:
>> Andy Bierman writes:
>>> 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;-)
>> 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?
>>
> 
> 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.
> 
>> 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?
>>
> 
> 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.
> 

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.

>> Thanks,
>>  Phil
>>
> 

Andy

_______________________________________________
NGO mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ngo