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