[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Is DOM vs SAX a red herring?
>>>>> Allen, Keith writes:
Keith> It's a tough one, though. Having been involved in network
Keith> management standards work before, I would estimate that 50% of
Keith> the time of a network management standards group gets spent on
Keith> naming-related issues. I think this group was hoping to put
Keith> those issues in the hands of the information model developers.
Keith> I'm concerned, though, that it impacts the protocol and needs
Keith> to be addressed here.
The NMRG work on SMIng is a good example which demonstrates that
naming is a serious issue since the management protocols we have today
are all making assumptions about the underlying naming. SNMP is
certainly an extreme example. Making SMIng less protocol depend really
gets tough when it comes down to the various different naming schemes
used by existing protocols.
With this insight, you can of course design a protocol which makes
less assumptions about naming. But you will likely end up with a
protocol which sends opaque blobs around, which is not necessarily
bad. The downside of this approach, however, is that the semantics of
the protocol operations will be pretty imprecise and limited. To make
e.g. error responses more concrete, you will again hit the wall that
you really would like to make assumptions about the naming scheme.
The enns draft was specifically written (as far as I understand it) to
move opaque text blobs around and the charter of this almost existing
working group basically to some extend acknowledges this. But at the
end, I guess we will have to develop some more or less commonly
accepted assumptions about the naming scheme we intend to use to get a
useful protocol where not everything is basically opaque.
Bottom line: I agree with your observation.
/js
--
Juergen Schoenwaelder International University Bremen
Phone: +49 421 200 3587 P.O. Box 750 561, 28725 Bremen, Germany
Fax: +49 421 200 3103 <http://www.iu-bremen.de/>
--
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/>