rfc3238.txt

RFC 的详细文档！

   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 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 such as an OPES architecture, which interacts
   with protocols from other standards bodies as well as from other IETF
   working groups, it seems necessary to keep in mind the overall
   picture while, at the same time, breaking out specific parts of the
   problem to be standardized in particular working groups.  Thus, a
   requirement that the overall OPES architecture address privacy
   concerns does not 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                          Informational                     [Page 12]

RFC 3238              IAB Considerations for OPES           January 2002


   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.





IAB                          Informational                     [Page 13]

RFC 3238              IAB Considerations for OPES           January 2002


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

   [Carr01]    Wayne Carr, "Suggested OPES Requirements for Integrity,
               Privacy and Security", email to [e-mail],
               August 16, 2001.  URL "http://www.imc.org/ietf-
               openproxy/mail-archive/msg00869.html".

   [CDT01]     Policy Concerns Raised by Proposed OPES Working Group
               Efforts, email to the IESG, from the Center for Democracy
               & Technology, August 3, 2001.  URL
               "http://www.imc.org/ietf-openproxy/mail-
               archive/msg00828.html".

   [Clark88]   David D. Clark, The Design Philosophy of the DARPA
               Internet Protocols, SIGCOMM 1988.

   [Morris01]  John Morris, "Re: corrected -  Suggested OPES
               Requirements for Integrity, Privacy and Security",
               September 28, 2001.  Email to [e-mail], URL
               "http://www.imc.org/ietf-openproxy/mail-
               archive/msg00935.html".

   [ODell01]   Mike O'Dell, "OPES continuing froth...", Message-Id:
               <[e-mail]>, July 10, 2001, email to
               [e-mail].  URL "http://www1.ietf.org/mail-
               archive/ietf/Current/msg12650.html".

   [OPES]      Open Pluggable Edge Services (OPES) Web Page,
               "http://www.ietf-opes.org/".

   [OPESBOF1]  OPES BOF, 49th IETF, December 12, 2000.  Agenda:
               "http://www.ietf.org/ietf/00dec/opes-agenda.txt".
               Minutes:  "http://www.ietf.cnri.reston.va.us/
               proceedings/00dec/toc.htm#P25_256".




IAB                          Informational                     [Page 14]

RFC 3238              IAB Considerations for OPES           January 2002


   [OPESBOF2]  OPES BOF, 50th IETF, March 9, 2001.  Minutes:
               "http://www.ietf.org/proceedings/01mar/ietf50-40.htm".

   [OPESBOF3]  OPES BOF, 51st IETF, August 2001.  Agenda:
               "http://www.ietf.org/ietf/01aug/opes.txt".  Minutes:
               "http://www.ietf.org/proceedings/01aug/minutes/OPES.HTM".

   [Orman01]   Hilarie Orman, "Data Integrity for Open Pluggable
               Services", email to [e-mail], August 15,
               2001.  URL "http://www.imc.org/ietf-openproxy/mail-
               archive/msg00865.html".

   [RFC 2316]  Bellovin, S., "Report of the IAB Security Architecture
               Workshop", RFC 2316, April 1998.

   [RFC2401]   Kent, S. and R. Atkinson, "Security Architecture for the
               Internet Protocol", RFC 2401, November 1998.

   [RFC 3040]  Cooper, I., Melve, I. and G. Tomlinson, "Internet Web
               Replication and Caching Taxonomy", RFC 3040, January
               2001.

   [RFC 3135]  Border, J., Kojo, M., Griner, J., Montenegro, G. and Z.
               Shelby, "Performance Enhancing Proxies Intended to
               Mitigate Link-Related Degradations", RFC 3135, June 2001.

   [Routson01] Joyce Routson, IETF's Edge Standards Controversy, July
               11, 2001, Stardust CDN Week.  URL
               "http://www.stardust.com/cdnweek/articles/2001/07/09/
               opes.htm".

10.  Security Considerations

   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.









IAB                          Informational                     [Page 15]

RFC 3238              IAB Considerations for OPES           January 2002


Authors' Addresses

   Internet Architecture Board
   EMail:  [e-mail]

   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































IAB                          Informational                     [Page 16]

RFC 3238              IAB Considerations for OPES           January 2002


12.  Full Copyright Statement

   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.



















IAB                          Informational                     [Page 17]