doc: Add RFC documents

1 files changed, 2019 insertions, 0 deletions

diff --git a/doc/rfc/rfc1210.txt b/doc/rfc/rfc1210.txt
new file mode 100644
index 0000000..de0fd24
--- /dev/null
+++ b/doc/rfc/rfc1210.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group                                            V. Cerf
+Request for Comments: 1210                                          CNRI
+                                                             P. Kirstein
+                                                                     UCL
+                                                              B. Randell
+                                                       Newcastle on Tyne
+                                                                 Editors
+                                                              March 1991
+
+
+            Network and Infrastructure User Requirements for
+                  Transatlantic Research Collaboration
+         Brussels, July 16-18, and Washington July 24-25, 1990
+
+Status of this Memo
+
+   This report complements a shorter printed version which appeared in a
+   summary report of all the committees which met in Brussels and
+   Washington last July, 1990.  This memo provides information for the
+   Internet community.  It does not specify an Internet standard.
+   Distribution of this memo is unlimited.
+
+Abstract
+
+   This report summarises user requirements for networking and related
+   infrastructure facilities needed to enable effective cooperation
+   between US and European research teams participating in the planned
+   ESPRIT-DARPA/NSF programme of collaborative research in Information
+   Science and Technology.  It analyses the problems and disparities of
+   the current facilities, and suggests appropriate one and three year
+   targets for improvements.  It proposes a number of initial actions
+   aimed at achieving these targets.  Finally, the workshop has
+   identified a non-exhaustive set of important issues upon which
+   support of future research will depend.  These issues could be
+   studied in the short term, with the aim of initiating a programme of
+   joint research in collaboration technology within the next year.
+
+SUMMARY OF PRINCIPAL RECOMMENDATIONS AND TARGETS
+
+   EMAIL (6.1) Initiate an intercontinental email operations forum
+   involving email service providers in the US and Europe to define and
+   implement operational procedures leading to high reliability.  The
+   forum should be tasked with analysing interoperability problems in
+   the existing email systems, and with developing functional and
+   performance specifications for email gateways (relays).  In addition
+   an international email user support group should be organized.  The
+   target would be to achieve, within one year, routine expectation of
+   proper and timely (less than one hour campus to campus) delivery of
+
+
+
+Cerf, Kirstein, & Randell                                       [Page 1]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   messages.  The three year target would be to provide global directory
+   services, a return/receipt facility, and support for privacy and
+   authenticity.
+
+   COMPOUND DOCUMENTS (6.2) Hold a workshop to review the ongoing
+   compound document research and development programmes in the two
+   regions.  One aim would be to recommend services, based on
+   proprietary compound document email for groups using specific
+   conforming products, for deployment within the first year.  Another
+   would be to propose work items in the NSF/DARPA and ESPRIT programmes
+   to ensure a timely collaborative programme could start in mid-1991,
+   with a three year target of supporting open system compound document
+   email.
+
+   DIRECTORY SERVICES (6.3) Initiate a formal collaboration between
+   ongoing US and European efforts to implement and maintain the
+   relevant directory databases.  Within the first year provide
+   effective access to existing directory services, and coverage of
+   relevant NSF/DARPA and ESPRIT communities.  Within three years
+   provide database maintenance tools, knowledge-based navigation
+   software, and authentication and capability-based access control
+   facilities.
+
+   INTERACTIVE LOGIN (6.4) Identify for which protocol suites
+   interactive login will be supported including the provision of
+   protocol translation facilities.  Within one year identify and
+   install the best available interactive software at all interested
+   sites.  Develop a cooperative effort on authentication and privacy
+   support, to provide such facilities within three years, together with
+   support for "type of service", and remote X-windows even through
+   different protocol suites.
+
+   FILE SERVICES (6.5) Identify and deploy within one year the best
+   available products for double-hop (staged) multi-megabyte file
+   transfer.  Within three years define and obtain or develop multi-
+   protocol facilities with automated staging, security and management
+   facilities; develop access control models, policies and mechanisms to
+   support collaborative file access by ad hoc groups.
+
+   GROUP COMMUNICATIONS SERVICES (6.6) Form a support/working group on
+   the use of tools, standards and facilities for group communication
+   services; set up a working group to harmonize current development
+   activities in group communications with the aim of early deployment;
+   hold a workshop to propose a harmonized programme of work in the
+   future programmes of ESPRIT and DARPA/NSF.  The one year target is to
+   provide administrative support for maintaining email mailing lists,
+   bulletin boards and shared databases, and to deploy facilities for
+   multi-site interactive blackboards.  The main three year target is to
+
+
+
+Cerf, Kirstein, & Randell                                       [Page 2]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   provide intercontinental services based on mature "advanced
+   groupware" facilities.
+
+   VIDEO CONFERENCING (6.7) Within a year install existing technology at
+   a limited number of sites in both regions; within three years extend
+   these, probably according to international standards, to have enough
+   sites to be available without undue travel; organize a workshop on
+   packet/ISDN/ATM video conferencing.
+
+   COMPUTER SUPPORTED COLLABORATIVE GROUP WORKING (6.8 and 7) Set up a
+   workshop to study the needs of a collaborative effort to provide
+   intercontinental packet video, multimedia conferencing and computer
+   supported collaborative group technology facilities.  The workshop
+   should, within a year, propose actions which could be made the basis
+   of a future harmonized ESPRIT and DARPA/NSF work program.  Within
+   three years set up a transatlantic testbed facility to support
+   collaborative research programs.
+
+   ACCESS TO UNIQUE RESOURCES (6.9) Organize a workshop dedicated to
+   analysing the needs, and defining the steps required, to provide
+   pilot access to one or more specific such resources - with due
+   attention to networking needs, security provisions, documentation and
+   advisory requirements, and usage policies.  This is to be done within
+   a year - within three years one or more significant transatlantic
+   pilots should be set up demonstrating remote secured access.
+
+   DISTRIBUTED VISUALIZATION (6.10) A working group should be set up to
+   select which current development efforts in distributed visualization
+   to support, identify required standards and begin to distribute
+   techniques and software, all within a year.  Its year 3 target should
+   be to establish mutually agreed upon standards and demonstrate
+   transatlantic distributed visualization applications.
+
+   NETWORK MANAGEMENT (6.11) Convene an international research network
+   operations, planning and management team to develop and apply
+   procedural and technical recommendations for international network
+   management; organize a set of international network operations
+   centers devoted to configuration management, fault detection,
+   isolation and repair of network problems; form one or more
+   intercontinental Computer Emergency Response Teams to coordinate
+   response to attacks against hosts and networks and to develop
+   procedures for collecting actionable evidence.  Within one year put
+   in place an administrative structure to coordinate existing
+   facilities manually and to plan technical solutions; within three
+   years technology for automating international network management
+   should have been developed and deployed.
+
+
+
+
+
+Cerf, Kirstein, & Randell                                       [Page 3]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   MULTI-PROTOCOL SUPPORT (6.12) Validate current multi-protocol
+   solutions, with a one year target of supporting campus-to-campus
+   communication for a subset of coexisting protocol suites (at least
+   OSI and TCP/IP), and of deploying internationally supported versions
+   of existing application level (protocol-translating) gateways;
+   collaborate on research and experimentation with multi-protocol
+   routing and resource allocation; make recommendations, to funders and
+   national research network service providers, on technical solutions
+   and standards for multi-protocol support.  Within three years deploy
+   improved management and resource allocation facilities for multi-
+   protocol routers in order to provide service guarantees.
+
+   CLIENT-SERVER FACILITIES (6.13) Within one year provide limited
+   bandwidth intercontinental X-windows, and convene workshops to
+   achieve agreements on Remote Procedure Call and Intercontinental
+   Distributed File System protocols; form a working group on support
+   for X-Windows in OSI and to validate performance through TCP/TPn
+   protocol translating gateways; initiate collaboration on
+   implementation and test of intercontinental RPC and distributed file
+   systems.  The main three year target is to achieve support for
+   intercontinental RPC and Distributed File Systems.
+
+   ARCHIVAL STORAGE FOR DISTRIBUTED COMPUTING ENVIRONMENTS (6.14)
+   Convene an international workshop whose goals are to ascertain the
+   relevance to this group of the data storage reference model that is
+   nearly ready to be declared an official standard guide; to carry out
+   an on-going discussion of the system issues that have to be developed
+   as a result of this model; to arrive at solutions to be proposed by
+   vendors and users for implementations of Data Systems Storage
+   Solutions which are modular, interconnectable, and standard.
+
+   DATA REPRESENTATION AND EXCHANGE (6.15) It is proposed that an
+   international working group be established to recommend a standard
+   collection of software encompassing a variety of data
+   representations.  This working group should address the issue of data
+   identification embedded in the data stream to allow for later
+   extensions.  After an initial planning meeting, the group would
+   schedule subsequent meetings annually to finalise the current data
+   exchange standard recommendation, and to define new work scopes.  The
+   working group would also make their recommendation known to other
+   standards bodies.
+
+   TRANSATLANTIC AND CONTINENTAL DISTRIBUTION FACILITIES (6.16) This
+   item is put last only because it is a corollary of the preceding
+   recommendations.  Use existing joint US/European coordination
+   mechanisms (e.g., CCIRN) for planning of higher speed, transatlantic
+   links; convene a special CEC/DARPA/NSF task force to consider much
+   higher speed transatlantic capacity sharing options; ensure that
+
+
+
+Cerf, Kirstein, & Randell                                       [Page 4]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   there is an infrastructure in Europe paralleling the US one of
+   providing the majority of relevant campuses access at speeds
+   approaching 1.5 Mb/s; encourage European user groups with high data
+   transmission requirements to aggregate their data transmission
+   facilities; attempt to integrate European application projects (like
+   the RACE Applications Pilots) to assist in providing an appropriate
+   European distribution network with 10-500 Mb/s access to appropriate
+   campuses.  The one year targets are to install 2 Mb/s multi-protocol
+   distribution facilities in Europe, and 1.5 Mb/s (or higher)
+   transatlantic capacity.  The three year targets are to install 2
+   additional 1.5 Mb/s (or higher) transatlantic links, and to determine
+   the feasibility of sharing much higher bandwidth transatlantic links.
+
+1.  INTRODUCTION
+
+   The Networks and Infrastructure Working Group (NIWG) attempted to
+   synthesize requirements and identify potential cooperative
+   development efforts for network-based capabilities both by internal
+   discussion within the working group and through interaction with the
+   other working groups in the workshop.
+
+   It is essential for the facilities supporting DARPA/NSF-ESPRIT
+   collaboration to be consistent with services being used by the US and
+   European projects for their own internal collaboration.  We have,
+   therefore, had to consider both what facilities must be available in
+   the two regions separately and then what must be done to facilitate
+   US-European collaboration.
+
+   Between the US and Europe, the Coordinating Committee for
+   Intercontinental Research Networks (CCIRN) is addressing the
+   improvement of coordination of network services.  To support US
+   DARPA/NSF and ESPRIT collaboration, it will be necessary to extend
+   the use of network services in each region as well as to improve the
+   quality of services linking the regions.
+
+   The NIWG met both in Brussels and in Washington.  It was led by Ira
+   Richer (DARPA) and Rolf Speth (CEC) in Brussels, and Tom Weber (NSF)
+   and Rosalie Zobel (CEC) in Washington.  The participants were largely
+   different in the two meetings, but it was agreed that there would be
+   a common set of minutes.  It is a commentary on the quality of the
+   infrastructure available to some of the participants that nine
+   people, from both sides of the Atlantic, contributed to these minutes
+   over five days - all by email.  The participants are listed in
+   Appendix A; a complete set of addresses (including telephone,
+   facsimile and email) are given in Appendix B.  Because many of the
+   abbreviations used here may not be familiar to all the readers, a
+   Glossary of Terms is given in Appendix C.
+
+
+
+
+Cerf, Kirstein, & Randell                                       [Page 5]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+2.  SCOPE AND OBJECTIVES
+
+   The scope of the working group was to concentrate on generic,
+   network-based user services considered helpful for a wide range of
+   collaborative work between US and European groups.  We distinguished
+   between the capabilities which would benefit from immediate attention
+   or were required in the short term (e.g., within a year), and those
+   which required longer term development.  While the prescribed scope
+   was to act only in support of the other groups by making use of
+   available technology, we identified one area where we felt more
+   research and development was an important adjunct to our scope.
+
+   The working group agreed that the major objectives, based on
+   instructions given in the opening plenary sessions, were to identify
+   the following:
+
+   (i)   user requirements which must be satisfied to support
+         cooperative US/European research;
+
+   (ii)  technical and other infrastructure requirements which must be
+         satisfied to support cooperative US/European research;
+
+   (iii) opportunities and potential means for satisfying these
+         requirements;
+
+   (iv)  potential obstacles to achieving the desired support;
+
+   (v)   mutual benefits which would accrue to the participants in
+         recommended cooperative projects;
+
+   (vi)  promising collaborative development activities needed for
+         a better infrastructure.
+
+3.  MOTIVATION FOR COLLABORATION ON NETWORKING AND INFRASTRUCTURE
+
+   Computer networking, by its very nature, requires cooperation and
+   collaboration among the participants developing, implementing,
+   deploying and operating the hardware and software comprising the
+   system.  The long-term vision is the creation of an infrastructure
+   which provides the user (rather than the network) with a distributed
+   multi-vendor heterogeneous computing environment - with transatlantic
+   facilities approaching those available locally.
+
+   A major element of successful networking is the agreement on
+   standards which are to be met by all systems included in the network.
+   Beyond technical agreements, there must also be concurrence on
+   operational procedures, performance objectives, support for the users
+   of the network and ability to plan for enhancement and growth of
+
+
+
+Cerf, Kirstein, & Randell                                       [Page 6]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   network services.
+
+   A consequence of these observations is that virtually any effort to
+   provide network service support to ESPRIT-DARPA/NSF collaboration
+   should be carried out cooperatively between the US and European
+   network research, design, development, engineering and operations
+   communities.
+
+4.  CURRENT STATE OF NETWORKING IN THE US AND EUROPE
+
+   In the DARPA/NSF communities, there is heavy use of electronic mail
+   and computer networking to support a wide range of scientific
+   research.  There is heavy use of the TCP/IP and DECNET protocols as
+   well as special electronic mail protocols in the BITNET and Unix
+   users networks (e.g., UUNET).  Email use varies in intensity among
+   different research disciplines.
+
+   There is an emerging interest in and use of OSI-based protocols,
+   particularly for email (X.400) and directory services (X.500).  Most
+   of the backbone networks making up the Internet use 1.5 Mb/s
+   telecommunications facilities although the NSFNET will be installing
+   a high speed, 45 Mb/s subnetwork during 1990.  There are many Local
+   Area Networks (LANs).  Plans are in place to support both IP (as in
+   TCP/IP) and CLNP (as in OSI) datagram protocols in backbone and
+   regional networks.  Most of these protocols are already supported on
+   LANs.  On a selective research basis, a set of 1000 Mb/s research
+   testbeds are being installed during 1990-1993.
+
+   In Europe, especially amongst the ESPRIT collaborators, there is more
+   limited use of computer networking, with the primary emphasis on the
+   use of electronic mail and bulletin boards.  There is a strong focus
+   on OSI protocols in European wide-area networks, but there is a
+   considerably amount of TCP/IP use on LANs, and growing use of TCP/IP
+   in Wide Area Networks (WANs) in some countries.  Most of the national
+   wide-area networks are based on the CCITT X.25 protocols with access
+   speeds up to 64 Kb/s, though higher access speeds in the 2 Mb/s range
+   are planned for many countries, and just becoming available in some.
+   An X.25 international backbone (IXI) has just become operational,
+   which connects in the National Research Networks and/or the Public
+   Packet Data Networks in each Western Europe country at 64 Kb/s.  The
+   funding of this network has only been agreed for a further short
+   period, and plans to upgrade it to higher speed access are not
+   agreed.  There are many LANs in place.  The OSI connection-oriented
+   network service (CONS) is layered above X.25, but there is growing
+   interest in supporting the connectionless service (CLNS) concurrently
+   with the Internet IP in national and international backbone networks.
+   Application testbeds at higher speeds are planned under the CEC RACE
+   programme.  Many of its higher level user services have not been
+
+
+
+Cerf, Kirstein, & Randell                                       [Page 7]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   specified collaboratively - as would be required for wide deployment.
+   These points are explained further in Section 6.
+
+   Thus although provisions or plans regarding National networks in some
+   CEC member states are not so far behind the American facilities, one
+   must note that in effect, because of continental backbone
+   limitations, Pan-European facilities are at least a generation
+   behind.  Specifically, both with respect to existing and planned
+   backbone provisions, there is a factor of 25 difference between
+   Europe and the USA.  In addition, this approximate comparison
+   flatters the European scene, since it compares facilities that are
+   just coming into existence, and plans that are not yet agreed or
+   funded, on the European side with facilities that have been available
+   for some time, and plans that will be realised before the end of this
+   year, in the USA.
+
+5.  POLLS OF THE OTHER WORKING GROUPS
+
+   The NIWG polled the other seven working groups meeting in Brussels
+   and Washington to find out what networking and infrastructure support
+   their collaborations might require.  In general, a strong emphasis
+   was placed on the provision of reliable and timely email, easier
+   accessibility of email service, user support and information on
+   existence and use of available services.  There was serious concern
+   about privacy, and great interest in transparency (i.e., hiding the
+   details of intercontinental networking).
+
+   Some users mentioned that FAX was easier to use and apparently more
+   ubiquitous than email for their communities (there are over 12 M
+   facsimile machines installed world-wide).  Interest in integrating
+   FAX and email was noticeable.  Most users recognised the many
+   advantages of email for multiple addressees, subsequent reprocessing,
+   relaying and cost.
+
+   The requirement for large file transfer was patchy.  Many did not
+   require such facilities, but several groups required transfer of 100
+   MB files and some even 1 GB.  Many groups desired remote log-in, but
+   found present performance - even on the Internet - inadequate.
+   Several wanted global file services and file sharing.
+
+   Many groups wished to use video conferencing - but only if they did
+   not have to travel more than two hours to a suitable facility.  Some
+   groups were interested in computer supported group collaboration -
+   but most did not understand this term.
+
+   One group (Vision) desired real time transfer at 300 Mb/s, but most
+   had much more modest user-user needs.  The needs for less visible
+   features like network management, client-user technology, remote
+
+
+
+Cerf, Kirstein, & Randell                                       [Page 8]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   visualization standards and data representation and exchange formats
+   were not voiced explicitly.  However they could be deduced from the
+   services which the users did request.
+
+6. USER SERVICES NEEDED IN THE SHORT AND MEDIUM TERM
+
+   To support collaboration between the research workers, we need a
+   number of services between the end users.  These require provisions
+   which impinge on many management domains: inside individual campuses;
+   campus-wide area gateways; national distribution; regional-
+   intercontinental gateways; intercontinental distribution.  However,
+   from the users' viewpoint, this set of services should constitute a
+   system whose internal details are not, or at least should not, be of
+   concern.  It is the overall performance and reliability exhibited,
+   and the facilities made available to the user (and their cost), which
+   matter.  Inadequacies of bandwidth, protocols, or administrative
+   support anywhere in the chain between the end users are, to them,
+   inadequacies in the system as a whole.
+
+   To some extent more funding from DARPA/NSF and the CEC can alleviate
+   the current difficulties.  However it is likely that such funding
+   will impact only the international and intercontinental components.
+   It is essential that the end-user distribution be strengthened also.
+   In the US this requires both Regional and Campus Networks.  In
+   Europe, it requires activity by the National network authorities
+   (usually represented in RARE and/or COSINE), and by the Campus
+   network providers.  Moreover, not only must the transmission
+   facilities be strengthened, but also the appropriate protocol suites
+   must be supported; this may require policy decisions as well as
+   technical measures.
+
+   We indicate below the services which are required immediately, and
+   are visible to the end-users.  They often have implications to the
+   service providers which have far-reaching consequences.  Some of the
+   services are urgent user services; some are underpinning requirements
+   needed to assure the user services; some are longer term needs.
+   There is clearly a strong interaction between the user services and
+   the underpinning ones; there is also some between the user services
+   themselves.  Partly as a result of our own deliberations, and partly
+   as a result of our polls of the other working groups, we have
+   identified needs in the areas below.
+
+USER SERVICES
+
+   In most cases these are services which are available in local or
+   homogeneous environments.  For the proposed collaborations they must
+   be available on an intercontinental basis between heterogeneous
+   systems.
+
+
+
+Cerf, Kirstein, & Randell                                       [Page 9]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+6.1  Electronic Mail
+
+   The current email services between the US and Europe suffer from gaps
+   in connectivity, lack of reliability and poor responsiveness.  These
+   problems stem, in part, from the multiplicity of protocols used (and
+   requiring translation) and in part from an inadequate operations and
+   maintenance infrastructure.  There are few user and directory support
+   services available; access to, and use of, email service varies
+   dramatically.  However, some initial cooperative work has started
+   already between RARE Working Group 1 and participants in the Internet
+   Engineering Task Force in the area of email.
+
+6.1.1  One Year Targets
+
+   (i)  Provide management structure to support user assistance and
+        reliable operation of email relays;
+
+   (ii) Achieve routine expectation of proper and timely (less than
+        1 hour campus-campus) delivery.
+
+6.1.2  Three Year Targets
+
+   (i)   Provide global, email directory services;
+
+   (ii)  Develop and deploy a return/receipt facility;
+
+   (iii) Provide support for privacy and authenticity.
+
+6.1.3  Recommended Actions
+
+   (i)   Initiate an intercontinental email operations forum involving
+         email service providers in the US and Europe to define and
+         implement operational procedures leading to high reliability;
+
+   (ii)  Task the email operations forum to develop functional and
+         performance specifications for email gateways (relays);
+
+   (iii) Organize an international email user support group;
+
+   (iv)  Organize a collaborative working group to analyse email
+         interoperability problems (X.400, UUCP, SMTP, EARN, EUROKOM,
+         BITNET) and make recommendations for specific developments to
+         improve interoperability.
+
+   Included in the terms of reference should be requirements for
+   cryptographic support for privacy, authenticity and integrity of
+   email.  This work could include specific collaboration on X.400 and
+   SMTP privacy enhancement methods.  (Note there are serious
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 10]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   international obstacles to achieving progress in areas involving
+   cryptographic technology.)
+
+   See Directory Services section for further possible actions.
+
+6.2  Compound Document Electronic Mail
+
+   While proprietary solutions for compound documents (text, font
+   support, geometric graphics, bit-map graphic, spread-sheets, voice
+   annotation, etc.) exist, these are limited to products of single
+   manufacturers.  While international standards for compound documents
+   exist, these are still evolving, and few real commercial products
+   based on the standards exist.  Nevertheless, both proprietary and
+   open systems compound document mail services could be made available
+   reasonably quickly.
+
+6.2.1  One Year Targets
+
+   (i)  Support proprietary compound document email for groups
+        interested in using specific conforming products;
+
+   (ii) Provide experimental services to groups with open systems
+        offerings using several products.  Support interoperation
+        for multi-font text, bit-mapped and geometric graphics.  The
+        software could be provided from that arising from the
+        combination of a previous NSF and an ESPRIT proposal.
+
+6.2.2  Three Year Targets
+
+   Provide support for open system compound document email and document
+   exchange including the following facilities: spreadsheets; integrity,
+   authentication and non-repudiation of origin of document parts;
+   confidentiality of document parts.
+
+6.2.3  Recommended Actions
+
+   Hold a workshop to review the ongoing compound document research and
+   development programmes in the two regions.  One aim would be to
+   recommend services for deployment in the short term.  Another would
+   be to propose work items in the NSF/DARPA and ESPRIT programmes to
+   ensure a timely collaborative programme could start in mid-1991.
+
+6.3  Directory Services
+
+   White pages services to assist network users to find email addresses,
+   computer services and other on-line facilities are, at best, only
+   lightly deployed in both the US and Europe.  If networked services
+   are to become infrastructural in nature, directory services must be
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 11]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   widely implemented, deployed and easily accessible.  In addition to
+   working with international standards such as CCITT X.500, access to
+   the installed base of white pages services (such as the US WHOIS
+   service and the UK NRS service) is essential.  These facilities are
+   also needed to support key management for cryptographic services
+   required for authenticity, integrity and confidentiality of email and
+   other communications.  Because there are different legal and
+   organizational views of directory service information, it will also
+   be critical to address organizational and international differences
+   in the sensitivity of such data and its accessibility.
+
+   It is essential that directory service databases be built and
+   maintained throughout the US and European research communities.
+
+6.3.1  One Year Targets
+
+   (i)  Get effective access to existing directory services
+        (X.500 and others);
+
+   (ii) Put in data for relevant NSF/DARPA and ESPRIT communities.
+
+6.3.2  Three Year Targets
+
+   (i)   Provide tools to support database maintenance;
+
+   (ii)  Provide good knowledge-based navigation software;
+
+   (iii) Provide strong authentication facilities;
+
+   (iv)  Provide capability-based access restrictions.
+
+6.3.3  Recommended Actions
+
+   Initiate a formal collaboration between ongoing US and European
+   (e.g., RARE WG3) efforts to implement and maintain the relevant
+   directory databases.
+
+6.4  Interactive Login
+
+   Interactive access to service systems in the US and Europe is, at
+   present, only partly feasible.  One inhibiting factor is incompatible
+   protocol suites in use in the provision of such services.  The
+   implementation and deployment of common protocols, and the provision
+   of protocol translation gateways, are needed to improve this
+   situation.
+
+
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 12]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+6.4.1  One Year Target
+
+   Identify and install the best available interactive login software
+   (using staging gateways, if necessary) on all interested sites.
+
+6.4.2  Three Year Targets
+
+   Improve interactive login performance to include support for:
+
+   (i)   "type of service" (quality or grade-of-service);
+
+   (ii)  support for privacy;
+
+   (iii) support for authentication;
+
+   (iv)  support for remote X-windows even through different protocol
+         suites.
+
+6.4.3  Recommended Actions
+
+   (i)   Identify for which protocol suites interactive login will be
+         supported;
+
+   (ii)  Determine mechanisms for good performance in staged facilities
+         (i.e., in which it is necessary to login and then open
+         manually new connections from the intermediate gateways);
+
+   (iii) Develop a cooperative effort on authentication and privacy
+         support.
+
+6.5  File Services
+
+   File transfers are not easily achieved in the multi-protocol
+   environment, and long files cannot be transferred reliably.  Manual
+   movement of files through staged, protocol-translating gateways is
+   awkward and often unreliable.  Performance of file transfer software
+   varies substantially.  Improvements in file transfer facilities are
+   needed, but there should also be other forms of file service based on
+   shared file systems.
+
+6.5.1  One Year Targets
+
+   Develop or identify and install the best available file transfer
+   software (providing staging gateways, if necessary) to support:
+
+   (i)   Multi-megabyte file transfers;
+
+   (ii)  Translation between distinct file transfer protocols;
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 13]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   (iii) High performance and robustness;
+
+   (iv)  Use of wide-area file systems, e.g., Andrew;
+
+   (v)   Ad hoc sharing of sections of file systems across two machines.
+
+6.5.2  Three Year Targets
+
+   Develop (or obtain) and deploy file transfer services with:
+
+   (i)   support for privacy, authentication and integrity;
+
+   (ii)  support for automatic staging through several file transfer
+         relays;
+
+   (iii) support for multi-party access of selected portions of file
+         systems across multiple machines.
+
+6.5.3  Recommended Actions
+
+   (i)   In conjunction with RARE WG4 and IETF, identify best available
+         products for multi-hop (staged) file transfer;
+
+   (ii)  Define and carry out comparative performance tests to select
+         best available file transfer software, including checkpointing;
+
+   (iii) Define and implement fuller multi-hop, multi-protocol
+         facilities with automated staging, security and management
+         facilities;
+
+   (iv)  Develop access control models, policies and mechanisms to
+         support collaborative file access by ad hoc groups.
+
+6.6  Group Communication Services
+
+   Coordination of collaborative efforts can be substantially enhanced
+   through provision of mailing lists, bulletin boards and shared
+   databases.  Setting up and managing such facilities, however,
+   typically requires special knowledge and privileges.  Making it
+   possible to set up and operate such facilities easily and without
+   special privileges would enhance the infrastructure of support for
+   collaborative activities between the US and Europe (and within each
+   region as well).
+
+   More advanced group communication services such as shared screens
+   with voice teleconferencing, distributed publishing through
+   electronic libraries, and various forms of teleconferencing, might
+   relieve some of the necessity for face-to-face meetings, if
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 14]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   sufficiently reliable and easy to use.  The prior use of such
+   facilities make subsequent face-to-face meetings much more productive
+   also.  Of course, time zone differences are a challenge to any real-
+   time conferencing schemes, and are often the primary rationale for
+   arranging face-to-face conferences which "force" participants to
+   enter the same time zone for the duration of the meeting.
+
+6.6.1  One Year Targets
+
+   (i)  Provide administrative support for setting up and maintaining
+        email mailing lists, bulletin boards and shared databases;
+
+   (ii) Provide facilities for multi-site interactive blackboards
+        including text, graphics, spreadsheets and program access.
+
+6.6.2  Three Year Targets
+
+   (i)  Provide intercontinental services based on more mature "advanced
+        groupware" facilities including shared screens and voice
+        services;
+
+   (ii) Extend interactive blackboard to include slow scan video, voice,
+        animation, and using international standards where feasible.
+
+6.6.3  Recommended Actions
+
+   (i)  Form a support/working group on the use of tools, standards and
+        facilities for group communication services;
+
+   (ii) Initiate collaboration on advanced group communications (e.g.,
+        shared screens, distributed electronic publishing, etc.).
+
+6.7  Video Conferencing
+
+   Facilities for low bandwidth (under 1 Mb/s) interactive video/voice
+   conferencing (e.g., packet-based) are, at present, unavailable for
+   support of intercontinental collaboration.  Even two-party
+   videoconferencing could be beneficial initially.  The comments from
+   the other seven working groups showed a strong interest in the use of
+   videoconferencing, provided the travel to the relevant facilities did
+   not exceed two hours.  This should impact the eventual deployment
+   plans for the facilities.
+
+   Minimum facilities needed for video conferencing include at least 256
+   Kb/s across the Atlantic for each concurrent conferencing channel.  A
+   video codec, two cameras and three monitors are needed at each site
+   along with suitable packetizing equipment if a packet-mode system is
+   to be deployed.  There exists at least one such system in use in the
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 15]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   US, developed by DARPA and used regularly for transcontinental
+   working group meetings.  Another such system is just being
+   commissioned (at University College London).
+
+6.7.1  One Year Target
+
+   Deploy two-party videoconferencing facilities in at least four sites
+   on each continent.
+
+6.7.2  Three Year Target
+
+   Develop and deploy multi-party conferencing capability on a larger
+   scale on both continents, to make the facilities accessible more
+   widely to the collaborators with less travel penalty.
+
+6.7.3  Recommended Actions
+
+   (i)  Install existing technology at a limited number of sites in
+        both regions, in line with the desire to limit travel
+        mentioned above;
+
+   (ii) Organize a workshop on packet/ISDN/ATM videoconferencing.
+
+6.8  Multimedia Computer Supported Group Working
+
+   The NSF has initiated an effort on collaboration technology
+   development and experimentation under the rubric: Collaboratory.
+   Similar research is in progress under the ESPRIT programme.  While
+   the subject of the NIWG's discussions was designated as
+   infrastructure support for the other research collaborations, we
+   believe it is very appropriate to mount a collaborative programme
+   among US and European researchers, which would enhance Collaboratory
+   efforts and force both groups to come to grips with problems of
+   supporting collaboration techniques across intercontinental
+   distances.
+
+6.8.1  One Year Target
+
+   Harmonise the ESPRIT and NSF Collaboratory research programmes.
+
+6.8.2  Three Year Target
+
+   Set up a common, transatlantic testbed facility to support
+   collaborative research programmes.
+
+6.8.3  Recommended Actions
+
+   Set up a workshop to study the needs of a collaborative effort to
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 16]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   provide intercontinental packet video, multimedia conferencing and
+   computer supported collaborative group technology facilities.  The
+   workshop should propose actions which could be made the basis of a
+   future harmonised ESPRIT and DARPA/NSF work programme.
+
+6.9  Access to Unique Resources
+
+   A number of resources can be labelled unique in the scope of
+   ESPRIT/DARPA/NSF or even on a worldwide basis.  Their uniqueness may
+   derive from their nature (e.g., large test facilities or a focus
+   point of knowledge in a discipline) or be such in a transitory phase.
+   In the spirit of the future EC/US cooperation, it is clear that there
+   should be agreed access to some such resources.  This will require:
+
+   (i)   Provision of appropriate access and usage information;
+
+   (ii)  Physical access for visitors;
+
+   (iii) Continued non-local access.
+
+   The third point has clear networking implication.  Appropriate remote
+   access to the resources, connectivity to the users and adequate
+   access speeds have to be provided, possibly together with access
+   control facilities.
+
+   The most demanding cases are those of newly developed products; their
+   transitory uniqueness does not allow one to amortise costs over
+   substantial periods as would be reasonable for large scale centres
+   like NCAR or CERN.
+
+6.9.1  One Year Target
+
+   (i)   Identify appropriate unique transitory resources
+         (e.g., Touchstone);
+
+   (ii)  Specify the provisions needed to make at least one such
+         resource available.
+
+6.9.2  Three Year Target
+
+   Set up one or more significant transatlantic pilots demonstrating
+   remote, secured access.
+
+6.9.3  Recommended Actions
+
+   Organise a workshop dedicated to analysing the needs and defining the
+   steps required to provide pilot access to one or more specific such
+   resources.  The workshop may need to address networking needs,
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 17]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   security provisions, documentation and advisory requirements,
+   modification of current access capabilities, and usage policies.
+
+6.10  Distributed Visualization
+
+   Scientific visualization applications often involve multiple
+   resources.  These resources can span a complete range of
+   sophistication, from simple hardcopy at one end to elaborate
+   rendering at the other end.  Interactive graphics workstations,
+   supercomputers and specialized scientific databases may all be
+   involved in a single application.  The scientist at a workstation
+   should be able to view all of these resources as a single network
+   resource, although they may be physically distributed over
+   considerable distances.  A typical example is a high performance
+   graphics workstation, a supercomputer and a network to connect them
+   together, all with appropriate software.  The workstation may be
+   close to the supercomputer or distant from it.
+
+   Currently there are efforts underway at several installations -
+   including ones funded by NSF/DARPA and ESPRIT - to develop
+   techniques, interfaces and software necessary to create this
+   environment.  In limited instances it already exists.  Better
+   coordination of these efforts on both sides of the Atlantic would be
+   desirable.  Coordinating such efforts across the Atlantic will be
+   necessary for effective collaboration in end-user visualization
+   applications in a variety of disciplines to take place in the future.
+
+6.10.1  One Year Targets
+
+   Identify the significant current development efforts in these areas
+   and determine which ones to support.  Identify the areas requiring
+   standards.  Minimize duplication of effort and begin to distribute
+   the techniques and software.
+
+6.10.2  Three Year Targets
+
+   Establish mutually agreed upon standards.  Demonstrate transatlantic
+   distributed visualization applications.
+
+6.10.3  Recommended Actions
+
+   Establish a working group to further refine and to implement the one
+   year and three year targets and to identify additional distributed
+   visualization topics that would benefit from coordinated efforts.
+   Determine the appropriate mechanisms for supporting such
+   collaborations.
+
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 18]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+UNDERLYING SERVICES
+
+   Most of the services described below are required to achieve the
+   goals of reliability, availability and transparency of the user
+   services.
+
+6.11  Network Management
+
+   Current network management technology and practice are not adequate
+   to support large scale, international research networks.  Time-zone
+   differences and lack of organizational operational network management
+   agreements combine to make international network management a serious
+   challenge.  To be effective, network management must operate on a
+   campus-to-campus basis, since the campuses are the sources and sinks
+   of traffic in the system.
+
+6.11.1  One Year Target
+
+   Put in place an administrative structure to coordinate existing
+   facilities manually and to plan technical solutions.
+
+6.11.2  Three Year Target
+
+   Develop and deploy technology for automating international network
+   management.
+
+6.11.3  Recommended Actions
+
+   (i)    Convene an international research network operations,
+          planning and management team to develop and apply
+          procedural and technical recommendations for international
+          network management;
+
+   (ii)   Organize a set of international network operations centres
+          devoted to configuration management, fault detection,
+          isolation and repair of network problems;
+
+   (iii)  Form one or more intercontinental Computer Emergency Response
+          Teams to coordinate response to attacks against hosts and
+          networks and to develop procedures for collecting actionable
+          evidence.
+
+6.12 Multi-protocol Support
+
+   Users depend on a variety of protocols to support their research.
+   The international network infrastructure does not uniformly support
+   the use of multiple protocols (e.g., DECNET, TCP/IP/ST, OSI) on an
+   end-to-end basis.  The use of various portions of the international
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 19]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   network also may be restricted by policy, and this must be
+   accommodated in implementing routing for campus-to-campus protocols.
+
+   Support for campus-to-campus multi-protocol transmission and routing
+   is needed at a minimum of 64 Kb/s end-to-end - higher for the support
+   of some of the services.  Where the end-users have adopted similar
+   protocols, the intervening networks should not impede the full
+   exploitation of the facilities available in the chosen protocol
+   suite.  Where different protocol suites are used, high quality
+   application-level gateways which can translate among protocols are
+   needed also; to the greatest extent possible, these should allow
+   people to use their own procedures, even though they are
+   communicating with services which use different ones.  For some
+   services, this will lead to a requirement to upgrade access, and
+   possibly even transparent access (including protocol conversion), to
+   at least 1.5 Mb/s between individual campuses in the US and Europe.
+
+6.12.1  One Year Targets
+
+   (i)  Support campus-to-campus communication for a subset of
+        coexisting protocol suites (at least OSI and TCP/IP) at a
+        minimum of 64 Kb/s;
+
+   (ii) Deploy internationally supported versions of existing
+        application level (protocol-translating) gateways.
+
+6.12.2  Three Year Targets
+
+   (i)  Improve management and resource allocation for multi-protocol
+        routers (e.g., to achieve service guarantees);
+
+   (ii) Support campus-to-campus communication at a minimum of 1.5 Mb/s.
+
+6.12.3  Recommended Actions
+
+   (i)   Validate current multi-protocol solutions for intercontinental,
+         and indeed campus-to-campus use;
+
+   (ii)  Collaborate on research and experimentation with multi-protocol
+         routing and resource allocation;
+
+   (iii) Make recommendations, to funders and national research network
+         service providers, on technical solutions and standards for
+         multi-protocol support.
+
+
+
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 20]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+6.13  Client-Server Technology
+
+   Among the more important computer communications techniques emerging
+   on a widespread basis during the last decade is the client-server
+   model of interprocess communication.  This notion was actually
+   developed during the earliest stages of packet network exploration
+   and dramatically enhanced with the invention of local area networks
+   (such as Ethernet) which could support very high speed, low delay
+   inter-computer exchanges.  Applications of this concept range from
+   remote procedure calls to remote file access and support for remote,
+   bit-mapped graphics.
+
+   At present, these techniques work best in a high bandwidth, low delay
+   environment; they are generally not well-supported in wide-area,
+   intercontinental networks.  Collaborative efforts between the US and
+   Europe could be enhanced substantially by support for client-server
+   services on an intercontinental basis.  Such facilities would permit
+   collaborative use of distributed filing systems, X-windows
+   applications and other distributed computing applications.  High
+   capacity, low-delay channels will be needed on an intercontinental
+   basis to support serious use of this technology.  In addition,
+   agreement must be reached on which protocols should be used to
+   support this technology.
+
+6.13.1  One Year Targets
+
+   (i)   Provide limited bandwidth intercontinental X-Windows support
+         for graphical user interfaces;
+
+   (ii)  Achieve agreements on intercontinental Remote Procedure Call
+         and Distributed File System protocols;
+
+   (iii) Validate support of X-Windows under OSI and through protocol
+         translating gateways.
+
+6.13.2  Three Year Targets
+
+   (i)  Achieve selective support for intercontinental remote
+        visualization;
+
+   (ii) Achieve support for intercontinental RPC and Distributed File
+        Systems.
+
+6.13.3  Recommended Actions
+
+   (i)   Convene workshops to achieve agreements on intercontinental
+         Remote Procedure Call and Distributed File System protocols;
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 21]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   (ii)  Form working group on support for X-Windows in OSI and to
+         validate performance through TCP/TPn protocol translating
+         gateways;
+
+   (iii) Initiate collaboration on implementation and test of
+         intercontinental RPC and distributed file systems.
+
+Section 6.14   Archival Storage for Distributed Computing Environments
+
+   There are several major issues that must be addressed by distributed
+   computing environments (DCEs) containing supercomputers.  Resolution
+   of these issues is likely to evolve over the next five to ten years.
+
+   One such issue is archival storage and bitfile management for the
+   complete environment.  Several problems have to be resolved to
+   appropriately handle this situation.  The first problem is the
+   global-naming of bitfiles that are being moved through the DCE
+   to/from the archive.  Second, the file system hierarchy must be
+   defined.  Third, there is the question of how the DCE knows the file
+   system hierarchy for which it is responsible, and the location of the
+   boundary through which the network and the archival system operate.
+   Lastly, there is the question how the file system hierarchy is
+   divided across a DCE and within a supercomputer.
+
+   A second issue in the DCE is the need for all nodes obtaining or
+   storing data to know the storage media differences.  For future
+   systems, this requirement manifests itself both at the distributed
+   nodes and at the supercomputer because of the differences in the
+   physical media structure.
+
+   The third issue is the delineation of the bitfile attributes.  This
+   relates to how the data must be maintained as it migrates through the
+   hierarchy, as well as through the DCE.  The bitfile carries
+   attributes based upon its location in the hierarchy, or in the DCE,
+   that may be different from those needed at the supercomputer level.
+   Many of these attributes are related to the data content and where it
+   resides in time within the DCE.  Section 6.15 discusses some of the
+   possible meta-data representation methodologies that may be used but
+   are not yet standardized.
+
+   Another issue is the determination and implementation of the site
+   policy that is to dictate data migration and allocation inside the
+   DCE archival storage system.
+
+   Several working committees are attacking the various problems
+   delineated above, and are trying to confront the difficulties in
+   these environments.  This work is progressing mostly in the United
+   States.  The IEEE Computer Society Technical Committee on Mass
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 22]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   Storage Systems is in the process of developing a Computer Society
+   draft standard on data storage systems.  The current working draft
+   provides a consistent terminology and an object-oriented design for
+   defining storage subsystem components, whether they are being built
+   around a single system or in a DCE.  Other groups in the computing
+   community are currently dealing with the problems of data migration
+   within a distributed environment.  This distributed environment may
+   or may not include a supercomputer, but it almost always includes a
+   high-volume storage system of some sort delineated as a "mass storage
+   system." This subject was not discussed long enough at the meeting to
+   deduce one year or three year targets - indeed these may well be set
+   by the relevant National working groups.
+
+6.14.1  Recommended Actions
+
+   Convene an international workshop whose goals are:
+
+   1.  An understanding of the contents of the data storage reference
+       model that is nearly ready to be declared an official standard
+       guide;
+
+   2.  To continue discussion of the various system issues that have
+       to be developed as a result of this model;
+
+   3.  To arrive at solutions to be proposed by vendors and users for
+       implementations of Data Systems Storage Solutions which are
+       modular, interconnectable, and standard.
+
+6.15  Data Representation and Exchange
+
+   The problem of data exchange between different computer architectures
+   and operating systems has been existent since the deployment of the
+   early computers.  This problem has been exacerbated by the acceptance
+   of the client-server paradigm as the provider of distributed
+   services.  Distributed computer services require immediate data
+   exchange.  In the past, data was exchanged on some medium, such as
+   tape, and could be examined at leisure.  Ad hoc data conversion
+   routines were created to process the data, and were often embedded in
+   the programs using the data.  Data exchange in the client-server
+   paradigm does not permit this leisurely data examination.  Both the
+   client and the server must be able to "call" software that is
+   guaranteed to convert the exchanged data "on the spot."  This
+   guarantee also implies a standard format rather than the ability to
+   convert all formats because it would be impossible to maintain
+   multiple architecture conversion software and, of course, the size of
+   such conversion software would be enormous.
+
+   The issue of data exchange has been addressed resulting in many data
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 23]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   exchange software packages.  A few of the currently more popular
+   packages are XDR, HDF, NetCDF, PostScript and CCSDS.  Each of these
+   packages addresses a specific type of data.  Some address bitmap
+   data; one addresses the general encoding of "display" information.
+   Some of these packages address various numerical representations in
+   computers.  It is unclear whether any existing package could or
+   should be extended to solve all data exchange problems.  However, a
+   more realistic approach would be a collection of data exchange
+   packages formed as the "standard."
+
+   This item was discussed only briefly at the meeting, so that no one
+   year or three year targets were specified.
+
+6.15.1  Recommended Actions
+
+   It is proposed that an international working group be established to
+   recommend a standard collection of software encompassing a variety of
+   data representations.  This working group should address the issue of
+   embedding identification of the data representations in the data
+   stream to allow for later extensions.  The working group would meet
+   initially to establish a work-scope and to assign the members tasks.
+   The group would schedule subsequent meetings (probably annually) to
+   finalise the current data exchange standard recommendation, and to
+   define new work scopes.  The working group would also make their
+   recommendation known to other standards bodies such as X/OPEN, UI,
+   OSF, X Consortium, NIST, IEEE, ACM, etc.
+
+6.16  Transatlantic Links and Continental Distribution
+
+   At present, there is inadequate transatlantic capacity to support
+   research collaborations involving significant amounts of computer-
+   mediated communication.  There is also considerable room for
+   improvement in the distribution of capacity and enhancement of
+   reliability of network service in Europe.  Moreover, the point was
+   made strongly that collaboration would be very difficult unless the
+   infrastructure on the two sides was broadly comparable - even if the
+   transatlantic capacity was per force lower.  Moreover, it was sharply
+   emphasised that there was a large requirement for transatlantic data
+   flow in other fields - e.g., Space Science, Atmospheric Science and
+   High Energy Physics.  In the US these needs are being aggregated in
+   the National Research and Engineering Network; such aggregation is
+   required also in Europe and on a transatlantic basis.
+
+6.16.1  One Year Targets
+
+   (i)  Install 2 Mb/s multi-protocol distribution facilities in Europe;
+
+   (ii) Install 1.5 Mb/s (or higher) transatlantic capacity.
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 24]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+6.16.2  Three Year Targets
+
+   (i)  Install 2 additional 1.5 Mb/s (or higher) transatlantic links
+        by 1993;
+
+   (ii) Determine feasibility of sharing much higher bandwidth
+        intercontinental links (e.g., in the 51 Mb/s STS-1 range).
+
+6.16.3  Recommended Actions
+
+   (i)   Use existing joint US/European coordination mechanisms
+         (e.g., CCIRN) for planning of higher speed, transatlantic
+         links;
+
+   (ii)  Convene a special CEC/DARPA/NSF task force to consider much
+         higher speed transatlantic capacity sharing options;
+
+   (iii) Ensure that there is an infrastructure in Europe, paralleling
+         the US one, providing the majority of relevant campuses access
+         at speeds approaching 1.5 Mb/s;
+
+   (iv)  Encourage European user groups with high data transmission
+         requirements to aggregate their data transmission facilities.
+         Attempt to integrate European application projects (like the
+         RACE Applications Pilots) to assist in providing an appropriate
+         European distribution network with 10 - 500 Mb/s access to
+         appropriate campuses.
+
+7.  LONGER TERM INITIATIVES
+
+   Although these were not discussed in any detail, for lack of time,
+   the following areas emerged as of interest for longer term
+   collaborative work:
+
+   (i)   Electronic Library Services (includes an important
+         intellectual property rights component);
+
+   (ii)  Multi-media Computer Supported Collaborative Work;
+
+   (iii) Portable Computing/Communications Environments;
+
+   (iv)  Distributed Computing using heterogeneous machines and unique
+         facilities;
+
+   (v)   Compatible approaches to computer networks with Gb/s access
+         speeds, and appropriate systems switching, transmission and
+         protocols.
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 25]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   It was felt that some collaborative research in these areas would
+   have immense medium term benefits to the other communities - and
+   would integrate well with the ongoing research programmes on both
+   sides of the Atlantic.
+
+8.  OBSTACLES
+
+   The largest single obstacle to the provision of the facilities
+   outlined in this report are that development of the necessary
+   facilities do not have priority to most funding agencies.  This is
+   exemplified by the role of our workshops in this series.  Not only
+   network provision, but also development of appropriate infrastructure
+   application software and testbed activity, are essential.
+
+   There are a number of problem areas which could benefit from official
+   attention from CEC and US research funding agencies.  For example,
+   there are a number of open and proprietary protocol suites which are
+   candidates for use in US/European collaborative research.  However,
+   there is lack of political agreement as to how to deal with these
+   various suites.  It would be politically valuable if the CEC and US
+   research agencies could issue a communique outlining common agreement
+   on treatment of multiple protocols (e.g., expressing serious interest
+   in supporting campus-to-campus communication using multiple
+   protocols).  Within the OSI protocol suite, there are differences as
+   to which features ought to make up the standard profile for use by
+   government-sponsored groups.  Handling of connection-oriented and
+   connectionless protocol elements within the suite is the subject of
+   continued debate.  Agreement to support at least TCP/IP and the
+   connectionless network protocol in the OSI suite on an
+   intercontinental basis would be beneficial to both parties; many CEC
+   members would like connection-oriented network protocols to be
+   supported also.
+
+   European international tariffs are relatively high.  This has
+   inhibited the implementation of private networks and impeded progress
+   on collaborative work between the US and Europe.  A CEC initiative to
+   come to grips with this problem could be quite helpful.
+
+   There are a diversity of intra-European networking organizations
+   which have technical, operational and policy interests.  Planning for
+   intercontinental networking infrastructure is sometimes confused by
+   the variety of interested parties.  Effort towards further
+   coordination and rationalization of intra-European networking
+   activities could make intercontinental planning somewhat easier.
+
+   There is a strong interest in the use of cryptographic methods to
+   provide privacy, authenticity and integrity assurance for various
+   forms of intercontinental communication and at various levels in the
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 26]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   protocol hierarchies.  Although there appears to be substantial
+   technical activity in this area, progress is now impeded by national
+   restrictions on the export of software which utilizes cryptographic
+   methods.  National use policies vary and the ability to apply these
+   valuable and needed techniques is uncertain.
+
+   Some national privacy and data protection laws prohibit the creation
+   of directories containing personal information (e.g., email and
+   postal addresses) and other laws limit what kinds of information (and
+   in what form) can be transported across national borders.
+
+   Handling of cryptographic exchanges, import/export of supporting
+   software and exchanges of keying information are all potentially
+   subject to national restrictions and constraints.  The government
+   agencies interested in promoting international collaboration may need
+   to seek alternative international formulations of permitted practice
+   to permit the required technical support.
+
+   Finally, several organizations in the US and Europe have pointed out
+   that the provision of networking infrastructure requires stable
+   funding over significant periods of time.  Stability for
+   infrastructure support has been shaky in the US and in Europe and
+   this presents an obstacle to achieving widespread and reliable
+   network services to aid collaborative efforts.
+
+9.  CONCLUDING REMARKS
+
+   The set of proposals contained in this report provide a realistic,
+   staged approach to ameliorating the grave problems caused by the
+   disparities with respect to bandwidth provision, user services and
+   network protocol issues that impede widespread and close
+   transatlantic collaboration at present between the ESPRIT and
+   DARPA/NSF research workers.  Their implementation will require a
+   considerable degree of commitment to resolve present administrative
+   difficulties, but the financial resources needed would, we estimate,
+   be relatively modest and fully commensurate with the benefits to be
+   gained.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 27]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+APPENDIX A  NIWG PARTICIPANTS
+
+(1) and (2) indicate the Brussels and Washington meetings respectively
+
+Co-chairmen:
+
+Ira Richer (1),(2) Rolf Speth (1) Tom Weber (2) Rosalie Zobel (1),(2)
+DARPA              CEC            NSF           CEC
+
+Rapporteurs:
+
+Vint Cerf (1)    Peter Kirstein (1), (2)     Mike Levine (2)
+CNRI             UCL                         PSC
+
+Other Participants:
+
+Franco Bigi (1)         Adriano Endrizzi (1), (2) Juan Riera(1)
+William Bostwick (1)    David Farber (1)          Jack Thorpe (1)
+Bill Buzbee (2)         Steve Goldstein (1)       Jose Torcato (1), (2)
+Mike Eyre (2)           Sid Karin (2)             Klaus Ullmann (1)
+Robert Cooper (1)       Barry Leiner (1)          Paul Wilson (2)
+Steve Crocker(2)        Jean-Pierre Peltier (2)   Bill Wulf (2)
+Karel De Vriendt(1)     Brian Randell (1), (2)
+
+APPENDIX B - NETWORKING AND INFRASTRUCTURE WORKING GROUP: TELEPHONE,
+EMAIL AND FAX NUMBERS
+
+   Franci Bigi (1)
+   CEC
+   Rue de la Loi 2000
+   B-1049
+   Brussels
+   BELGIUM
+     Tel: +32 2 236 3493
+     Fax: +32 2 235 6937
+
+   William Bostwick (1)
+   US Dept of Energy
+     Tel: +1 703 276 3533
+     Fax: +1 703 276 2536
+     Email: bostwick@darpa.mil
+
+
+
+
+
+
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 28]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   Bill Buzbee (2)
+   National Center for Atmospheric Research
+   P.O.  Box 3000
+   Boulder, CO 80307
+   USA
+     Tel +1 303 497 120?
+     Fax +1 303 497 1137
+   Email buzbee@bierstadt.ucar.edu
+
+   Vinton Cerf (1)
+   Corporation for National Research Initiatives (CNRI)
+   1895 Preston White Drive, Suite 100
+   Reston, VA 22091
+   USA
+     Tel: +1 703 620 8990
+     Fax: +1 703 620 0913
+   Email: vcerf@nri.reston.va.us
+
+   Robert Cooper (1)
+   Rutherford and Appleton Laboratories
+   Didcot, Oxon, 0x11 0QX
+   UK
+     Tel: +44 23544 5459
+     Fax: +44 23544 5808
+   Email: R.Cooper@Rutherford.AC.UK
+
+   Steve Crocker (2)
+   Trusted Information Systems
+   3060 Washington Road
+   Glenwood, MD 21738
+   USA
+     Tel: +1 301 854 6889
+     Fax: +1 301 854 5363
+   Email:  crocker@tis.com
+
+   Adriano Endrizzi (1), (2)
+   JRC
+   21020 ISPRA
+   ITALY
+     Tel: +39 332 789213
+     Fax: +39 332 789098
+   Email: a_endrizzi@cen.jrc.it
+
+
+
+
+
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 29]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   Michael Eyre (2)
+   Architecture Projects Management Ltd (ANSA)
+   Poseidon Ho
+   Castle Park
+   Cambridge
+   CB3ORD
+   UK
+     Tel: +44 223 323010
+     Fax: +44 223 359779
+   Email:  dme@ansa.co.uk
+
+   David Farber (1)
+   University of Pennsylvania
+   200 South 33rd Street
+   Philadelphia, PA 19104-6389
+   USA
+     Tel: +1 215 898 9508
+     Fax: +1 215 274 8293
+   Email: farber@cis.upenn.edu
+
+   Steve Goldstein (1)
+   NSF
+   18th & G Street, NW
+   Washington, DC 20550
+   USA
+     Tel: +1 202 357 9717
+     Fax: +1 202 357 0320
+   Email:  sgoldstein@note.nsf.gov
+
+   Sid Karin (2)
+   San Diego Supercomputer Center
+   University of California at San Diego
+   San Diego, CA 92186-9784
+   USA
+     Tel: +1 619 534 5075
+     Fax: +1 619 534 5113
+   Email: Karin@sdsc.edu
+
+   Peter Kirstein (1) (2)
+   University College London
+   Gower Street
+   London
+   WCIE GBT
+   UK
+     Tel: +44 71 380 7286
+     Fax: +44 71 387 1397
+   Email: kirstein@cs.ucl.ac.uk
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 30]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   Barry Leiner (1)
+   Research Institute for Advanced Computer Science (RIACS)
+   USA
+     Tel: +1 415 694 6362
+     Fax: +1 415 962 7772
+   Email: leiner@riacs.edu
+
+   Michael Levine (2)
+   Pittsburgh Supercomputing Center
+   Carnegie Mellon University
+   Pittsburgh, PA 15213  USA
+     Tel: +1 412 268 4960
+     Fax: +1 412 268 5832
+   Email: levine @a.psc.edu
+
+   Jean-Pierre Peltier (2)
+   ONERA
+   Chatillon CEDEX
+   BP 72
+   92322
+   FRANCE
+     Tel: +33 1 4657 1160
+     Fax: +33 1 4746 9025
+   Email: Peltier@Froner81.bitnet
+
+   Brian Randell (1), (2)
+   Computing Laboratory
+   University of Newcastle upon Tyne
+   NE1 7RU
+   UK
+     Tel: +44 91 222 7923
+     Fax: +44 91 222 8232
+   Email: Brian.Randell@newcastle.ac.uk
+
+   Ira Richer (1) (2)
+   Defense Advanced Research Projects Agency  (DARPA)
+   1400 Wilson Bld
+   Arlington, VA  22209
+   USA
+   USA
+      Tel: +1 703 614 5800
+      Fax: +1 703 614 5004
+   Email: richer@darpa.mil
+
+
+
+
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 31]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   Juan Riera (1)
+   University of Madrid
+   ETSI
+   Ciudad Universitaria
+   E-28040
+   Madrid
+   ESPAGNA
+     Tel: +34 1 449 5762
+     Fax: +34 1 243 2077
+   Email: jriera@dit.upm.es
+
+   Rolf Speth (1)
+   CEC
+   Rue de la Loi 2000
+   B-1049
+   Brussels
+   BELGIUM
+     Tel: +32 2 236 0416
+     Fax: +32 2 235 0655
+   Email: Rolf_speth@eurokom.ie
+
+   Jack Thorpe (1)
+   Defense Advanced Research Projects Agency - Europe (DARPA-E)
+   GERMANY
+     Tel: +49 711 715 5418
+     Fax: +49 711 715 5448
+   Email: thorpe@darpa.mil
+
+   Jose Torcato (1), (2)
+   CEC, TR 61 0/10
+   Rue de la Loi 2000
+   B-1049
+   Brussels
+   BELGIUM
+      Tel: +32 2 236 3537
+      Fax: +32 2 235 6937
+   Email: --
+
+   Klaus Ullmann (1)
+   Deutsche Forschungsnetz
+   Pariserstr. 44
+   D-1000 Berlin 15
+   GERMANY
+      Tel: +49 30 8842 9920
+      Fax: +49 30 8842 9970
+   Email: ullmann@zpl.dfn.dbp.de
+
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 32]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   Karel De Vriendt (1)
+   CEC
+   Rue de la Loi 2000
+   B-1049
+   Brussels
+   BELGIUM
+      Tel:
+      Fax: +32 3 235 0655
+   Email: k_d_v@eurokom.ie
+
+   Thomas A.  Weber (2)
+   NSF
+   18th & G Street, NW
+   Washington, DC 20550
+   USA
+     Tel: +1 202 357 7558
+     Fax: +1 202 357 0320
+   Email:  tweber@note.nsf.gov
+
+   Paul Wilson
+   Computer Sciences Company Ltd.
+   Computer Sciences House, Brunel Way
+   Slough, Berkshire SL1 1XL
+   UK
+     Tel: 0753 73232
+     Fax: 0753 516178
+   Email: wilson@cs.nott.ac.uk
+
+   Bill Wulf (2)
+   University of Virginia
+   Charlottesville, VA 22903-2442
+   USA
+     Tel: +1 804 982 2223
+     Fax: +1 804 982 2214
+   Email: wulf@virginia.edu
+
+   Rosalie Zobel (1) (2)
+   CEC
+   Rue de la Loi 2000
+   B-1049
+   Brussels
+   BELGIUM
+     Tel: +32 2 236 0324
+     Fax: +32 2 236 3031
+   Email: R_Zobel@eurokom.ie
+
+
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 33]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+APPENDIX C GLOSSARY
+
+   There is no attempt to provide a comprehensive glossary.  However,
+   some of the participants were unfamiliar with the terms used on the
+   other side of the Atlantic, so some of the more parochial technical
+   terms are defined below.
+
+   CCITT - The international body responsible for recommendations
+        to the National communications authorities.
+
+   CLNP - Connectionless Network Protocol.  A specific ISO/OSI
+        protocol analgous to the IP mentioned below.
+
+   CONS - Connection-oriented service.  Another specific ISO/OSI
+        protocol more aligned to the X.25 protocol mentioned below.
+
+   Compound Document - Documents containing different content types
+        including some of the following: text (possibly with various
+        fonts), geometric graphics, bit-map graphics, spreadsheets,
+        tables, animation, voice  annotation.
+
+   IAB - The Internet Activities Board.  This is the body which
+        guides the evolution of the TCP/IP protocol suite and the
+        general Internet architecture.  The Internet Engineering Task
+        Force and Internet Research Task Force are subsidiary
+        activities of the IAB.
+
+   IETF - The Internet Engineering Task Force.  This is a working
+        group responsible for the specification, development and
+        discussion of the operation of facilities in the Internet
+        research networks, which are the basis of US research network
+        services - but also have European counterparts and
+        participation.
+
+   Internet - The concatenations of packet-switched networks which
+        comprise the research networks used by most of the contractors
+        of the NSF and DARPA (amonsgst other US groups).  The Internet
+        also extends to other countries including some in Europe.
+
+   IP - The Internet Protocol.  This is the lowest level protocol which
+        is the basis of the current Internet.
+
+   ISO - The International Standards Organisation.  The international
+        organisation responsible for the standardisation of a broad
+        range of facilities including network ones.
+
+   IXI - The international packet switched network which has been
+        installed by the European communication authorities as part
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 34]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+        of a European project to provide an international backbone
+        network linking in the West European National research (and
+        public) networks.
+
+   OSI - Open Systems Interconnection.  An evolving set of ISO
+        standards which should allow services on different host
+        computers networks to inter-operate.
+
+   RARE - The international committee comprising representatives of
+        European National and international research networks.
+
+   TCP/IP - The transport protocols currently used on the Internet.
+
+   X.25 - The Network Access protocols specified by CCITT/OSI as
+        standard.
+
+   X.400 - The set of protocols for message services specified by
+        CCITT/ISO.
+
+   X.500 - The set of protocols for directory services specified by
+        CCITT/ISO.
+
+Security Considerations
+
+   Security issues are discussed in Sections 6.5, 6.9, and 6.11.
+
+Authors' Addresses
+
+   Vinton G. Cerf
+   Corporation for National Research Initiatives
+   1895 Preston White Drive, Suite 100
+   Reston, VA 22091
+
+   Phone: +1 703 620 8990
+
+   Email: vcerf@nri.reston.va.us
+
+
+   Peter Kirstein
+   University College London
+   Department of Computer Science
+   Gower Street
+   London WCIE GBT
+   UK
+
+   Phone: +44 71 380 7286
+
+   Email: kirstein@cs.ucl.ac.uk
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 35]
+
+RFC 1210      Network and Infrastructure User Requirements    March 1991
+
+
+   Brian Randell
+   Computing Laboratory
+   University of Newcastle upon Tyne
+   NE1 7RU
+   UK
+
+   Phone: +44 91 222 7923
+
+   Email: Brian.Randell@newcastle.ac.uk
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Cerf, Kirstein, & Randell                                      [Page 36]
+
\ No newline at end of file