RE: do we need filtering or some such

["Allen, Keith" <kallen@tri.sbc.com>]

Scott Lawrence writes:
> Defining the operation as a part of the data model would, it seems to
> me, make it much more difficult to build an administrative application
> capable of supporting products from multiple vendors.  The semantics
> of 'write' might well be different for different devices (see numerous
> examples in this discussion).  Forget how one might compare 'change'
> in one device to 'modify' in another.

Making the operation an attribute on the data elements would not preclude us
from defining the "operationType" attribute and its allowable values. This
would then allow you to build a network management "browser."


Keith Allen
SBC Labs
9505 Arboretum Blvd.
Austin, TX 78759
(512) 372-5741
kallen@tri.sbc.com
 
-----Original Message-----
From: Scott Lawrence [mailto:scott-xmlconf@skrb.org] 
Sent: Monday, May 26, 2003 7:40 AM
To: Chen, Weijing
Cc: 'Wijnen, Bert (Bert)'; netconf@ops.ietf.org
Subject: Re: do we need filtering or some such

"Chen, Weijing" <wchen@tri.sbc.com> writes:

> In our approach, you can have
>
> <perform-request id="101" transaction="stop-on-error"
>                  xmlns="http://ietf.org/xmlconf/1.0/protocol";
>                  xmlns:example="http://example.com/schema/1.2";>
>   <operation id="1" target="/root">
>     <example:root>
>       <example:running>
>         <example:users operation="get">
>           <type>admin</type>

Is the fact that you left the 'example' prefix off of the 'type'
element above an oversight, or is 'type' part of the protocol rather
than the data model?

Independent of this specific example...

Defining the operation as a part of the data model would, it seems to
me, make it much more difficult to build an administrative application
capable of supporting products from multiple vendors.  The semantics
of 'write' might well be different for different devices (see numerous
examples in this discussion).  Forget how one might compare 'change'
in one device to 'modify' in another.

It is equally true that we can't, in practice, define a single set of
operations that tightly constrain the operational model of all
devices.  As has been pointed out here, the range of device size and
complexity we would like to accomodate is too great; the ability to
store and validate multiple configurations so important in high end
devices is too expensive and not really needed at the low end.

It seems to me that the enns draft was on the right track in that it
allowed for a constrained range of operational models, and provided a
way to discover at run time which a particular device supports.
Whether the particular models it proposed are the right ones or not,
the idea of defining at small set of possible modes of operation and a
way to discover which are available allows the protocol standard to
best meet the needs of applications while giving device vendors the
flexibility to choose an appropriate support cost.

--
Scott Lawrence
  http://skrb.org/scott/
  [ <lawrence@world.std.com> is deprecated ]


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

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