[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: I-D ACTION:draft-weijing-netconf-interface-00.txt
>>>>> Allen, Keith writes:
Keith> What is your feeling here? When both the CMIP and SNMP folks
Keith> decided that the ASN.1 data definition language alone was not
Keith> enough, they each developed their own object definition
Keith> language of sorts. I have heard that the CMIP folks debated
Keith> quite a bit over the need to support the ability to define and
Keith> invoke methods on objects but ended up supporting the ability
Keith> with the M-Action capability. I don't know if the SNMP folks
Keith> debated it but they didn't end up supporting a way to define
Keith> and invoke methods on objects.
SNMP folks did not even manage to define create/delete - we just
have this RowStatus hack which pushes some of the complexity from
the protocol into the instrumentation, which has proven to be
problematic. :-(
Keith> If you look at CMIP information models, there are surprisingly
Keith> few custom methods defined for the objects. And some of the
Keith> more often used methods, such as setting up a connection, could
Keith> have just as easily been done with a standard "create" method.
Some methods (or RPC calls if you will) have proven to be very
useful. The most prominent example is running a traceroute or ping
from a remote device. Doing these things without protocol support to
invoke operations (a term I prefer instead of methods since it has
less OO baggage) results in kind of ugly solutions. Look at RFC 2925
for an example. In other words, many things can be done very well
without such a "method" capability but some things are really hard to
do without such a capability. It is a trade-off, as usual.
Keith> I lean towards using standard create, delete, get, set only,
Keith> mainly because I think trying to devise a way of defining
Keith> methods on objects in XML schema will be too painful and not
Keith> worth the complexity. I know this is not truly
Keith> object-oriented, but I think it is reasonable given that the
Keith> answer is XML. I do support, however, trying to view the
Keith> elements in an XML infoset as object as much as possible.
I think the logic is wrong. We have to figure out whether we need
methods (and whether we need them now or prefer a plan to do them
later) and then we select/create a suitable language that supports
this, if needed. Not the other way round.
BTW, WSDL is in my understanding a way to define methods (well,
actually just RPCs since there is no notion of an object binding if I
recall right - and they are not even necessarily RPCs - just messages)
where the data structures exchanged are defined by XML schemas. Since
people seem to hate SOAP, we would need something similar to WSDL to
define methods for netconf if we were to support "methods" in the
netconf protocol.
/js
--
Juergen Schoenwaelder International University Bremen
<http://www.eecs.iu-bremen.de/> P.O. Box 750 561, 28725 Bremen, Germany
--
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/>