Subject: [Netconf] 4741bis (011) - duplicate edit-config modifications

From: Martin Bjorklund <[email-masked]>
Date: Mon, 09 Nov 2009 13:13:25 +0100 (CET)

Hi,

This issue was brought up in the NETCONF session today.

The problem is what happens in the following case, when mtu is a leaf:

   <if:interface nc:operation="merge">
     <if:name>eth0</if:name>
     <if:mtu>100</if:mtu>
     <if:mtu>1500</if:mtu>
   </if:interface>

The proposal was that the result is implementation specific, (just as
in SNMP when the same variable occurs twice in a SET PDU).

But Wes and Balazs argued that this a data model issue, and thus does
not belong in 4741bis.  For example, if mtu were a leaf-list, the XML
above is perfectly fine.

I will close this issue for 4741bis, unless noone objects.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 09 Nov 2009 23:09:21 +0900

> not belong in 4741bis.  For example, if mtu were a leaf-list, the XML

It was me, not Balazs. :-) I didn't agree with the formulation that the
result is implementation specific - every NETCONF implementation should
pass this data to the "Content Layer" because it is outside its scope. 

I don't know why this example is so specific - the same could be said
about an edit-config that uses unknown elements. It should suffice to
say that NETCONF doesn't care about data contents of the PDUs as long as
they satisfy some minimum requirements on well-formedness.

Lada

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
-- 
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Mon, 09 Nov 2009 08:52:12 -0800

> they satisfy some minimum requirements on well-formedness.

I think this needs to be left implementation-specific,
just like SNMP.  The PDU above may not be interpreted
as a request to create 2 mtu leafs.  It is more likely
the server will see 2 separate attempts to merge a value
into the mtu leaf.

The only standard approach that makes sense to me is to
declare the order to be significant, and last one wins.
However, I prefer to leave this corner-case as an
implementation-specific matter.  The server needs to
preserve order on 'ordered-by=user' lists/leaf-lists.
We should not require any more than that.

>> I will close this issue for 4741bis, unless noone objects.

Andy