[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: edit-config
At 08:13 AM 12/15/2004, noe wrote:
>Another question about edit-config:
> What about the difference between a "create" and "merge" , is it
>just that we send back an information encapsulated in an "rpc-error"?
>
> Page 28 , paragraph about create:
> "If the configuration data exists, an <rpc-error> element is returned with an <error-tag> value of DATA_EXISTS."
>
> From what Andy says below ,I interpret it this way. So why do we
>have both "merge" and "create" if they are doing the same job?
they don't -- it just looks that way for the derivative case in
your example. Create fails if the data already exists. Merge does not.
>thanks.
Andy
>noe wrote:
>
>>Thanks ,it is much clearer now.
>>
>>
>>Andy Bierman wrote:
>>
>>>At 09:20 AM 12/14/2004, noe wrote:
>>>
>>>
>>>
>>>>Hello Han,
>>>>
>>>>Yeah the result will be always setting the MTU to 1500 but in the case
>>>>you say we are either replacing or creating but not merging? I am still
>>>>confused on that.
>>>>
>>>
>>>Andy :
>>>
>>>The default operation is merge. In your example, interface "Ethernet0/0"
>>>would be created if it didn't already exist. In this derivative case,
>>>merge and replace have the same result (i.e., "merge X with nothing"
>>>is equivalent to "replace nothing with X").
>>>
>>>If interface "Ethernet0/0" already existed, then only the "mtu" attribute
>>>would be affected by this merge operation. Since this attribute
>>>is a scalar, the behavior is the same for merge or replace (i.e., replace).
>>>Whether the "mtu" attribute existed or not, after the merge succeeds,
>>>it exists and has the specified value "1500".
>>>
>>>The difference between merge and replace is only apparent for non-scalar
>>>attributes, such as an ACL list. Merge will add entries that don't
>>>already exist and modify entries which do exist. Replace will remove
>>>all existing entries before adding the new ones (if any).
>>>The merge order is dependent on the data model. The NETCONF Data Modeling Language (TBD) will need to provide mechanisms to specify merge behavior.
>>>
>>>
>>>>Thank you,
>>>>
>>>>Noe
>>>>
>>>
>>>
>>>Andy
>>>
>>>
>>>
>>>
>>>
>>>
>>>>Íõº± wrote:
>>>>
>>>>
>>>>
>>>>>noe£¬
>>>>>¡¡¡¡I think if there HAS been an interface named "ethernet0/0" in the
>>>>>target configuration, the operation
>>>>>will set its MTU to 1500, if not, the operation will create a Element
>>>>>named "Ethernet0/0" in the target
>>>>>configuration, and then set its MTU to 1500.
>>>>>so, it's result will always be to setting the MTU value to 1500 in the
>>>>>configuration, just as what the prop has said.
>>>>>Best Regards
>>>>>Wang Han
>>>>>======== 2004-12-14 01:21:28 noe said£º =====
>>>>>
>>>>> Hello All,
>>>>> I couldn't understand something about "operation" attribute in
>>>>> edit-config request,revision 4 page 28. That is, when there is no
>>>>> "operation" attrb. we should merge the data with the "target file"
>>>>> from the
>>>>> corresponding level. That is a default behaviour. However in the
>>>>> example after the explanation , if i am not wrong ,we are again
>>>>> replacing the value of "mtu" under the interface element.
>>>>> Shouldn't we
>>>>> here add a new interface into the taget configuration ?
>>>>> "If the operation attribute is not specified, the configuration
>>>>> is merged into the configuration datastore.
>>>>> The operation attribute has one of the following values:
>>>>> merge: The configuration data identified by the element
>>>>> containing this attribute is merged with the configuration
>>>>> at the corresponding level in the configuration datastore
>>>>> identified by the target parameter. This is the default
>>>>> behavior.
>>>>> "
>>>>> Example:
>>>>> Set the MTU to 1500 on an interface named "Ethernet0/0" in the
>>>>> running configuration:
>>>>> < rpc message-id="101"
>>>>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>> < edit-config>
>>>>> < target>
>>>>> < running/>
>>>>> < /target>
>>>>> < config>
>>>>> < top xmlns="http://example.com/schema/1.2/config";>
>>>>> < interface>
>>>>> < name> Ethernet0/0< /name>
>>>>> < mtu> 1500< /mtu>
>>>>> < /interface>
>>>>> < /top>
>>>>> < /config>
>>>>> < /edit-config>
>>>>> < /rpc>
>>>>> < rpc-reply message-id="101"
>>>>> xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>>>>> < ok/>
>>>>> < /rpc-reply>
>>>>> --
>>>>> 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/>
>>>>>
>>>>>------------------------------------------------------------
>>>>>Wang Han
>>>>>y030737@njupt.edu.cn <mailto:y030737@njupt.edu.cn>
>>>>>Research Center of Network Technology
>>>>>Nanjing University of Posts and Telecommunications
>>>>>¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª
>>>>>
>>>>>
>>>>
>>>>--
>>>>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/>