[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issue 13.3.1: the 'create' operator



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



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