Re: Issue 13.3.1: the 'create' operator

[Andy Bierman <abierman@cisco.com>]

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.


>>(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.)
>
>Are you saying a generic "start point" for any operation?

No, I'm rephrasing this paragraph on page 19:

    Elements in the <config> subtree may contain an operation
    attribute.  The attribute identifies the point in the
    configuration to perform the operation.

BTW, the next sentence is a problem.  I think SHOULD
instead of MUST would be better (or remove the sentence).

    In the interest of simplicity, all operation attributes
    appearing within the <config> subtree MUST have the same value.


>>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
>
>This is a strong claim.  Can you support it?  I see forcing use of
>a create attribute as making more fragile code and I see no impact
>on programming practices or application development.

Some application developers have asked for this and
they think it's important.  This functionality exists
in database applications, which need a robust transaction
model.  Relying on workarounds or side effects through
the data model is not as robust.  


>>  - access control policy can be easily designed which 
>>    differentiates between 'create' and 'modify' operations
>
>The policy engine will have to look deeper into
>the data than just a cursory check of attributes,
>so I don't see a win here.

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.  


>>  - 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.
>
>Automatic instance naming?  If you want this, consider
>making it explicit in your data model:
>
>    <foo>
>       <name instance="automatic"/>
>       ...
>    </foo>
>    <goo>
>       <name instance="next-magically-created-one"/>
>       ...
>    </goo>

This ad-hoc approach is kind of like SNMP RowStatus.
A good transaction model should not be based on side effects
in the data model.  We should learn from the mistakes
of SNMP.  

>    
>>  - 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'.
>
>As I said above, there's more than the implementation cost to
>consider.  test-then-create is an odd corner case, and I don't see
>the value in making it the default behavior.  FWIW, we don't have
>it in Junoscript and no one's ever asked for it.

Test-then-create isn't that hard to implement.
In fact, it's already required for 'replace'.

Any implementation of edit-config is going to
need to identify the "insertion point" for config
data. If the operation is 'replace', then the
agent has to "clear out" all the data at the insertion
point before continuing.  If the operation is 'create'
then the agent stops and returns an error instead.
I don't see the implementation costs for 'create'
to be any harder than for 'replace'.


>Maybe this is just too far into the data model to worry with, since
>this behavior may be tied up with the style of data that's being
>manipulated.

I want to avoid an ad-hoc transaction model buried
in the data model, if at all possible. 


>Thanks,
> Phil

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