Ambiguity

["Allen, Keith" <kallen@tri.sbc.com>]

I'm still concerned about ambiguity in the approach described by the Enns
draft.  I've read what Phil and Rob have said about it, and I appreciate the
"assume it's always the innermost element(s) that are being operated upon"
argument, but I'm still not convinced that solves the ambiguity problem.

Consider if a device has a 1000 line XML configuration file, and I want to
change the IP address of one of the interfaces.  The Enns draft would have
me send an edit-config message with the following contents.  Presumably,
this would change only 2 lines out of those 1000 lines.


     <rpc id="102" xmlns="http://ietf.org/xmlconf/1.0/base";>
         <edit-config>
           <target>
             <running></running>
           </target>
           <test-option>test-then-set</test-option>
           <write-option>replace</write-option>
           <error-option>stop-on-error</error-option>
           <config xmlns="http://example.com/schema/1.2/config";>
             <interface name="Ethernet0/0">
                <address>
                   <ipv4>1.2.3.4</ipv4>
                   <ipv4-mask>255.0.0.0</ipv4-mask>
                </address>
             </interface>
           </config>
         </edit-config>
       </rpc>

Now, here's my question.  What if I want to instead replace the entire 1000
lines of data with the following 6 lines?  

             <interface name="Ethernet0/0">
                <address>
                   <ipv4>1.2.3.4</ipv4>
                   <ipv4-mask>255.0.0.0</ipv4-mask>
                </address>
             </interface>

How would I do that?  If it's with the same message as above, then I think
there is an ambiguity problem.  I guess as an operator I should be concerned
that by trying to change only 2 lines of data I end up wiping out 994 lines
of data, but I don't think equipment suppliers would really let this happen.
Instead, I'm more concerned that equipment suppliers will find that
preventing this from happening will be burdensome to the point that the
protocol is difficult to implement.

If instead of using the same message, your answer to "How would I do that?"
is "You can't," then I'm concerned about what else the protocol won't let me
do.

Does anybody else see a problem here?


Keith Allen
SBC Labs
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com
 


--
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/>