Re: Explicit and unique naming of configuration target

[Andy Bierman <abierman@cisco.com>]

At 02:47 PM 5/22/2003, Larry Menten wrote:
>Margaret Wasserman wrote:
>
>>
>>Hi Larry,
>>
>>At 03:23 PM 5/22/2003 -0400, Larry Menten wrote:
>>
>>>Consequently, a request to add, for example, an MD5 key to what
>>>you intend to be an existing interface instance within an OSPF area might
>>>end up causing the creation of an OSPF instance, the creation of
>>>an OSPF area, and the creation of an OSPF interface instance, and
>>>the creation of the desired MD5 key.  There is no way to express that
>>>you only wish to create an MD5 key and you will not know
>>>from the response that instead of a simple operation you have executed
>>>a complex one.  I believe that characteristics  like these are undesireable.
>>
>>
>>In your example above, I don't understand how it could
>>be valid to add an MD5 key to an OSPF instance that doesn't
>>exist...
>
>To my mind, you should be able to express the desire to add an MD5 key
>to an existing interface instance and have the request fail if the instance does not
>exist.

This is a trade-off of complexity in the device vs. complexity
in the client.  I don't think locking is a big factor here either.
Why would the client want an MD5 key added to an interface,
but not want the interface to be created, if necessary?  
This seems to be optimizing for a corner-case.  The client should 
check if the interface exists if it's that important.   I don't 
think it's unreasonable for the client to know the state of the 
device before modifying the device config.  I view the 'add MD5 key' 
as a modify, not an add.


>That is not what the draft proposes.  The draft proposes that the device will
>attempt to create anything that is named in the tag hierarchy that does not already
>exist.  The expression to create the OSPF instance, the OSPF area, the OSPF
>interface, and the OSPF MD5 key is exactly the same as the  expression to
>merely add an MD5 key.  Please feel free to give me a call.  Might be more efficient
>and give me a better idea of your thoughts on the matter.

I don't think the xmlconf draft says anything specific about 
creating subordinate objects if the higher layer objects do not
exist.  This is very data-model and implementation-specific.

 From section 1.1:
   The content layer is outside the scope of this document.  Given the
   current proprietary nature of the configuration data being
   manipulated, the specification of this content will depend on the
   device vendor.  It is expected that a separate effort to specify a
   standard data definition language and standard content will be
   undertaken, independent of this effort.

With current CLI configuration, devices often impose creation
order and other restrictions on config manipulation.  I don't
see these restrictions going away just because the API is
XML-based.


>Larry

Andy


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