summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc1856.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc1856.txt')
-rw-r--r--doc/rfc/rfc1856.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc1856.txt b/doc/rfc/rfc1856.txt
new file mode 100644
index 0000000..f3922a8
--- /dev/null
+++ b/doc/rfc/rfc1856.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Network Working Group H. Clark
+Request For Comments: 1856 BBN Planet
+Category: Informational September 1995
+
+
+ The Opstat Client-Server Model for Statistics Retrieval
+
+Status of this Memo
+
+ This memo provides information for the Internet community. This memo
+ does not specify an Internet standard of any kind. Distribution of
+ this memo is unlimited.
+
+Abstract
+
+ Network administrators gather data related to the performance,
+ utilization, usability and growth of their data network. The amount
+ of raw data gathered is usually quite large, typically ranging
+ somewhere between several megabytes to several gigabytes of data each
+ month. Few (if any) tools exist today for the sharing of that raw
+ data among network operators or between a network service provider
+ (NSP) and its customers. This document defines a model and protocol
+ for a set of tools which could be used by NSPs and Network Operation
+ Centers (NOCs) to share data among themselves and with customers.
+
+1.0 Introduction
+
+ Network administrators gather data related to the performance,
+ utilization, usability and growth of their data network. The primary
+ goal of gathering the data is to facilitate near-term problem
+ isolation and longer-term network planning within the organization.
+ The amount of raw data gathered is usually quite large, typically
+ ranging somewhere between several megabytes to several gigabytes of
+ data each month. From this raw data, the network administrator
+ produces various types of reports. Few (if any) tools exist today
+ for the sharing of that raw data among network operators or between a
+ network service provider (NSP) and its customers. This document
+ defines a model and protocol for a set of tools which could be used
+ by NSPs and Network Operation Centers (NOCs) to share data among
+ themselves and with customers.
+
+1.1 The OPSTAT Model
+
+ Under the Operational Statistics model [1], there exists a common
+ model under which tools exist for the collection, storage, retrieval
+ and presentation of network management data.
+
+
+
+
+
+Clark Informational [Page 1]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+ This document defines a protocol which would allow a client on a
+ remote machine to retrieve data from a central server, which itself
+ retrieves from the common statistics database. The client then
+ presents the data to the user in the form requested (maybe to a X-
+ window, or to paper).
+
+ The basic model used for the retrieval methods defined in this
+ document is a client-server model. This architecture envisions that
+ each NOC (or NSP) should install a server which provides locally
+ collected information for clients. Using a query language the client
+ should be able to define the network object of interest, the
+ interface, the metrics and the time period to be examined. Using a
+ reliable transport-layer protocol (e.g., TCP), the server will
+ transmit the requested data. Once this data is received by the
+ client it could be processed and presented by a variety of tools
+ including displaying the data in a X window, sending postscript to a
+ printer, or displaying the raw data on the user's terminal.
+
+ The remainder of this document describes how the client and server
+ interact, describes the protocol used between the client and server,
+ and discusses a variety of other issues surrounding the sharing of
+ data.
+
+2.0 Client-Server Description
+
+2.1 The Client
+
+ The basic function of the client is to retrieve data from the server.
+ It will accept requests from the user, translate those requests into
+ the common retrieval protocol and transmit them to the server, wait
+ for the server's reply, and send that reply to the user.
+
+ Note that this document does not define how the data should be
+ presented to the user. There are many methods of doing this
+ including:
+
+ - use a X based tool that displays graphs (line, histogram, etc.)
+ - generate PostScript output to be sent to a printer
+ - dump the raw data to the user's terminal
+
+ Future documents based on the Operational Statistics model may define
+ standard graphs and variables to be displayed, but this is work yet
+ to be done (as of this writing).
+
+
+
+
+
+
+
+
+Clark Informational [Page 2]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+2.2 The Server
+
+ The basic function of the server is to accept connections from a
+ client, accept some series of commands from the client and perform a
+ series of actions based on the commands, and then close the
+ connection to the client.
+
+ The server must have some type of configuration file, which is left
+ undefined in this document. The configuration file would list users
+ that could access the server along with the authentication they would
+ use. The configuration file should also allow the specification of
+ the data items that the user should be permitted to access (and, by
+ implication, not allowed to access). Server security concerns are
+ specifically addressed in Section 4.
+
+3.0 Protocol Commands
+
+ This section defines the commands which may be transmitted to the
+ server and the server responses to those commands. The available
+ commands are:
+
+ LOGIN - accept new connection
+ EXIT - disconnect
+ LIST - show available variables
+ SELECT - mark data for retrieval
+ STATUS - show the state of the server
+ GET - download data to the client
+
+ In addition, a state machine describing specific actions by the
+ server is included. Server security concerns are addressed in
+ Section 4.
+
+ Note that in some of the descriptions below, the term <ASCII-STRING>
+ is used. This refers to printable ASCII characters, defined as all
+ letters, numbers, and special characters such as $, %, or *. It
+ specifically excludes all special control characters in the lower
+ parts of the character set (i.e., 0x00 - 0x1F), and any such
+ characters that are received by the server or client should be
+ ignored.
+
+
+
+
+
+
+
+
+
+
+
+
+Clark Informational [Page 3]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+3.1 Command Return Codes
+
+ The responses a server will return to a client are of the form:
+
+ RETURN-INFO ::= <RETURN-CODE> " <ASCII-STRING> " | <RETURN-CODE>
+ RETURN-CODE ::= <MAIN-CODE><COMMAND><SUB-CODE>
+ MAIN-CODE ::= 1..9
+ COMMAND ::= 1..9
+ SUB-CODE ::= 0..9
+
+ For each command sent to the server, the server returns a series of
+ three digit numeric codes which specifies the result of the
+ operation, plus optional ASCII text for humans. The value of MAIN-
+ CODE specifies what happened, as in:
+
+ 1 Error
+ 9 Success / Informational
+
+ The commands are encoded as:
+
+ 1 LOGIN
+ 2 SELECT
+ 3 STATUS
+ 4 LIST
+ 5 GET
+ 9 EXIT
+
+ The following specific error codes must be supported by all servers
+ and clients:
+
+ 110 Login Invalid
+ 113 Scanning Error during LOGIN
+ 120 SELECT Failed
+ 130 STATUS Failed
+ 140 LIST Failed
+ 141 Bad LIST encoding
+ 150 GET Failed
+ 151 GET doesn't support that type of encoding
+ 910 Login Accepted
+ 920 SELECT successful
+ 931 STATUS Output Starting
+ 932 STATUS Output Done
+ 941 LIST lookup successful, here comes the data!
+ 942 LIST dump done!
+ 951 GET lookup successful, here comes the data!
+ 952 GET dump done!
+ 990 Server closing connection after EXIT received
+
+
+
+
+Clark Informational [Page 4]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+ Other codes may be used, but may not be supported by all clients or
+ servers.
+
+3.2 The LOGIN Command
+
+ The LOGIN command authenticates a user to the server. The format of
+ the LOGIN command is:
+
+ LOGIN-CMD ::= LOGIN <username> <auth-type>
+ USERNAME ::= " <ASCII-STRING> "
+ AUTH-TYPE ::= "none" | "password" | " <ASCII-STRING> "
+ CHAL-CMD ::= CHAL " <ASCII-STRING> "
+ AUTH-CMD ::= AUTH " <ASCII-STRING> "
+
+ The authentication types supported by each server will vary, but must
+ include "none" and "password". Note that a server may or may not
+ choose to allow logins via either of these methods, but it must
+ recognize the two special authentication types.
+
+ In processing a LOGIN command sequence, the server first checks the
+ username and authentication type requested. If the username is
+ invalid (e.g., there's no such user known to the server) or the
+ authentication type requested is not supported by the server, then
+ the server must return a 110 error and close the connection after
+ faking the challenge/authentication process (see examples below).
+
+ After passing the username and authentication type checking, a
+ challenge must be sent. Note that the challenge will be specific to
+ the type of authentication requested, and the ASCII string may be an
+ empty string if no specific challenge is needed (such as in the
+ password-only case). The next command the client returns must be an
+ AUTH response, and if not, the server must close the connection.
+ After processing the authentication information, the server must
+ return a 910 code if the authentication process is successful, or a
+ 110 error messsage if unsuccessful. Additionally, if the
+ authentication fails, the server must immediately close the
+ connection.
+
+ If, at any point, during the LOGIN sequence, a syntax error occurs (a
+ client doesn't send the correct number of arguments in the LOGIN
+ command, for example), the server must return a 113 error and close
+ the connection.
+
+ If the special AUTH-TYPE of "none" is used, and the server allows the
+ specified username (such as anonymous) to login without
+ authentication, then the server should still send a "CHAL" response
+ to get additional information about the person logging in. The
+ server may then choose to allow or disallow the login based on the
+
+
+
+Clark Informational [Page 5]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+ information returned in the AUTH response.
+
+ An example of an invalid authentication type requested:
+
+ >LOGIN "cow" "s/key"
+ <CHAL "lo35098 98"
+ >AUTH "COW DOG BARK CAT MOO MEOW"
+ <110 "Login invalid"
+
+ The server didn't support S/Key, but it made it appear to the user as
+ if it did. An example of an authentication failure:
+
+ >LOGIN "dog" "securid"
+ <CHAL "enter passcode"
+ >AUTH "103945"
+ <110 "Login invalid"
+
+ The user gave the wrong number for SecurID authentication. An
+ example of a successful login:
+
+ >LOGIN "cat" "password"
+ <CHAL "send the dumb clear-text password"
+ >AUTH "foobar"
+ <910 "Login accepted"
+
+ or
+
+ >LOGIN "anonymous" "none"
+ <CHAL "tell me who you are anyway"
+ >AUTH "bessie@barn.farm.com"
+ <910 "Login accepted"
+
+ An example of a invalid username:
+
+ >LOGIN "mule" "skey"
+ <CHAL "78 lo39065"
+ >AUTH "COW DOG FRED LOG COLD WAR"
+ <110 "Login invalid"
+
+ The server should have some type of logging mechanism to record both
+ successful and unsuccessful login attempts for a system adminstrator
+ to peruse.
+
+
+
+
+
+
+
+
+
+Clark Informational [Page 6]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+3.3 The EXIT Command
+
+ The EXIT command disconnects a current user from the server. The
+ format of the EXIT command is:
+
+ EXIT
+
+ Note that upon reception of an EXIT command, the server must always
+ close the connection, even if it would be appropriate to return an
+ ERROR return code.
+
+ A sample EXIT command:
+
+ >EXIT
+ <990 "OK, Bye now"
+
+3.4 The SELECT Command
+
+ The SELECT command is the function used to tag data for retrieval
+ from the server. The SELECT command has the format:
+
+ SELECT-COM ::= SELECT <NETWORK> <DEVICE> <INTERFACE> <VARNAME>
+ <GRANULARITY> <START-DATE> <START-TIME> <END-DATE>
+ <END-TIME> <AGG> <SELECT-COND>
+
+ NETWORK ::= <ASCII-STRING>
+
+ DEVICE ::= <ASCII-STRING>
+ INTERFACE ::= <ASCII-STRING>
+ VARNAME ::= <ASCII-STRING>
+ GRANULARITY ::= <ASCII-STRING>
+ START-DATE ::= <DATE-TYPE>
+ END-DATE ::= <DATE-TYPE>
+ DATE-TYPE ::= YYYY-MM-YY
+ START-TIME ::= <TIME-TYPE>
+ END-TIME ::= <TIME-TYPE>
+ TIME-TYPE ::= HH:MM:SS
+ AGG ::= <AGG-TYPE> | NULL
+ AGG-TYPE ::= TOTAL | PEAK
+ SELECT-COND ::= <SELECT-STMT> | NULL
+ SELECT-STMT ::= WITH DATA <COND-TYPE> <ASCII-STRING>
+ COND-TYPE ::= LE | GE | EQ | NE | LT | GT
+
+ If any conditional within the SELECT does not match existing data
+ within the database (such as VARNAME, the S-DATE or E-DATE, or
+ GRANULARITY), the server must return an ERROR (and hopefully a
+ meaningful error message). The time values must be specified in GMT,
+ and hours are specified in the range from 0-23. The granularity
+
+
+
+Clark Informational [Page 7]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+ should always be specified in seconds. A sample query might be:
+
+ SELECT net rtr1 eth-0 ifInOctets 900 1992-01-01 00:00:00 1992-02-
+ 01 23:59:59
+
+ which would select all data from network "net" device "rtr1"
+ interface "eth-0" from Jan 1, 1992 @ 00:00:00 to Feb 1, 1992 @
+ 23:59:59.
+
+ Note that if the client requests some type of aggregation to be
+ performed upon the data, then the aggregation field specifies how to
+ perform the aggregration (i.e., total or peak) and the granularity
+ specifies to what interval (in seconds) to agggregate the data to.
+ For more details about the granularity types, see [1]. If the server
+ cannot perform the requested action, then it must return a 120 error.
+ The server may, if it wishes, use other error codes in the range
+ 121-129 to convey more information about the specific error that
+ occured. In either case, its recommended that the server return
+ ASCII text describing the error.
+
+ Upon completion of the data lookup, the SELECT must return the an
+ indication of whether the lookup was successful and (if the search
+ was successful) the tag associated with that data. If the lookup was
+ successful, then information in the return code should be encoded as:
+
+ 920 " TAG <ASCII-STRING> "
+
+ In this case, the use of the word TAG is used as a handle for the
+ selected data on the server. Note that this single handle may refer
+ to one or more specific SNMP variables (refer to [1] for a further
+ explanation).
+
+ For example, if the tag "foobar" were assigned to the select example
+ above, then the OK would be as:
+
+ 920 "TAG foobar"
+
+ It is recommended that the return tag string be less than 10 bytes
+ long (this gives many tag combinations), although the server (and
+ client) should be capable of handling arbitrary length strings.
+ There is no requirement that the TAG have any particular meaning and
+ may be composed of arbitrary strings.
+
+ The server must keep any internal information it needs during a
+ session so that all SELECT tags can be processed by GET or other
+ commands. If a server doesn't have the resources to process the
+ given SELECT, it must return an error message.
+
+
+
+
+Clark Informational [Page 8]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+ It is the responsibility of the client to store information about the
+ data that a particular tag corresponds to, i.e., if the server had
+ returned a tag "1234" for ifInOctet data for October 1993, then the
+ client must store that information someplace as the variables which
+ correspond to that tag cannot be retrieved from the server.
+
+3.5 The STATUS Command
+
+ The STATUS command shows the general state of the server plus listing
+ all data sets which have been tagged via the SELECT command. The
+ STATUS command has no arguments. The output from a STATUS command
+ is:
+
+ STATUS-DATA ::= <SERVER-STATUS> <SERVER-TAG-LIST>
+ SERVER-STATUS ::= "STATUS= " <STATUS-FIELDS>
+ STATUS-FIELDS ::= "OK" | "NOT-OK"
+ SERVER-TAG-LIST ::= <SERVER-TAG> | NULL
+ SERVER-TAG ::= "TAG" <TAG-ID> "SIZE" <NUMBER>
+
+ The number returned in the SIZE field represents the number of octets
+ of data represented by the particular TAG. The server must return a
+ 931 message before the STATUS output starts, and a 932 message at the
+ end of the STATUS output. If any type of failure occurs, then a 130
+ error messages must be sent. If the server prefers, it may send a
+ message in the range of 131-139 if it wishes, but its recommended
+ that the server always return ASCII describing the enoutered error.
+ For example, a sample output might look like:
+
+ >STATUS
+ <931 "STATUS Command Starting"
+ <STATUS= OK
+ <TAG 1234 SIZE 123456
+ <TAG ABCD SIZE 654321
+ <932 "STATUS Command successful"
+
+ or
+
+ >STATUS
+ <130 "Can't get STATUS right now, sorry."
+
+ or
+
+ >STATUS
+ <931 "STATUS Command Starting"
+ <STATUS= OK
+ <TAG 1234 SIZE 1
+ <131 "Oops, error reading TAG table, sorry."
+
+
+
+
+Clark Informational [Page 9]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+ 3.6 The GET Command
+
+ The GET command actually retrieves the data chosen via a previous
+ SELECT command. The GET command has the format:
+
+ GET-CMD ::= GET <TAG> <TYPE>
+ TAG ::= <ASCII-STRING>
+ TYPE ::= 1404 | <ASCII-STRING>
+
+ If the TAG matches a previously returned TAG from a SELECT statement,
+ then the previously tagged data is returned. If the TAG is invalid
+ (i.e., it hasn't been previously assigned by the server), then the
+ server must return an error. The TYPE specifies the encoding of the
+ data stream. All servers must support "1404" encoding. Others forms
+ may be supported as desired.
+
+ If the server, while retrieving the data, cannot retrieve some
+ portion of the data (i.e., some of the data previously found
+ disappeared between the time of the SELECT and the time of the GET),
+ then the server must return a 150 error. If the client requests an
+ encoding type not supported by the server, then the server must
+ return a 151 error.
+
+ The format of the returned data is as follows:
+
+ RETURN-DATA-TYPE ::= START-DATA <RETURN-TYPE> <DATA> END-DATA
+ RETURN-TYPE ::= 1404 | <ASCII-STRING>
+
+ An example would be:
+
+ >GET ABC 1404
+ <951 "OK, here it comes!"
+ <START-DATA 1404
+
+ 1404 data stream here...
+
+ <END-DATA
+ <952 "All done!"
+
+ Error examples:
+
+ >GET ABC STRONG-CRYPT
+ <151 "Sorry, that encoding not available here"
+
+ or
+
+ >GET ABC 1404
+ <951 "OK, here it comes!"
+
+
+
+Clark Informational [Page 10]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+ <START-DATA 1404
+
+ 1404 data stream here...
+
+ <END-DATA
+ <150 "Whoa, bad data..."
+
+ If any type of error code is returned by the server, the client must
+ discard all data received from the server.
+
+3.7 The LIST Command
+
+ The LIST command allows the client to query the server about
+ available data residing on the server. The LIST command has the
+ format:
+
+ LIST-CMD ::= LIST <net> <dev> <intf> <var> <gran> <sdate> <stime>
+ <edate> <etime>
+ <net> ::= <ASCII-STRING> | *
+ <dev> ::= <ASCII-STRING> | *
+ <intf> ::= <ASCII-STRING> | *
+ <var> ::= <ASCII-STRING> | *
+ <gran> ::= <ASCII-STRING> | *
+ <sdate> ::= <DATE-TYPE> | *
+ <edate> ::= <DATE-TYPE> | *
+ <stime> ::= <TIME-TYPE> | *
+ <etime> ::= <TIME-TYPE> | *
+
+ For example, to get a list of networks that the server has data for,
+ you would use the command:
+
+ LIST * * * * * * * * *
+
+ The command
+
+ LIST netx rtry * * * * * * *
+
+ will list all interfaces for rtry. The command
+
+ LIST netx rtry * ifInOctets * 1993-02-01 * * *
+
+ will get the list of interfaces on device "rtry" in network "netx"
+ which have values for the variable "ifInOctets" after the start date
+ of Februrary 1, 1993.
+
+
+
+
+
+
+
+Clark Informational [Page 11]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+ To process wildcards in a LIST command, follow these rules:
+
+ 1) Only the leftmost wildcard will be serviced for a given
+ LIST command
+ 2) If all fields to the right of the leftmost wildcard are
+ wildcards, then all values for the wildcard being processed
+ will be returned.
+ 3) If specific values are given for fields to the right of the
+ wildcard being serviced, then the specific values must match
+ a known value
+
+ The output from the LIST command is formatted as follows:
+
+ LIST-RETURN ::= START-LIST <LIST-ENTRY> END-LIST
+ LIST-ENTRY ::= <net> <device> <intf> <var> <gran> <sdate> <stime>
+ <edate> <etime>
+ <net> ::= <ASCII-STRING>
+ <device> ::= <ASCII-STRING> | <NULL>
+ <intf> ::= <ASCII-STRING> | <NULL>
+ <var> ::= <ASCII-STRING> | <NULL>
+ <gran> ::= <ASCII-STRING> | <NULL>
+ <sdate> ::= <DATE-TYPE> | <NULL>
+ <edate> ::= <DATE-TYPE> | <NULL>
+ <stime> ::= <TIME-TYPE> | <NULL>
+ <etime> ::= <TIME-TYPE> | <NULL>
+
+ Note that only the fields with values in them will be returned by the
+ server. For example, the query to find the interfaces on rtry:
+
+ >LIST netx rtry * * * * * * *
+ <941 "OK, here comes the list..."
+ <START-LIST
+ <netx rtry intf1
+ <netx rtry intf2
+ <netx rtry intf3
+ <END-LIST
+ <942 "all done"
+
+ The query to find interfaces having ifInOctets data with a 15 minute
+ granularity:
+
+ >LIST netx rtry * ifInOctets 15min * * * *
+ <941 "OK, here comes the list..."
+ <START-LIST
+ <netx rtry intf1
+ <netx rtry intf2
+ <netx rtry intf3
+ <END-LIST
+
+
+
+Clark Informational [Page 12]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+ <942 "all done"
+
+ If, while processing a LIST command, the server encounters an error,
+ then the server must return a 140 error message. If the server
+ cannot process the LIST command (syntax error, etc.), then it must
+ return a 141 message. For example:
+
+ >LIST netx rtry
+ <141 "huh, bad list dude"
+
+ or
+
+ >LIST netx rtry * ifInOctets 15min * * * *
+ <941 "OK, here comes the list..."
+ <START-LIST
+ <netx rtry intf1
+ <netx rtry intf2
+ <netx rtry intf3
+ <END-LIST
+ <140 "Whoa, bad list dude, please ignore"
+
+3.8 The Server State Machine
+
+ The state machine pictured below describes how a server should
+ interact with a client:
+
+
+ +------+
+ +-------->| WAIT |<-----+
+ | +------+ |
+ | New | |
+ | Connect | | LOGIN Failure
+ EXIT | \ / |
+ Received | +-------+ |
+ | | LOGIN |-----+
+ | +-------+
+ | |
+ | | LOGIN Successful
+ | \ /
+ | +---------+
+ +--------| PROCESS |<----+
+ +---------+ |
+ | | Process Commands
+ | |
+ +----------+
+
+
+
+
+
+
+Clark Informational [Page 13]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+ The server normally stays in WAIT (after starting and initialization)
+ until a new connection is made from a client. The first command a
+ client must issue is a LOGIN command, otherwise the server must
+ immediately close the connection. If the login process fails in any
+ way (as described in 3.2), then the server must immediately close the
+ connection and return to the WAIT state.
+
+ Once a successful LOGIN is received, the server enters the PROCESS
+ state where it processes some number of LIST, GET, STATUS, and SELECT
+ commands. Any other command received while in this state must be
+ ignored, except for the EXIT command. Once an EXIT command is
+ received, the server exits immediately (after perfoming any needed
+ internal bookkeeping) and returns to the WAIT state. Any command a
+ server receives while processing a command (e.g., if you send an
+ "EXIT" while a large "GET" is being processed) will be ignored until
+ the command being processed completes.
+
+ If the data connection to the client closes for any reason while the
+ server is in the PROCESS state, the server must immediately close its
+ connection and do any associated internal cleanup and return to the
+ LOGIN state.
+
+4.0 Security Issues
+
+ There are legal, ethical and political concerns of data sharing. For
+ this reason there is a need to insure integrity and confidentiality
+ of any shared data. Although not specified in this standard,
+ mechanisms to control a user's access to specific data about specific
+ objects may need to be included in server implementations. This
+ could potentially be done in several ways, including a configuration
+ file that listed the objects a user was allowed to access or limiting
+ file access by using file permissions within a given file system. At
+ a minimum, the server should not allow default access to all data on
+ the server.
+
+ Additionally, the server should strictly follow the state diagram
+ shown in section 3.8. The server should be tested with arbitrary
+ strings in the command fields to ensure that no unexpected security
+ problems will be caused by the server. The server should
+ specifically discard illegal ASCII characters as discussed in section
+ 3.0. If the server executes other programs, then the server must
+ verify that no unexpected side-effects will occur as the result of
+ the invocation or the arguments given to that program. The server
+ should always verify that all data is contained within the input
+ buffer, and that a long input string from a client will not cause
+ unexpected side-effects.
+
+
+
+
+
+Clark Informational [Page 14]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+ Finally, given the relative insecurity of the global Internet, and
+ the presence of packet-sniffing capability, several considerations
+ must be weighed. The authentication process via the LOGIN process
+ must be strictly adhered to, and the use of one-time authentication
+ is strongly encouraged. It is also suggested that the data returned
+ from the server be protected (such as through encryption) so that no
+ sensitive data is revealed by accident.
+
+5.0 Summary
+
+ This document defines a protocol which could be used in a client-
+ server relationship to retrieve statistics from a remote database
+ server.
+
+ Much work remains to be done in the area of Operational Statistics
+ including questions such as:
+
+ - what "standard" graphs or "variables" should always be made
+ available to the user?
+ - what additions to the standard MIB would make the network
+ manager's job easier?
+
+6.0 References
+
+ [1] Stockman, B., "A Model for Common Operational Statistics", RFC
+ 1404, NORDUnet/SUNET, January 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark Informational [Page 15]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+Appendix A: Sample Client-Server Sessions
+
+ Session 1: Check available variables on device rtr1 interface eth0
+
+ >LOGIN "henry" "skey"
+ <CHAL "78 lo35098"
+ >AUTH "COW MOO DOG BARK CAT MEOW"
+ <910 "Login OK, what now?"
+ >LIST OARnet rtr1 eth0 * * * *
+ <941 "List lookup OK, here it comes!"
+ <START-LIST
+ <OARnet rtr1 eth0 ifInOctets
+ <OARnet rtr1 eth0 ifOutOctets
+ <OARnet rtr1 eth0 ifInErrors
+ <OARnet rtr1 eth0 ifOutErrors
+ <END-LIST
+ <942 "List done!"
+ >EXIT
+ <990 "OK, Bye now!"
+
+
+ Session 2: Retrieve a bit of data from the server
+
+
+ >LOGIN henryc "skey"
+ <CHAL "78 lo35098"
+ >AUTH "COW MOO DOG BARK CAT MEOW"
+ <910 "Login OK, what now?"
+ >SELECT OARnet rtr1 eth0 InBytes 15min 1993-02-01 00:00:00 1993-03-01 23:59:59
+ <920 "TAG blah"
+ >STATUS
+ <931 "here it comes..."
+ <STATUS= OK
+ <TAG blah SIZE 654321
+ <932 "all done"
+ >GET blah 1404
+ <951 "here it comes..."
+ <START-DATA 1404
+
+ 1404 data here
+
+ <END-DATA
+ <952 "wow, all done"
+ >EXIT
+ <990 "OK, bye"
+
+
+
+
+
+
+Clark Informational [Page 16]
+
+RFC 1856 Opstat Client-Server Model October 1995
+
+
+Author's Address
+
+Henry Clark
+BBN Planet Corp.
+150 Cambridge Park Dr.
+Cambridge, MA 02140
+
+Phone: (617) 873-4622
+EMail: henryc@bbnplanet.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Clark Informational [Page 17]
+