Re: 8.1) <get-all>

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

On Wed, Feb 25, 2004 at 09:29:32AM -0800, Randy Presuhn wrote:
> 
> ...
> > I am not as concerned with get-config as a standard operation, the premise
> > of this discussion is get-all, and the lack of get + filter. From a
> > conventions point of view if we are going to define operations with rigid
> > filters and we want to extend netconf in the future then we may have to
> > define get-state (which is where this started), and with the addition of
> > asynchronous notification probably get-alarm, get-event, get-log. Until then
> > we are painted into the corner of get-config and dump. If the convention is
> > get + filter the flexibility is in tact and the standard can mandate
> > filtering that is interoperable and the vendors are free to extend that
> > filtering for specific data models.
> 
> Agreed, though I'd express more like get(target, filter) to emphasize that
> there are (at least) two parameters at the API level.

While I understand the idea and the motivations from a purist point
of view, we have to acknowledge that the distinction between all data
and configuration data seems to be essential for operators. Perhaps
putting only this distinction into netconf 1.0 might turn out later
after a few years to be problematic (but first netconf has to become 
a success for this to be an issue at all), I think it is better to 
address this requirement as it stands now since it allows to move
forward quickly with a good chance of interoperability.

Achieving get-config with a magic filter or some other naming details
requires to worry much more about the data models and their naming
system. And if there is no clear specification how to distinguish
configuration from other data, we end up like SNMP where in principle
we have a powerful mechanism (contexts) to realize such an distinction
in a nice way, but there is no agreement on how to use the mechanism
for this purpose (and of course not in an interoperable way).

[My lessons from several years in the IETF is that indeed solutions
 that address clear specific requirements in simple direct ways are 
 at the end more successful, even if the maintenance afterwards may 
 be more complex and costly.]

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>