RFC 3238

IAB Architectural and Policy Considerations for Open Pluggable Edge Services

📅 published January 2002, from ietf

RFC 3238: IAB Architectural and Policy Considerations for Open Pluggable Edge Services 🎀

okay bestie, this one is from the Internet Architecture Board (IAB), written by S. Floyd and L. Daigle, and it came out in January 2002 ✨. It's Informational, so it's sharing advice and not setting a standard 💅. The header doesn't list anything it obsoletes or updates, so it's standing on its own 🌸. The whole thing is about the IAB's concerns for Open Pluggable Edge Services (OPES), which were being discussed for chartering in the IETF at the time 🦋.

Status of this Memo ✨

This memo gives info to the Internet community 💖. It doesn't specify an Internet standard of any kind, so don't go implementing it like it's law 🙈. Distribution of this memo is unlimited 🌈.

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

Abstract 💜

okay so this doc has the IAB's comments and recommendations on some architectural and policy issues about chartering OPES in the IETF 🫶. OPES are services that would run at application-level intermediaries in the network, like a web proxy cache sitting between the origin server and the client 🧚. These middlemen would transform or filter content, but only with the explicit consent of either the content provider or the end user 🍓. Honestly, consent is the whole vibe ✨.

1. Introduction 🦋

okay, the intro sets the scene 💅. OPES are services that would be deployed in the network, for example at a web proxy cache between the origin server and the client, and they'd transform or filter content 🌸. Examples of proposed OPES services include assembling personalized web pages, adding user-specific regional information to web pages, virus scanning, content adaptation for clients with limited bandwidth, language translation, and the like [OPES] 🌈. So many ideas, lowkey iconic 🔥.

Now the drama 🙈. Chartering OPES in the IETF ([OPESBOF1], [OPESBOF2], [OPESBOF3]) and the controversy around it in the IETF community ([Carr01], [CDT01], [Morris01], [Orman01], [Routson01]) brought up a bunch of architectural and policy issues 😭. They're about robustness and the end-to-end integrity of data, meaning the differences between what the "origin server" makes available and what the client actually receives 💀. People also asked whether a protocol developed and standardized in the IETF should have to protect the end-to-end privacy and integrity of data 🫶. This document tries to tackle some of those unresolved issues in the OPES chartering and get some common recommendations from the IAB on them 💖.

The purpose of this document is not to recommend specific solutions for OPES, and it's not trying to mandate specific functional requirements either 🙅‍♀️. It's also not a recommendation to the IESG about whether OPES should be chartered 🎀. Instead, these are recommendations on issues that any OPES solutions standardized in the IETF should be required to address, kind of like the "Security Considerations" that IETF documents already need [RFC2316] ✨. For example, you can address security issues by showing that appropriate security mechanisms are in the protocol, or by showing that no security issues apply to that particular protocol 🦋. (Real talk though: a blanket sentence saying "no security issues are involved" is never considered enough to address security concerns in a protocol with known security issues 🚨💅.)

This document makes our concerns about integrity, privacy, and security as clear as possible 🔥. We recommend that the IESG require OPES documents to address integrity, privacy, and security concerns somehow 🌈. They can either demonstrate appropriate mechanisms or make a convincing case that no integrity or privacy concerns are relevant to a particular document 🧚.

Here's the part that worries me most 😭. It seems unavoidable that at some point some OPES service will behave inappropriately, like a virus scanner rejecting content that doesn't actually include a virus 💀. It also seems likely that some OPES intermediary will get compromised, either by accident or with malicious intent 🙈. So the overall architecture needs to help protect end-to-end data integrity from the very beginning of the design process by helping end hosts detect and respond to inappropriate behavior by OPES intermediaries 🛡️💜.

One of the goals of the OPES architecture must be to keep the robustness that's long been cited as one of the overriding goals of the Internet architecture [Clark88] 👑. So we recommend that the IESG require the OPES architecture to protect end-to-end data integrity by supporting end-host detection and response to inappropriate behavior by OPES intermediaries ✨. When we say "supporting end-host detection," we mean supporting detection by the humans responsible for the end hosts at the content provider and the client 🫶. Also, a lot of these worries about end hosts detecting and responding to bad intermediary behavior could apply to web caches and content distribution infrastructures even without OPES in the picture 🌸.

Each section of the document has a set of IAB Considerations that we'd recommend the OPES architecture address 🎀. Section 6 summarizes all of them in one place, so skip ahead there if you want the cheat sheet 💅✨.

Last thing: in this document we try to use terminology consistent with [RFC 3040] and with OPES works in progress 🧚.

2. Some history of the controversy about chartering OPES 🍿

okay so let's talk drama 💅 One view on OPES has been that "OPES is deeply evil and the IETF should stay far, far away from this hideous abomination" [ODell01]. Others have suggested that "OPES would reduce both the integrity, and the perception of integrity, of communications over the Internet, and would significantly increase uncertainly about what might have been done to content as it moved through the network", and that therefore the risks of OPES outweigh the benefits [CDT01]. This view of the risks of OPES was revised in later email, based on the proposals from [Carr01], "assuming that certain privacy and integrity protections can be incorporated into the goals of the working group" [Morris01]. the glow-up arc is real 🦋

One issue concerns the one-party consent model. 🫶 In the one-party consent model, one of the end-nodes (that is, either the content provider or the end user) is required to explicitly authorize the OPES service, but authorization is not required from both parties. [CDT01] comments that relying only on a one-party consent model in the OPES charter "could facilitate third-party or state-sponsored censorship of Internet content without the knowledge or consent of end users", among other undesirable scenarios. 😭

A natural first question is whether there is any architectural benefit to putting specific services inside the network (e.g., at the application-level web cache) instead of positioning all services either at the content provider or the end user. (Note that we are asking here whether there is architectural benefit, which is not the same as asking if there is a business model.) Client-centric services suggested for OPES include virus scanning, language translation, limited client bandwidth adaptation, request filtering, and adaptation of streaming media, and suggested server-centric services include location-based services and personalized web pages. 🧚

It seems clear that there can indeed be significant architectural benefit in providing some OPES services inside the network at the application-level OPES intermediary. For example, if some content is already available from a local or regional web cache, and the end user requires some transformation (such as adaptation to a limited-bandwidth path) applied to that data, providing that service at the web cache itself can prevent the wasted bandwidth of having to retrieve more data from the content provider, and at the same time avoid unnecessary delays in providing the service to the end user. 🌸

A second question is whether the architectural benefits of providing services in the middle of the network outweigh the architectural costs, such as the potential costs concerning data integrity. This is similar to the issues considered in RFC 3135 [RFC 3135] of the relative costs and benefits of placing performance-enhancing proxies (PEPs) in the middle of a network to address link-related degradations. In the case of PEPs, the potential costs include disabling the end-to-end use of IP layer security mechanisms; introducing a new possible point of failure that is not under the control of the end systems; adding increased difficulty in diagnosing and dealing with failures; and introducing possible complications with asymmetric routing or mobile hosts. RFC 3135 carefully considers these possible costs, the mitigations that can be introduced, and the cases when the benefits of performance-enhancing proxies to the user are likely to outweigh the costs. A similar approach could be applied to OPES services (though we do not attempt that here). 🎀

A third question is whether an OPES service, designed primarily for a single retrieval action, has an impact on the application layer addressing architecture. This is related to the integrity issue above, but is independent of whether these services are applied in the middle of the network or at either end. 💜

Most of this document deals with the specific issue of data integrity with OPES services, including the goal of enabling end hosts to detect and respond to inappropriate behavior from broken or compromised OPES intermediaries. ✨

We agree that one-party consent, with one of the end-hosts explicitly authorizing the OPES service, must be a requirement for OPES to be standardized in the IETF.

However, as we discuss in the next section of this document, we agree with [CDT01] that the one-party consent model by itself (e.g., with one of the end-hosts authorizing the OPES service, and the other end-host perhaps being unaware of the OPES service) is insufficient for protecting data integrity in the network. We also agree with [CDT01] that, regardless of the security and authorization mechanisms standardized for OPES in the IETF, OPES implementations could probably be modified to circumvent these mechanisms, resulting in the unauthorized modification of content. Many of the protocols in the IETF could be modified for anti-social purposes - transport protocols could be modified to evade end-to-end congestion control, routing protocols could be modified to inject invalid routes, web proxy caches could be used for the unauthorized modification of content even without OPES, and so on. None of these seem like compelling reasons not to standardize transport protocols, routing protocols, web caching protocols, or OPES itself. In our view, it means instead that the infrastructure needs, as much as possible, to be designed to detect and defend itself against compromised implementations, and misuses of protocols need to be addressed directly, each in the appropriate venue. 🔥

Mechanisms such as digital signatures, which help users to verify for themselves that content has not been altered, are a first step towards the detection of the unauthorized modification of content in the network. However, in the case of OPES, additional protection to ensure the end-to-end integrity of data is desirable as well, for example, to help end-users to detect cases where OPES intermediaries were authorized to modify content, but perform inappropriate modifications. We would note that mechanisms can help end-users to detect compromised OPES intermediaries in some cases even if they do not guarantee that end-users will be able to detect compromised OPES intermediaries in all cases. 🌈

If OPES is chartered, the OPES working group will also have to explicitly decide and document whether the OPES architecture must be compatible with the use of end-to-end encryption by one or more ends of an OPES-involved session. If OPES was compatible with end-to-end encryption, this would effectively ensure that OPES boxes would be restricted to ones that are known, trusted, explicitly addressed at the IP layer, and authorized (by the provision of decryption keys) by at least one of the ends. Compatibility with end-to-end encryption would also help to prevent the widespread deployment of yet another set of services that, to benefit from, require one to keep one's packet contents in the clear for all to snoop. 🙈

IAB Considerations:

  • (2.1) One-party consent: An OPES framework standardized in the IETF must require that the use of any OPES service be explicitly authorized by one of the application-layer end-hosts (that is, either the content provider or the client).
  • (2.2) IP-layer communications: For an OPES framework standardized in the IETF, the OPES intermediary must be explicitly addressed at the IP layer by the end user.

We note that (2.2) is not intended to preclude a chain of intermediaries, with the first intermediary in the chain explicitly addressed at the IP layer by the end user. 👑

3. End-to-end Integrity 💖

The proposed OPES services have several possible forms, including server-centric services, such as the dynamic assembling of web pages, explicitly authorized by the content provider; client-centric services such as virus scanning or language translation explicitly authorized by the end user to act on the response from the content provider; and client-centric services such as privacy-based services or content-filtering explicitly authorized by the end user to act on the request from the end user to the content provider. We consider the issue of the end-to-end integrity of data separately for these different classes of services. 🦋

For each specific service, the question arises of whether it is necessary for both the content provider and the end user to be able to detect and respond to inappropriate behavior by OPES intermediaries, or if it is sufficient for just one of the two end-hosts to have this ability. We don't attempt a general answer, but we do discuss the issues further in the sections below. 🫶

3.1. Data integrity with client-centric OPES services on responses ✨

Okay so, why would anyone care about the end-to-end integrity of data when a client-centric OPES service is messing with a response from a content provider? 🤔 If the client asks for virus scanning or language translation, why should the content provider care one way or another? 💅 Here's the tea: one of the IETF's proper jobs is designing architectures that let end-hosts detect and respond to inappropriate actions in the network. This matters a LOT for powerful devices in the network like OPES intermediaries. An end-node authorizes them to act on or transform data in the network, but they're not under that end-node's direct control, and that's giving major "who's watching the watchers" energy 👀🔥

Let's use virus scanning or language translation as an example 🌸 The end user has real power over imperfect or corrupted virus scanners or translators that live under her direct control, like on her own machine 💻 She knows exactly what program is installed, and she can look at the content before and after the service touches it 🦋 With OPES services running in the network itself, though, the end user might only get a binary choice: authorize the service or don't. That's a lot less control 😭 (Also, quick side note: services deployed on the end host in a self-contained way, like a local virus scanning program, aren't a service in the network, so they're not in the IETF's province one way or another 🧚)

For an OPES service like virus scanning or language translation, the end user could catch a corrupted intermediary, but only with a "black-box" approach of comparing the input with the output. 🙈 That's imprecise and takes a lot more effort than checking a corrupted virus scanner on your own machine. For example, the user could grab the "non-OPES" version of the content straight from the content provider (if there is one) and compare it with the "OPES" version from the OPES intermediary. BUT, with dynamic content, the "non-OPES" version the user fetched directly might not be the same as the "non-OPES" version the OPES intermediary was looking at 💀 So the end user has limited control over the OPES service and limited ability to detect imperfect or corrupted intermediaries. That's exactly why we need an architecture that also helps the content provider detect and respond to imperfect or corrupted OPES intermediaries 🫶

Let's zoom in on virus scanning, authorized by the end user as an OPES service. You could totally imagine virus scanning becoming a widely deployed OPES service, sitting on top of the virus scanning already happening on the end host itself 🌈 Say I ask for a paper by Steve Bellovin on security and viruses in the network, and my authorized OPES virus-scanning service tells me this content does not pass the virus-scan. Now there are a few possibilities:

  1. Unknown to Steve, the content (that is, Steve's paper) contains a harmful virus.
  2. Steve inserted a harmful virus in the content on purpose, with playful or malicious intent.
  3. The OPES virus scanner can't distinguish between a true harmful virus and Steve's paper about harmful viruses. 🙃
  4. My local OPES virus scanner has been hacked, with malicious intent, to reject all content from Steve Bellovin. 😤

At some point, for some content, some widely-deployed implementation of some OPES virus scanner is likely to result in problem (3), and some OPES implementation is likely to get corrupted into problem (4) 💅 Because the end user has limited control over the OPES virus scanner, she's also limited in her ability to detect problems (3) or (4) in it. Plus, the content provider is probably the one with the strongest incentive to catch problems (3) or (4) in the OPES virus scanner. (The content provider generally has a strong incentive to catch problem (1) too.) So it seems prudent to carefully design the overall OPES architecture so the OPES virus scanning service, as authorized by the client, doesn't unnecessarily block content that actually doesn't have viruses in it 🍓

Now, it's obviously not viable for content providers to just say "pass this to the end user without virus scanning," because the whole point of virus scanning is for the end user to stay in control here 🙅‍♀️ BUT, if some form of end-system notification lets the content provider find out that its content is being rejected by a virus scanning service instead of being delivered to the end user, then the content provider (Steve, in this case) might want to tell end users that this content is known not to pass some OPES virus scanning services. Then end users can make their own call on whether to fetch that content while bypassing the OPES virus scanning service, relying on their own virus scanner or an alternate virus scanning service for that particular content 🎀 That kind of end-system notification to the content provider, if requested, can't be enforced, and it can't be relied upon from corrupted intermediaries. Still, it seems important anyway ✨

Of course, malicious users can also use their awareness of the virus scanning service to level up their ability to build viruses that dodge it 😈 This will happen anyway, with any virus scanning service, and it seems like an acceptable cost for giving content providers some protection against the vagaries of imperfect or corrupted OPES services in the network 💜

So, for client-requested services like virus scanning and language translation, it's clearly desirable for the origin server to get notification, if it asks for it, that these services are being performed on its content before the content goes to the client 🫶 Any such end-system notification might come with reduced performance (in terms of overhead, delays, etc.) for the OPES service applied to that content. But some form of end-system notification is clearly necessary if content providers are going to be able to detect and respond to actions by OPES intermediaries that the content provider deems inappropriate. No notification, no detecting, no responding! 😭

Similarly, for a client-based OPES service of language translation, it's clearly desirable for content providers to be able to tell end users when some content is deemed by the content provider to be incompatible with language translation 🌸 In this case, the important thing isn't to stop the OPES language translation from happening on the content. Instead, it's to give the content provider a mechanism to discover the language translation and to inform the end user (or, more precisely, the end user's host computer) if the content provider believes this translation is incompatible with this particular content 🦋

IAB Considerations:

(3.1) Notification: The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider. 👑

3.2. Data integrity with server-centric OPES services 🌸

okay so, what are the concerns, if any, with end-to-end integrity of data in a server-centric OPES service like location-based services? 👀 For example, CNN could authorize a location-based OPES service where the OPES intermediary slips the weather report or news headline of regional interest into the requested web page 🗞️ The same issue of detecting and responding to broken or modified OPES intermediaries shows up with server-centric OPES just like it does with client-centric ones. We're only looking at server-centric services on responses, because we're not aware of any proposals for server-centric OPES services on requests from the client to the content provider 🤷‍♀️

So how are the end-nodes supposed to detect inappropriate actions from OPES services that the content provider authorized? 🤔 The OPES service runs at an OPES intermediary sitting in the network itself, and it's totally not under the direct control of the content provider. So the content provider might not even be able to monitor the intermediary's output directly 😭 Someone could argue that the content provider and the server-centric OPES intermediary are one single distributed application, and can handle broken or modified intermediaries on their own without involving the end user. But that's kinda unconvincing, bestie 🙃 It basically says that standardizing protocols for OPES services is a network issue that's squarely the IETF's job, but making sure the whole service has integrity is a distributed application thing that's not the IETF's problem at all. You can't have it both ways 💅 Just labeling the content provider and the OPES intermediary as "part of the same app" doesn't give the content provider the power to monitor what the intermediary does.

However, if the end user gets some kind of notification that these OPES services were applied, AND has a way to grab the "non-OPES" content from the content provider without the intermediary's changes (if a non-OPES version of the content even exists 🧐), then the end user is in a much better spot to detect and react to bad behavior from compromised or poorly designed intermediaries ✨ So some form of end-system notification is REQUIRED, so the end user can detect and respond to broken or modified OPES intermediaries. If the end user knows an OPES intermediary took action, they could "veto" the OPES service just by tossing the OPES-modified content in the trash 🗑️ And if the client wants to talk straight to the origin server to get the "non-OPES" version, and the origin server is set up to allow it, then the OPES intermediary MUST be designed to permit that end-to-end communication 🫶

In addition to concerns about detecting and responding to faulty or compromised OPES intermediaries, there are purely policy-based concerns about data integrity 📜 If the content provider looks at the source IP address from the HTTP request, or flips a coin, to decide what content to serve, that's the content provider's business 🪙 But if there's a "non-OPES" version of some content available from the content provider, and modified versions available from OPES intermediaries too, then it's important that end users can discover they're getting a modified version from the network, and not the "non-OPES" version that the content provider serves directly 🌈

IAB Considerations:

  • (3.2) Notification: The overall OPES framework SHOULD assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries.
  • (3.3) Non-blocking: If there exists a "non-OPES" version of content available from the content provider, the OPES architecture MUST NOT prevent users from retrieving this "non-OPES" version from the content provider.

3.3. Data integrity with client-centric OPES services on requests 🦋

There have also been proposals for OPES services authorized by the client on requests from the client to the content provider 📨 Examples include services that remove fields from the HTTP header for added privacy, and content-filtering services that filter requests based on the requested URL 🙈 For these, end hosts still need help detecting and responding to imperfect or corrupted intermediaries. But it's less clear how far this applies to the content provider, and how far it applies to the end user who authorized the service. The requirements will probably have to be worked out by the OPES and wider IETF communities on a case-by-case basis for each specific service 💜

4. Application Layer Addresses 📍

Most application layer addressing revolves around URIs, which mostly give a structured way to refer to a single data entity on a remote server 🧭 URIs are universal, in that, in principle, you get the same result no matter where the client is doing the resolution 🌍

Practice often doesn't match the theory, though 😅 Ad-strippers remove data from pages at the client end, and web server farms redirect clients to one of several potential target machines for load-balancing, or to give the user "localized" content 🍓

But architecturally, it's important to be clear about what's actually going on 🧠 In all cases, URI resolution standards (as defined for individual URI schemes, such as HTTP) apply unchanged between the client and the OPES intermediary. What the intermediary does to fulfill the request isn't the point here, but it MUST produce a result that is compliant with the applicable URI scheme definition. In this sense, the OPES intermediary is the "endpoint" of URI resolution 🎯

In client-centric OPES, the intermediary resolves the URI on behalf of the client, and then applies client-requested services to provide a data response to the client. The client gets the data it wanted, but it didn't carry out the URI resolution itself 💁‍♀️

In server-centric OPES, the "origin server" cedes its authority to the intermediary to determine what the "appropriate" content is for a given URI 🫠 The client may well perform standard URI resolution, but that reaches no further than the intermediary.

With those distinctions firmly in mind, there are two particular areas of concern for OPES-like services 👑

The first is the effect of a series of interactions over time and location, not just one document retrieval. Potential problems include inconsistencies in intra- and inter-document references. Depending on what content is changed, references from one version of a document might not exist in a modified target, etc. 🤯

The other concern is whether this leads to content that is exclusively accessible through an intermediary. That is, there's no "non-OPES" version. Either this SHOULD NOT be allowed, or it would argue for an extension to the Internet application layer addressing architecture 🧩

IAB Considerations:

  • (4.1) URI resolution: OPES documentation MUST be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself.
  • (4.2) Reference validity: All proposed services MUST define their impact on inter- and intra-document reference validity.
  • (4.3) Any services that cannot be achieved while respecting the above two considerations MAY be reviewed as potential requirements for Internet application addressing architecture extensions, but MUST NOT be undertaken as ad hoc fixes.

5. Privacy 🔐

Intermediaries in the middle of the network increase the number of locations where the privacy of an end-to-end transaction could be compromised 😬 Some of these privacy concerns apply to web caches and CDNs in general, as well as specifically to OPES intermediaries. It seems like a reasonable requirement, for OPES to be chartered in the IETF, that the issue of providing mechanisms for end users to determine the privacy policies of OPES intermediaries SHOULD be addressed. These mechanisms could be quite different for client-centric and server-centric OPES services 🫧

For a complex issue like an OPES architecture, which interacts with protocols from other standards bodies as well as from other IETF working groups, it's necessary to keep the overall picture in mind while also breaking out specific parts of the problem to be standardized in particular working groups 🧩 So a requirement that the overall OPES architecture address privacy concerns doesn't necessarily mean that the mechanisms for this need to be developed in the IETF, or in the OPES working group (if it is chartered) 💖

IAB Considerations:

  • (5.1) Privacy: The overall OPES framework MUST provide for mechanisms for end users to determine the privacy policies of OPES intermediaries.

6. Summary of IAB Considerations 📋

  • (2.1) One-party consent: An OPES framework standardized in the IETF MUST require that the use of any OPES service be explicitly authorized by one of the application-layer end-hosts (that is, either the content provider or the client).
  • (2.2) IP-layer communications: For an OPES framework standardized in the IETF, the OPES intermediary MUST be explicitly addressed at the IP layer by the end user.
  • (3.1) Notification: The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider.
  • (3.2) Notification: The overall OPES framework SHOULD assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries.
  • (3.3) Non-blocking: If there exists a "non-OPES" version of content available from the content provider, the OPES architecture MUST NOT prevent users from retrieving this "non-OPES" version from the content provider.
  • (4.1) URI resolution: OPES documentation MUST be clear in describing these services as being applied to the result of URI resolution, not as URI resolution itself.
  • (4.2) Reference validity: All proposed services MUST define their impact on inter- and intra-document reference validity.
  • (4.3) Any services that cannot be achieved while respecting the above two considerations MAY be reviewed as potential requirements for Internet application addressing architecture extensions, but MUST NOT be undertaken as ad hoc fixes.
  • (5.1) Privacy: The overall OPES framework MUST provide for mechanisms for end users to determine the privacy policies of OPES intermediaries.

7. Conclusions 🎓

This document includes comments and recommendations by the IAB on some architectural and policy issues related to the chartering of OPES in the IETF 🌟

8. Acknowledgements 🫶

This document has benefited from discussions with members of the IAB and the IESG, contributors to OPES, John Wroclawski, and others. However, this is a document of the IAB, and we do not claim that the other people listed above agree with the contents 💜

9. References ✨

Okay bestie, the reference list is where the receipts live 🧾💅 Every citation below is listed with all its details, so you can go find the sources yourself.

10. Security Considerations 🔐⚠️

Okay, this one is SERIOUS, so read it properly. 🙈

This document does not propose any new protocols, and therefore does not involve any security considerations in that sense. However, throughout this document there are discussions of the privacy and integrity issues of OPES services and the architectural requirements created by those issues. 🔒✨

11. IANA Considerations 🧚

There are no IANA considerations regarding this document. 💤

Authors' Addresses 🖊️

Internet Architecture Board EMail: iab@iab.org

Membership at time this document was completed:

  • Harald Alvestrand
  • Ran Atkinson
  • Rob Austein
  • Fred Baker
  • Steve Bellovin
  • Brian Carpenter
  • Jon Crowcroft
  • Leslie Daigle
  • Steve Deering
  • Sally Floyd
  • Geoff Huston
  • John Klensin
  • Henning Schulzrinne

Copyright (C) The Internet Society (2002). 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