Re: Is beep really what operators would want?

[Juergen Schoenwaelder <schoenw@ibr.cs.tu-bs.de>]

>>>>> Hunkins, Andrew writes:

Andrew> Aren't you guys saying the same thing?  Going forward,
Andrew> assuming netconf is there, won't you choose to implement a CLI
Andrew> or any other human interface on top of netconf?  There are a
Andrew> lot of tracing, logging, security reasons to bottleneck all
Andrew> the interaction.

Andrew> So CLI or not becomes either "irrelevant" or "part of the
Andrew> plan", depending on your view.  How does this change the
Andrew> requirements for netconf?

In a well designed system, you have exactly one piece of code which
I think Dave Perkins calls a "resource manager" and the access
mechanisms layered on top of it. SNMP, CLI and xmlconf are all
access mechanism and in the ideal world, the dirty job is only
done once in the resource manager. The sad news is that even
after years of experience with SNMP, CLI and other access mechanisms,
some companies still do not design the software on the boxes this
way (for several individually good reasons that however do not
lead to a global optimum).

The question which I find interesting is whether (a) xmlconf will at
the end be just another access protocol or whether (b) xmlconf will
become the generally used mechanism to access the resource manager
(and to build such resource managers on devices that do not really
have them). In other words, will xmlconf help companies to do better
software design and is there a realistic migration plan from existing
designs to new designs. So yes, to some notable extend, the success of
xmlconf depends on solving these software design problems while at the
same time keeping in mind the requirements of real operators (and they
complained several times that they dislike protocols like SNMP where
you have to rely on software libraries to do what normal people
consider rather complex encoding/decoding without any realistic chance
to debug problems which occur naturally in any system that is build
out of many (perhaps too many) complex components).

From my perspective, I think netconf is an important, interesting and
also very fragile project and serious contributors really need to work
closely together to make this whole thing a success.

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