Re: Incomplete XML Draft

[Andy Bierman <abierman@cisco.com>]

At 01:08 PM 6/25/2002, RJ Atkinson wrote:

>On Tuesday, June 25, 2002, at 03:56 , Andy Bierman wrote:
>>I'll wait for the BOF to see what all the attendees think.
>>I don't think your opinions represent those of all network operators.
>
>I'm quite sure that there is nothing that all network operators
>will agree upon.  The pool of operators is large enough that
>there will be lots of views on anything.
>
>I'm also pretty sure that this BOF will be light on operators --
>travel budgets having been cut all over.  (There is a probability
>that I won't be there in person either, giving you something
>to look forward to. :-)
>
>
>>There are plenty of proprietary MIB objects for configuration.
>
>Varies by vendor of course.  In my experience, not generally
>enough of the right objects to be useful in automating configuration
>of network boxes.
>
>>I'm thinking about an application which wishes to monitor with SNMP
>>and configure with XML. It needs to know how to translate the '42'
>>in ifInOctets.42 to an interface name in XML.
>
>The applications I'm familiar with in that area currently grab data
>via SNMP, make decisions, then alter the configuration stored in an
>RDBS (often a SQL database), the new official config generally gets
>pushed out via (expect + Tcl + CLI + SSH).
>
>It is that last bit (expect + Tcl + CLI + SSH) that might be replaceable
>if there were a standard way of moving proprietary XML config data
>around.

I agree with you that this aspect of config management is an important
first step.  As it is, cisco has N development groups doing XML config
in N different ways, where N is a steadily growing small integer.

I just want to be able to translate MIB data in the first step as well.


>>I'll abide by the majority consensus, as determined at the BOF.
>>If the majority thinks SMI->XML name translation should be part
>>of a separate WG, then that's fine with me.
>
>Should be easy to get your way then.  Operators are basically never
>a majority of attendees at any IETF session (even if they were
>to all agree with themselves).

Then maybe we should try to gauge consensus on the mailing list,
before and after the BOF (what a concept! :-)  I wouldn't
be going to this IETF if I didn't have to, and I suspect many
people may decide to skip it because of travel costs and time
constraints.

>Ran
>rja@extremenetworks.com

Andy


--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>