Re: do we need filtering or some such

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

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.

"Allen, Keith" <kallen@tri.sbc.com> writes:

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

I agree - my concern is with where the operations are defined (and how
uniformly they are defined across implementations).  

It seems to me that naming and other selection operations are
inextricably bound to the data model of the managed element.  For
example, I don't see how we could define a single naming scheme that
would encompass both an XML data representation and a CLI script.

I do think that we can define a way to express a set of operations
such that a management application can rely on them being understood
in a reasonably uniform way by different devices.  To take an example
from the enns draft model - if a device supports modification and
validation of configurations other than the running configuration,
then a management application can exploit that to make changes in a
more controlled way.  If, on the other hand, we were to allow each
device to have its own definition of what 'modify' means (which is
unavoidable if the operations are defined by each data model), then I
don't see how the author of a multi-vendor management application has
any chance.

This problem overlaps with the issue of how to deal with that of how
to deal with multiple managers.  Operations may need to be defined
such that they can be qualified to accomodate support for preventing
or at least detecting conflicts.  Again, large and small devices may
have conflicting needs here.  Large complex devices may require the
ability to partition conflict management, because enabling partitioned
simultaneous management by different parties can be a product
requirement.  Small ones might well find a scheme that limits changes
to a single manager acceptable (no particular mechanism about how to
do this should be inferred at this point), because the memory overhead
and code complexity of the partitioning would be prohibitive.

Again, I think that the netconf standard should define a (small) range
of capabilities.  The device should be able to express to a manager
what set of capabilities it supports - whether those are combined into
the definition of the operations or orthogonal to them is a good topic
to explore.  Supporting an operation that returns a netconf-standard
capabilities description should be one thing that all
netconf-conformant devices have in common.

I'm not (now) suggesting it as a solution, but if you're familiar with
WSDL, I'd suggest that WSIL (Web Services Inspection Language) offers
and interesting analogue from that world.

http://www-106.ibm.com/developerworks/webservices/library/ws-wsilspec.html

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