Re: [NGO] external module properties

Hi,

"Randy Presuhn" <randy_presuhn@mindspring.com> wrote:
> 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.

This is an interesting problem, but I think it is separate from the
issue about importing w/ or w/o versions?  You will have the rewind
problem in a single module with a single rpc, when the module gets
updated with the new parameter.

I don't know if you're suggesting that the client should send version
information in the request (rpc rewind-1.0 vs. rpc rewind-1.1)?  I
don't think this solves the problem anyway.  IMO, the server will
implement the rpc with the new parameter, and then it will
have to translate this into native function calls to the drivers, and
in that process reject requests it cannot handle.

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