RFC 2768

Network Policy and Services: A Report of a Workshop on Middleware

📅 published February 2000, from ietf

Network Policy and Services: A Report of a Workshop on Middleware 🎀

Okay bestie, this is RFC 2768 from the Network Working Group 💖 It's an Informational doc, dated February 2000, and it's basically a workshop report on middleware ✨ The authors are B. Aiken and J. Strassner (Cisco Systems), B. Carpenter (IBM), I. Foster (Argonne National Laboratory), C. Lynch (Coalition for Networked Information), J. Mambretti (ICAIR), R. Moore (UCSD), and B. Teitelbaum (Advanced Networks & Services, Inc.) 👑 The header doesn't list anything it obsoletes or updates, so there's nothing to chase down there 🧚

Status of This Memo 🌸

This memo gives information to the Internet community. It is not an Internet standard of any kind, and it doesn't specify one. Distribution of this memo is unlimited 💅

Copyright (C) The Internet Society (2000). All Rights Reserved.

Abstract ✨

So an ad hoc middleware workshop happened at the International Center for Advanced Internet Research in December 1998 🌈 It was organized and sponsored by Cisco, Northwestern University's International Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The whole point was to figure out which existing middleware services could be leveraged for new capabilities, and which additional middleware services still needed research and development 🔥 The participants talked about what middleware even means, looked at it from the applications side, and went through the network transport capabilities that matter for middleware services. Then they covered specific examples of middleware components: APIs, authentication, authorization, and accounting (AAA) issues, policy framework, directories, resource management, networked information discovery and retrieval services, quality of service, security, and operational tools 💜 They agreed that middleware R&D needs a more organized framework, and they made a list of specific topics that still need work 🦋

Table of Contents 🗺️

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . .  2
1.0   Contextual Framework . . . . . . . . . . . . . . . . . . . .  3
2.0   What is Middleware?  . . . . . . . . . . . . . . . . . . . .  4
3.0   Application Perspective  . . . . . . . . . . . . . . . . . .  6
4.0   Exemplary Components . . . . . . . . . . . . . . . . . . . .  7
5.0   Application Programming Interfaces and Signaling . . . . . .  8
6.0   IETF AAA . . . . . . . . . . . . . . . . . . . . . . . . . .  9
7.0   Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.0   Directories  . . . . . . . . . . . . . . . . . . . . . . . . 12
9.0   Resource Management  . . . . . . . . . . . . . . . . . . . . 15
10.0  Networked Information Discovery and Retrieval Services . . . 17
11.0  Network QOS  . . . . . . . . . . . . . . . . . . . . . . . . 18
12.0  Authentication, authorization, and access management . . . . 21
13.0  Network Management, Performance, and Operations  . . . . . . 22
14.0  Middleware to support multicast applications . . . . . . . . 23
15.0  Java and Jini TM . . . . . . . . . . . . . . . . . . . . . . 24
16.0  Security Considerations  . . . . . . . . . . . . . . . . . . 24
17.0  Summary  . . . . . . . . . . . . . . . . . . . . . . . . . . 24
18.0  Participants . . . . . . . . . . . . . . . . . . . . . . . . 26
19.0  URLs/references  . . . . . . . . . . . . . . . . . . . . . . 27
20.0  Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 27
21.0  Full Copyright Statement . . . . . . . . . . . . . . . . . . 29

Introduction 🧚

This doc describes the term "middleware," plus its requirements and scope 💖 The goal is to help developers of collaboration-based and high-performance distributed computing apps talk to the people building the network infrastructure. In advanced networks, middleware is generally the stuff of services and other resources that sit between the applications and the underlying packet forwarding and routing infrastructure 🌸 Nobody has agreed yet on exactly where those lines should be drawn, though 🙈

This document is being developed within the context of existing standards efforts. So it defines middleware core components within the framework of where middleware-related standards work currently stands, especially at the IETF and the Desktop Management Task Force (DMTF) 👑 The envisioned role of the IETF is to lead the work on the underlying protocols that could support a middleware infrastructure. The plan is to leverage the information modeling work, plus the advanced XML and CIM/DEN-LDAP mapping work, going on at the DMTF 🔥 (The recently constituted Grid Forum is also pursuing relevant activities 🌈)

This doc also looks at how middleware affects Internet protocol development ✨ For its approach, it started out focused on the intersections between middleware components and application areas that already have well-defined activities underway 💅

This document is a product of an ad hoc Middleware Workshop held on December 4-5 1998 🎀 The workshop was organized and sponsored by Cisco, Northwestern University's International Center for Advanced Internet Research (iCAIR), IBM, and the National Science Foundation (NSF). The goal was to define the term middleware and its requirements on advanced network infrastructures, as well as on distributed applications 🦋 Those definitions will then let a set of core middleware components get specified, both to support advanced application environments and to give a basis for other middleware services 💜

Yes, this document is about more than just Internet protocols, but the ideas here matter a lot for how networks and protocols need to evolve as we move into implementing "the network is the computer" 🤖 So this document is offered for consideration to the IETF, DMTF, Internet2, Next Generation Internet (NGI), NSF Partnerships for Advanced Computational Infrastructure (PACI), the interagency Information Technology for the 21st Century (IT2) program, the Grid Forum, the Worldwide Web Consortium, and other communities 🌸

Here's the layout: Section 1 gives a contextual framework. Section 2 defines middleware. Section 3 discusses application requirements. The later sections cover requirements and capabilities for middleware as defined by applications and middleware practitioners 💖 They also talk about the underlying transport infrastructure that's required, administrative policy and management, exemplary core middleware components, provisioning issues, network environment and implementation issues, and research areas ✨

1.0 Contextual Framework 🌈

Middleware can be defined to cover a huge set of services 🙃 We chose to start with the services needed to support a common set of applications running on a distributed network environment. The workshop agreed that there really wasn't a core set of middleware services that every application requires 💅 That doesn't make domain-specific middleware less important, or take away the flexibility needed to pick customized approaches 🫶 Communities like Internet2, NGI, and other advanced Internet constituencies may decide on their own common set of middleware services and tools. Still, they should strive for interoperability whenever possible 🦋 The workshop topics were picked to get people talking about the nature and scope of middleware itself, as distinct from specific types of applications. So lots of relevant middleware topics didn't get discussed 🙈

Another thing the workshop agreed on, which helped focus things: even though middleware could be pictured as hierarchical, or layered, that approach wasn't helpful. It had actually been problematic and unproductive in earlier efforts 💀

The better way to think about it is as an unstructured, often orthogonal collection of components (like resources and services) that can be used individually or in various subsets 🧩 This working assumption helped avoid long theological modeling debates, and it lets work on different middleware issues move forward independently 🚀

An important goal of the workshop was to identify any middleware or network-related research and development needed to advance the state of the art for advanced application environments, like the ones NGI and Internet2 are developing and pursuing 🔥 So the discussion focused on the areas with the most opportunity for those advances 👑 More parts are coming, bestie 🦋

2.0 What is Middleware? 🌸

okay so the workshop folks all agreed middleware is real, but the second they tried to define it, everyone had a different take 💅 what middleware means really depends on who's looking at it, and maybe even when you ask. yesterday's middleware (think DNS, Public Key Infrastructure, and Event Services) can totally turn into tomorrow's fundamental network infrastructure 🦋 application environment users and programmers see everything below the API as middleware. networking gurus see anything above IP as middleware 🤓 and people building apps, tools, and mechanisms in between see it as living somewhere between TCP and the API. some of them even split middleware into application-specific upper middleware, generic middle middleware, and resource-specific lower middleware ✨

the group kept coming back to the point that middleware doesn't stop at the "network." it spreads out into the compute, storage, and other resources the network connects 🧚 like, a video serving app wants resource discovery and allocation not just for networks but also for the archives and computers needed to serve and process the video stream. so after a LOT of general set theory and rough consensus 😭, they roughly characterized middleware as the services found above the transport (i.e., over TCP/IP) layer set of services but below the application environment (i.e., below application-level APIs). it's giving "in the middle, but make it precise-ish" 💜

some of the earliest ideas about middleware came from distributed operating research in the late 1970s and early 1980s, and then the I-WAY project at SC'95 pushed it further 🔥 I-WAY linked high performance computers nation-wide over high performance networks, so the whole setup worked like one single high performance environment. the researchers behind it re-emphasized that effective high performance distributed computing needs distributed common computing and networking resources, including libraries and utilities for resource discovery, scheduling and monitoring, process creation, communication and data transport. main character energy for sure 👑

then the Globus project came along and kept building on that middleware stuff. it showed that these resources could really help with optimizing advanced application performance in distributed domains 🌈

in May 1997, a Next Generation Internet (NGI) workshop on NGI research areas put out a publication called "Research Challenges for the Next Generation Internet" 📚 and it describes middleware like this: "Middleware can be viewed as a reusable, expandable set of services and functions that are commonly needed by many applications to function well in a networked environment". this definition could also be refined to include persistent services (like the ones inside an operating system), distributed operating environments (e.g., JAVA/JINI), the network infrastructure (e.g., DNS), and transient capabilities (e.g., run time support and libraries) needed to support client software on systems and hosts. iconic definition, tbh 💖

so yeah, there are a bunch of views on what middleware is 🙈 the consensus at the workshop was that since middleware is so dynamic and always morphing, it mattered more to pin down some core middleware services and actually start working on them than to agree on a dictionary-style definition. honestly the vibe was "ship the thing first, define it later" 🎀

middleware systems for networked information discovery have been active research areas since at least the late 1980s 🍓 for example, Archie and the Harvest project. you could easily argue that the site logs Archie used, and the broker system and harvest agents, were important middleware tools. and more work in this area is urgently needed to improve the efficiency and scope of web-based indexing services 😭

"As long ago" as 1994, the Internet Architecture Board held a workshop on "Information Infrastructure for the Internet," reported in RFC 1862, which covered a lot of similar issues 🦋 its recommendations were summarized as follows:

  • increased focus on a general caching and replication architecture
  • a rapid deployment of name resolution services, and
  • the articulation of a common security architecture for information applications."

and ngl, it's clear that this work is nowhere near done 💀

last thing from this workshop: there's a tight link between middleware as a set of standards and protocols and the infrastructure that makes the middleware actually meaningful 🫶 for example, the DNS protocol would be pretty limited without the system of DNS servers, and without the administrative infrastructure of the name registry. NTP needs time servers to be useful. and newer middleware services like naming, public key registries, and certificate authorities will need even more extensive server and administrative infrastructure to become both useful and usable 🌸

3.0 Application Perspective 💅

from the applications side, the network is just another type of resource that apps need to use and manage ✨ the middleware services and requirements needed to support advanced applications come from a big vision that combines applications in areas like: distributed computing, distributed data bases, advanced video services, teleimmersion (i.e., a capability for providing a compelling real-life experience in a virtual environment based for example on CAVE technologies), extensions with haptics, electronic commerce, distance education, interactive collaborative research, high-rate instrumentation (60 MByte/s and above sustained), including use of online scientific facilities (e.g. microscopes, telescopes, etc.), effectively managing large amounts of data, computation and information Grids, adaptable and morphing network infrastructure, proxies and agents, and electronic persistent presence (EPP). the list is LONG 😭🔥

a lot of these apps are "bleeding edge" compared to what's running on the commodity Internet right now, so they have unique requirements 🚀 remember how the Web was an advanced app in the early 1990s? many of the areas above won't be commonplace anytime soon either. BUT they all have the power to change how the network gets used, and what we even count as infrastructure, just like the Web and Mosaic did in the early 90s 🌈 a notable recent trend is more and more HTTP, voice, and video traffic, and the workshop noted that voice and video especially need some form of QoS and associated middleware to manage it 🎀

now the teleimmersion requirements are a great example 🧚 they call for multiple concurrent logical network channels, each with its own latency, jitter, burst, and bandwidth QoS, and yet they all have to be coordinated through a single middleware interface to the application. for security and efficiency, people using online instruments need to be able to steer the devices and change parameters as a direct result of real-time analysis done on the data as it arrives from the instruments 🙈 so network requirements include high bandwidth, low latency, and security, and all of that has to be coordinated through middleware.

big databases, archives, and digital libraries are becoming a mainstay for researchers and industry too 📚 the requirements they put on the network and on middleware are extensive, including support for authentication, authorization, access management, quality of service, networked information discovery and retrieval tools, naming and service location, to name only a few. they also need middleware that supports collection building and self-describing data 💜 distributed computing environments (e.g., Globus, Condor, Legion, etc.) are quickly evolving into the computing and information Grids of the future. these Grids need adaptive and manageable network services, AND a sophisticated set of secure middleware capabilities that give the application easy-to-use APIs 👑

a bunch of app folks were adamant that they ALSO need "pass through" services 💅 this means being able to bypass the middleware and directly access the underlying infrastructure such as the operating system or network). even though they were super eager to use middleware services and wanted to see more of it built for their own apps, they still wanted that bypass option. and authentication, access control, and security are required for all of the applications mentioned above too, just at different levels 🦋

4.0 Exemplary Components ✨

so the goal here is to describe middleware and talk through the issues around building and deploying it 🌸 to do that, the group picked an exemplary set of services to discuss. these were picked to get people talking, NOT to define some exclusive list of middleware services 🙈 and this effort isn't about duplicating existing IETF work or the work of other standards bodies (e.g., the DMTF). it's more about building on those efforts, and especially highlighting areas that were already far enough along that they might be close to deployment 🫶🎀

5.0 Application Programming Interfaces and Signaling ✨

okay so apps need to be able to ask for network resources based on what they actually need right now 🎀 those requests come with network management controls and resource implications, but getting them fulfilled can take a bunch of steps in between. ngl, middleware is still pretty new, so there's no common framework yet, let alone a method, for an app to signal that it needs a set of network services. that includes quality and priority of service and all the resource requirements that come with them 😭 BUT middleware is super useful, especially for optimizing advanced apps, so preliminary models for quality and priority of service and resource management already exist and keep evolving 🦋

the tea is that without an agreed framework for standards in this area, we risk having multiple competing standards, and that could slow down the rollout of a middleware-rich infrastructure 💀 this framework should probably cover signaling methods, access and admission controls, and a set of defined services and resources. it should also include service levels, priority considerations, scheduling, a Service-Level-Agreement (SLA) function, and a feedback mechanism that tells applications or systems when performance drops below the SLA specification or when an app violates the SLA 📢 any mechanism like this implies capabilities for:

  1. an interaction with some type of policy implementation and enforcement,
  2. dynamic assessment of available network resources,
  3. policy monitoring,
  4. service guarantees,
  5. conflict resolution, and
  6. restitution for lack of performance.

app programmers want fewer interfaces to learn just to reach middleware services 🫶 so unifying common services behind a single API is a huge deal for middleware users. some common APIs that might be achievable are:

  • Environmental discovery interface, whether for discovering hardware resources, network status and capabilities, data sets, applications, remote services, or user information. 🔍
  • Remote execution interface, whether for distributed metacomputing applications, or for access to a digital library presentation service, or a Java analysis service. 🧚
  • Data management interface, whether for manipulating data within distributed caches, or replication of data between file systems, or archival storage of data. 🗂️
  • Process management interface, whether for composing data movement with remote execution, or for linking together multiple processing steps. ⭐

6.0 IETF AAA ✨

the IETF AAA (authentication, authorization, and accounting) effort is just one of many IETF security initiatives 🔐 it leans heavily on a Public key infrastructure, which is meant to provide a framework that supports a range of trust and hierarchy environments and a range of usage environments (RFC1422 is an example of one such model) 💜

the IETF AAA working group was formed recently 🌸 it's focused on lots of middleware issues, including defining processes for access and admission control and identification (a process for determining a unique entity), authentication (a process for validating that identity), authorization (a process for determining eligibility for resource requests and utilization), and accounting (at least to the degree that resource utilization is recorded). AAA covers certain security levels to some degree, but only at a preliminary level 🥺 AAA protocols exist already, just not as an integrated model or standard yet. one thing to think about for AAA is offering various levels of granularity. even without an integrated model, it's possible to provide basic AAA mechanisms that can serve as a basis for supporting SLAs ✨ any kind of AAA implementation needs a policy management framework that it must be linked to, and right now a well-formulated linking mechanism hasn't been defined 🙈

middleware AAA requirements are also shaped by the distributed interoperation that can happen between middleware services 🌈 when application support is spread across multiple autonomous systems, you'll need self-consistent third-party mechanisms for authentication as well as data movement. conceptually, an application might need access to data under the control of a remote collection so it can run a procedure at a third site 🦋

the data flow should go directly from the collection to the execution platform for efficiency 🏃‍♀️ at the same time, the procedure needs access permission to the data set while it's acting on behalf of the requestor. how authentication happens between the remote procedure and the remote data collection entities raises some big issues around transitivity of trust, and it'll require a trust policy for third-party mechanisms to be set up 😳 this gets even messier when a collection of entities is involved, like what visualization applications need 👑

7.0 Policy ✨

the IETF Policy Framework working group is working on a policy framework definition language, a policy architecture model, policy terminology, and specifically a policy model that works for signaled as well as provisioned QoS 💅 the policy meta-model links high-level business requirements (the kind you could specify in an SLA) to low-level device implementation mechanisms. that covers everything from specific access control and management of services, objects, and other resources, to configuring the mechanisms needed to deliver a given service 🎀

policies are an integral part of all middleware services, and you'll find them in most middleware services in one form or another 💖 they're often written as an "if condition then action" tuple. policies can be complex and numerous, so policy management services must be able to identify and resolve policy conflicts 🫠 they also need to support both static modes (loaded at boot time via a configuration file) and dynamic modes (where the configuration of a policy enforcing device may change based on an event) ✨

a generalized policy management architecture (as suggested by the IETF policy architecture draft) includes a policy management service, a dedicated policy repository, at least one policy decision point (PDP), and at least one policy enforcement point (PEP) 🧚 the policy management service handles the specification, editing, and administration of policy, through a graphical user interface as well as programmatically. the policy repository handles storage and retrieval of policies and policy components. policy components hold definitional information, and they can be used to build more complex policies or as part of the decision and/or enforcement process 🗂️ the PDP (for example a resource manager such as a bandwidth broker or an intra-domain policy server) handles events, makes decisions based on those events (e.g., at time x do y), and updates the PEP configuration appropriately. it may also be responsible for providing the initial configuration of the PEP 👑 the PEP (for example a router, firewall, or host) enforces policy based on the "if condition then action" rule sets it has received from the PDP 🔥

policy information can move from the PDP to the PEP over a variety of protocols, like COPS or DIAMETER 🦋 a proxy may be used to translate the information in these protocols into forms that devices can consume (for example command line interface commands or SNMP sets). additional information, held in Policy Information Bases (PIBs), may also be used to translate from an intermediate specification to the specific functions and capabilities of a device. for example, a policy might say:

if source IP address is 198.10.20.132, then remark traffic with a DSCP of 5

the PIB would be used to translate the device-specific meaning of the conditioning specified by the DiffServ code point of 5 (for example, a specific set of queue and threshold settings) 🤓

policy needs AAA functions, not just for access control but also to set up the trust relationships that enable distributed policy interactions 🫶 PDPs may require requesting end systems and applications to be authenticated before the PDP will honor any requests. the PDP and PEP must be authenticated to each other to reduce the probability of spoofing 🚨 this is true whichever protocol is used to support communication between these entities. audit trails are essential for all of these transactions 📝 on top of that, trust management policies will need to be developed, along with the supporting middleware mechanisms needed to enable inter-domain policy negotiation 🌍

ultimately, many policy processes link entities to resources, so they require interactions with entity identification mechanisms, resource identification mechanisms, and allocation mechanisms 💫 the distributed computing community has already started developing policy definition languages and systems. Globus uses its Resource Services Language (RSL) to define resources and the policies attached to them. Condor uses a matchmaking bidding technique to pair up those providing services with those acquiring them 🎯 the IETF has several policy definition languages at different stages of development too, including RPSL, RPCL, SPSL, PFDL, PAX, and Keynote 🌈 eventually, these efforts should be merged into a single specification (or at least a smaller group of specifications) so distributed computing applications can communicate effectively and use network resources and services together 🥳

directories play a crucial role in policy systems 📚 they're ideally suited for storing and retrieving policy information because of their exceptionally high read rates, their ability to intelligently replicate all or part of their information, per-attribute access control, and their use of containment 💜 to that end, the IETF Policy Framework working group (in conjunction with the DMTF) is developing a core information model and LDAP schema that can represent policy information applications can use. this core model provides a common representation and structure for policy information. applications can then subclass all or part of the classes in this core schema to meet their own specific needs, while still being able to communicate and interoperate with each other 🦋✨

8.0 Directories ✨

Okay bestie, directories are literally critical resource components 💅 They support a whole bunch of other middleware stuff, especially policy 🫶 As networks keep evolving, it's not going to be viable to cram policy info straight into every single app 😭 The current vibe is that each app keeps its own private data store with its own view of a device's data (like configuration) 🎀 That data covers network resources and services, plus the clients who want to use them (people, processes, and applications) 🌸 The same resource (or parts of it, like its physical vs. logical side) can show up in several data stores 🦋 Even when a device is modeled the same way everywhere, each app can only see its own data 💀 So you get duplicated data and sync problems, and it's giving chaos 🙈

The promise of CIM and DEN is that every app stores data about the resources it manages in one directory, using a common format and access protocol ✨ That means the data describing a resource only gets represented once 💖 Having a logically centralized common repository, where resources and services are represented the same way, lets apps of all different types use and share info about resources and services 🧚

And it's not just about killing duplication and sync problems 😤 It also gives you inherent extensibility when describing an object 🌈 One entity can be represented by multiple directory objects, and each one covers a different aspect of that entity 💜 Different apps can manage the different objects that together make up a higher-level object, even if those apps can not talk to each other 🦋 So they can effectively share and reuse data, which is a major win for users and apps alike 👑 Short term, users and apps get all their data in one place 🍓 Long term, they can take advantage of data managed by other apps too ⭐

Directories are key to supporting advanced network-based application environments 🔥 Directory purists will tell you the directory is not middleware 🙄 It's basically a dumb storage device that becomes an intelligent repository once you wrap it in middleware 💅 A directory does associate attributes with objects, but there are four key things that make it different from a database ✨

  • directory objects are essentially independent of each other, whereas database objects are related to each other (sometimes in very complex ways) 🎀
  • directories organize their information using the notion of containment, which is not naturally implemented in databases 🌸
  • directory objects can have specific access controls assigned to an object and even attributes of an object 🔐
  • directories, unlike databases, are optimized to perform a high number of reads vs. writes 📖

Directories use a common core schema, with a common set of syntaxes and matching rules, that defines the characteristics of their data 🧚 That's what lets a common access protocol be used to store and retrieve data 💖

Containment can be used for lots of purposes, including associating roles with objects 🦋 This is super important for real-world environments, where people and elements may take on different roles based on time or other context 🫶 Containment can also provide different naming scopes for a given set of data 🌈

Directories use attribute inheritance, which means subclasses inherit the attributes of their superclasses 💜 This lets you define generalized access control at a container (like a group) and then refine access control for individual objects inside that container (where different objects have different access privileges) 👑

Right now, directories are mostly used to represent people, servers, printers, and other similar objects 🖨️ CIM, DEN, and similar efforts have encouraged directories to hold common objects in a managed environment 🍓 For networked applications, this lets clients of the network (users and applications) get bound to services available in the network in a transparent way ✨ The "Grid" community is making extensive use of directory services for exactly this, using them to keep track of the structure and state of networks, computers, storage systems, software, and people 🔥 The DMTF uses directories to contain CIM and DEN information, which means a common information model can be applied to objects in a managed environment 🌸 The IETF is using directories for lots of different purposes, not least of which is holding common policy info for users and applications, plus services and configuration info for network devices 🎀

CIM and DEN are conceptual information models for describing the management of entities, from network elements to protocols to hosts and services 🧚 They're both platform- and technology-independent 💅 DEN is an extension of CIM that, among other things, describes how to map CIM data into a form that LDAP can use 🫶

The CIM Specification describes the meta schema, information model, language, naming, and mapping techniques to other management models, like SNMP MIBs and DMTF MIFs 🦋 DEN gives a good start on a model that addresses managing the network and its elements 💖 It's an extension of CIM that covers managing networks as a whole, not just individual elements 🌈 DEN handles abstracting a complex entity, like a router, into multiple components that can be used to manage individual aspects of that entity 👑 The DEN information model, like CIM, includes both static and dynamic info 🍓 DEN provides a mapping to directories for storing and retrieving data ✨ DEN will also rely heavily on AAA services to maintain the integrity of the directory and its policies, and to manage how policies get distributed among the policy repositories, PDPs, and PEPs 🔥 Resource managers and applications will also rely heavily on directories to store policy and security info needed for managing and allocating resources 💜

Since so much info about a person, agent, or element is stored in a directory, and access to that info will be controlled with appropriate security mechanisms, lots of people voiced the need for a single user/process sign on 🔐🫶

Future advanced applications (like NGI, Internet2, PACI, and Grids) may need a variety of PDPs to manage a variety of resource types (i.e., QOS, security, etc.) 🌈 In that case, a general model would have to be developed that defines the protocols and mechanisms used by cooperating resource managers (i.e., PDPs) across different domains and different genres of resource (i.e., network, security, storage, proxy agents, online facility, etc.) 🦋 For policies to be implemented in a coherent fashion, there needs to be a mechanism that discovers and tracks resources and utilization 🧚

There's an architectural issue of central importance that has most recently surfaced in the directory area 🚨 Lots of applications, and lots of middleware components, need what is essentially a highly scalable, distributed database service 🍓 In other words, people want the best of what directories and databases have to offer 💖 This would result in a distributed, replicated database that can use containment to effectively organize and scope its information 🌸 It would have exceptional read response time, and also offer transactional and relational integrity 👑 It would support simple and complex queries 🎀 Such a service has never been defined as a middleware component, and the complexities involved in specifying and implementing it are certainly formidable 😭 Still, in the absence of such a general service, many middleware components have tried to use the closest service available, which is deployed (historically using DNS first, and more recently, directory services) 🫶

It'll be important to clarify the limitations of appropriate use of directory services ✨ We also need to consider whether a more general data storage and retrieval service may be required, or whether directory services can be seamlessly integrated (from the point-of-view of the applications using them) with other forms of storage and retrieval (such as relational databases) 🔥 That would give us an integrated directory service with these capabilities 💜

9.0 Resource Management ✨

okay so policy implementation processes need to be linked to Resource Managers in a way more sophisticated way than what exists right now 💅 these processes have to be dynamic and able to reflect changes in their environment. like, adjusting the quality of service an app gets when there's congestion, or when new users with higher priorities log onto the system 🦋 that's giving main character energy. we still need to figure out how different types of resource managers learn about one another and locate each other, and we have to deal with cross-domain security issues too 🔥 another piece is developing a resource definition language that can describe the individual elements of whatever resource is being used, whether that's a network, processor, agent, memory or storage. that's gonna need an appropriate metadata representation and an underlying meta schema that can be applied to multiple resource types 🌸

some models of resource managers are already being used to manage distributed computing and Grid environments (e.g., Condor, Globus, and Legion) 🧚 these resource managers provide languages, clients, and servers to support accessing various types of distributed computing resources (e.g. processors, memory, storage and network access). there's broad interest in the distributed and parallel computing communities in developing an automated access control architecture, using policies, to support the evolving IETF differentiated services architecture 💜 however, this work has not yet been incorporated into any IETF working group charter 🙈 the term "bandwidth broker" has been used to refer to the agents that will implement this functionality through network resource management, policy control, and automated edge device configuration.

the IETF Policy Framework working group is currently working on a policy architecture framework, information model, and policy definition language that's targeted initially at policy management within a single domain. but this work is fundamental in defining inter-domain policy management issues, like the ones required for implementing a network resource manager / bandwidth broker 👑 many resource managers being deployed today rely on directory services for storing policy information, plus X.509 for certificate-based authentication and authorization to these resources. middleware will be required to translate the needs of distributed and parallel computing applications within and across different policy domains. it is crucial that a standard means for representing and using resource management be developed 🫶

advance reservation of resources, as well as dynamic requests for resources, is a crucial aspect of any resource management system 💖 advance reservations are more of a policy issue than a provisioning issue. however, the mechanisms for exchanging and propagating such requests between resource managers located within different administrative domains is a currently unsolved problem that needs to be addressed 😭 it's also important to address the possibility of deadlock and/or the inefficient use of resources (i.e., the time period between a request, or set of requests, being initiated and honored and resources being allocated). there's also a need for rendezvous management in resource allocation services, where an application must gather resource reservations involving multiple sites and services 🍓

a mesh of cooperating resource managers, which interact with each other using standards based protocols (e.g. COPS), could be the model for a resource management infrastructure ✨ each of these may manage different sets of resources. for example, one may be a bandwidth broker that only manages network bandwidth, while another may be a general-purpose resource manager that manages security, IP address allocation, storage, processors, agents, and other network resources. there are already plans for middleware resource managers that not only allocate the resources but also manage the composition of a group of services that may include security services, billing services, shaping of multimedia composite images, etc.). another form of resource manager may provide mapping between a set of related services (i.e., mapping an IP based RSVP request to an ATM SVC, as was demonstrated in a pilot project on the vBNS) 🌈

resource managers depend on the use of locator services to find other resource managers, as well as to locate the AAA server(s) for the requestor and the associated directories containing applicable policy information. they may also need to query the network to determine if a policy request for bandwidth can be satisfied 🎀 it is essential that these (and other) different uses of resource management be integrated to provide an end-to-end service for applications and users alike 👑

10.0 Networked Information Discovery and Retrieval Services 🦋

there's a wide range of middleware services broadly related to the discovery and retrieval of networked information. because such a broad range of applications (and not just high-performance, distributed, or parallel applications) needs these services, this area is under very active development, and new requirements are constantly emerging 💅

perhaps the most basic service here is persistent naming and location services (and infrastructure) that can resolve names to locations (i.e., URLs) 🧚 the IETF has done considerable work defining a syntax for Uniform Resource Identifiers (URIs), which are intended to be persistent name spaces administered by a wide range of agencies. URIs get resolved to URLs using resolver services. there are a bunch of different proposals for these resolver services, and some implementations exist, like the CNRI Handler Service. many organizations are beginning to establish and manage URI namespaces, notably the publishing community with their Digital Object Identifier (DOI) 💜 however, there are many unresolved questions, like how to most effectively deal with the situation where the resource named by a URI exists in multiple places on the network (e.g., find the "closest" mirror in terms of network connectivity and resource availability) 🙈 there's a need for an extensive set of infrastructure around resolvers, including how resources are registered and identifiers are assigned, the ongoing management of data about the current location of resources identified by a specific URI, and the operation of sets of resolvers for various name spaces. finally, given a URI, you need to locate the resolver services connected with that namespace. the IETF has done initial work on resolution service location for URI namespaces 🌸

URIs are intended to be processed primarily by machines. they are not intended to necessarily be easy to remember, though they are intended to be robust under transcription (not sensitive to whitespace, for example) 🫶 more recently, the IETF has begun work on defining requirements for human friendly identifier systems that might be used to register and resolve mnemonic names 🍓

another set of issues revolves around various types of metadata (descriptive, ratings, provenance, rights management, and the like) that may be associated with objects on the network 🌈 the Resource Description Framework (RDF) from the Worldwide Web Consortium (W3C) provides a syntax for attaching such descriptions to network objects and for encoding the descriptions. additional middleware work is needed to locate metadata associated with objects that may be stored in repositories, and to retrieve such metadata. validation of metadata is a key issue, and both IETF and W3C are working on XML canonicalization algorithms that can be used in conjunction with public key infrastructure to sign metadata assertions. however, such an approach implies a complex set of trust relationships and hierarchies that will need to be managed, plus policies that will need to be specified for the use of these trust relationships in retrieval 😭

there's specific work going on defining various types of metadata for applications such as rights management. ultimately this will imply the development of middleware services. it will also impact the use of directory, database, and similar services in the storage, access, and retrieval of this information. similarly, there will be a need for services to connect descriptive metadata and identifiers (URNs) ✨

(See also the NSF/ERCIM report on metadata research issues at

finally, there's a need for a set of middleware services which build upon the research work already integrated into services such as Archie and Harvest 💖 these services permit the efficient extraction of metadata about the contents of network information objects and services without necessarily retrieving and inspecting those services. this includes the ability to dispatch "indexing agents" or "knowbots" that can run at a site to compute such indexing, under appropriate security and authentication constraints. in addition, a set of "push-based" broker services, which aggregate, filter and collect metadata from multiple sites and provide it to interested applications, are also required. such services can provide a massive performance, quality, comprehensiveness and timeliness improvement for today's webcrawler-based indexing services 🚀🔥

11.0. Network QoS ✨

okay so, as we said earlier 💅, apps sometimes need to ask the network for resources so they get the kind of communication they need, or so they get a service with a real guarantee on one or more metrics like bandwidth, jitter, latency, and loss 🎀. One request that's been getting SO much attention lately is for services beyond best effort, especially over IP 🦋. This matters a lot for the advanced apps we mentioned before (think visualization and teleimmersion) and for the rising importance of voice and video, especially voice and video running at lower bandwidth or mixed together with data 🌸. One way to look at it: multiple drops in a single RTT are catastrophic for TCP apps 😭, but they might not be a big deal at all for real-time traffic 💀. Better services can come from a bunch of quality of service (QoS) and class of service (CoS) mechanisms 💜. The first IETF model was Integrated Services (IntServ), which used RSVP as its signaling mechanism 🧚. Since it needs state in every router for every session and to manage the traffic flows, it's generally recognized to have scaling limits 🙈. Still, it's very appropriate in certain situations ✨.

Differentiated Services, or DiffServ, was basically a reaction against the scalability problems people saw in IntServ 🔥. DiffServ is an architecture for scalable service differentiation on the Internet. Scalability comes from aggregating traffic with IP-layer packet marking 👑. Packets get classified and marked so they receive a particular per-hop forwarding behavior at nodes along their path. The fancy stuff, like classification, marking, policing, and shaping, only needs to happen at network boundaries or on hosts 🫶. Network resources get allocated to traffic streams by service provisioning policies, which control how traffic gets marked and conditioned when it enters a differentiated services-capable network, and how it's forwarded inside that network 🌈. These simple PHBs are paired with a much larger number of policing policies enforced at the network edge, so you get a broad, flexible range of services without needing state or complex forwarding decisions in the core and distribution layers 💖.

Recently, people have been super into "tunneling" RSVP over a DiffServ-capable network ⭐. It tries to get the best bits of both IntServ and DiffServ while easing the downsides of each 🦋. That's led the IETF to study ways to make sure Differv and Inteserv can not only coexist but also be interoperable 👀.

The practical realization of either or both architectures depends on lots of middleware components, some of which this document describes 🍓. The workshop talked mostly about DiffServ mechanisms and what they'd do to middleware and its ability to monitor and manage the network infrastructure for the apps' benefit 💅. Both IntServ and DiffServ only fully make sense when linked to a policy mechanism. That mechanism has to be able to make policy decisions, detect and resolve policy conflicts, and enforce and monitor policies 🔥.

Workshop folks almost unanimously agreed they also needed a scalable inter-domain resource manager (e.g., a bandwidth broker) 👑. Right now, if an RSVP session runs, every router along the path gets involved, with flow policing at each hop 😩. Bandwidth Broker models include the bandwidth broker, a policy decision point (which makes admission control and policy decisions), and the policy enforcement points (i.e., edge routers). The enforcement points handle policing at the first hop and remark aggregate flows, so later routers only need to deal with the aggregates 💜.

COPS, Diameter, and others were discussed too, as protocols that could implement a Bandwidth Broker model 🧚. Diameter is interesting here because it sets up basic network resource allocations and reallocations, plus optional allocations.- All of these can be used for various bandwidth broker implementations, including ones aimed at QoS using RSVP-type information 🎀. Diameter doesn't currently provide path information. Instead, it relies on network pathway info set up at ingress and egress nodes 🤔. Still, Diameter's status is open in the IETF 👀.

COPS was first developed to set up RSVP policy within a domain, so it's still very intra-domain focused 🌸. It's a useful intra-domain mechanism for allocating bandwidth within a policy context ✨. Work is happening now to use COPS to set up policy for a DiffServ-capable network ⭐. COPS is designed to help the PDP and PEP talk, carrying policy decisions and other info 💬.

To implement any bandwidth broker model, you need a mechanism for policy exchanges 📨. Internet2's Qbone working group is working on a prototype inter-domain bandwidth broker signaling protocol, and that work is being coordinated with IETF efforts 🌈.

Traffic shaping and SLA policing and enforcement need another mechanism too 🚦. One option is fair queuing in its various forms, which has been described as TDM emulation without the time and space components 🙃. Techniques for fair queuing on low speed lines have been around for years. For DS-3 with 40 byte packets and OC-3c speeds with 200-byte packets, weighted fair queuing uses a deficit round-robin algorithm that lets it scale 💪. It can discriminate flows based on stochastically hashing the flows 🎲. An extra expansion of this technique is to put class indicators in front of it. Right now, classification is based on IP precedence, but it'll soon be done in many routers using Diffserv code points (DSCPs) to specify the type of conditioning to apply 🫶. The complete policing requirements for DiffServ implementations, e.g., via bandwidth brokers, haven't been fully explored or defined yet 🥺.

Network monitoring (querying the network for state information at micro and macro levels) to support middleware and app services was identified as a core requirement 🔍. In fact, a network instrumentation and measurement infrastructure, which intelligent network management middleware services can be built on, is absolutely critical 💯.

Current mechanisms (e.g. ICMP, SNMP) weren't deemed robust enough for middleware and app developers to figure out the state of the network, or to verify they're getting the specific treatment they requested 😤. That was especially true for networks providing QoS or CoS. Honestly, it's not clear SNMP is even the right architectural model for middleware to let apps determine network state 🤷. Other capabilities, like OcxMon, RTFM, new MIBs, and active measurement techniques (e.g., IPPM one-way delay metrics), need to be made available to middleware services and apps 📊.

Differentiated services take the Internet one step away from its "dumb" best effort status 🧠. As complexity grows (VPNs, QoS, CoS, VoIP, etc.), more attention needs to go to giving end-users, customers, or network administrators the tools to securely and dynamically manage an adaptable network infrastructure 🔐. Differentiated services mean some traffic theoretically gets better service than other traffic, so people can expect to pay for better service 💸. That makes accounting and billing services one of the important middleware core components that others will rely on 🧾. The model and protocols needed to do this aren't developed yet 🚧.

12.0 Authentication, Authorization, and Accounting ✨

okay so the IETF's AAA working group is focused on the requirements for authentication, authorization, accounting, and auditing of access to, and services from, network resource managers (think bandwidth brokers 🦋). these processes are a big deal of a security infrastructure that middleware and apps are going to lean on, BUT real talk, they're only basic security components 😭 the group flagged a PKI (public key infrastructure) as a crucial security service component. the PKI has to support the transitivity of authentication, authorization, and access control, and accounting and billing where that makes sense 💅

here's the tea: apart from group security and maybe more efficient, simpler management, there's no real technical blocker stopping a wide scale PKI deployment right now 🙈 the main obstacles are political and economic. extra middleware might still be needed to make a PKI easier to use 🧚 that said, some people think we do have some seriously big technical security challenges. revocation lists and security when group memberships keep changing are the two big examples 💀

middleware and security support is also needed for newer apps 🫶 like proxy agents that act on behalf of a process or application and gather the certificates needed to access and use resources. remote collaboration is a particularly tricky case, because reaching one resource might mean a user or app has to collect certificates from more than one policy-controlling agent 🌸 an entity can also have different identities depending on the task it's doing (usage or role based) or the context of the app. for a PKI to actually work everywhere, there needs to be a set of independent signing authorities that can vouch for the top-level certificate authorities 👑

then there are the higher-level middleware services that will be built on top of all this: PKI, notary services, and provenance verification ✨ as we shift from a relatively dumb network (like best effort IP) to an Internet with embedded intelligence (DiffServ, IntServ, bandwidth brokers, directory-enabled networks, and so on), secure information exchange gets even more important 🔥 once we offer differentiated services, accounting and statistics gathering become way more important too. we also need integrity and security when collecting, analyzing, and transporting network management and monitoring information 🎀 and data privacy and integrity, plus addressing denial of service and non-repudiation, absolutely cannot be ignored 🚨

13.0 Network Management, Performance, and Operations 🍓

network management was identified as paramount to middleware deployment, and therefore to the success of the app too 💖 a lot of this stuff isn't part of standard NOC operations. in a more complex QoS, CoS, and micro prioritization world, reactions to network failures have to be handled differently than current procedures 🌈 allocations get way more dynamic, especially additions, deletions, and changes that come with extra requirements like priorities and new kinds of inter-domain interactions. all of that will inevitably make network management more complex 😭

there are loads of microscopic and macroscopic network management projects working on making both active and passive network statistics and information available to end users ✨ current visual debugging and analysis tools (like the ones built by NLANR/CAIDA) are crucial for network administrators and designers trying to understand their networks 🦋 on top of that, current network management techniques and mechanisms were designed for network designers and managers, so they need to be adapted to give middleware or application service software a dynamic and relevant set of information 🧚 that way programs can adapt on the fly to the changing state of the network infrastructure while keeping the integrity and security of the network and other resources intact 💅

another thing that hasn't gotten enough attention is modeling and analysis tools for network and middleware designers 🙈 CIM and DEN look super promising as a common framework for modeling how network elements and services are managed, along with users, applications, and other network resources 💜 and honestly, middleware designers are going to put new requirements on CIM and DEN that will push these approaches to evolve 🔥

14.0 Middleware to support multicast applications 🦋

IP multicast (the routing and forwarding of multicast packets in an IP-based network) is, according to the workshop, part of the basic network infrastructure 💖 the Internet Group Multicast Protocol, which manages joining and leaving multicast groups, could also count as a basic network service. BUT there's a massive need for middleware services to make multicast actually usable for different applications 😭 it's kind of like how TCP played a key role in making IP applications usable 🫶 specifically, it's reasonable to want middleware services that provide authenticated control of multicast services 🔐 examples include creating and joining multicast groups, multicast address management, multicast channel directories (lots of work has already happened here 🌸), various forms of reliable multicast services (an IRTF research area 🧚), and securing multicast groups with different cryptographic strategies 👑

because multicast can have such a big impact on a network, multicast management middleware services will be needed, especially together with QoS ✨ services that link multicasting across networks that don't directly exchange multicast routing information will also be needed 🎀 but heads up: several security issues with multicast are still unresolved, especially for groups with dynamic membership policies 🚨

15.0 Java and Jini 🧚

Java was picked as an example of a heterogeneous runtime support system to talk through whether it could count as a development language especially suitable for building middleware 💅 the consensus was that the Java language and compilers matter a lot in today's distributed model of the Internet, and for supporting middleware (that is, middleware written in Java) 🌈 a virtual Java machine running on a system can also be considered middleware, the same way an operating system or network operating system would be 🦋

Jini middleware technology doesn't just define a set of protocols for discovery, join, and lookup 💖 it also has a leasing and transaction mechanism to provide resilience in a dynamic networked environment ✨ Java and Jini are going to depend on a working PKI, especially for signed applets 🫶 that said, there are security concerns with both Java and Jini that need to be dealt with, like allowing applets and servlets to be downloaded 😭🔥

16.0 Security Considerations 🔐

this document is a report on a workshop where security was a common theme, which you can see from all the references to security throughout 💜 BUT the workshop didn't reach any specific recommendations for new security-related terminology 🙈

17.0 Summary ✨

okay so middleware isn't only stuff hiding in the persistent infrastructure 💅 it also has components that make app-to-app or host-to-host chats work even when they cross a bunch of separate admin domains 🫶 bestie, the core middleware services are a must-have base for building fancier services on top, kinda like an onion or layers 🧅 these core services help apps use everything the network can do and let them adapt when the network changes 🦋 which services an app actually uses depends on what its field or affinity group needs, like network management or high energy physics 🔬

this doc covers some of the basic core middleware services, including (but not only): directories, name/address resolution, security stuff (authentication, authorization, accounting, and access control 🔐), network management, network monitoring, time servers, and accounting again 😭 network-level capabilities like multicast and DiffServ are NOT middleware 🙅‍♀️ they're enabling infrastructure that middleware gets built on, or that middleware can use and manage 🌸 a second tier of important services sits on top of the core set and can include accounting/billing, resource managers, single sign-on, globally unique names, metadata servers, and locators 👑

the big goal is a set of middleware services that let you access and manage the underlying network and support apps that want to use it ✨ we need an agreed framework for supporting, provisioning, operating, and managing the network 💖 right now there are piecemeal efforts all over the place in standards orgs like the IETF and DMTF (AAA, Policy Framework, DiffServ, DEN, CIM, etc.) and in advanced app environments (Grid Forum, the PACIs, NGI, Internet2, etc.) 🌈 both of these need to integrate and manage lots of infrastructure components, not just networks, and honestly there's no overall framework pulling it all together or any way to coordinate it all 💀 we're just starting to plan a rich set of middleware services, so there's SO much work left 😭🎀 once we move into an electronic persistent presence (EPP) environment where one identity or person (or their proxy agents) has multiple instances, we'll need enhanced locator and brokering services 🧚 the directory (like DNS or X.500) and locator services we have today might not be up to that job 🙈

one goal of the workshop was finding middleware R&D areas that federal agencies and industry might want to fund 🍓 it highlighted a few, including (but not limited to):

  • inter-domain resource management architecture and protocols (e.g., inter-domain bandwidth brokers)
  • resource languages that describe and enable the management of a wide variety of resources (e.g., networks, data bases, storage, online facilities, etc.
  • avoiding deadlock and ensuring efficiency with resource managers
  • network management tools and APIs that provide macroscopic and microscopic real-time infrastructure
  • information to middleware services and applications (not just MIBs and SNMP access)
  • domain and inter-domain accounting and billing
  • monitoring and verification services of contracted infrastructure services
  • enhanced locators that can locate resources and resource managers
  • cross administrative policy negotiation and authentication
  • middleware bypass (i.e. access to raw system or network resources metadata (i.e., data that is used to describe data found in directories or exchanged between services such as resource managers, PDPs, PEPs, directories, accounting and billing services, etc.)
  • middleware support for mobile or nomadic use
  • support for availability of resources (i.e. replication and load balancing

this workshop was just one small step in figuring out which middleware topics, technologies, and players matter 🦋 it didn't land on one agreed definition of middleware, but it did show we need more work 💅 specifically, we need to identify and qualify middleware services for specific affinity groups (e.g. Internet2, Education, the PACIs, Grids, etc.) and define a big-picture framework that brings together the middleware work of the IETF, DMTF, and other relevant orgs like the Grid Forum 🌸

18.0 Participants 🎀

the whole crew who showed up to the workshop, with their contact info 🫶

Deb Agarwal <deba@george.lbl.gov>, Bob Aiken <raiken@cisco.com>, Guy
Almes <almes@internet2.edu>, Chase Bailey <chase@cisco.com>, Fred
Baker <fred@cisco.com>, Pete Beckman <beckman@lanl.gov>, Javad
Boroumand <jborouma@nsf.gov>, Scott Bradner <sob@harvard.edu>, George
Brett <ghbrett@mindspring.com>, Rich Carlson <racarlson@anl.gov>,
Brian Carpenter <bcarpent@uk.ibm.com>, Charlie Catlett
<catlett@ncsa.uiuc.edu>, Bill Cheng <wtcheng@us.ibm.com>, Kim Claffy
<kc@caida.org>, Bill Decker <Wdecker@nsf.gov>, Christine Falsetti
<cfalsetti@arc.nasa.gov>, Ian Foster <foster@mcs.anl.gov>, Andrew
Grimshaw <grimshaw@cs.virginia.edu>, Ed Grossman
<egrossma@ncsa.uiuc.edu>, Ted Hanss <ted@internet2.edu>, Ron Hutchins
<ron@oit.gatech.edu>, Larry Jackson <jackson@ncsa.uiuc.edu>, Bill
Johnston <Wejohnston@lbl.gov>, Juerg von Kaenel <jvk@us.ibm.com>,
Miron Livny <miron@cs.wisc.edu>, Cliff Lynch <cliff@cni.org>, Joel
Mambretti <j-mambretti@nwu.edu>, Reagan Moore <moore@sdsc.edu>, Klara
Nahstedt <klara@cs.uiuc.edu>, Mike Nelson <mrn@us.ibm.com>, Bill
Nitzberg <nitzberg@nas.nasa.gov>, Hilarie Orman <ho@darpa.mil>, John
Schnizlein <jschnizl@cisco.com>, Rick Stevens <stevens@mcs.anl.gov>,
John Strassner <johns@cisco.com>, Ben Teitelbaum <ben@advanced.org>,
George Vanecek <g.vanecek@att.com>, Ken Klingenstein
<Ken.Klingenstein@Colorado.EDU>, Arvind Krishna
<akrishna@us.ibm.com>, Dilip Kandlur <kandlur@us.ibm.com

19.0 URLs/references 🔗

if you want the workshop slides plus a list of related URLs on apps, middleware, and network services, check out http://www.mcs.anl.gov/middleware98 🧚✨

20.0 Authors' Addresses 💌

the editor and authors, and how to reach them 💖

Editor:  Bob Aiken
         EMail: raiken@cisco.com

Authors:

Bob Aiken
Cisco Systems, Inc.
6519 Debold Rd.
Sabillasville, Md.  21780 USA

Phone: +1 301 271 2919
EMail: raiken@cisco.com


John Strassner
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA  95134

Phone: +1 408 527 1069
EMail: johns@cisco.com


Brian E. Carpenter
IBM United Kingdom Laboratories
MP 185, Hursley Park
Winchester, Hampshire SO21 2JN, UK

EMail: brian@hursley.ibm.com


Ian Foster
Argonne National Laboratory
The University of Chicago
Argonne, IL 60439  USA

Phone: +1 630 252 4619
EMail: foster@mcs.anl.gov
Clifford Lynch
Coalition for Networked Information
21 Dupont Circle
Washington, DC  20036

Phone: +1 202 296 5098
EMail: cliff@cni.org


Joe Mambretti
International Center for Advanced Internet Research
1890 Maple, Suite 150
Northwestern University, Evanston, Illinois 60201

Phone: +1 847 467 3911
EMail: j-mambretti@nwu.edu


Reagan Moore
University of California, San Diego
NPACI/SDSC, MC 0505
9500 Gilman Drive
La Jolla, CA 92093-0505   USA

EMail: moore@sdsc.edu


Benjamin Teitelbaum
Advanced Networks & Services, Inc.

EMail: ben@internet2.edu

this part is the legal stuff, so I'm keeping it word-for-word 🫶 no cap, you do not want to mess with it 😭

Copyright (C) The Internet Society (2000). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🌈

funding for the RFC Editor function is currently provided by the Internet Society 💜

📦 where this page comes from