another datapoint from the scli prototype

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

Last year, I started to write a command line interface called scli
<http://www.ibr.cs.tu-bs.de/projects/scli/> which uses SNMP to access
the actual device data and which provides a task-oriented view to
operators on top of the data-centric view SNMP provides.

[Most of the my recent implementation efforts in this area have been
 in the context of layer two port-based vlan configurations. scli
 basically provides two commands to create/delete vlans and a third to
 assign ports to vlans. The actual implementation of these
 task-oriented commands is remarkably different for the 3com, nortel,
 avaya switches I am faced with, but this story is not relevant here.]

The scli interpreter supports two output formats: The first one is
ASCII optimized for human readability and the second one is XML
optimized for post-processors. Recently, I added some protocol support
so that actions can be invoked not only interactively and from within
shell scripts, but also remotely via a machine to machine protocol
interface. I decided to clearly seperate the protocol verbs from the
data moved around and I decided to go with a simple SMTP like protocol
rather than doing the protocol itself in XML as well (which has the
potential to blur the protocol/data interface). The basic protocol
verbs so far are "show", "set", "dump", "restore" (which is being
worked on as the original scli dump command just generated a script of
scli commands to be pushed back to the system, but that is probably
too simplistic).

Here is a trivial example how a simple protocol transaction actually
looks like after establishing the TCP connection (the ">>> " is just
notation and not part of the protocol):

  200 ok; scli 0.2.10i ready
  >>> show system info
  <?xml version="1.0"?>          
  <scli version="0.2.10i" peer="uff" date="2002-07-03 09:27:14 +02:00">
    <system>
      <info>
        <name>uff</name>
        <taddress>uff:161</taddress>
        <description>
          HP ETHERNET MULTI-ENVIRONMENT,ROM
          G.05.34,JETDIRECT,JD30,EEPROM G.05.35
        </description>
	<contact></contact>
        <location></location>
        <vendor>Hewlett Packard</vendor>
        <url>http://www.hp.com/</url>
        <service>application</service>
        <agent-boot-time>2002-05-25 06:06:47 +02:00</agent-boot-time>
	<interfaces>1</interfaces>
      </info>
    </system>
  </scli>
  200 ok; scli 0.2.10i ready
  >>> exit
  201 ok; scli 0.2.10i exiting

The corresponding human ASCII interface looks like the following:

  (uff) scli > show system info  
  Name:             uff          
  Address:          uff:161
  Description:      HP ETHERNET MULTI-ENVIRONMENT,ROM
                    G.05.34,JETDIRECT,JD30,EEPROM G.05.35
  Contact:          
  Location:         
  Vendor:           Hewlett Packard <http://www.hp.com/>
  Services:         application 
  Agent Boot Time:  2002-05-25 06:07:11 +02:00
  Interfaces:       1
  (uff) scli > exit

The XML and ASCII formatting functions are not layered (e.g. ASCII on
top of XML though XML transformations) but live next to each other.
However, they share the same logic to implement the functionality. We
also provide some XML schema fragments (you can query scli for them)
but this clearly lacks behind as this is a spare time project and I am
after all as lazy as others. (In fact, an automatic validation setup
is needed to ensure that the output generated for some test boxes is
actually in sync with the schema - otherwise this will never be
consistent.)

While doing the prototype, I decided that automatic conversion from
the data-centric MIB view to the task-oriented SCLI view leads to a
poor task-oriented view. Instead, I decided to create an independent
task-oriented view which however takes into account my data access
method, but which requires some manual implementation work ones you
have figured out the "elements of procedure" from a data-centric MIB
definition. For many MIBs, this is some major design work as most MIBs
do not really explain how they are to be used to achieve certain
tasks.

There are some papers on SCLI available from the project home page and
you can pick up the code, although the protocol stuff is just recently
getting stable and finding its way into the CVS. I will not be in
Yokohama but I am happy to answer any questions people might have on
this.

/js

-- 
Juergen Schoenwaelder    <http://www.informatik.uni-osnabrueck.de/schoenw/>

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