Service center standards for remote usage: A user's view
RFC 231

Document Type RFC - Unknown (September 1971; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 231 (Unknown)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                     J. Heafner - Rand
Request for Comments  231                 E. Harslem - Rand
NIC 7648                                  21 September 1971

                        SERVICE CENTER STANDARDS
                        ------------------------
                    FOR REMOTE USAGE--A USER'S VIEW
                    -------------------------------

INTRODUCTION
------------

     This note is a statement of our views on service cen- ter
standards.  It is an input to the service center panel discussion of
the October Network meeting.  Some areas are identified for
consideration in intra-network standardiza- tion.  We do not describe
a methodology for analyzing com- puter systems; however, such analysis
may be appropriate for solving the problems.  We also do not enumerate
the spectrum of services that may be required.  We merely enu- merate
areas where commonality of appearance and function can be of immediate
value to a network user.

CAVEAT
------

     It is assumed that service centers will conform to official
network standard protocols.  This is essential for service centers
since the effects of their practices are generally more wide-spread
and are crucial to the effectiveness of minimal hosts such as TIPs.

JUSTIFICATION
-------------

     The generation of network standards for service centers is of
value to a very important class of people--the ultimate user
community.  We have such a community at Rand that is composed of
research scientists and their support programmers.  Certainly such
users exist elsewhere, and a goal of the net- work must be to
encourage their use.  In the past, these researchers have relied
solely on programmers to buffer them from computer detail.
Standardization of services is cer- tainly a great value in expanding
the community of users and eliminating the buffer.

     Additionally, standards will be of benefit to those persons
responsible for implementation of resource access programs.  Instances
and areas of standardization are cited below to support both of these
statements.

                                                                [Page 1]
AREAS FOR STANDARDIZATION
-------------------------

     Each host installation has its own standards for pro- gramming
and operational procedures.  From a network point of view, we are only
interested in standards affecting external performance--primarily
required operations and documentation of procedures.  Intra-network
standards should allow a user to plan his network use effectively to
improve the performance of his tasks and take advantage of savings in
both time and money.

Remote Job Entry
----------------

     One immediately apparent area for standardization is in the
access to network resources.  For example, there are two remote job
entry (RJE) facilities on the network at present with two different
data protocols.  The UCSB facility was developed early to provide
timely access to their resources.  The UCLA facility was developed
after the Telnet and Data Transfer protocols and takes advantage of
them.  If these two services appeared alike to the user and to the
using process, two significant advantages would be obtained.  First,
the using system would need only one module to access both facilities.
And secondly, a user could select either facility on a dynamic basis
using the conditions influencing him at any given moment without any
additional knowledge of the specific site.

Login Procedures and Subsystem Access
-------------------------------------

     A more global example of common access to resources is the login
procedure to remote systems.  All systems require basically the same
information--password, identification, account number.  Yet the
formats are syntactically inconsis- tent.  An extension to the logger
generally exists at these sites in the form of a "line scanner" for
the network.  In general, this module also performs other
transformational functions.  It would certainly be reasonable for this
module to translate a network standard login into whatever format was
required at the site.  Perhaps to a lesser extent, a similar approach
could be taken to constructing a uniform access to subsystems from the
supervisor.  In like fashion, a network standard interrupt could be
translated into the escape (e.g., control C) of the serving host to
return from a subsystem.

Charging Algorithms and Accounting Protocol
-------------------------------------------

     To accurately forecast costs, a normalized formula for machine

                                                                [Page 2]
time estimation is needed.  Technically, an accounting protocol is
easily added at the subnet and/or NCP levels--the relevant information
is the same for all nodes, thus the Net charges are readily determined
by any node.  More difficult is the prediction and comparison of host
charges.  Like the login procedure example, each host uses the same
ingredients, namely storage, I/O, connect time, and CPU resources
Show full document text