Re: A few potential requirements

[David Meyer <dmm@maoz.com>]

[hopefully I'm posting from the right addr...]

>> > 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.
>> 
>> My guess is that a lot of the easier scripting falls by the wayside once
>> one goes beyond basic ASCII.  Is ASCII sufficient or is it necessary to
>> enter the brave new world of internationalized character sets?

While I agree with Bill et al wrt the current generation of
routers, for anything much larger (much less what is possible
with near future density, rates, and channelization), the current
style of configuration will likely be difficult if not
impractical. That is not to say that it won't be done in ascii. 
In fact, its a good guess that it will (cf the wellfleet
experience).  

My sense of the discussion to date is that it is focused on
smaller and/or conventionally sized boxes. So a question one
might ask is of the form: Is it important to be able to configure
a 2^(large) i/f box from the CLI? If so, what  should that CLI 
look like? Is the CLI itself a scripting language? I suspect the
answer to all of these questions is yes. As an aside, even on
today's sized routers, a few channelized OC192/768s will win you
a hard CLI configuration problem. 

All that being said, I'm in favor of simple representations of 
simple regular languages that can be manipulated with standard
tools. Compactness is (or hopefully will be) a secondary
concern. ascii is a simple representation.  The common CLIs are  
close to regular languages (of course, they could be better; in 
general,it would be nice if you could write a flex/bison LL(1)
parser, etc). BTW, this not is to say that some pieces of a
configuration system might be not be ascii (e.g., you might argue
that something like the internal representation of a database
like the RADB is non-ascii, but in general the point holds).   

My point is that whatever we converge on should be applicable to
all of the size ranges we're dealing with, and allow construction
of configuration management tools based on standard and easily
available tools.  

Dave