Re: Proposal to do away with netconf attributes in data model payloads

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "Gilbert Gagnon" <gagnong@nortelnetworks.com>
> To: "'Andy Bierman'" <abierman@cisco.com>; "Randy Presuhn" <randy_presuhn@mindspring.com>
> Cc: <netconf@ops.ietf.org>
> Sent: Wednesday, March 31, 2004 1:17 PM
> Subject: RE: Proposal to do away with netconf attributes in data model payloads
>

> Hello,
>
> Seems to me that XPath is just another way of specifying a component name
> (edit-path)
> [and a not so simple one at that].
...

I think a distinction from an ancient management protocol is worth keeping
in mind:
   - how one specifies the starting point (name) of a tree to be operated on
      XPATH is total overkill for this
   - how one (optionally) further qualifies the set of instances of interest
      within that that tree.  XPATH fits this nicely.

The first is the question of having a "canonical" name for an instance;
the latter is the question of scoping / filtering.

> If the data model of the payload is to be deferred to the implementation,
> wouldn't
> it be logical to do the same for the edit-path specification, for example;

Perhaps, as long as the normalization issue is resolved, since that is a question
of how the protocol encodes things, rather that one of what the data model
represents.

...
> This way, one could use an XPath expression, a component name, whatever...
> Maybe we need to define a type element or attribute to make that clear;

Agreed.

...
> Conceptually, the "where" above does not identify an "element" within the
> payload but the element in the target object model where the operation is to
> occur.
...

Yup.

Randy



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