[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 8.1) <get-all>
At 06:41 AM 2/23/2004, Chen, Weijing wrote:
>I think Ed made a strong point to make the protocol clean and flexible.
>Current WG draft attaches too much weight to the semantics of a specific
>operation, E.g. get-config means "get" only so called "config" view a NE
>database, etc. With the operation attributes just proposed by Andy in the
>other thread, the filter imposed by name of operations seems superficial.
>The readability of document should not be an excuse for not to clean up the
>protocol.
The <get-config> operation exists because operators at several
venues (NANOG, RIPE, LISA, IAB NM Workshop, XMLCONF BOF) have
requested the ability to retrieve just configuration data.
The idea of decoupling all the targets from the operations
was discussed at the interim and on the mailing list. IMO,
the WG has clearly stated a preference for well-constrained
standard operations over vendor flexibility.
I don't understand the "filter imposed by name" comment.
There are various ways to edit a configuration and the
operation attribute just refines edit-config.
Please explain what needs to be cleaned up in the protocol
and the WG can discuss and decide those issues. Document
readability is important and so is specificity. Standards
that have too much vague or missing text are hard to
implement in an interoperable way.
>Weijing
Andy
>-----Original Message-----
>From: Ed Roskos [mailto:Ed.Roskos@utstar.com]
>Sent: Saturday, February 21, 2004 12:51 AM
>To: Andy Bierman
>Cc: tstoddar@utstar.com; 'Chen, Weijing'; netconf@ops.ietf.org
>Subject: 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/>
--
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/>