RE: do we need filtering or some such

["Chen, Weijing" <wchen@tri.sbc.com>]

Multi-vendor management applications is inherent complex regardless the
interface protocol as long as there are multi vendors.  And regarding
protocol, we have two issues at hands here: 1) How do we specify the target
of an operation? Outer most level (global) or inner most level (local, or
operation as attribute)? 2) Do we want the same name for the same operation
as long as semantic is the same? "create" is "create", "modify" is "modify",
not "set", etc.  For 2), we should do it.  For 1), my preference is local.




--

Weijing Chen

SBC Laboratories, Inc.

9505 Arboretum Blvd.

Austin, TX 78759

512 372 5710

wchen@tri.sbc.com


> -----Original Message-----
> From: Scott Lawrence [mailto:scott-xmlconf@skrb.org]
> Sent: Tuesday, May 27, 2003 10:06 AM
> To: netconf@ops.ietf.org
> Subject: Re: do we need filtering or some such
> 
> 
> 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/>

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