[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 8.1) <get-all>


Ok, call me a developer, but here is how I see this issue. There are a
number of databases with which we wish to work with NetConf. A configuration
file represents a database. The current state of a network element represents
a database. An EMS replication of state data represents a database. A
candidate configuration is a database. "Config" is *not* a database. "Stat"
is *not* a database. "Running" is *not* a database. These are attributes of
the various data in a database. Grabbing the config projection of the current
state of an NE gets you the running config of the NE. Grabbing the stat
projection of a config file would get you nothing, but hey, it's what you
asked for =) Really, I don't think there is a need to explicitly
"discount" these cases in the protocol. We just don't want to paint
ourselves into a corner by defining a protocol which confuses filtering
with databases, or which imposes at the command level the inability to
define capabilities which allow various projections and depths of various
subtrees for the data in a database.

Sooooo, if we go with "simple" and restrictive commands for 1.0 to facilitate
interoperability and get our feet on the ground, let us not drop the challenge
of achieving inter-operability and flexibility with a more powerful "get"
command in the future, shall we? After all, with the power of XML to represent
arbitrarily complex queries and arbitrarily complex data, if we do no strive
to define such a standard eventually, vendors will implement their own
enterprise flavors and we may very well wind up with less inter-operability.

At 07:20 PM 2/20/2004, Tim Stoddard wrote:


There seems to be some growing concensus that the current operations are
limiting and IMHO the position that combinations don't make sense is due to
the lack of flexibility of operation attributes, e.g. defining the target
prior to the operation mandates a limited set of standardized targets to
operate against. Isn't this constraining the flexibility that xml offers and
reducing capabilities for queries, filtering, sub-tree retrieval and
locking? Shouldn't we define the operations and allow the targets to
data-model centric?



I don't agree that there is growing consensus for this.
We discussed this tradeoff of interoperability vs. flexibility
at the interim meeting.  We made a conscious decision to limit
vendor flexibility in order to increase our chances of multi-vendor
interoperability.  We want to spell out very specific configuration
related operations that all vendors must support the same.




I also find it hard to understand the position of not choosing the more
elegant solution because it would make the document harder to read.



Because the documentation would either be vague or full of
all kinds of special case sections, and we have to explain
why most of the protocol operations don't make sense on
most of the targets.  I think what we have now is quite
readable, and it's easy enough for an implementor to
figure out what needs to be done for a given operation.




I think if we are considering a get and we have a get-config then we should
invest in a robust set of operations against targets with granularity that
matches the tool sets available and doesn't restrict existing and future
data models.



We have get-config because of a specific operator requirement
to be able to retrieve configuration data without any state
information mixed in, because this state info often causes
false positives when the config is diffed against an archived
version.

I think there is WG consensus that we have the right set
of protocol operations for v1.0.  It don't see how this
set restricts data model development.




Tim



Andy





-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
Behalf Of Andy Bierman
Sent: Friday, February 20, 2004 1:27 PM
To: Chen, Weijing
Cc: netconf@ops.ietf.org
Subject: RE: 8.1) <get-all>


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




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