RFC 1210

Network and infrastructure user requirements for transatlantic research collaboration: Brussels, July 16-18, and Washington July 24-25, 1990

📅 published March 1991, from ietf

Network and Infrastructure User Requirements for Transatlantic Research Collaboration 🌈

Okay bestie, the tea first ☕✨ This is RFC 1210 from the Network Working Group, dated March 1991. The editors are V. Cerf (CNRI), P. Kirstein (UCL), and B. Randell (Newcastle on Tyne). It's all about what research teams need from networks and infrastructure, based on workshops in Brussels (July 16-18, 1990) and Washington (July 24-25, 1990). The category is informational, so it provides information for the Internet community and does not specify an Internet standard. Nothing is listed as obsoleting or updating anything. 💅

Status of this Memo 📌

So this memo is the longer sibling of a shorter printed version. That one showed up in a summary report of all the committees that met in Brussels and Washington last July, 1990. 🧚 It provides information for the Internet community and does not specify an Internet standard. Distribution of this memo is unlimited. 🫶

Abstract 📚

This report sums up user requirements for networking and related infrastructure facilities needed to enable effective cooperation between US and European research teams taking part in the planned ESPRIT-DARPA/NSF programme of collaborative research in Information Science and Technology. 🌸 It looks at 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 hitting those targets. Finally, the workshop identified a non-exhaustive set of important issues that future research support will depend on. These issues could be studied in the short term, with the aim of starting a programme of joint research in collaboration technology within the next year. ✨

SUMMARY OF PRINCIPAL RECOMMENDATIONS AND TARGETS 👑

EMAIL (6.1) 💌

Start an intercontinental email operations forum with email service providers in the US and Europe. Their job is to define and implement operational procedures that lead 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). On top of that, an international email user support group should be organized. The one year target is routine expectation of proper and timely (less than one hour campus to campus) delivery of messages. The three year target is 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 so 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) 📇

Start 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 which protocol suites interactive login will be supported for, 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. Also 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 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, so there are enough sites to be available without undue travel. Also 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 that 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. Give 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. 🛡️

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 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 with several goals. The first is to ascertain the relevance to this group of the data storage reference model that is nearly ready to be declared an official standard guide. Next is to carry out an on-going discussion of the system issues that have to be developed as a result of this model. The last is 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 there is an infrastructure in Europe paralleling the US one, 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 ✨

Okay so the Networks and Infrastructure Working Group (NIWG) 💜 tried to pin down what people needed from network-based capabilities and which cooperative development efforts were worth pursuing. They did this two ways: by chatting internally within the working group, and by talking with the other working groups at the workshop. 🫶

The facilities supporting DARPA/NSF-ESPRIT collaboration have to match the services the US and European projects already use for their own internal collaboration, or it's going to be chaos 💅. So the group had to look at two things: what facilities must be available in each region on its own, and then what must be done to help US-European collaboration actually work. 🎀

Between the US and Europe, the Coordinating Committee for Intercontinental Research Networks (CCIRN) is working on better coordination of network services 🌸. To support US DARPA/NSF and ESPRIT collaboration, the use of network services needs to grow in each region, and the quality of the services linking the two regions needs to get a serious upgrade too. 🚀

The NIWG met in both Brussels and Washington 🗺️. In Brussels it was led by Ira Richer (DARPA) and Rolf Speth (CEC), and in Washington it was led by Tom Weber (NSF) and Rosalie Zobel (CEC). The people in the two meetings were mostly different, but everyone agreed there would be one common set of minutes. Honestly it's kind of iconic that nine people, from both sides of the Atlantic, contributed to those minutes over five days, and they did it all by email 😭. The participants are listed in Appendix A, and a complete set of addresses (including telephone, facsimile and email) is in Appendix B. Because a lot of the abbreviations here might not be familiar to every reader, there's a Glossary of Terms in Appendix C 📖.

2. SCOPE AND OBJECTIVES 💅

The working group's scope was to focus on generic, network-based user services that could help a wide range of collaborative work between US and European groups 🌈. We split things into two buckets: capabilities that deserved immediate attention or were needed in the short term (e.g., within a year), and capabilities that needed longer term development ⏳. The scope was to only support the other groups by making use of technology that already existed, but we spotted one area where we felt more research and development was an important add-on 🔍.

The working group agreed that, based on the instructions from the opening plenary sessions, the major objectives 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 🧚

Networking is, by its very nature, a team sport 🤝. Everyone who develops, implements, deploys and operates the hardware and software in the system has to work together and collaborate. The long-term vision is an infrastructure that gives the user (rather than the network) a distributed, multi-vendor, heterogeneous computing environment, with transatlantic facilities that feel almost as good as the ones available locally ✨.

A huge part of successful networking is agreeing on standards that every system in the network has to meet 📏. Beyond the technical stuff, everyone also needs to agree on operational procedures, performance objectives, user support, and how to plan for enhancing and growing the network services 🌱.

So basically, pretty much any effort to provide network service support to ESPRIT-DARPA/NSF collaboration should be done 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, electronic mail and computer networking get a LOT of use 💌, supporting a wide range of scientific research. The TCP/IP and DECNET protocols are heavily used, along with special electronic mail protocols in the BITNET and Unix users networks (e.g., UUNET). How much people use email really depends on the research discipline 📬.

There's an emerging interest in OSI-based protocols 👀, especially for email (X.400) and directory services (X.500). Most of the backbone networks that make 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 among the ESPRIT collaborators, computer networking is more limited, with the main focus on electronic mail and bulletin boards 📮. There's a strong focus on OSI protocols in European wide-area networks, but there's quite a bit of TCP/IP use on LANs, and TCP/IP use is growing 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 are just becoming available in some 🛣️. An X.25 international backbone (IXI) has just become operational. It connects the National Research Networks and/or the Public Packet Data Networks in each Western Europe country at 64 Kb/s. Funding for this network has only been agreed for a further short period, and plans to upgrade it to higher speed access are not agreed yet 😬. There are many LANs in place. The OSI connection-oriented network service (CONS) is layered above X.25, but there's growing interest in supporting the connectionless service (CLNS) alongside 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 haven't been specified collaboratively yet, which would be needed for wide deployment 🧠. These points are explained further in Section 6 🔗.

So even though some CEC member states have national network provisions or plans that aren't too far behind the American facilities, the reality is that Pan-European facilities are at least a generation behind, because of continental backbone limitations 🐢. Both in existing and planned backbone provisions, there's a factor of 25 difference between Europe and the USA 😳. And honestly, this comparison flatters the European scene, because it compares facilities that are just coming into existence, and plans that aren't agreed or funded yet, on the European side, with facilities that have been around for a while, 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 need 🔎. Overall, there was a strong emphasis on reliable and timely email, easier access to email service, user support, and information about which services exist and how to use them 💌. People were seriously concerned about privacy 🔐, and there was great interest in transparency (i.e., hiding the details of intercontinental networking) 🪟.

Some users said FAX was easier to use and seemed 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 need for large file transfer was patchy 🧩. Plenty of groups didn't need that kind of facility, but several groups needed transfers of 100 MB files, and some even 1 GB 😱. Many groups wanted remote log-in, but found present performance, even on the Internet, inadequate 🥲. Several groups wanted global file services and file sharing 🗂️.

Many groups wanted to use video conferencing, but only if they didn't have to travel more than two hours to a suitable facility 🎥. Some groups were interested in computer supported group collaboration, but most didn't understand what that term meant 🤷‍♀️.

One group (Vision) wanted 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 visualization standards, and data representation and exchange formats weren't voiced explicitly. However, they could be deduced from the services the users did request 🕵️‍♀️✨.

6. USER SERVICES NEEDED IN THE SHORT AND MEDIUM TERM ✨

Okay so, to get research workers actually collaborating, we need a bunch of services between the end users 🫶. These touch loads of management domains: inside individual campuses, campus-wide area gateways, national distribution, regional-intercontinental gateways, and intercontinental distribution. BUT from the users' point of view, the whole thing should feel like one system, and the internal details are not (or at least shouldn't be) their problem 💅. What they actually care about is the overall performance and reliability, the facilities they get, and how much it costs. If bandwidth, protocols, or admin support are lacking anywhere along the chain, the user just experiences that as "the system is bad" 😭.

To some extent, more funding from DARPA/NSF and the CEC can help with the current struggles 💸. Real talk though, that funding will probably only hit the international and intercontinental parts 🌍. It's essential that end-user distribution gets stronger too. In the US, that means both Regional and Campus Networks. In Europe, it means activity from the National network authorities (usually represented in RARE and/or COSINE) and from the Campus network providers. And it's not just about transmission facilities: the right protocol suites need to be supported too, which might take policy decisions as well as technical fixes 🧚.

We list below the services that are needed right now and are visible to end users. They often have far-reaching consequences for service providers 👑. Some are urgent user services, some are underpinning requirements that make the user services work, and some are longer-term needs. There's a strong interaction between the user services and the underpinning ones, and some between the user services themselves. Partly from our own deliberations, and partly from our polls of the other working groups, we've identified needs in the areas below 🦋.

USER SERVICES 🌸

In most cases, these services already exist in local or homogeneous environments. For the proposed collaborations, they need to be available intercontinentally between heterogeneous systems 🌈.

6.1 Electronic Mail 💌

Email between the US and Europe is kind of a mess right now 📧😩. There are gaps in connectivity, not much reliability, and poor responsiveness. Part of the problem is the multiplicity of protocols (which all need translating), and part is an inadequate operations and maintenance infrastructure. There are few user and directory support services, and access to and use of email varies dramatically 💀. HOWEVER, some initial cooperative work has already started between RARE Working Group 1 and folks in the Internet Engineering Task Force in the area of email, which is lowkey amazing 🙌.

6.1.1 One Year Targets ✨

  • (i) Provide management structure to support user assistance and reliable operation of email relays;
  • (ii) Get to the point where proper and timely (less than 1 hour campus-campus) delivery is the routine expectation.

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.
  • (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 with developing 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.

The terms of reference should also include 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 international obstacles to achieving progress in areas involving cryptographic technology.) 🔐

See the Directory Services section below for further possible actions 👀.

6.2 Compound Document Electronic Mail 📎

Proprietary solutions for compound documents (text, font support, geometric graphics, bit-map graphic, spread-sheets, voice annotation, etc.) do exist, but they're limited to products from single manufacturers 🙃. International standards for compound documents exist too, but they're still evolving, and few real commercial products are based on them. Still, 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.

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, so a timely collaborative programme could start in mid-1991 🦋.

6.3 Directory Services 🗂️

White pages services that help network users 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 going to become infrastructural, directory services MUST... sorry, let me say it right: directory services need to be widely implemented, deployed and easily accessible 💖. On top of working with international standards like 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 the cryptographic services used for authenticity, integrity and confidentiality of email and other communications 🔑. And because there are different legal and organizational views of directory service information, it'll also be critical to address organizational and international differences in how sensitive that data is and how accessible it should be 🫣.

It's 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.

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, right now, only partly feasible 😮‍💨. One thing holding it back is the incompatible protocol suites used to provide these services. Implementing and deploying common protocols, plus providing protocol translation gateways, are needed to make this better 🔧.

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.
  • (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 aren't easily achieved in the multi-protocol environment, and long files can't be transferred reliably 🥲. Manually moving files through staged, protocol-translating gateways is awkward and often unreliable. Performance of file transfer software varies substantially. Improvements in file transfer facilities are definitely 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;
  • (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.
  • (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 ✨

okay so collaboration gets SO much easier with mailing lists, bulletin boards and shared databases 💖📬. the catch is that setting these up and managing them usually takes special knowledge and privileges, which is lowkey annoying 😩. if anyone could set them up and run them easily without special privileges, the support infrastructure for collaborative work between the US and Europe would get a major glow-up ✨🌈 (and it would help inside each region too).

more advanced group communication stuff, like shared screens with voice teleconferencing, distributed publishing through electronic libraries, and various kinds of teleconferencing, might cut down on the need for face-to-face meetings, if it's reliable and easy to use 🦋. using these tools beforehand also makes later in-person meetings way more productive 💅. and yes, time zone differences are a challenge for any real-time conferencing setup 🕰️. they're often the main reason people schedule in-person conferences that "force" everyone into the same time zone for the whole meeting 🙈.

6.6.1 One Year Targets 🌸

  • (i) give us admin support for setting up and maintaining email mailing lists, bulletin boards and shared databases 📬;
  • (ii) build facilities for multi-site interactive blackboards with text, graphics, spreadsheets and program access 🖍️.

6.6.2 Three Year Targets 💜

  • (i) intercontinental services built on more mature "advanced groupware" facilities, including shared screens and voice services 🌍;
  • (ii) level up the interactive blackboard with slow scan video, voice, animation, using international standards where feasible 🎬.
  • (i) form a support/working group on the tools, standards and facilities for group communication services 🤝;
  • (ii) start collaborating on advanced group communications (e.g., shared screens, distributed electronic publishing, etc.) 🚀.

6.7 Video Conferencing 🎀

okay so low-bandwidth (under 1 Mb/s) interactive video/voice conferencing, like packet-based stuff, is not available right now for intercontinental collaboration 😭. even just two-party videoconferencing would be a win to start with 💕. the other seven working groups were super into videoconferencing, as long as getting to the facilities didn't take more than two hours 🚗💨. this should totally shape how the facilities get deployed later 🫶.

the minimum setup is at least 256 Kb/s across the Atlantic for each concurrent conferencing channel 📶. each site needs a video codec, two cameras and three monitors 🎥📺, plus suitable packetizing equipment if you're deploying a packet-mode system 📦. and the tea? there's at least one system like this already in use in the US, developed by DARPA and used regularly for transcontinental working group meetings 👑. another one is just being commissioned at University College London 🇬🇧✨.

6.7.1 One Year Target 🌷

get two-party videoconferencing running in at least four sites on each continent 🌍.

6.7.2 Three Year Target 🧚

develop and deploy multi-party conferencing on a bigger scale on both continents, so more collaborators can access the facilities with less travel penalty 🧳.

  • (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 kicked off a whole effort on collaboration technology development and experimentation called Collaboratory 🧪. ESPRIT is doing similar research too 🇪🇺. the NIWG's discussions were framed as infrastructure support for the other research collaborations, but honestly we think it's super appropriate to run a joint programme between US and European researchers 🤝. it would boost Collaboratory efforts and make both groups actually deal with supporting collaboration 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 🧪💜.

set up a workshop to study what a collaborative effort needs to provide intercontinental packet video, multimedia conferencing and computer supported collaborative group technology facilities. the workshop should propose actions that could become the basis for a future harmonised ESPRIT and DARPA/NSF work programme 💡.

6.9 Access to Unique Resources 🔑

a bunch of resources count as unique within ESPRIT/DARPA/NSF, or even worldwide 🌎. that uniqueness can come from what the thing is (like big test facilities, or a focus point of knowledge in a discipline), or it can just be a temporary phase ⏳. with the future EC/US cooperation in mind, it's clear there should be agreed access to some of these 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 very clear networking implications 🌐. remote access to the resources, connectivity to the users and adequate access speeds have to be provided, possibly along with access control facilities 🔐.

the most demanding cases are brand-new products 😤. their uniqueness is temporary, so you can't spread the costs out over long periods the way you could for big 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 that show off remote, secured access 🌟.

organise a workshop focused on analysing the needs and defining the steps to provide pilot access to one or more specific resources. the workshop may need to cover networking needs, security provisions, documentation and advisory requirements, changes to current access capabilities, and usage policies 📋.

6.10 Distributed Visualization 🌈

scientific visualization apps usually involve loads of resources 🖥️. they can span the whole range of sophistication, from simple hardcopy on one end to fancy rendering on the other 🎨. interactive graphics workstations, supercomputers and specialized scientific databases might all be part of one single application. the scientist at a workstation should be able to see all of these resources as one network resource, even if they're physically spread out over huge distances 🗺️. classic example: a high performance graphics workstation, a supercomputer, and a network connecting them, all with the right software 💻. the workstation might sit right next to the supercomputer or be miles away 🚀.

right now, several installations are already working on techniques, interfaces and software to create this environment 🛠️, including ones funded by NSF/DARPA and ESPRIT 💫. in some limited cases it already exists 🙌. better coordination of these efforts on both sides of the Atlantic would be desirable 👀. coordinating across the Atlantic will be necessary for effective collaboration in end-user visualization applications across a variety of disciplines in the future 🔮.

6.10.1 One Year Targets 🔍

identify the significant current development efforts in these areas and decide which ones to support. identify the areas that need standards 📏. minimize duplication of effort and start distributing the techniques and software 📦.

6.10.2 Three Year Targets 🤝

establish mutually agreed standards, and demonstrate transatlantic distributed visualization applications 🌉.

set up a working group to refine and implement the one year and three year targets, and to spot extra distributed visualization topics that would benefit from coordinated efforts. figure out the right mechanisms for supporting these collaborations 🗝️.

UNDERLYING SERVICES 🧱

okay so most of the services below are needed to hit the goals of reliability, availability and transparency for the user services 💜.

6.11 Network Management 🛰️

the current network management tech and practice aren't adequate for large scale, international research networks 😬. time zone differences plus a lack of organizational operational network management agreements team up to make international network management a serious challenge 🌍. to be effective, network management must operate on a campus-to-campus basis, because campuses are the sources and sinks of traffic in the system 🏫.

6.11.1 One Year Target 📋

put an administrative structure in place to coordinate existing facilities manually and plan technical solutions.

6.11.2 Three Year Target 🤖

develop and deploy tech that automates international network management.

  • (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 rely on a whole bunch of protocols for their research 📚. the international network infrastructure doesn't uniformly support using multiple protocols (e.g., DECNET, TCP/IP/ST, OSI) end-to-end 😩. parts of the international network can also be restricted by policy, and routing for campus-to-campus protocols has to account for that 🗺️.

campus-to-campus multi-protocol transmission and routing needs at least 64 Kb/s end-to-end 📶, and higher for some services ⬆️. when end-users have picked similar protocols, the networks in between should not get in the way of making full use of the facilities in that protocol suite 🙌. when different protocol suites are involved, you also need high quality application-level gateways that can translate between protocols 🔁. as much as possible, these should let people keep using their own procedures, even when they're talking to services that use different ones 💖. for some services this means upgrading access, and maybe 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 🎀

okay bestie, the one-year goals for multi-protocol stuff are lowkey ambitious 🌈

  • (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 🌸

three years out, things level up 🔥

  • (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. 🚀

the homework part, aka what we actually need to do 📚

  • (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.

6.13 Client-Server Technology 🧚

okay so the client-server model of interprocess communication is literally one of the most important techniques to pop off over the last decade 🔥. It was developed super early, back when packet network exploration was just starting, and then it got a huge glow-up when local area networks like Ethernet showed up. Those could handle very high speed, low delay inter-computer exchanges, which is iconic 🦋. Use cases range from remote procedure calls to remote file access and support for remote, bit-mapped graphics ✨.

BUT here's the tea 🍵: these techniques work best in a high bandwidth, low delay environment, and they're generally not well-supported in wide-area, intercontinental networks 💀. Collaborations between the US and Europe could get a major upgrade if client-server services worked on an intercontinental basis 💖. That would allow 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 tech. Also, 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.
  • (i) convene workshops to achieve agreements on intercontinental Remote Procedure Call and Distributed File System protocols;
  • (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.

6.14 Archival Storage for Distributed Computing Environments 🗄️

there are several major issues that must be addressed by distributed computing environments (DCEs) containing supercomputers 👑. Figuring them out is likely to take the next five to ten years, so buckle up 🌈.

one big one is archival storage and bitfile management for the whole environment. A few problems need solving to handle this properly 🧩. First, there's global-naming of bitfiles moving through the DCE to and from the archive. Second, the file system hierarchy must be defined. Third, the DCE has to know which file system hierarchy it's responsible for, plus where the boundary sits between the network and the archival system. Lastly, there's the question of how the file system hierarchy gets divided across a DCE and inside a supercomputer.

the second issue is that every node that gets or stores data needs to know the storage media differences. For future systems, this shows up both at the distributed nodes and at the supercomputer, because the physical media structures are different 💅.

the third issue is the delineation of bitfile attributes. This is about how the data has to be maintained as it migrates through the hierarchy and through the DCE 🦋. A bitfile picks up attributes based on where it sits in the hierarchy or the DCE, and those can differ from what the supercomputer level needs. A lot of them are tied to the data content and to where the data lives in time within the DCE. Section 6.15 covers some possible meta-data representation methodologies that may be used, though they aren't standardized yet 🔍.

another issue is figuring out and implementing the site policy that's supposed to dictate data migration and allocation inside the DCE archival storage system 📋.

several working committees are attacking these problems and wrestling with how hard these environments are 💪. Most of this work is happening in the United States. The IEEE Computer Society Technical Committee on Mass Storage Systems is developing a Computer Society draft standard on data storage systems. Its current working draft gives a consistent terminology and an object-oriented design for defining storage subsystem components, whether they're built around a single system or in a DCE ✨. Other groups in the computing community are dealing with data migration within a distributed environment too. That environment may or may not include a supercomputer, but it almost always includes a high-volume storage system of some sort, called a "mass storage system." This subject wasn't discussed long enough at the meeting to pin down one year or three year targets, so these may well be set by the relevant National working groups 🙈.

convene an international workshop with these goals:

  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 🦋

data exchange between different computer architectures and operating systems has been a problem since the early computers showed up 🕰️. It got even more intense once the client-server paradigm became the way distributed services are provided. Distributed computer services need immediate data exchange. Back in the day, data went over something like tape and could be examined at leisure. Ad hoc data conversion routines got written to process it, and they were often embedded right in the programs using the data 😭. Client-server data exchange doesn't allow that leisurely examination. Both the client and the server have to be able to "call" software that's guaranteed to convert the exchanged data "on the spot." That guarantee also implies a standard format, rather than the ability to convert all formats, because maintaining conversion software for multiple architectures would be impossible, and, of course, that conversion software would be enormous 💀.

data exchange has been tackled, and it's resulted in lots of data exchange software packages. A few of the more popular ones right now are XDR, HDF, NetCDF, PostScript and CCSDS 🌸. Each one addresses a specific type of data. Some handle bitmap data, one handles the general encoding of "display" information, and some handle various numerical representations in computers. It's unclear whether any existing package could or should be extended to solve every data exchange problem. A more realistic move would be a collection of data exchange packages formed as the "standard" 🫶.

this item was only discussed briefly at the meeting, so no one year or three year targets were specified.

the plan is to set up an international working group to recommend a standard collection of software covering a variety of data representations 🌈. This group should figure out how to embed identification of the data representations in the data stream, so later extensions are possible. The working group would meet at first to set a work-scope and assign members their tasks. After that it would schedule subsequent meetings (probably annually) to finalise the current data exchange standard recommendation and define new work scopes 📅. It would also make its recommendation known to other standards bodies such as X/OPEN, UI, OSF, X Consortium, NIST, IEEE, ACM, etc. ✨.

right now there's not enough transatlantic capacity to support research collaborations with a lot of computer-mediated communication 😩. Europe also has lots of room to improve how capacity is distributed and how reliable its network service is. People made a strong point that collaboration gets really hard unless the infrastructure on both sides is broadly comparable, even if the transatlantic capacity ends up being lower by necessity 🙅‍♀️. It was also sharply emphasised that transatlantic data flow is badly needed in other fields too, like Space Science, Atmospheric Science and High Energy Physics 🔬. In the US, these needs are being aggregated in the National Research and Engineering Network. That kind of aggregation is needed in Europe too, and across the Atlantic 🫶.

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.

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).
  • (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 ✨

Okay so these didn't get a deep dive because we ran out of time 😭, but five areas came up as ones to team up on for the long haul:

  • (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 ⚡

Honestly, some collab research in these areas could be giant for the other communities in the medium term 🔥, and it would mesh really well with the ongoing research programmes on both sides of the Atlantic 🌈.

8. OBSTACLES 🚧

Okay, the biggest blocker? Building the facilities we need just isn't a priority for most funding agencies 💀. Our workshop series is proof of that 🙈. It's not only about getting the network provisioned, we also need solid infrastructure, application software and testbed work. Non-negotiable, bestie.

Some problem areas could really use official attention from CEC and US research funding agencies 👑. For example, there are open and proprietary protocol suites that are candidates for US/European collab, but there's no political agreement yet on how to handle them 😤. A joint communiqué from CEC and the US research agencies showing common agreement on treating multiple protocols would be politically valuable 💅 (think: expressing serious interest in supporting campus-to-campus communication using multiple protocols). Inside the OSI suite, people disagree on which features should make up the standard profile for government-sponsored groups, and how connection-oriented and connectionless elements get handled is still being debated 🥱. Agreeing to support at least TCP/IP and the connectionless network protocol in OSI on an intercontinental basis would help both parties 🫶, though lots of CEC members also want connection-oriented network protocols supported 🌸.

European international tariffs are pretty high 😩. That's held back private networks and slowed down US-Europe collab. A CEC initiative to tackle this could be super helpful 💖.

There are tons of intra-European networking organizations with technical, operational and policy interests 🦋. Planning intercontinental infrastructure can get messy because there are so many interested parties. More coordination and rationalization of intra-European networking activities could make intercontinental planning somewhat easier 🧚.

There's a strong interest in using cryptographic methods for privacy, authenticity and integrity assurance across intercontinental communication, at various levels in the protocol hierarchies 🔐. There's substantial technical activity happening, but national restrictions on exporting software that uses cryptography are slowing things down 😭. National use policies vary too, so being able to apply these valuable techniques is uncertain 🥺.

Some national privacy and data protection laws prohibit creating directories containing personal information (like email and postal addresses) 🙅, and other laws limit what kinds of information can be transported across national borders, and in what form.

Handling cryptographic exchanges, importing and exporting supporting software, and exchanging keying information are all potentially subject to national restrictions and constraints 🔑. The government agencies that want to promote international collab may need to seek alternative international formulations of permitted practice so the required technical support can happen ✨.

Finally, several organizations in the US and Europe pointed out that networking infrastructure needs stable funding over significant periods of time 💸. Infrastructure support has been shaky in both the US and Europe, which makes it harder to get widespread and reliable network services for collab efforts 😵.

9. CONCLUDING REMARKS 🎀

The proposals in this report give us a realistic, staged approach to fixing the grave problems caused by the disparities in bandwidth provision, user services and network protocol issues. Those disparities are what currently stop close, widespread transatlantic collab between the ESPRIT and DARPA/NSF research workers 🌍. Making it happen will take a serious degree of commitment to resolve the present administrative difficulties, but the financial resources needed would, we estimate, be relatively modest and fully commensurate with the benefits 💜.

APPENDIX A NIWG PARTICIPANTS 🧑‍🤝‍🧑

Quick decoder ring: (1) means the Brussels meeting and (2) means the Washington one 🗺️.

The co-chairs 👑:

Ira Richer (1),(2) Rolf Speth (1) Tom Weber (2) Rosalie Zobel (1),(2)
DARPA              CEC            NSF           CEC

The rapporteurs 📝:

Vint Cerf (1)    Peter Kirstein (1), (2)     Mike Levine (2)
CNRI             UCL                         PSC

And the 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 📞

Here's the whole contact list, copied exactly as it was, so you can reach everyone 💌.

   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

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

APPENDIX C GLOSSARY 📖

Okay so there's no attempt to make a full glossary here 🙈 but some of the people in the room were lowkey lost on the terms they used on the other side of the Atlantic, so the more parochial technical terms get defined below 🫶

  • CCITT - the international body that makes recommendations to the national communications authorities 🏛️
  • CLNP - Connectionless Network Protocol. It's a specific ISO/OSI protocol that's basically the cousin of IP, which we'll get to below 👯
  • CONS - Connection-oriented service. Another specific ISO/OSI protocol, and it's more aligned with the X.25 protocol mentioned below 🔗
  • Compound Document - a document that mixes different content types, like some combo of text (possibly in various fonts), geometric graphics, bit-map graphics, spreadsheets, tables, animation, and voice annotation 🎨
  • IAB - the Internet Activities Board. This is the body that guides how the TCP/IP protocol suite and the general Internet architecture evolve 👑. The Internet Engineering Task Force and the Internet Research Task Force are subsidiary activities of the IAB 🧚
  • IETF - the Internet Engineering Task Force. It's a working group responsible for the specification, development, and discussion of how facilities work in the Internet research networks 🦋. Those networks are the basis of US research network services, but they also have European counterparts and participation 🌈
  • Internet - the concatenation of packet-switched networks that make up the research networks used by most of the contractors of the NSF and DARPA (amongst other US groups) 🌐. The Internet also extends to other countries, including some in Europe 💖
  • IP - the Internet Protocol 💅. It's the lowest level protocol and the basis of the current Internet ✨
  • ISO - the International Standards Organisation. It's the international organisation responsible for standardising a broad range of facilities, including network ones 📏
  • IXI - an international packet switched network. The European communication authorities installed it as part of a European project to provide an international backbone network, linking the West European National research (and public) networks together 🇪🇺
  • OSI - Open Systems Interconnection. It's an evolving set of ISO standards that should allow services on different host computer networks to inter-operate 🫶
  • RARE - an international committee made up of representatives from 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 🔐

Okay bestie, this part is serious 😭 Security issues are discussed in Sections 6.5, 6.9, and 6.11. Go read those sections, no skipping!! 💀

Authors' Addresses 💌

Here are the three authors and how to reach them, exactly as written 🎀

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
Brian Randell
Computing Laboratory
University of Newcastle upon Tyne
NE1 7RU
UK

Phone: +44 91 222 7923

Email: Brian.Randell@newcastle.ac.uk

That's the whole doc, bestie!! 🌈✨ Iconic ending, no cap 👑💖

📦 where this page comes from