Subject: [Netconf] question about merge operation

From: [email-masked]
Date: Wed, 14 May 2014 13:56:33 +0800

Hi all,
      I have a question about merge operation.
 
      For example:
      YANG MODEL
       container foo {
           typedef priority {
               type enumeration {
                    enum first {...}
                    enum second {..}
               }
           }
 
           list source {
                key name;
                unique priority;
                leaf name {...}
                leaf priority {
                    type priority;
                }
           }
       }

     Existed data:
     <foo>
          <source>
             <name>src1</name>
             <priority>first</priority>
          </source>
          <source>
             <name>src2</name>
             <priority>second</priority>
          </source>
     </foo>

     If NETCONF server received a message like listed below:
     <rpc message-id = "101">
          <edit-config>
               <target>
                   <candidate/>
               </target>
               <config>
                  <foo>
                      <source>
                         <name>src1</name>
                         <priority>second</priority>
                      </source>
                      <source>
                         <name>src2</name>
                         <priority>first</priority>
                      </source>
                  </foo>
               </config>
          </edit-config>
     </rpc>

      The client want to exchange priorities of src1 and src2.
 
      What should the NETCONF server do?
      1.report an error?
        Because priority is unique. When set src1's priority to second, 
while existed data src2's priority is also second.
      2. return ok?
         Treat the config of two srcs as whole?
/frank
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 14 May 2014 08:54:55 +0200

Frank,

RFC 6020 section 8.3.3 specifies more details. In short, the
validation happens at commit time (this is relevant since you example
uses <candidate/> and the tree that is validated is the resulting new
configuration and not each intermediate result (if you consider
partial edits in isolation).

/js

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>