Re: Is beep really what operators would want?

[Andy Bierman <abierman@cisco.com>]

At 12:41 PM 6/18/2003, Juergen Schoenwaelder wrote:

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

Although these protocols are supposed to be independent
of the data model, in fact they are not.  SNMP is the
worst, because of OID naming, lexinext ordering, the
mix-and-match Set PDU, and the arbitrary subset createAndWait
problems.  This doesn't mean lots of agent code couldn't be
better layered -- it just means there are plenty of protocol
specific details that make the 'one piece of code' goal
unrealistic.


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

For some vendors, which have a large investment in CLI configuration,
netconf will be especially useful because it aligns very well with
CLI characteristics.  It has great potential as a replacement
for scripts that interact with the CLI.


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

I don't think it is that fragile. I am seeing a lot of interest
in an XML-based replacement for CLI scripting. The perceived
success of netconf depends on one's expectations of its applicability.


>/js

Andy


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