A few potential requirements

[Bill Woodcock <woody@pch.net>]

To get discussion going, here's a list of a few potential requirements for
the draft.  Please tell me what's wrong with them.  :-)

                                -Bill


____________________________________________________________________________

Operator Requirements of Infrastructure Management Methods


01) Any management system which results from this work needs to
include provision for multiple permissions-levels of authenticated
access, each with read and write access to different resources
within the managed device or system.  For instance, some users
should have only read access, and only to specific portions of a
device.  Other users would have the authority to create new
instances by applying a predefined template (turning up new BGP
peers using a peer-group).  More advanced users would have
permission to apply a template but also make specific
individual-line overrides to the predefined configuration of the
template.  Superusers would have the ability to define new templates
and destroy old ones.  This requirement is related to requirements
07 and 08. -woody@pch.net

02) The syntax of any management language be portable to different
transport methods, and not be coupled explicitly to a single
protocol like SNMP.  That is, one must be able to dictate commands
over the telephone, or type them in on a serial port, or via SSH,
all in the same syntax.  -woody@pch.net

03) The syntax of data collected from reads should be, wherever
possible, the same as the sytax which would be used to perform any
corresponding write.  An example of this is the command "show
configuration" in IOS, which produces a file which can be re-entered
into another router of similar hardware configuration to produce an
identical configuration.  Note that this process could work better
in IOS, but the intent is correct.  A counter-example is the IOS
command "show access-list" which produces text which appears to be
configuration, but cannot be re-entered into a router.  This
requirement is related to requirement 04. -woody@pch.net

04) Reads and writes should, wherever possible, share the same
name-space.  This requirement is related to requirement 03.
-saperia@jdscons.com

05) SMTP should be taken as a model of a good on-the-wire protocol
for operational use.  It's easily implemented, whether in code or in
scripts.  It's also easily typed manually, for debugging purposes.
It contains machine-readable numeric error codes, as well as verbose
text descriptions of the errors which can be either observed by an
operator performing interactive debugging, or communicated by an
automated system to someone capable of interpreting them.  It
requires no special tools of the person attempting the debugging, as
they can do so simply by telnetting to a well-known port.  The
commands are simple enough and memorable enough that a person of
average intelligence can use them from memory, in the middle of the
night, without enough coffee, and it contains a rudimentary
interactive help system which allows an interactive user to
determine what commands are available.  If a device-management
protocol were to be implemented in a manner similar to SMTP, a "no
verbose" command should be included so that automated console
implementations could minimize the volume of return traffic from the
device.  -woody@pch.net

06) A common configuration language needs to exist between
platforms.  For example, an interface should be named by its
position within its host chassis and by any logical subdivision of
the physical interface, and the syntax by which it's named should be
exactly the same regardless of the vendor of the equipment.
-woody@pch.net

07) Operators need to be able to define templates, and apply those
templates to lists or ranges of interfaces, or peers, or users, or
whatever.  This requirement is related to requirements 01 and 08.
-woody@pch.net

08) Operators need to be able to define default configurations for
new resources before they become available or before they're
created.  That is, an operator needs to be able to define the
default settings (DNS servers, for instance) for any DHCP pool, and
have those defaults applied to any new pool which is created on a
managed device, or to any new pool which is created within a
specific address range on a managed device, or to any new pool which
is created by a specific user of a managed device.  Similarly, an
operator needs to be able to define default settings (ESF, B8ZS,
frame relay encapsulation, for instance) for new serial interfaces
which may be subsequently inserted into the chassis, or subsequently
defined within a channelized resource.  This requirement is related
to requirements 01 and 07.  -woody@pch.net

09) When making automatically-applied templates, one needs to be
able to create pools of resources to be drawn from by the template.
For example, just as DHCP users are temporarily assigned IP
addresses from a pool, numbered interfaces need to be able to
semi-permanently draw IP addresses from a pool and configure
themselves according to rules within the template.  This requirement
is related to requirement 08.  -woody@pch.net