Re: [NGO] external module properties

Hi -

> From: "Martin Bjorklund" <mbj@tail-f.com>
> To: <phil@juniper.net>
> Cc: <randy_presuhn@mindspring.com>; <ngo@ietf.org>
> Sent: Thursday, May 01, 2008 3:26 PM
> Subject: Re: [NGO] external module properties 
...
> 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.
...

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

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