Subject: Re: edit-config

From: noe <[email-masked]>
Date: Tue, 14 Dec 2004 18:20:53 +0100

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.

Thank you,

Noe

王罕 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 [email-masked] with
>     the word 'unsubscribe' in a single line as the message text body.
>     archive: < http://ops.ietf.org/lists/netconf/>
>
> ------------------------------------------------------------
> Wang Han
> [email-masked] <mailto:[email-masked]>
> Research Center of Network Technology
> Nanjing University of Posts and Telecommunications
> ――――――――――――――――――――――――――
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 14 Dec 2004 09:55:31 -0800

>you say we are either replacing or creating but not merging? I am still

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.  

>Noe

Andy

>Íõº± wrote:
>
>> noe£¬
>> ¡¡¡¡I think if there HAS been an interface named "ethernet0/0" in the
>> ======== 2004-12-14 01:21:28 noe said£º =====
>>
>>     Hello All,
>> ¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª¡ª
>>
>
>
>--

---

From: noe <[email-masked]>
Date: Wed, 15 Dec 2004 11:33:06 +0100

Thanks ,it is  much clearer now.

---

From: noe <[email-masked]>
Date: Wed, 15 Dec 2004 17:13:29 +0100

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?

thanks.

noe wrote:

>> Andy :
>> 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£¬

---

From: Andy Bierman <[email-masked]>
Date: Wed, 15 Dec 2004 08:28:32 -0800

At 08:13 AM 12/15/2004, noe wrote:
>  "If the configuration data exists, an <rpc-error> element is returned with an <error-tag> value of DATA_EXISTS."
>

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.

Andy

>>>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£¬