Re: Questions for the list regarding Operator Requirements draft

[Eliot Lear <lear@cisco.com>]

At 03:41 PM 11/22/2001 -0800, Bill Woodcock wrote:
>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.

Bill,

First, your target of a BCP is probably not sufficient.  When we specify 
output to be sent and interpreted by computers, that's a protocol.  And I 
presume that the result codes are strictly for computers, and not for 
humans, correct?

Just as you pointed out with "show" commands, computers don't just parse 
the result code, they parse output.  In SMTP, the client only really needs 
to look at a single digit to determine the result of a command and up to 
six digits to determine the precise error, which is specified by 
standard.  That works largely because there are a very limited number of 
states within SMTP, which are manipulated with less than ten 
verbs.  Success or failure is easy to signal.  The whys and wherefores are 
not so easy.  The reason you couldn't set an interface's QoS parameters 
*might* be any one of the following:

   -  the interface doesn't exist
   -  the interface doesn't support QoS
   -  you don't have permission to set those parameters.
   -  bandwidth reservation exceeds the interface speed.
   -  bandwidth reservation exceeds ATM MIR/ or FR CIR.
   -  insufficient resources available
   -  there is a syntax error
   -  QoS features are implemented but not enabled.
   -  an internal error

Just to name a few.  Whereas the reasons you couldn't configure a routing 
protocol would be quite different.

This is why BEEP chose to use a single digit to indicate success or failure 
at the protocol level, and left it to the application running above to 
provide more specific detail.  Here that's not the case.  Indeed, LARGELY 
the computer won't care WHY the command failed, but more that it did fail, 
so that it can pass something more verbose back to a human to debug.  If we 
want to standardize that part we can do it separately (there would be a lot 
of work involved).

This gets to the heart of the matter, which is that the document needs to 
be clear on the requirements first, and worry about solutions later.




>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?

Here, you have a good requirement, but there are quite a number of existing 
mechanisms to provide a solution.  No need to invent one (IMHO).  The more 
important issue is this: how do we add such tags (or, for that matter, 
result codes from #1)?  Do we have some sort of MIB or Schema WG in the 
IETF?  One might say, "Ewwww..  MIBs".  Okay, but look at what they're 
addressing, which is how do computers send and interpret commands and 
output, respectively.

Regards,

Eliot