Re: same value operation attributes restriction

[Andy Bierman <abierman@cisco.com>]

At 12:38 PM 3/26/2004, Juergen Schoenwaelder wrote:
>On Thu, Mar 25, 2004 at 06:59:35AM -0800, Andy Bierman wrote:
> 
>> >> We can have a CLR that says only 1 operation attribute can
>> >> appear in a given element sub-tree.  Or we can say that
>> >> if multiple operation attributes appear, unpredictable
>> >> results will occur.  Or we don't have to say anything --
>> >> we can let the data model designers make choices appropriate
>> >> for that data model.
> 
>> I want to have some chance at multi-vendor interoperability.
>> If we don't specify how the protocol allows a configuration
>> database to be manipulated, then developers won't know what
>> to code.  We have a set of operations (create, modify, merge,
>> replace, delete) with well understood semantics.  I don't
>> see how this is a CLR.
>
>These two paragraphs (both written by you) do not really go well
>together in my head. I have the feeling that you simply argue against 
>me without really looking at the technical issue I have brought up. 
>
>As another last attempt to focus on the technical issue, here is
>what my main technical concerns and proposals are:
>
>a) The semantics of the <config/> parameter of the get-config operation 
>   are not defined. I consider this parameter to be a filter and
>   I prefer to use a real filter mechanism such as XPATH (or a subset 
>   for conformance) for this purpose since XPATH works generically on 
>   XML documents, is a stable and well understood standard and 
>   implementations are readily available.

The WG has decided (a few times already) that the element
sub-tree filtering is useful and we should keep it.  The
current draft does not formally define its behavior. This
will be addressed before WG Last Call.


>b) I believe that the notion of operation attributes is the wrong
>   approach. I think we are better served if operations such as
>   create/merge/replace (or verbs as I have called them) are well
>   defined operations of the netconf protocol and not something 
>   that the data model provides or some magic netconf attributes
>   to be embedded somewhere in the payload of the edit-config
>   operation (without spelling out the real details of what these
>   attributes mean which we can't do as we do not know the
>   structure of the data model).
>
>These are the two fundamental issues I have. I totally agree that
>having a mechanism to bind sequences of merge/replace/add operations 
>together is useful (and I pointed to NFSv4 compound operations as 
>an example how this can be done in a generic way at the RPC layer
>without introducing an opaque edit-config operation).

I don't see how the operation attribute is some ill-defined
magic.  I don't see how the edit-config operation is opaque.
There is a constrained set of operations.  This set is not
vendor-extensible.  

Data model designers (using the TBD data modeling language) need to
define which of these 5 operations apply to their data model.
Some operations, like create and delete, may behave differently
depending on the data model (e.g., does delete(node-X) fail
if children-of-X exist, or does it delete X and all its
children?  It depends on the data model.)


>/js

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