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