diff options
Diffstat (limited to 'doc/rfc/rfc3914.txt')
| -rw-r--r-- | doc/rfc/rfc3914.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc3914.txt b/doc/rfc/rfc3914.txt new file mode 100644 index 0000000..c1dcc35 --- /dev/null +++ b/doc/rfc/rfc3914.txt @@ -0,0 +1,899 @@ + + + + + + +Network Working Group A. Barbir +Request for Comments: 3914 Nortel Networks +Category: Informational A. Rousskov + The Measurement Factory + October 2004 + + + Open Pluggable Edge Services (OPES) Treatment of + IAB Considerations + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2004). + +Abstract + + IETF Internet Architecture Board (IAB) expressed nine architecture- + level considerations for the Open Pluggable Edge Services (OPES) + framework. This document describes how OPES addresses those + considerations. + + + + + + + + + + + + + + + + + + + + + + + + + +Babir & Rousskov Informational [Page 1] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Consideration (2.1) 'One-party consent' . . . . . . . . . . . 3 + 4. Consideration (2.2) 'IP-layer communications' . . . . . . . . 4 + 5. Notification Considerations . . . . . . . . . . . . . . . . . 5 + 5.1. Notification versus trace. . . . . . . . . . . . . . . . 6 + 5.2. An example of an OPES trace for HTTP . . . . . . . . . . 8 + 5.3. Consideration (3.1) 'Notification' . . . . . . . . . . . 9 + 5.4. Consideration (3.2) 'Notification' . . . . . . . . . . . 10 + 6. Consideration (3.3) 'Non-blocking' . . . . . . . . . . . . . . 10 + 7. Consideration (4.1) 'URI resolution' . . . . . . . . . . . . . 11 + 8. Consideration (4.2) 'Reference validity' . . . . . . . . . . . 11 + 9. Consideration (4.3) 'Addressing extensions' . . . . . . . . . 12 + 10. Consideration (5.1) 'Privacy' . . . . . . . . . . . . . . . . 12 + 11. Consideration 'Encryption' . . . . . . . . . . . . . . . . . . 12 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13 + 13. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 + 14.2. Informative References . . . . . . . . . . . . . . . . . 14 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 + Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 16 + +1. Introduction + + The Open Pluggable Edge Services (OPES) architecture [RFC3835], + enables cooperative application services (OPES services) between a + data provider, a data consumer, and zero or more OPES processors. + The application services under consideration analyze and possibly + transform application-level messages exchanged between the data + provider and the data consumer. + + In the process of chartering OPES, the IAB made recommendations on + issues that OPES solutions should be required to address. These + recommendations were formulated in the form of a specific IAB + considerations document [RFC3238]. In that document, IAB emphasized + that its considerations did not recommend specific solutions and did + not mandate specific functional requirements. Addressing an IAB + consideration may involve showing appropriate protocol mechanisms or + demonstrating that the issue does not apply. Addressing a + consideration does not necessarily mean supporting technology implied + by the consideration wording. + + + + + + + +Babir & Rousskov Informational [Page 2] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + + The primary goal of this document is to show that all formal IAB + recommendations are addressed by OPES, to the extent that those + considerations can be addressed by an IETF working group. The + limitations of OPES working group to address certain aspects of IAB + considerations are also explicitly documented. + + IAB considerations document [RFC3238] contains many informal + recommendations. For example, while the IAB informally requires OPES + architecture to "protect end-to-end data integrity by supporting + end-host detection and response to inappropriate behavior by OPES + intermediaries", the IAB has chosen to formalize these requirements + via a set of more specific recommendations, such as Notification + considerations addressed in Section 5.3 and Section 5.4 below. OPES + framework addresses informal IAB recommendations by addressing + corresponding formal considerations. + + There are nine formal IAB considerations [RFC3238] that OPES has to + address. In the core of this document are the corresponding nine + "Consideration" sections. For each IAB consideration, its section + contains general discussion as well as references to specific OPES + mechanisms relevant to the consideration. + +2. Terminology + + This document does not introduce any new terminology but uses + terminology from other OPES documents. + +3. Consideration (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)." [RFC3238] + + OPES architecture requires that "OPES processors MUST be consented to + by either the data consumer or data provider application" [RFC3835]. + While this requirement directly satisfies IAB concern, no requirement + alone can prevent consent-less introduction of OPES processors. In + other words, OPES framework requires one-party consent but cannot + guarantee it in the presence of incompliant OPES entities. + + In [RFC3897], the OPES architecture enables concerned parties to + detect unwanted OPES processors by examining OPES traces. While the + use of traces in OPES is mandatory, a tracing mechanism on its own + cannot detect processors that are in violation of OPES + specifications. Examples include OPES processors operating in + stealth mode. However, the OPES architecture allows the use of + content signature to verify the authenticity of performed + + + +Babir & Rousskov Informational [Page 3] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + + adaptations. Content signatures is a strong but expensive mechanism + that can detect any modifications of signed content provided that the + content provider is willing to sign the data and that the client is + willing to either check the signature or relay received content to + the content provider for signature verification. + + OPES entities may copy or otherwise access content without modifying + it. Such access cannot be detected using content signatures. Thus, + "passive" OPES entities can operate on signed content without the + data consumer or provider consent. If content privacy is a concern, + then content encryption can be used. A passive processor is no + different from any intermediary operating outside of OPES framework. + No OPES mechanism (existing or foreseeable) can prevent non-modifying + access to content. + + In summary, the one-party consent is satisfied by including the + corresponding requirement in the IAB architecture document. That + requirement alone cannot stop incompliant OPES entities to perform + consent-less adaptations, but OPES framework allows for various means + of detecting and/or preventing such adaptations. These means + typically introduce overheads and require some level of producer- + consumer cooperation. + +4. Consideration (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" [RFC3238]. + + The OPES architecture requires that "OPES processors MUST be + addressable at the IP layer by the end user (data consumer + application)" [RFC3835]. The IAB and the architecture documents + mention an important exception: addressing the first OPES processor + in a chain of processors is sufficient. That is, a chain of OPES + processors is viewed as a single OPES "system" at the address of the + first chain element. + + The notion of a chain is not strictly defined by IAB. For the + purpose of addressing this consideration, a group of OPES processors + working on a given application transaction is considered. Such a + group would necessarily form a single processing chain, with a single + "exit" OPES processor (i.e., the processor that adapted the given + message last). The OPES architecture essentially requires that last + OPES processor to be explicitly addressable at the IP layer by the + data consumer application. The chain formation, including its exit + point may depend on an application message and other dynamic factors + such as time of the day or system load. + + + + +Babir & Rousskov Informational [Page 4] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + + Furthermore, if OPES processing is an internal processing step at a + data consumer or a data provider application side, then the last OPES + processor may reside in a private address space and may not be + explicitly addressable from the outside. In such situations, the + processing side must designate an addressable point on the same + processing chain. That designated point may not be, strictly + speaking, an OPES processor, but it will suffice as such as far as + IAB considerations are concerned -- the data consumer application + will be able to address it explicitly at the IP layer and it will + represent the OPES processing chain to the outside world. + + Designating an addressable processing point avoids the conflict + between narrow interpretation of the IAB consideration and real + system designs. It is irrational to expect a content provider to + provide access to internal hosts participating in content generation, + whether OPES processors are involved or not. Moreover, providing + such access would serve little practical purpose because internal + OPES processors are not likely to be able to answer any data consumer + queries, being completely out of content generation context. For + example, an OPES processor adding customer-specific information to + XML pages may not understand or be aware of any final HTML content + that the data consumer application receives and may not be able to + map end user request to any internal user identification. Since OPES + requires the end of the message processing chain to be addressable, + the conflict does not exist. OPES places no requirements on the + internal architecture of data producer systems while requiring the + entire OPES-related content production "system" to be addressable at + the IP layer. + + Private Domain | Public Domain | Private Domain + | | + +--------------+ | +-------------+ +--------+ + | Data | | | OPES System | |Data | + | Consumer |<--- network -->| with public |<---->|Provider| + | Application | | | IP address | |App | + +--------------+ | +-------------+ +--------+ + | | + | | + + Figure 1 + +5. Notification Considerations + + This section discusses how OPES framework addresses IAB Notification + considerations 3.1 and 3.2. + + + + + + +Babir & Rousskov Informational [Page 5] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + +5.1. Notification versus trace + + Before specific considerations are discussed, the relationship + between IAB notifications and OPES tracing has to be explained. OPES + framework concentrates on tracing rather than notification. The OPES + Communications specification [RFC3897] defines "OPES trace" as + application message information about OPES entities that adapted the + message. Thus, OPES trace follows the application message it traces. + The trace is for the recipient of the application message. Traces + are implemented as extensions of application protocols being adapted + and traced. + + As opposed to an OPES trace, provider notification (as implied by + IAB) notifies the sender of the application message rather than the + recipient. Thus, notifications propagate in the opposite direction + of traces. Supporting notifications directly would require a new + protocol. Figure 2 illustrates the differences between a trace and + notification from a single application message point of view. + + sender --[message A]--> OPES --[message A']--> recipient + ^ V [with trace] + | | + +-<-- [notification] ---+ + + Figure 2 + + Since notifications cannot be piggy-backed to application messages, + they create new messages and may double the number of messages the + sender has to process. The number of messages that need to be + proceed is larger if several intermediaries on the message path + generate notifications. Associating notifications with application + messages may require duplicating application message information in + notifications and may require maintaining a sender state until + notification is received. These actions increase the performance + overhead of notifications. + + The level of available details in notifications versus provider + interest in supporting notification is another concern. Experience + shows that content providers often require very detailed information + about user actions to be interested in notifications at all. For + example, Hit Metering protocol [RFC2227] has been designed to supply + content providers with proxy cache hit counts, in an effort to reduce + cache busting behavior which was caused by content providers desire + to get accurate site "access counts". However, the Hit Metering + protocol is currently not widely deployed because the protocol does + not supply content providers with information such as client IP + addresses, browser versions, or cookies. + + + + +Babir & Rousskov Informational [Page 6] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + + Hit Metering experience is relevant because Hit Metering protocol was + designed to do for HTTP caching intermediaries what OPES + notifications are meant to do for OPES intermediaries. Performance + requirements call for state reduction via aggregation of + notifications while provider preferences call for state preservation + or duplication. Achieving the right balance when two sides belong to + different organizations and have different optimization priorities + may be impossible. + + Thus, instead of explicitly supporting notifications at the protocol + level, OPES concentrates on tracing facilities. In essence, OPES + supports notifications indirectly, using tracing facilities. In + other words, the IAB choice of "Notification" label is interpreted as + "Notification assistance" (i.e., making notifications meaningful) and + is not interpreted as a "Notification protocol". + + The above concerns call for making notification optional. The OPES + architecture allows for an efficient and meaningful notification + protocol to be implemented in certain OPES environments. For + example, an OPES callout server attached to a gateway or firewall may + scan outgoing traffic for signs of worm or virus activity and notify + a local Intrusion Detection System (IDS) of potentially compromised + hosts (e.g., servers or client PCs) inside the network. Such + notifications may use OPES tracing information to pinpoint the + infected host (which could be another OPES entity). In this example, + notifications are essentially sent back to the content producer (the + local network) and use OPES tracing to supply details. + + Another environment where efficient and meaningful notification using + OPES tracing is possible are Content Delivery Networks (CDNs). A CDN + node may use multiple content adaptation services to customize + generic content supplied by the content producer (a web site). For + example, a callout service may insert advertisements for client-local + events. The CDN node itself may not understand specifics of the ad + insertion algorithm implemented at callout servers. However, the + node may use information in the OPES trace (e.g., coming from the + callout service) to notify the content producer. Such notifications + may be about the number of certain advertisements inserted (i.e., the + number of "impressions" delivered to the customer) or even the number + of ad "clicks" the customer made (e.g., if the node hosts content + linked from the ads). Callout services doing ad insertion may lack + details (e.g., a customer ID/address or a web server authentication + token) to contact the content producer directly in this case. Thus, + OPES trace produced by an OPES service becomes essential in enabling + meaningful notifications that the CDN node sends to the content + producer. + + + + + +Babir & Rousskov Informational [Page 7] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + +5.2. An example of an OPES trace for HTTP + + The example below illustrates adaptations done to HTTP request at an + OPES processor operated by the client ISP. Both original (as sent by + an end user) and adapted (as received by the origin web server) + requests are shown. The primary adaptation is the modification of + HTTP "Accept" header. The secondary adaptation is the addition of an + OPES-System HTTP extension header [I-D.ietf-opes-http]. + + GET /pub/WWW/ HTTP/1.1 + Host: www.w3.org + Accept: text/plain + Figure 3 + + ... may be adapted by an ISP OPES system to become: + + GET /pub/WWW/ HTTP/1.1 + Host: www.w3.org + Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8 + OPES-System: http://www.isp-example.com/opes/?client-hash=1234567 + + Figure 4 + + The example below illustrates adaptations done to HTTP response at an + OPES intermediary operated by a Content Distribution Network (CDN). + Both original (as sent by the origin web server) and adapted (as + received by the end user) responses are shown. The primary + adaptation is the conversion from HTML markup to plain text. The + secondary adaptation is the addition of an OPES-System HTTP extension + header. + + HTTP/1.1 200 OK + Content-Length: 12345 + Content-Encoding: text/html + + <html><head><h1>Available Documenta... + + Figure 5 + + ... may be adapted by a CDN OPES system to become: + + HTTP/1.1 200 OK + Content-Length: 2345 + Content-Encoding: text/plain + OPES-System: http://www.cdn-example.com/opes/?site=7654&svc=h2t + + AVAILABLE DOCUMENTA... + Figure 6 + + + +Babir & Rousskov Informational [Page 8] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + + In the above examples, OPES-System header values contain URIs that + may point to OPES-specific documents such as description of the OPES + operator and its privacy policy. Those documents may be + parameterized to allow for customizations specific to the transaction + being traced (e.g., client or even transaction identifier may be used + to provide more information about performed adaptations). An OPES- + Via header may be used to provide a more detailed trace of specific + OPES entities within an OPES System that adapted the message. Traced + OPES URIs may be later used to request OPES bypass [RFC3897]. + +5.3. Consideration (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" + [RFC3238]. + + OPES tracing mechanisms assist content providers in detecting + client-centric actions by OPES intermediaries. Specifically, a + compliant OPES intermediary or system notifies a content provider of + its presence by including its tracing information in the application + protocol requests. An OPES system MUST leave its trace [RFC3897]. + Detection assistance has its limitations. Some OPES intermediaries + may work exclusively on responses and may not have a chance to trace + the request. Moreover, some application protocols may not have + explicit requests (e.g., a content push service). + + OPES tracing mechanisms assist content providers in responding to + client-centric actions by OPES intermediaries. Specifically, OPES + traces MUST include identification of OPES systems and SHOULD include + a list of adaptation actions performed on provider's content. This + tracing information may be included in the application request. + Usually, however, this information will be included in the + application response, an adapted version of which does not reach the + content provider. If OPES end points cooperate, then notification + can be assisted with traces. Content providers that suspect or + experience difficulties can do any of the following: + + o Check whether requests they receive pass through OPES + intermediaries. Presence of OPES tracing info will determine + that. This check is only possible for request/response protocols. + For other protocols (e.g., broadcast or push), the provider would + have to assume that OPES intermediaries are involved until proven + otherwise. + + + + + + + +Babir & Rousskov Informational [Page 9] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + + o If OPES intermediaries are suspected, request OPES traces from + potentially affected user(s). The trace will be a part of the + application message received by the user software. If involved + parties cooperate, the provider(s) may have access to all the + needed information. Certainly, lack of cooperation may hinder + access to tracing information. To encourage cooperation, data + providers might be able to deny service to uncooperative users. + + o Some traces may indicate that more information is available by + accessing certain resources on the specified OPES intermediary or + elsewhere. Content providers may query for more information in + this case. + + o If everything else fails, providers can enforce no-adaptation + policy using appropriate OPES bypass mechanisms and/or end-to-end + encryption mechanisms. + + OPES detection and response assistance is limited to application + protocols with support for tracing extensions. For example, HTTP + [RFC2616] has such support while DNS over UDP does not. + +5.4. Consideration (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" [RFC3238]. + + OPES tracing mechanisms assist end users in detecting OPES + intermediaries. Specifically, a compliant OPES intermediary or + system notifies an end user of its presence by including its tracing + information in the application protocol messages sent to the client. + An OPES system MUST leave its trace [RFC3897]. However, detection + assistance has its limitations. Some OPES systems may work + exclusively on requests and may not have a chance to trace the + response. Moreover, some application protocols may not have explicit + responses (e.g., event logging service). + + OPES detection assistance is limited to application protocols with + support for tracing extensions. For example, HTTP [RFC2616] has such + support while DNS over UDP does not. + +6. Consideration (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" + [RFC3238]. + + + + +Babir & Rousskov Informational [Page 10] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + + "OPES entities MUST support a bypass feature" [RFC3897]. If an + application message includes bypass instructions and an OPES + intermediary is not configured to ignore them, the matching OPES + intermediary will not process the message. An OPES intermediary may + be configured to ignore bypass instructions only if no non-OPES + version of content is available. Bypass may generate content errors + since some OPES services may be essential but may not be configured + as such. + + Bypass support has limitations similar to the two notification- + related considerations above. + +7. Consideration (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" [RFC3238]. + + "OPES Scenarios and Use Cases" specification [RFC3752] documents + content adaptations that are in scope of the OPES framework. + Scenarios include content adaptation of requests and responses. + These documented adaptations do not include URI resolution. In some + environments, it is technically possible to use documented OPES + mechanisms to resolve URIs (and other kinds of identifiers or + addresses). The OPES framework cannot effectively prevent any + specific kind of adaptation. + + For example, a CDN node may substitute domain names in URLs with + CDN-chosen IP addresses, essentially performing a URI resolution on + behalf of the content producer (i.e., the web site owner). An OPES + callout service running on a user PC may rewrite all HTML-embedded + advertisement URLs to point to a user-specified local image, + essentially performing a URI redirection on behalf of the content + consumer (i.e., the end user). Such URI manipulations are outside of + the OPES framework scope, but cannot be effectively eliminated from + the real world. + +8. Consideration (4.2) 'Reference validity' + + "All proposed services must define their impact on inter- and intra- + document reference validity" [RFC3238]. + + The OPES framework does not propose adaptation services. However, + OPES tracing requirements include identification of OPES + intermediaries and services (for details, see "Notification" + consideration sections in this document). It is required that + + + + + +Babir & Rousskov Informational [Page 11] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + + provided identification can be used to locate information about the + OPES intermediaries, including the description of impact on reference + validity [RFC3897]. + +9. Consideration (4.3) 'Addressing extensions' + + "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" [RFC3238]. + + OPES framework does not contain ad hoc fixes. This document in + combination with and other OPES documents should be sufficient to + inform service creators of IAB considerations. If a service does URI + resolution or silently affects document reference validity, the + authors are requested to review service impact on Internet + application addressing architecture and work within IETF on potential + extension requirements. Such actions would be outside of the current + OPES framework. + +10. Consideration (5.1) 'Privacy' + + "The overall OPES framework must provide for mechanisms for end users + to determine the privacy policies of OPES intermediaries" [RFC3238]. + + OPES tracing mechanisms allow end users to identify OPES + intermediaries (for details, see "Notification" consideration + sections in this document). It is required that provided + identification can be used to locate information about the OPES + intermediaries, including their privacy policies. + + The term "privacy policy" is not defined in this context (by IAB or + OPES working group). OPES tracing mechanisms allow end users and + content providers to identify an OPES system and/or intermediaries. + It is believed that once an OPES system is identified, it would be + possible to locate relevant information about that system, including + information relevant to requesters perception of privacy policy or + reference validity. + +11. Consideration 'Encryption' + + "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 + + + + + +Babir & Rousskov Informational [Page 12] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + + 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" [RFC3238]. + + The above quoted requirement was not explicitly listed as on of the + IAB considerations, but still needs to be addressed. The context of + the quote implies that the phrase "end-to-end encryption" refers to + encryption along all links of the end-to-end path, with the OPES + intermediaries as encrypting/decrypting participants or hops (e.g., + encryption between the provider and the OPES intermediaries, and + between the OPES intermediaries and the client). + + Since OPES processors are regular hops on the application protocol + path, OPES architecture allows for such encryption, provided the + application protocol being adapted supports it. Hop-by-hop + encryption would do little good for the overall application message + path protection if callout services have to receive unencrypted + content. To allow for complete link encryption coverage, OPES + callout protocol (OCP) supports encryption of OCP connections between + an OPES processor and a callout server via optional (negotiated) + transport encryption mechanisms [I-D.ietf-opes-ocp-core]. + + For example, TLS encryption [RFC2817] can be used among HTTP hops + (some of which could be OPES processors) and between each OPES + processor and a callout server. + +12. Security Considerations + + This document does not define any mechanisms that may be subject to + security considerations. This document scope is to address specific + IAB considerations. Security of OPES mechanisms are discussed in + Security Considerations sections of the corresponding OPES framework + documents. + + For example, OPES tracing mechanisms assist content providers and + consumers in protecting content integrity and confidentiality by + requiring OPES intermediaries to disclose their presence. Security + of the tracing mechanism is discussed in the Security Considerations + section of [RFC3897]. + +13. Compliance + + This document may be perceived as a proof of OPES compliance with IAB + implied recommendations. However, this document does not introduce + any compliance subjects. Compliance of OPES implementations is + defined in other OPES documents discussed above. + + + + + +Babir & Rousskov Informational [Page 13] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + +14. References + +14.1. Normative References + + [RFC3238] Floyd, S. and L. Daigle, "IAB + Architectural and Policy Considerations + for Open Pluggable Edge Services", RFC + 3238, January 2002. + + [RFC3752] Barbir, A., Burger, E., Chen, R., + McHenry, S., Orman, H. and R. Penno, + "Open Pluggable Edge Services (OPES) + Use Cases and Deployment Scenarios", + RFC 3752, April 2004. + + [RFC3835] Barbir, A., Penno, R., Chen, R., + Hofmann, M., and H. Orman, "An + Architecture for Open Pluggable Edge + Services (OPES)", RFC 3835, August + 2004. + + [RFC3897] Barbir, A., "Open Pluggable Edge + Services (OPES) Entities and End Points + Communication", RFC 3897, September + 2004. + +14.2. Informative References + + [RFC2227] Mogul, J. and P. Leach, "Simple + Hit-Metering and Usage-Limiting for + HTTP", RFC 2227, October 1997. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., + Frystyk, H., Masinter, L., Leach, P. + and T. Berners-Lee, "Hypertext Transfer + Protocol -- HTTP/1.1", RFC 2616, June + 1999. + + [RFC2817] Khare, R. and S. Lawrence, "Upgrading + to TLS Within HTTP/1.1", RFC 2817, May + 2000. + + [I-D.ietf-opes-http] Rousskov, A. and M. Stecher, "HTTP + adaptation with OPES", Work in + Progress, October 2003. + + + + + + +Babir & Rousskov Informational [Page 14] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + + [I-D.ietf-opes-ocp-core] Rousskov, A., "OPES Callout Protocol + Core", Work in Progress, November 2003. + +Authors' Addresses + + Abbie Barbir + Nortel Networks + 3500 Carling Avenue + Nepean, Ontario + CA + + Phone: +1 613 763 5229 + EMail: abbieb@nortelnetworks.com + + + Alex Rousskov + The Measurement Factory + + EMail: rousskov@measurement-factory.com + URI: http://www.measurement-factory.com/ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Babir & Rousskov Informational [Page 15] + +RFC 3914 OPES Treatment of IAB Considerations October 2004 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2004). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE + INTERNET ENGINEERING TASK FORCE DISCLAIM 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. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the IETF's procedures with respect to rights in IETF Documents can + be found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Babir & Rousskov Informational [Page 16] + |