Re: Is DOM vs SAX a red herring?

Larry Menten writes:

> In my opinion, there is a very big flaw in a representation that
> does not provide for precise naming of the target of the operation.

I agree. In fact, I brought this issue up a few weeks ago. It's a tough one, though. Having been involved in network management standards work before, I would estimate that 50% of the time of a network management standards group gets spent on naming-related issues. I think this group was hoping to put those issues in the hands of the information model developers. I'm concerned, though, that it impacts the protocol and needs to be addressed here.

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: Wednesday, May 14, 2003 9:23 AM
To: netconf
Subject: Re: Is DOM vs SAX a red herring?

Keith,

In my opinion, there is a very big flaw in a representation that
does not provide for precise naming of the target of the operation.
You cannot, for example, request that a particular interface instance
be deleted. Instead, you must request the replacement of the parent
element with a new configuration that omits the child. This requires that
you acquire the complete config of the parent element and requires that
you include that complete config, without mistake, in the transaction request.
So what happens if someone has created an interface between when you
acquired the config of the area and formulated your request to replace the
config? You wipe out the interface config without even knowing that you did
so. That, to my mind is a serious flaw.

Another flaw, to my mind, is that it is not clear what is being requested. Is it the
creation of an OSFP instance and an OSPF area and an interface and an MD5 key? Or is it
just the creation of just the key? If you make a mistake in providing the ID of the OSPF instance
you will accidentally create an instance that you did not intend to create. It is far
to easy to make a serious configuration mistake.

In my opinion, the XPath spec of the target, or the nested elements that
lead up to the op="delete", specify the target and are not part of the target
configuration data. The transaction that operates on the device configuration
should be distinguished from what you will get from a request to serialize
the configuration state. (get-config) Doing configuration by merging
or overlaying config trees seems simple on the surface. But it is a bad model for
device configuration. If you cannot safely request that, for example, an interface be deleted
without risking the silent destruction of someone else's configuration changes, the
design is flawed.

Larry

--

Larry Menten               Lucent Technologies/Bell Laboratories

Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA