RE: 8.1) <get-all>

["Tim Stoddard" <tstoddar@utstar.com>]

I am not confused and there is a group of folks (probably a minority with
consensus among themselves) who are concerned that this is a real issue. I
will refrain from using the word consensus if that smooths the discussion.

As for the programmers point of view I believe there are two camps, one that
wants netconf for scripting and one that wants netconf for programming. We
heard from vendors and carriers at the interim that this function is
constraining from the API function perspective, in particular from the data
model perspective. Obviously there was also a group (larger) who agreed with
the current get-config and the get-all didn't really get any play until the
get-state issue was raised.

The get-all in this case would return an entire configuration including
state, and without appropriate filtering all events, alarms, log entries
that could be present in a running datastore. In the case of large scale
devices like multi-service switches this can easily exceed 100's of
thousands of data elements/attributes.

get-config is a constrained method of filtering where get is the operator
and config is the filter, if we only have get-all and get-config we are
constraining the ability to filter out of the gate.

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.

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

thanks,

Tim

-----Original Message-----
From: Phil Shafer [mailto:phil@juniper.net]
Sent: Wednesday, February 25, 2004 10:12 AM
To: tstoddar@utstar.com
Cc: 'Randy Presuhn'; netconf@ops.ietf.org
Subject: Re: 8.1) <get-all>


I'm just confused about whether you are saying you see a group of
folks who are concerned about an issue or whether there's a real
concensus that this is an issue.  I see some discussion but not a
consensus.

Anyway, I see the issue as more style than anything.  As a programmer,
I see the rpc methods as functions in an API.  A get_config()
function sits well with my view.  Putting everything under a single
get() function doesn't.  I think it fits better with the netconf
idea of solving real problems in real terms, rather than generic
ones in generic terms.  We want to deal with configuration in a
specific sense, just as we deal with running configurations and
candidate configurations as specific datastores with specific,
well-known behaviors.

This also fits with the design goal that the API should say what
it means, rather than allow important operations to happens as
side-effects of generic operations.  For example, we have a 'commit'
operation, not a commit operation that happens as a side-effect of
copying files.

The unix syscall API could have been reduced to the simple, generic,
easily documentable function 'syscall()', but think of the utility
that would have been lost.  Specificity wins for developers on
both sides of the netconf.

Thanks,
 Phil


P.s.: And trust me, I never pick on _anyone's_ speling. ;^)



"Tim Stoddard" writes:
>Phil,
>
>see 2, add the word growing before it. Then show me a political group
>without a single dissenter, see 1.
>
>
>1. An opinion or position reached by a group as a whole: ?Among political
>women... there is a clear consensus about the problems women candidates
have
>traditionally faced? (Wendy Kaminer). See Usage Note at redundancy.
>
>2. General agreement or accord
>
>sorry about the spelling if that was your point.
>
>thanks,
>
>Tim
>
>-----Original Message-----
>From: Phil Shafer [mailto:phil@juniper.net]
>Sent: Wednesday, February 25, 2004 9:24 AM
>To: tstoddar@utstar.com
>Cc: 'Randy Presuhn'; netconf@ops.ietf.org
>Subject: Re: 8.1) <get-all>
>
>
>"Tim Stoddard" writes:
>>I want to re-emphasize that I believe there is growing concensus (I never
>>said majority) that understands ....
>
>Huh?
>
>xhttp://dictionary.reference.com/search?r=2&q=consensus
>
>Thanks,
> Phil
>


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