Re: text format of configurations

[john heasley <heas@shrubbery.net>]

we should not be asking for uniform config syntax between vendors,
tools from vendors (we almost certainly do not want their "tools"), etc.

we want the tools to forge our own management tools!

- consistency in interface for and between vendor code trains.  random
  changes like character case or default-config changes are useless and
  a PITA.  excepting differences in hardware (like buffer configuration),
  all platforms with the same software should represent themselves in
  the same manner; defaults, etc.

- cmd-line UI MUST be supplied in human-readible format and be asynchronous
  (cmd, result, ...).  i like the SMTP-like integer error code idea.
  multi-lingual input and output??  readline()?

- cmd-line serial console MUST be supplied with the same cmd-line
  functionality as ssh/telnet connection (including XML).  ie: MUST
  function identically.

- the tools to _automate_ interaction with the box.  eg: SNMP or XML over
  telnet/ssh with standardized DTDs, ala snmp MIBs.  any thing that can
  be done in CLI, MUST be possible via XML.  the box should translate the
  XML format to it's native config format, just as in the CLI.  from these
  i'll write my own tools, to support what i want/need to support the way
  i want to support them.

  new "features" can start in vendor specific URI tree and move when/if a
  standardized DTD appears.

- it MUST be possible to determine the FULL configuration of a box.  ie: NO
  hidden "defaults".  if 'ip directed-broadcast' is the default, a 'show
  config' option MUST exist that will display that in the o/p (ascii or XML).

- secure and insecure methods to access a box (client and server!).
  telnet/tftp/rcp and ssh/scp (where legal) should be an absolute
  requirement.  local per-user ssh RSA/DSA keys HIGHLY RECOMMENDED.

  it MUST be possible to disable any one of them.  if the vendor chooses to
  supply web or curses (etc) interfaces, fine.  i dont care, as long as i
  can turn them off and curses or menu driven interfaces are never the
  default.

  whether or not something is off or on by default, is of little concern
  to me.  (see "FULL configuration").  otoh, note 'no ip directed-broadcast',
  which is not to imply that knobs should ever be removed because they are
  "dangerous."

- slew of required SNMP MIBs

probably many others.

Mon, Jun 25, 2001 at 06:21:51PM -0400, Joel M. Halpern:
> There are two problems here that need to be recognized.  Before I state 
> them, let me note that I agree with the goal.
> 
> 1) This implies standardizing the command sequence (human readable 
> commands) for controlling boxes.  User interface has generally been a space 
> that the IETF stayed out of.
> 2) If there are new features, there is no way that you can expect multiple 
> vendors to create the exact same syntax for controlling these 
> features.  This implies that even if everyone buys into the goal of 
> uniformity, it will not be perfectly achieved.
> 2') vendors will often claim that their command differences are due to the 
> technical differentiation between products.  This will occasionally be 
> accurate, and usually be an excuse to do things their own way.
> 
> Yours,
> Joel M. Halpern
> 
> At 03:03 PM 6/25/01 -0700, Bill Woodcock wrote:
> >     > re: 03 & 04. strong echo of Adi's statement. if the vendor only 
> > supplied
> >     > compiled configurations, they should be required to decompile when 
> > speaking
> >     > the 'Infrastructure Management Protocol'
> >
> >I think is is one area where operators and vendors may run into a
> >sticking-point...  Jon and I talked about it at some length.  It's _really
> >important_ to operators that we have a uniform configuration syntax
> >between devices, so that we don't have to train technicians on several
> >different kinds of syntax.
> >
> >This obviously benefits competitive vendors, and is a potential problem
> >for incumbent vendors, if the incumbent vendors aren't competitive.  If
> >the syntax for a new device is the same as that which our techs are used
> >to, we can deploy it without the cost of retraining, which means we're
> >more likely to buy it.
> >
> >                                 -Bill
> >
>