Re: Issue 13.3.1: the 'create' operator

[Andy Bierman <abierman@cisco.com>]

At 04:11 PM 2/20/2004, Mark Stahl wrote:

>On Feb 20, 2004, at 1:06 PM, Andy Bierman wrote:
>
>>At 09:04 PM 2/19/2004, Phil Shafer wrote:
>>>Andy Bierman writes:
>>>>I want to summarize the arguments for the addition of
>>>>a 'create' enum to the 'operation' attribute.
>>>
>>>As an optional attribute, I'm not opposed to this.
>>
>>I think we already have too many optional features.
>>I don't think there's a good reason to make this optional.
>>
>>>But I truly do not see the need for it.  In most cases, the app
>>>will want the hierarchy built automatically and forcing them to put
>>>a create attribute will likely just open them up to bugs when the
>>>user's config doesn't have nodes that the developer's test environment
>>>had.  Increased risk for no win.  It seems like a "no-I-really-mean-it"
>>>attribute.
>>
>>Application developers have told me that
>>NETCONF has an incomplete (or awful, or not well thought
>>out, etc.) transaction model.  One big difference between
>>what we have now (CLI scripting, SNMP), and what we need,
>>is a robust transaction model.
>
>>The win is the ability to easily distinguish a create
>>operation from a modify operation.  The issue is how
>>difficult we make it for an authorization model to
>>be created which can distinguish between different
>>operations.
>
>I'm a little new to this dicussions, so please excuse me if I'm rehashing an old topic.
>
>I tend to agree that there is good programming value in an explict "create" operation.  I presume the alternative proposal is implicit create triggered by a modify operation.  There was a proposal that under the implicit create model, an explict create could be simulated by first doing a 'get' followed by a 'modify', but this was felt to be inefficient (and not a very clean transaction model.)  So I think explicit create is necessary.
>
>Assuming we add create, what then is the semantic of modify?  I'm guessing it no longer does implicit create, so if the data to modify does not exist, the modify operation will fail.

no -- we don't have 'modify'. We have 'merge' and 'replace'.
In this case, merge and replace work exactly as before.
(Merge X with nothing or replace nothing with X -- both work).


>But this creates a similar inefficiency in the case where the user wants to either modify or create some data, which is likely to be the case much of the time?  With only those two operations, the user must first get to determine if the data exists, then either modify or create, as appropriate.
>
>So there appear to me to be three operations to be considered:
>   - modify-only
>   - create-or-modify
>   - create-only
>
>Which are being considered as part of this spec?  I'm inclined to think all three should be possible.

create-or-modify is all we have in the spec today.


>-- mark 

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