Re: 8.1) <get-all>

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Tim Stoddard" <tstoddar@utstar.com>
> To: "'Phil Shafer'" <phil@juniper.net>
> Cc: "'Randy Presuhn'" <randy_presuhn@mindspring.com>; <netconf@ops.ietf.org>
> Sent: Wednesday, February 25, 2004 8:42 AM
> Subject: RE: 8.1) <get-all>
>

...
> 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.

> Spending more time on filtering which in turn requires more time on partial
> or sub-tree locking is IMHO worthwhile. Exercising the full potential of
> complex joins enables robust program development like provisioning wizards

Agreed, though the WG seems intent on avoiding this path.

> using web services that may query partial config and state information for
> rendering a circuit provisioning form or other forms. I fail to see where
> the specificity of get-config combined with get-all provide the specificity
> to enhance such programming. Parsing the dump for a few state attributes and
> the config for a subset of data elements in multiple sub-trees to render
> such forms would be painstaking, bandwidth consuming, parser intensive, and
> potentially NE processing intensive. get + filtering is the answer IMHO.
...

Agreed.
However, it really begs the question of what filters look like, which in turn
is highly dependent on the meta-model.

Randy



--
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/>