Re: Interactive vs Batch modes

[Mike MacFaden <mrm@riverstonenet.com>]

>Bill Woodcock writes:
>I think that there shouldn't be a modal distinction between batch and
>interactive configuration, if it can be avoided...

I think interactive configuration is a subset of batch interaction
since humans can only comprehend a small amount of data at a time
with the restriction that it be formatted...

>Again, there seems to
>be a lot of consensus around the idea that syntax and replies and so forth
>should be identical, irrespective of the mode of communication.  

Certainly if the console and syslog agree, things are easier to learn,
easier for other companies to build tools against. Not many folks
have learned a given technology in the abstract, they learn from the CLI and
it can be anoying if other subsystems don't behave in the same manner.

I keep getting asked by novices why they can't clear snmp counters like
they can with the CLI (http://www.nanog.org/mtg-0102/ppt/mibs/index.htm)

>1) Issue commands interactively, receive interleaved error reports.  Error
>handling consists of ignoring invalid or unparseable commands.  Successful
>commands take effect interactively.  This is the way many vendors do it
>right now, and it has the advantage of allowing for mid-course correction
>if someone is working live, but the disadvantage of allowing situations
>where a config which would be valid when wholly entered exists in a
>temporarily uncommunicative state at some point as it's being entered:
>
>    > telnet 10.10.10.10
>    > show configuration
>    interface Ethernet 0
>     ip address 10.10.10.10/24
>    > configure
>    config> interface Ethernet 0
>    config-if>  access-list 1 in
>    config-if> access-list 1 permit any any eq SMTP
>    -lost connection- 
>
>...despite you intention of typing "access-list 1 permit any any eq
>telnet" right on the next line.  This tends to argue in favor of having
>three copies of the configuration, rather than Cisco's two: nvram
>(persistent, what will be used at next boot), running, and a working copy
>which can be parsed and sanity-checked, but hasn't yet overwritten the
>running copy.

Consider an sql database approach.

If you apply commands interactively using mysql for instance, it 
still makes sense to have a commit but it may be set to auto-execute
after each command.  The operator has the *choice* of auto
or manual commit. 

The interleaving of errors to commands command only works
if you are not trying to load more than a screenful of commands. 
I prefer the CLI to not spew lots of lines at the user like some 
compiler diagnostics but batch the errors
when issuing the commands like this:

  Router#copy  slot0:some-file running-config
   % CFG-ERR 5 errors occured, see show parse-errors for details
  Router#show parse-errors
    some-file:4:hostname has invalid string name %$%W$#, must be alphanumeric...
     
The "shoot-yourself-in-the-foot" problem was solved in a different
way in JUNOS from Juniper Networks. 
If you are not able to confirm the change after some period of minutes,
the device can revert to a prior config. See the "commit confirmed" command:
http://www.juniper.net/techpubs/software/junos42/swconfig-install42/html/cli-configuration-mode23.html

In the best current practice document in SNMPCONF working group
(draft-ietf-snmpconf-bcp-04.txt),  Jon and I detail a common,
generic form of the above that covers making changes either 
interactively or in batch. 

The procedure involves running a pre-test and then a post-test
to verify changes. Now if only vendors supported the change
methods sysadmins have sucessfuly employed for some time
when managing DNS, sendmail, etc...

Regards,
Mike MacFaden