RE: 8.1) <get-all>

[Andy Bierman <abierman@cisco.com>]

At 07:54 AM 2/20/2004, Chen, Weijing wrote:
>I would concur Tim's view.  <get>, <edit>, <delete>, <copy>, <create> with
>the proper target: config (default), named config, state, etc.

I agree that this approach is more elegant than what
we have now, but IMO it would make the document harder
to read if we used this approach.  There are many
combinations that either don't make sense (e.g.,
create, edit, delete or copy state) or are not supported 
in v1.0 (e.g. create user-db).

As for <get>, it is the same as SNMP GET -- a get all
operation.  <get> will return everything in the
requested subtree(s), whereas <get-config> will only
return elements which are deemed to be configuration
data instead of state data.  It's still a data-model
language detail as to how an element is deemed to
be configuration data.




>Weijing

Andy





>-----Original Message-----
>From: Tim Stoddard [mailto:tstoddar@utstar.com] 
>Sent: Thursday, February 19, 2004 12:16 PM
>To: 'Margaret Wasserman'; 'Andy Bierman'
>Cc: netconf@ops.ietf.org
>Subject: RE: 8.1) <get-all> 
>
>All,
>
>I have to ask if we have get-config, edit-config, delete-config,
>copy-config, and these are all relative to a target (running or named
>config) then what is the target for 'get'? Is this implicitely 'state'
>information, are there potentials for using get in terms of filtering
>(subtree retreival). It sounds like we are starting to define operators
>against the data rather than a container of the data. If this is the case
>won't we have to address the create issue as was brought up on the list and
>then the mod and delete issue?
>
>If this is the path we are going down then the original operations appear
>restrictive, why have get-config when you can have get <target>, edit
><target>, delete <target> where target can be a container like the reserved
>'running-config' or a file, or a data element.
>
>I didn't open this can of worm soup but I have to stir the pot.
>
>thanks,
>
>Tim
>
>-----Original Message-----
>From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
>Behalf Of Margaret Wasserman
>Sent: Monday, February 09, 2004 10:25 PM
>To: Andy Bierman
>Cc: netconf@ops.ietf.org
>Subject: Re: 8.1) <get-all>
>
>
>
>I agree that <get> would be better.
>
>Margaret
>
>At 12:37 PM 2/9/2004 -0800, Andy Bierman wrote:
>>Hi,
>>
>>I think we should change the name of this operation
>>from <get-all> to a simple <get>.  This aligns better
>>with terminology and behavior of a get command in
>>other protocols.
>>
>>I know the status says this is closed, but <get-all>
>>is redundant and non-intuitive.  We should fix this
>>before it's too late.
>>
>>Andy
>>
>>
>>--
>>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/>
>
>
>--
>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/>
>
>
>
>
>--
>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/>
>
>--
>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/> 


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