Re: more flexible write-option alternative

[Larry Menten <lmenten@lucent.com>]

Keith,

Since the attribute would reside in a separate namespace,
I would argue that it is not part actually of the definition of the
managed elements that are yet to be defined.  It is true
that the schema extensions for the new elements might have to
accommodate the presence of the attribute for the element.  However,
the spec is already placing some rather arbitrary requirements
on the undefined elements already, such as the avoidance of
attributes and the creation of elements to group members of arrays.
Requiring support for the op attribute is very mild in comparison.

As it stands, the protocol is in some ways less functional than SNMP because
it limits what can be expressed as an atomic operation.

I would argue that it is critically important that the protocol  be able to
flexibly express the modification of multiple variable values in a single
atomic operation.  IMO, the goal of greater expressiveness in managing
devices is a primary goal of this effort.

Larry


Allen, Keith wrote:

> Larry Menten writes:
>
> IMO, the write-option tag should be an attribute of the target element that
> is to undergo the operation.
> ...
>
> I think a problem with this would be that the write-option tag would have to
> be an attribute of elements that are not defined by this group and will not
> be defined by this group.  The write-option tag would be mixing the protocol
> used to transfer configuration data in with the configuration data itself.
>
> 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: Thursday, May 08, 2003 12:05 PM
> To: xmlconf
> Subject: more flexible write-option alternative 
> In the Enns draft, a global write option is proposed that is expressed
> as a direct child of the <edit-config> element.  IMO, the write-option
> tag should be an attribute of the target element that is to undergo the
> operation.  This makes the target of the operation explicit, simplifies
> the processing of the command, and allows multiple operations on the
> tree to be expressed in a single atomic transaction.
>
>
> Rather than:
>
> <edit-config>
>    <write-option>
>         merge
>    </write-option>
>    <ospf>
>         <id>135.104.52.1</id>
>         <area>
>              <id>0</id>
>              <interface>
>                  <id>135.104.52.3</id>
>                   <helloInterval>10</helloInterval>
>               </interface>
>          </area>
>     </ospf>
> </edit-config>
>
> ... followed by three more <edit-config> statements of similar size, we 
> should have
> the following single configuration transaction:
>
> <edit-config>
>    <ospf id="135.104.52.1">
>         <area id="0">
>              <interface id="135.104.52.3" op="merge" helloInterval="10"/>
>              <interface id="135.104.54.2" op="overwrite" 
> helloInterval="10" deadInterval="40"/>
>         </area>
>         <area id="1" op="overwrite">
>               <interface id="135.104.50.2" helloInterval="10" 
> deadInterval="40"/>
>         </area>
>      </ospf>
> <edit-config>
>
> This is very clear to express and, in this example, less disruptive of 
> the operation
> of the target protocol implementation.  We have used this approach 
> extensively
> in the context of routing protocols and related subsystems after having 
> explored a
> representation similar to the one proposed in the Enns draft.  We have 
> found that
> placing the operation with the target element is a much more powerful 
> approach.
>
> Larry
>
>
>  
--
Larry Menten               Lucent Technologies/Bell Laboratories
Phone: 908 582-4467        600 Mountain Avenue, Murray Hill, NJ  07974 USA 


--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>