Re: Transactions and operations

[Larry Menten <lmenten@lucent.com>]

Keith,

What they have in common is that they both clearly
specify the target of the operation.  They both can support
explicit expression of a delete operation, while the Enns spec cannot.
That was the point of the example.  

The transaction could be required to be atomic.  Or not.  I believe that
that should be an option specified within the transaction.

When a failure occurs, you need to know where the transaction 
failed.  The opId provides the reference to be used in the response
message.
Also, you want to be able to specify what the behavior is to be upon
failure.
The request might not be verify-then-set.  It might be process until
the first failure,
or process all that can succeed.  IMO, we want to be able to express
all of these.
So, for each element of the transaction, you might need to provide the
status.

It is quite simple to parse a simple subset of XPath without applying a
complete
XPath parser.  The answer is yes.  A parser for a subset of XPath used
simply to
specify the unique keys of a configuration target is very easy to write
and very small.

Allen, Keith wrote:

Larry,

 

Your latest example (included below) seems different than your first proposal. 

 

        <addRequest opId="3" select="/root/configuration/protocol/ospf">
            <area id="4">

            ...

            </area>

        </addRequest>

is different from:

 

      <area id="4" op="addRequest">

      ...

      </area>

 

I thought something along the lines of the latter was what you were proposing.  Sorry if I misunderstood.

 

Just to make sure I understand this message, your example would:

            Delete OSPF area 0

            Delete OSPF area 3

            Add a new OSPF area 4 with one interface (ge-2/2) in it

            Modify interface ge-1/5 in OSPF area 2 to have a dead interval of 40

            Add a new IS-IS area 5

            Add an LSP named "to-SFO" to OSPF area 1 with a metric of 15

            Change the metric of the LSP named "to-SFO" in OSPF area 6 to 20

 

All as a single atomic transaction.

 

Your use of X-Path is intriguing.  I think the conventional wisdom has been that X-Path would be too complicated to implement on an embedded system.  It is cleaner, though, than the approach this group has been pursuing, which would be to include the parent elements in the XML payload.  Have you been able to implement X-Path on a small embedded system?

 

Are there semantics associated with the opID attributes in your example?  Since it seems to be an atomic transaction I assume they do not imply order of execution.  Why are they needed?  Same with the transaction IDs.

 

Keith Allen

SBC Technology Resources

9505 Arboretum Blvd.

Austin,TX 78759

(512) 372-5741

kallen@tri.sbc.com

 

 

-----Original Message-----
From: Larry Menten [mailto:lmenten@lucent.com]
Sent: Tuesday, May 13, 2003 3:08 PM
To: netconf
Subject: Re: Is DOM vs SAX a red herring?

 

Keith,



To represent the transaction in multiple parts the target has to be identified.

We have used XPath expressions for this purpose as in the following example:



<transaction id="29">

        <deleteRequest opId="2" select="/root/configuration/protocol/ospf/area[@id='0']" />

        <deleteRequest opId="1" select="/root/configuration/protocol/ospf/area[@id='3']" />

        <addRequest opId="3" select="/root/configuration/protocol/ospf">

            <area id="4">

                <interface id="ge-2/2">

                    <authentication-key>

                        <keyname>gargoyle</keyname>

                        <key-id>3</key-id>

                    </authentication-key>

                    <metric>1</metric>

                    <hello-interval>10</hello-interval>

                    <dead-interval>40</dead-interval>

                    <retransmit-interval>10</retransmit-interval>

                    <transit-delay>5</transit-delay>

                </interface>

            </area>

        </addRequest>

        <addRequest opId="4" select="/root/configuration/protocol/ospf/area[@id='2']/interface[@id='ge-1/5']">

            <dead-interval>40</dead-interval>

        </addRequest>

        <addRequest opId="5" select="/root/configuration/protocol/is-is">

            <area id="5"></area>

        </addRequest>

        <addRequest opId="6" select="/root/configuration/protocol/ospf/area[@id='1']">

            <label-switched-path id="to-SFO">

                <metric>15</metric>

            </label-switched-path>

        </addRequest>

        <replaceRequest opId="7" select="/root/configuration/protocol/ospf/area[@id='6']/label-switched-path[@id='to-SFO']">

            <metric>20</metric>

        </replaceRequest>

    </transaction>

-- 
Larry Menten               Lucent Technologies/Bell Laboratories
Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA