Re: Issue 13.3.1: the 'create' operator

[Andy Bierman <abierman@cisco.com>]

At 03:47 PM 2/19/2004, David T. Perkins wrote:
>HI,
>
>One question on create of an object where the instance is not provided...
>Consider a create that is accepted and processed, but before the
>requester can get back the response, the transport connection is
>dropped. Is there any special cleanup? Might the instance that got
>create get "lost"?

The proper configuration change logging should be enough to 
handle this case.


>Is create used to add an attribute that is optional for an object
>instance?

huh?

Create is the same as merge or replace if the instance
doesn't exist yet.  Create will fail if the instance does
exist.  Since instance creation is data-model specific,
instance creation without specifying the instance ID
is also data-model specific.


>Also, the create sort of backs into the issue of multi-valued items.
>Is a create used to add another value or is this done with a modify
>operation, and likewise is a modify used to remove one or more
>values from a multi-valued item.

The data model defines how instances are identified.
I would use create to add new items and delete to remove
them. 


>Finally, are deletes explicit? If so, does the removal of the last
>value of a multi-valued item result in the item being deleted?

This is a good question.  Should it be a warning or an
error or a no-op for requests to delete something that
doesn't exist? 

Andy




>At 01:51 PM 2/19/2004 -0800, Andy Bierman wrote:
>>Hi,
>>
>>I want to summarize the arguments for the addition of 
>>a 'create' enum to the 'operation' attribute.  (This 
>>attribute is placed in an element within the user data 
>>model to identify the start point of an edit-config 
>>operation.  See sec. 5.2.)
>>
>>The are important architectural advantages for an
>>explicit create operation instead of implicit create
>>operation:
>>
>>  - better programming practice; makes application development
>>    easier and allows for more robust code
>>  - access control policy can be easily designed which 
>>    differentiates between 'create' and 'modify' operations
>>  - creation without supplying an instance ID
>>    - Sometimes the application doesn't care what the
>>      actual instance ID is (e.g. loopback interface
>>      or an RMON history control entry) and just wants
>>      the next available ID.  An explicit create operation
>>      allows for data models which provide this feature.
>>      An implicit create operation would prohibit data models
>>      from providing this feature.
>>  - same programming costs; the 'create' operator would only
>>    require a few additional lines of code beyond the already 
>>    mandatory support for 'merge', 'replace', and 'delete'.
>>  - the work-around (get followed by set) does not address
>>    all the benefits of an explicit create operation.  It
>>    will also degrade transaction performance, which is
>>    very important for provisioning applications.
>>
>>Andy
>regards,
>/david t. perkins 


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