[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Deja vu Again
Thanks for the clarification. So, instead of talking about converting
SNMP schema (ie definitions in MIB modules) to XML schema and providing
the same operations in XML as found in SNMP, we talking about
creating a translation of CLI to XML. Which CLI was this?
I'm not familiar with the CLI from Extreme. Is it like cisco or
Juniper, or something else? I'm somewhat familiar with both c&j, and
it is certainly easy to convert between Juniper's config and XML.
Don't think it is easy with cisco's, and not sure about others.
Let's assume that you can convert between each vendor's config
format and an XML format for the same config. The result is
juniper config and juniper XML (for config)
cisco config and cisco XML (for config)
vendor X config and vendor XML (for config)
What is a WG to standardize? Is it "higher level" operations,
1) replace existing config with config in this message
2) merge config in message with existing config
3) retrieve the existing (running) config
4) retrieve the saved (to be used at next system restart) config
In general, there are several different models as to how configuration
is done, such as
1) what can be changed during operation of the device versus what
can only be changed by device reset.
2) does a config modification operation change both the "running"
config and the "persistent" config, or is a explicit
operation needed to cause running to be copied to persistent
3) are there more than one copy of persistent config, and if so,
then how are they named and managed?
4) are default values supported (that is, are incomplete
5) how are configurations removed?
What part of the above are to be standardized?
Does Soap operations and schema easily map to CLIs?
At 06:18 PM 6/25/2002 -0400, RJ Atkinson wrote:
>On Tuesday, June 25, 2002, at 05:42 , David T. Perkins wrote:
>>Does using XML-based techniques really make a difference?
> Some operators believe that XML over SSHv2 (or maybe XML over some other
>transmission technique) is more interesting than (Tcl + expect + CLI + SSH).
>Several vendors (e.g. Juniper) have existing proprietary XML stuff that seems
>to work and that operators have chosen to actually mess around with.
> Today, the most common technique for moving configuration data to/from
>boxes is (Tcl + expect + CLI + SSH). So some few of us are trying
>to make that *single* incremental improvement in our operational
>lives. This is not a new NM architecture and won't solve most of the
>problems out there. It *might* solve a problem that operators really
> The proposal on the table is *not* XML as panacea for OPS/NM issues,
>though some (e.g. Andy Bierman) would like to explore the panacea approach.
/david t. perkins
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.