Re: Issue 13.3.1: the 'create' operator

[Mark Stahl <Mark.Stahl@utstar.com>]

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.

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.

-- mark 





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