Re: do we need filtering or some such

[Scott Lawrence <scott-xmlconf@skrb.org>]

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