[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: same value operation attributes restriction
On Fri, Mar 26, 2004 at 01:15:33PM -0800, Andy Bierman wrote:
> 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.
I must have missed these several WG calls for concensus on the mailing
list. But even then, it strikes me that "the WG has decided (a few
times already) that the element sub-tree filtering is useful" without
(a) having a specification of the behavior and (b) knowing what the
data model serialization in XML will look like.
Whatever you use to gauge consensus, please count me in the group of
people who strongly disagree with this (not even specified) approach
of sub-tree filtering without any understanding how key data model
features such as instance identification work.
> >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).
[...]
> 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.)
I fail to see why it is useful to define verbs such as create/delete and
so on in the protocol without saying what they really mean and how they
are going to be used and to expect that the data model provides the details.
If create/delete/... is outside the scope of the protocol, then leave it
completely up to the data model to define these things. If, however,
create/delete/... is in the scope of the protocol, then I expect that
the details are worked out up to the level that people can create
interoperable implementations.
We obviously disagree on this point as well and so please count me in
the group of people who stronly disagree with this design when you
gauge consensus.
/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/>