Re: Issue 13.3.1: the 'create' operator

[Phil Shafer <phil@juniper.net>]

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.

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.

>(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?

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

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

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

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.

Thanks,
 Phil

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