Re: same value operation attributes restriction

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

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.

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

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany

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