Re: Is DOM vs SAX a red herring?

[Andy Bierman <abierman@cisco.com>]

At 11:04 AM 5/14/2003, Larry Menten wrote:
>Keith,
>
>I also made the point that the transaction representation
>proposed in Enns does not support the expression of 
>setting multiple variables in a single atomic transaction
>unless they happen to reside in the same target subtree.

This is not the intent.  The contents of a <config> subtree
can be multiple subtrees from multiple namespaces.  The examples
are kept simple and only show one, but the protocol is
not limited to one.

BTW, I agree with the comment below that precise (and consistent)
naming is an important aspect of the data model design.  It's
probably out of scope for the netconf WG though.


>This, too, impacts the protocol.
>
>Larry

Andy




>Allen, Keith wrote:
>>
>>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
>>
>><mailto:kallen@tri.sbc.com>kallen@tri.sbc.com
>>
>> 
>>
>> 
>>
>>-----Original Message-----
>>From: Larry Menten [<mailto:lmenten@lucent.com>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 
>
>
>-- 
>Larry Menten               Lucent Technologies/Bell Laboratories
>Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA 


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