Questions for the list regarding Operator Requirements draft

[Bill Woodcock <woody@pch.net>]

At the NM/Ops area joint meeting held in conjunction with the RIPE
meeting in Prague there was substantial discussion of the
ops-operator-req-mgmt draft, and a number of changes considered.  It
was deemed appropriate to bring all of these potential changes back
to the list for wider discussion prior to applying them to the next
draft of the document.

1) Do we have consensus on versioned numeric result codes?  That is,
can we all agree that wherever possible, CLI output should begin
with an SMTP-style number which uniquely summarizes the result which
is more verbosely described in subsequent text?  Furthermore, that
this result code should include, as its last digit(s) a version
number which vendors should increment if the meaning or correct
interpretation of the result code changes over time?  Perhaps the
result code could also a digit which allows the differentiation of
results which are transient state, from those which are
regurgitation of operator-supplied configuration, from those which
are vendor-supplied default configuration.

2) How does the issue of autoconfiguration/default-security and the
requirement for serial communications interact with the scope of
devices on the market and limit the appropriate audience for this
document?  That is, should this document be thought of as a BCP for
core devices, and merely strongly-recommended-reading for vendors of
cable-modem/DSL edge devices? Or should this document sacrifice
operator requirements for core devices in order to avoid alienating
vendors of $15 hubs?  My personal preference is to refer back to the
title of the draft for a definition of its scope: operator
requirements.  These are requirements of operators, who are people
who operate devices professionally.  Vendors of $15 hubs are not
targeting the needs of people who operate devices professionally,
so I think they should treat this document as advisory.  I think
people who believe that their devices will and should be used
primarily by professionals (core router vendors) should treat this
document as a BCP rather than merely advisory.

3) Is it _ever appropriate_ for a network device which will be
configured by a professional operator to attempt to "autoconfigure"
or must it remain in a safe, inert, passive state, listening only on
its console port, until it's explicitly configured otherwise by an
operator?  If a box is allowed to autoconfigure, what are the limits
of this behavior?  Do we have consensus that boxes should never
contain "default passwords" or preconfigured user/administrator
accounts?

4) It seems that we are drawing near to common understanding of the
difference between the needs of a machine interface and the needs of
a human interface, and the significant difference is between
line-by-line and tabular formatting of output data.  That is, for
the output of something like "sho ip bgp", humans tend to like to
see it in a table, even if that means that some things get scrunched
a bit, whereas parsers much prefer to see it as a long list of data,
one field or label/data pair to a line.  This honestly doesn't seem
like too great a difference to overcome, nor does it necessarily
seem like something that we need to force a compromise on, if we can
agree that that's really the difference we're talking about. The
basic idea here is that by branching the human and machine
interfaces as late as possible, we minimize the amount of parallel
code that needs to be kept synchronised, and minimize the total
amount of work necessary to implement a decent interface.  Do we
just specify that vendors have a "vertical" or "line" option (we can
figure out what to call it later) which when passed at the end of a
CLI command/query causes any result which would otherwise come back
in tabular form to come back in label/data pair-per-line form
instead?  Does that basically address everyone's needs?

If we can get closure on the issues above, I think we'll be done
with all the big stuff, and only have a few minor details to wrap
up.  I think the things above are the only ones that very many
people feel strongly about.


                                -Bill