Re: Interactive vs Batch modes

[Bill Woodcock <woody@pch.net>]

    > distinction between interactive configuration and batched
    > (or bulk) configuration. The interactive kind is like SNMP, or
    > CLI session with a person or script driving it. The batched kind
    > is like "load this config file", where the config file may be
    > stored locally on the managed device or somewhere on the network.
    > There are different ways to handle errors with each.

I think that there shouldn't be a modal distinction between batch and
interactive configuration, if it can be avoided...  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.  

There are, as you say, a bunch of different ways of getting configs into a
device, and as you say, the error handling and reporting may necessarily
be different.

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.

2) Drop in a whole configuration at once.  This might be via HTTPS upload,
or TFTP, or pasting into a terminal emulator across a serial line, or
xmodem across a serial line.  If we have the distinction between working
and running copies, we don't need a different mode to handle batch than
interactive, really.  I think I'd like to be able to have config errors
syslogged, in any event.  Basically you just need to be able to see the
error reports directly associated with the lines which caused them.
Perhaps a mandatory sanity-check of the working copy before it can be used
to overwrite the running copy, and report errors then, whether or not they
were previously reported?

                                -Bill