Re: A few potential requirements

[Bill Woodcock <woody@pch.net>]

    > > Because we need to write scripts and train people who will interact with
    > > all of these devices.  We need to make sure that what goes across the wire
    > > is as simple and easy to implement from the user side as possible.
    > > 
    > Thanks, so this is primarily for debugging purposes.

Mmm, I wouldn't say _primarily_, necessarily.  When one is debugging a
problem is certainly when all of this becomes the most critical, though.
So it's that much more critical that the interaction methods people use
while debugging be the same as those they're comfortable with from routine
use performing configurations.

    > You write scripts
    > and like anyone, you would like to have as many places as possible to
    > check and debug the code. If you could see the script/code on the router
    > would that make a difference to you?

I'm not quite sure what you mean, here...  I don't want to write scripts
which execute on the device...  That would be a different mode of
interaction than the user has, since I can't squeeze a user into the
device.  Of course I want to see the _configuration_ of the device...  I
want to see the configuration I'm working on, the one that's running, and
the one that'll try to load at next boot time.  Plus perhaps any
alternate configurations I may have socked away in persistent storage on
the device, if it exists.

Randy brought up a good suggestion, which is that it would be nice to be
able to diff configurations and get out a result which was itself a valid
partial config for converting one of the input configs to the other.

                                -Bill