From owner-ietf-openproxy@mail.imc.org Thu May 2 14:55:17 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26284 for ; Thu, 2 May 2002 14:55:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g42IPmG04701 for ietf-openproxy-bks; Thu, 2 May 2002 11:25:48 -0700 (PDT) Received: from flyingfox.snowshore.com (flyingfox.snowshore.com [216.57.133.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42IPla04697 for ; Thu, 2 May 2002 11:25:47 -0700 (PDT) Received: from eburger (keeper.snowshore.com [216.57.133.4]) by flyingfox.snowshore.com (8.11.2/8.11.2) with ESMTP id g42IPnB06670 for ; Thu, 2 May 2002 14:25:49 -0400 (EDT) Reply-To: From: "Eric Burger" To: Subject: RE: call protocol requirements questions Date: Thu, 2 May 2002 14:25:40 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-reply-to: <7B802811BE77D51189910002A55CFD2C01EFCB1E@zsc3c032.us.nortel.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit My $0.02 On Behalf Of Reinaldo Penno: > This is my current list of call protocol requirements questions. Any opinions? I have the same opinion on the following questions: > *Should it be reliable? > Would the transport layer provide this service? > *Should it be congestion aware? > Would the transport layer provide this service? > *Should it support keepalives? > Would the transport layer provide this service (SCTP, for instance)? The protocol needs to be reliable. That may include needing keep alive packets. The IAB will look rather poorly on any protocol that may adversely impact the Internet. A protocol that is not congestion aware would be a prime candidate for rejection. That said, I don't think the requirements document should state the solution. Clearly, TCP addresses all of the requirements. However, there may be other factors that makes TCP less than ideal. Rather than put us in a box today, we should just state the requirements, and on the next pass say either "the protocol provides congestion control using the facilities of the transport layer" or "the protocol provides congestion control using protocol-specific facilities." > *Should the protocol reuse current encryption methods? We assume yes. Is it even possible to say no? > *What about Failover requirements? Hmm. There was a lot of work done for MGCP and Megaco to build-in failover. Two years later, it's still not complete. I would offer that we say the requirement for the protocol is that it allows for high availability solutions. For that matter, we could call out the Reliable Server Pooling work. > *Should it support capability negotiation? > For instance you just tell the intermediary that there are some callout > server available and it figures out by itself which > services each one provides, extensions, etc. Discovery is infinitely better than configuration. > *Should it be NAT friendly? > *Should it work through firewalls? > Maybe in some situations the intermediary is also a middlebox. If possible, but is it a requirement? > *Should it be application agnostic? How would it be application-specific? From owner-ietf-openproxy@mail.imc.org Fri May 3 14:46:03 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24135 for ; Fri, 3 May 2002 14:46:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43Hejw16282 for ietf-openproxy-bks; Fri, 3 May 2002 10:40:45 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Heia16278 for ; Fri, 3 May 2002 10:40:44 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g43HdeL03077; Fri, 3 May 2002 13:39:41 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 3 May 2002 13:39:41 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540212B5C7@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: internet-drafts@ietf.org Cc: Markus Hofmann , Marshall Rose , ietf-openproxy@imc.org, "Abbie Barbir" Subject: draft-ietf-opes-architecture-00 Date: Fri, 3 May 2002 13:39:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1F2C9.817C489E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1F2C9.817C489E Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F2C9.817C489E" ------_=_NextPart_001_01C1F2C9.817C489E Content-Type: text/plain; charset="iso-8859-1" Please publish the attached as as Internet-Draft draft-ietf-opes-architecture-00. <> ------_=_NextPart_001_01C1F2C9.817C489E Content-Type: text/html; charset="iso-8859-1" draft-ietf-opes-architecture-00

Please publish the attached as as Internet-Draft
draft-ietf-opes-architecture-00.
<<draft-ietf-opes-architecture-00.txt>>

------_=_NextPart_001_01C1F2C9.817C489E-- ------_=_NextPart_000_01C1F2C9.817C489E Content-Type: text/plain; name="draft-ietf-opes-architecture-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-opes-architecture-00.txt" Content-Transfer-Encoding: quoted-printable Network Working Group Abbie. Barbir Internet-Draft Nortel = Networks Expires: November 1, 2002 R. = Chen AT&T = Labs M. = Hofmann Bell Labs/Lucent = Technologies H. = Orman The Purple Streak = Development R. = Penno Nortel = Networks G. = Tomlinson = Cacheflow May 3, = 2002 An Architecture for Open Pluggable Edge Services (OPES) draft-ietf-opes-architecture-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 1, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This memo defines an architecture for a cooperative application service in which a data provider, a data consumer, and zero or more Barbir , et al. Expires November 1, 2002 [Page = 1] =0C Internet-Draft OPES Architecture May = 2002 application entities cooperatively realize a data stream service. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 2. The Architecture . . . . . . . . . . . . . . . . . . . . . . . = 4 2.1 OPES Entities . . . . . . . . . . . . . . . . . . . . . . . . = 4 2.2 OPES Flows . . . . . . . . . . . . . . . . . . . . . . . . . . = 5 2.3 OPES Rules . . . . . . . . . . . . . . . . . . . . . . . . . . = 6 2.4 Callout Servers . . . . . . . . . . . . . . . . . . . . . . . = 7 2.5 Policy Enforcement . . . . . . . . . . . . . . . . . . . . . . = 8 2.6 Tracing Facility . . . . . . . . . . . . . . . . . . . . . . . = 8 3. Security and Privacy Considerations . . . . . . . . . . . . . = 10 3.1 Trust Domains . . . . . . . . . . . . . . . . . . . . . . . . = 10 3.2 Primary data flow . . . . . . . . . . . . . . . . . . . . . . = 11 3.3 Callout protocol . . . . . . . . . . . . . . . . . . . . . . . = 11 3.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . . = 11 3.5 Establishing trust . . . . . . . . . . . . . . . . . . . . . . = 12 3.6 End-to-end Integrity . . . . . . . . . . . . . . . . . . . . . = 12 4. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . = 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . = 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . = 14 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . . = 17 Barbir , et al. Expires November 1, 2002 [Page = 2] =0C Internet-Draft OPES Architecture May = 2002 1. Introduction When realizing a data stream service between a provider and a consumer, the need may arise to provision the use of other application entities, in addition to the provider and consumer. For example, some party may wish to customize a data stream as a service to a consumer, e.g., a service might customize the data based on the customer's geographical locality (e.g., language) or resource availability (e.g., display capabilities). In some cases it may be impossible to offer the customization = service at either the provider or the consumer applications. In this case, one or more additional application entities may participate in the data stream service. There are many possible provisioning scenarios which make a data stream service attractive. The reader is referred to [1] for a description of several scenarios. The document presents the architectural components of Open Pluggable Edge Services (OPES) that are needed in order to perform a data stream service. The architecture addresses the IAB considerations described in [2]. These considerations are covered in the various parts of the document, specifically with respect to tracing (Section 2.6) and security considerations (Section 3). The document is organized as follows: Section 2 introduces the OPES architecture. Section 3 discusses security considerations. Section 4 provides a summary of the architecture and the requirements for interoperability. Barbir , et al. Expires November 1, 2002 [Page = 3] =0C Internet-Draft OPES Architecture May = 2002 2. The Architecture The architecture of Open Pluggable Edge Services (OPES) can be described in terms of three interrelated concepts, mainly: o OPES entities: processes operating in the network; o OPES flows: data flows that are cooperatively realized by the OPES entities; and, o OPES rules: these determine how a given data flow is modified by an OPES entity. 2.1 OPES Entities An OPES entity is an application that operates on a data flow = between a data provider application and a data consumer application. OPES entities can be one of the following: o an OPES service application, which analyzes and possibly transforms messages exchanged between the data provider application and the data consumer application; or, o a data dispatcher, which invokes an OPES service application = based on filtering rules and application-specific knowledge. In the network, OPES entities reside inside OPES processors. The cooperative behavior of OPES entities introduces additional functionality for each data flow provided that it matches the OPES rules. The OPES architecture is largely independent of the protocol that is used by the OPES entities to exchange data. However, this document selects HTTP [4] as the example protocol to be used for realizing a data flow. In this regard, the "protocol" stack of an OPES entity = is summarized in Figure 1. Barbir , et al. Expires November 1, 2002 [Page = 4] =0C Internet-Draft OPES Architecture May = 2002 = --------------------------------------------------------------------- OPES entity +-------------+ | | | HTTP | | | +-------------+ | TCP/IP | +-------------+ | ... | +-------------+ Figure 1: An OPES protocol stack = --------------------------------------------------------------------- Figure 1 depicts a "minimal" stack for OPES. However, other protocols may be present, depending on the functions that are performed by the application. 2.2 OPES Flows An OPES flow is a cooperative undertaking between a data provider application, a data consumer application, one or more OPES service applications, and one or more data dispatchers. In order to understand the trust relationships between OPES = entities, each is labeled as residing in an administrative domain. However, depending on provisioning decisions, the entities associated with a given OPES flow may reside in one or more administrative domains. For example, Figure 2 depicts a data flow (also known as an "OPES flow"), that spans two administrative domains. Barbir , et al. Expires November 1, 2002 [Page = 5] =0C Internet-Draft OPES Architecture May = 2002 = --------------------------------------------------------------------- consumer administrative domain provider administrative domain +------------------------------+ = +------------------------------+ | | | = | | data OPES | | OPES data = | | consumer processor | | processor provider = | | | | = | | +----------+ +--------+ | | +--------+ +----------+ = | | | data | | OPES | | | | OPES | | data | = | | | consumer | |service | | | |service | | provider | = | | | appl | | appl | | | | appl | | appl | = | | +----------+ +--------+ | | +--------+ +----------+ = | | | | | | | | | | | | = | | | HTTP | | HTTP | | | | HTTP | | HTTP | = | | | | | | | | | | | | = | | +----------+ +--------+ | | +--------+ +----------+ = | | | TCP/IP | | TCP/IP | | | | TCP/IP | | TCP/IP | = | | +----------+ +--------+ | | +--------+ +----------+ = | | || || || | | || || || = | | =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D | | | | = | +------------------------------+ = +------------------------------+ | <----------------- OPES flow -----------------> | Figure 2: An OPES flow = --------------------------------------------------------------------- Figure 2 depicts two data dispatchers that are present in the OPES flow. However, the architecture allows for zero or more data dispatchers to be present in any flow. 2.3 OPES Rules The behavior of data dispatchers is governed by a set of filtering rules, consisting of a set of conditions and related actions. The ruleset is the superset of all OPES rules on the processor. Data dispatchers invoke OPES service applications that may perform modifications on an OPES flow. In this model, all data filters are invoked for all data. In order to ensure predictable behavior the OPES architecture requires the use of a standardized schema for the purpose of = defining and interpreting the ruleset. The OPES architecture does not = require Barbir , et al. Expires November 1, 2002 [Page = 6] =0C Internet-Draft OPES Architecture May = 2002 a mechanism for configuring a ruleset into a data dispatcher. This is treated as a local matter for each implementation (e.g., through the use of a text editor, secure upload protocol, and so on). = Future revisions of the architecture may introduce such a requirement. 2.4 Callout Servers The OPES ruleset is executed within a data dispatcher, which = triggers the execution of local OPES service applications. How the ruleset = is executed is not the subject of the architecture. However, in some cases it may be useful for the OPES processor to distribute the responsibility of service execution by communicating with one or = more callout servers (cf., [7]). The situation is illustrated in Figure 3, which shows a data dispatcher communicating with multiple callout servers as it processes an OPES flow. = --------------------------------------------------------------------- +----------+ +---------+ +---------+ +---------+ | data | | callout | | callout | | callout | |dispatcher| | server | | server | | server | +----------+ +---------+ +---------+ +---------+ | | | | | | | | | OCP | | OCP | | OCP | ... | OCP | | | | | | | | | +----------+ +---------+ +---------+ +---------+ | TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP | +----------+ +---------+ +---------+ +---------+ || || || || ||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D = || ... || || || || = ||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D || || || = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= Figure 3: An OPES flow with Callout servers = --------------------------------------------------------------------- In Figure 3, a data dispatcher invokes the services of a callout server by using the OPES callout protocol (OCP). The requirements for the OCP are given in [7]. The OCP is application-agnostic, = being unaware of the semantics of the encapsulated application protocol (e.g., HTTP). However, the OCP must incorporate a service aware vectoring capability that parses the data flow according to the ruleset and delivers the data to the OPES service application that Barbir , et al. Expires November 1, 2002 [Page = 7] =0C Internet-Draft OPES Architecture May = 2002 can be local or remote. 2.5 Policy Enforcement Data dispatchers include a ruleset that can be compiled from several sources and must resolve into an unambiguous result. The compiled ruleset enables an OPES processor to detremine which service applications to invoke for which data flow. Accordingly, the data dispatcher consitutes an enhanced Policy Enforcement Point (PEP), where policy rules are executed, data vectoring and connection management is performed, and service-specific data handlers and = state information are maintained, as depicted in Figure 4. = --------------------------------------------------------------------- +----------+ | callout | | server | +----------+ || || || || +---------------------------+ | +----------+ || | | | OPES | || | | | service | || | | | appl | || | | +----------+ || | | +----------------------+ | OPES flow <---->| | data dispatcher/PEP | | <----> OPES flow | +----------------------+ | | OPES | | processor | +--------------------------+ Figure 4: Data Dispatchers and Policy Enforcement Point = --------------------------------------------------------------------- The architecture allows more than one PEP to be present on an OPES flow. 2.6 Tracing Facility The architecture makes no requirements as to how an OPES flow is negotiated, provided that it is consistent with the security policy Barbir , et al. Expires November 1, 2002 [Page = 8] =0C Internet-Draft OPES Architecture May = 2002 (Section 3) of each administrative domain that hosts the OPES entities that are associated with the flow. The OPES architecture requires that each data dispatcher provides tracing facilities that allow the appropriate verification of its operation. The OPES architecture requires that tracing be feasible on the OPES flow per OPES processor using in-band annotation = through header extensions on the application protocol that is used (e.g., HTTP). One of those annotations could be a URL with more detailed information on the transformation that occurred to the data on the OPES flow. Future revisions of the architecture may provide for a tracing facility to be used for subsequent out-of-band analysis. Barbir , et al. Expires November 1, 2002 [Page = 9] =0C Internet-Draft OPES Architecture May = 2002 3. Security and Privacy Considerations Each data flow must be secured in accordance with several policies. The primary stakeholders are the data consumer and the data = provider. The secondary stakeholders are the entities to which they may have delegated their trust. The other stakeholders are the owners of the callout servers. Any of these parties may be participants in the OPES architecture. These parties must have a model, explicit or implicit, describing their trust policy; which of the other parties are trusted to = operate on data, and what security enhancements are required for communication. The trust might be delegated for all data, or it might be restricted to granularity as small as an application data unit. All parties that are involved in enforcing policies must communicate the policies to the parties that are involved. These parties are trusted to adhere to the communicated policies. In order to delegate fine-grained trust, the parties must convey policy information by implicit contract, by a setup protocol, by a dynamic negotiation protocol, or in-line with application data headers. 3.1 Trust Domains The delegation of authority starts at either a data consumer or data provider and moves to more distant entities in a "stepwise" fashion. Stepwise means A delegates to B and B delegates to C and so force. The entities thus "colored" by the delegation are said to form a trust domain with respect to the original delegating party. Here, "Colored" means that if the first step in the chain is the data provider, then the stepwise delegation "colors" the chain with that data "provider" color. The only colors that are defined are data = the "provider" and the data "consumer". An OPES processor may be in several trust domains at any time. There is no restriction on whether the OPES processors are authorized by data consumers and/or data providers. The original party has the option of forbidding or limiting redelegation. An OPES processor must have a representation of its trust domain memberships that it can report in whole or in part for tracing purposes. It must include the name of the party which delegated = each privilege to it. Barbir , et al. Expires November 1, 2002 [Page = 10] =0C Internet-Draft OPES Architecture May = 2002 3.2 Primary data flow The primary data flow occurs between the data provider and the data consumer. OPES must not interfere with the capability of these parties to use end-to-end authentication and confidentiality. If the primary parties want the assurance that their data does not appear in plaintext on network links, but they will permit use of plaintext on OPES processors and/or callout servers, then the OPES processors must use authentication and encryption between "hops". A separate security association must be used for each channel established between two OPES processors. 3.3 Callout protocol The determination of whether or not OPES processors will use the measures that are described in the previous section during their communication with callout servers depends on the details of how the primary parties delegated trust to the OPES processors and the trust relationship between the OPES processors and the callout server. If the OPES processors are in a single administrative domain with = strong confidentiality guarantees, then encryption may be optional. In other cases, encryption and strong authentication would be at least strongly recommended. If the delegation mechanism names the trusted parties and their privileges in some way that permits authentication, then the OPES processors will be responsible for enforcing the policy and for = using authentication as part of that enforcement. The callout servers must be aware of the policy governing the communication path. They must not, for example, communicate confidential information to auxiliary servers outside the trust domain. A separate security association must be used for each channel established between an OPES processor and a callout server. The channels must be separate for different primary parties. 3.4 Privacy Some data from data consumers is considered "private" or = "sensitive", and OPES processors must both advise the primary parties of the = their privacy policy and respect the policies of the primary parties. The privacy information must be conveyed on a per-flow basis. The callout servers must also participate in handling of private Barbir , et al. Expires November 1, 2002 [Page = 11] =0C Internet-Draft OPES Architecture May = 2002 data, and they must be prepared to announce their own capabilities and to enforce the policy required by the primary parties. 3.5 Establishing trust The OPES processor will have configuration policy specifying what privileges the callout servers have and how they are to be identified. This is especially critical for third-party (fourth- party, etc.) callout servers. OPES uses standard protocols for authenticating and otherwise security communication with callout servers. An OPES processor will have a trusted method for receiving configuration information such as rules for the data dispatcher, trusted callout servers, primary parties that opt-in or opt-out of individual services, etc. 3.6 End-to-end Integrity Digital signature techniques can be used to mark data changes in = such a way that a third-party can verify that the changes are or are not consistent with the originating party's policy. This requires an inline manner of specifying policy and its binding to data, a trace of changes and the party making the changes, and strong identities and authentication methods. Strong end-to-end integrity can fulfill some of the functions required by "tracing". Barbir , et al. Expires November 1, 2002 [Page = 12] =0C Internet-Draft OPES Architecture May = 2002 4. Summary Although the architecture supports a wide range of cooperative transformation services, it has few requirements for interoperability. The necessary and sufficient elements are specified in the following documents: o the OPES ruleset schema [6] which defines the syntax and = semantics of the rules interpreted by a data dispatcher; and, o the OPES callout protocol (OCP) [7] which defines the protocol between a data dispatcher and a callout server. Barbir , et al. Expires November 1, 2002 [Page = 13] =0C Internet-Draft OPES Architecture May = 2002 References [1] McHenry, S., et. al, "OPES Scenarios and Use Cases", Internet- Draft TBD, May 2002. [2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. [3] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC = 3198, November 2001. [4] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [5] OPES working group, "OPES Service Authorization and Enforcement Requirements", Internet-Draft TBD, May 2002. [6] OPES working group, "OPES Ruleset Schema", Internet-Draft TBD, May 2002. [7] OPES working group, "OPES Callout Protocol and Tracing Protocol Requirements", Internet-Draft TBD, May 2002. Authors' Addresses Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 EMail: abbieb@nortelnetworks.com Robin Chen AT&T Labs Room E219, 180 Park Avenue Florham Park, NJ 07932 US Phone: +1 973 360 8653 EMail: chen@research.att.com Barbir , et al. Expires November 1, 2002 [Page = 14] =0C Internet-Draft OPES Architecture May = 2002 Markus Hofmann Bell Labs/Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel, NJ 07733 US Phone: +1 732 332 5983 EMail: hofmann@bell-labs.com Hilarie Orman The Purple Streak Development EMail: ho@alum.mit.edu Reinaldo Penno Nortel Networks 2305 Mission College Boulevard San Jose, CA 95134 US EMail: rpenno@nortelnetworks.com Gary Tomlinson Cacheflow EMail: gary@tomlinsongroup.net Barbir , et al. Expires November 1, 2002 [Page = 15] =0C Internet-Draft OPES Architecture May = 2002 Appendix A. Acknowledgements The authors gratefully acknowledge the contributions of: Marshall T. Rose. (more to come, soon...) Barbir , et al. Expires November 1, 2002 [Page = 16] =0C Internet-Draft OPES Architecture May = 2002 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. Barbir , et al. Expires November 1, 2002 [Page = 17] =0C ------_=_NextPart_000_01C1F2C9.817C489E-- From owner-ietf-openproxy@mail.imc.org Mon May 6 08:00:05 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14076 for ; Mon, 6 May 2002 08:00:04 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g46BQB613358 for ietf-openproxy-bks; Mon, 6 May 2002 04:26:11 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g46BQAL13354 for ; Mon, 6 May 2002 04:26:10 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13009; Mon, 6 May 2002 07:26:03 -0400 (EDT) Message-Id: <200205061126.HAA13009@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-architecture-00.txt Date: Mon, 06 May 2002 07:26:03 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : An Architecture for Open Pluggable Edge Services (OPES) Author(s) : A. Barbir et al. Filename : draft-ietf-opes-architecture-00.txt Pages : 17 Date : 03-May-02 This memo defines an architecture for a cooperative application service in which a data provider, a data consumer, and zero or more application entities cooperatively realize a data stream service. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-architecture-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-architecture-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020503135615.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-architecture-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-architecture-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020503135615.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Wed May 8 10:17:55 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08465 for ; Wed, 8 May 2002 10:17:54 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g48Ddn520351 for ietf-openproxy-bks; Wed, 8 May 2002 06:39:49 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48DdlL20347 for ; Wed, 8 May 2002 06:39:48 -0700 (PDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g48DfGUL084098 for ; Wed, 8 May 2002 09:41:16 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g48Ddgo49783 for ; Wed, 8 May 2002 09:39:42 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA22212 for ; Wed, 8 May 2002 09:39:40 -0400 (EDT) Message-ID: <3CD92A9C.1090601@mhof.com> Date: Wed, 08 May 2002 09:39:40 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417 X-Accept-Language: en-us, en MIME-Version: 1.0 To: OPES Group Subject: OPES Architecture Draft Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hi, you might have noticed that an OPES architecture draft has been published this Monday, see http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-00.txt As this draft is overdue, please check it out and comment on it ASAP - we need to move forward and need to close on it very soon. Please send comments to this mailing list. Thanks, Markus From owner-ietf-openproxy@mail.imc.org Wed May 8 15:37:24 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21627 for ; Wed, 8 May 2002 15:37:24 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g48JCQm04888 for ietf-openproxy-bks; Wed, 8 May 2002 12:12:26 -0700 (PDT) Received: from demetrius.hosting.swbell.net (demetrius.hosting.swbell.net [216.100.99.30]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48JCOL04884 for ; Wed, 8 May 2002 12:12:24 -0700 (PDT) Received: from imimic.com ([63.141.155.200]) by demetrius.hosting.swbell.net id PAA08648; Wed, 8 May 2002 15:12:10 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <3CD97837.9904A1FC@imimic.com> Date: Wed, 08 May 2002 14:10:47 -0500 From: Raj Pagaku Organization: Imimic X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 4.3-STABLE i386) X-Accept-Language: en MIME-Version: 1.0 To: ietf-openproxy@imc.org Subject: Symantec CarrierScan's ICAP capabilities Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Hello, I am currently evaluating the Symantec CarrierScan Server's ICAP capabilities for Linux. Whatever request i send, it always seem to return HTTP 504 error ? Has anyone got this server running for ICAP ? What are the details it expects ? The same problem was encountered by Ben of Telcordia technologies a few months back. Unfortunately i could'nt find the responses to those questions. Here is the link to his posting : http://www.imc.org/ietf-openproxy/mail-archive/msg01079.html Thanks. Regards raj From owner-ietf-openproxy@mail.imc.org Sat May 18 22:33:45 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10354 for ; Sat, 18 May 2002 22:33:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4J21OS21247 for ietf-openproxy-bks; Sat, 18 May 2002 19:01:24 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4J21ML21243 for ; Sat, 18 May 2002 19:01:23 -0700 (PDT) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout02.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.6 (built Apr 26 2002)) with ESMTP id <0GWC006TM5M8YQ@mtaout02.icomcast.net> for ietf-openproxy@imc.org; Sat, 18 May 2002 22:01:21 -0400 (EDT) Date: Sat, 18 May 2002 22:01:20 -0400 From: Markus Hofmann Subject: WG Last Call: draft-ietf-opes-architecture-00 To: OPES Group Cc: Allison Mankin , Ned Freed Message-id: <3CE70770.7060500@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Since there haven't been any comments on the published OPES Architecture draft so far, we're issuing a Working Group last call on this draft: This is an OPES Working Group Last Call for comments on draft-ietf-opes-architecture-00. This last call closes Sunday, June 2, 2002. Please post any final comments you have on the draft to this list by that date. If there are no substantive technical issues raised by June 2, we will forward this document to the IESG for publication as Informational. The draft is available at http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-00.txt From owner-ietf-openproxy@mail.imc.org Mon May 20 06:12:36 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03661 for ; Mon, 20 May 2002 06:12:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4K9gVS10165 for ietf-openproxy-bks; Mon, 20 May 2002 02:42:31 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4K9gUL10159 for ; Mon, 20 May 2002 02:42:30 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([212.159.36.6]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g4KHK7409903; Mon, 20 May 2002 10:20:08 -0700 Message-Id: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 20 May 2002 10:47:08 +0100 To: Markus Hofmann From: Graham Klyne Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 Cc: OPES Group , Allison Mankin , Ned Freed In-Reply-To: <3CE70770.7060500@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: There's nothing like a last-call to raise a reviewer's priorities, right?-) I approach this document on the assumption that (based on its title) it is to be a basis for designing and understanding OPES protocol elements. I think it starts off quite well, but then descends into a morass of vague hand-waving whose design intent is hard to fathom. Much of the later parts of the document seem to be a catalogue of requirements rather than the design elements that I would expect in an "architecture". For example, I would expect an "architecture" document to enumerate the various components that must be specified to make up the OPES specification. Also, I think that there are some serious problems with tracing facilities sketched in section 2.6. And I think that, as a starting point for other aspects of OPES design, it would be appropriate to include a collected glossary in this document. And so to detail: Section 1 --------- The first paragraph mentions customization based on geographical locality. Taking this as an example, I didn't notice anything later in the document about the source of information that an OPES processor might use as the basis for customization services. I think some discussion might be appropriate; e.g. is any such customization to be based on information provided by the party with respect of whom the customization is being performed? Or conversely, If I connect via an ISP in a foreign country, might I expect to get information customized for that country? I think such sources of information should at least be clearly identified in any trace information. Section 2.0 ----------- Do OPES entiries include the provider and consumer? It's not clear to me. The second bullet here suggests "yes", but elsewhere suggests "no". Section 2.1 ----------- The distinctive roles of OPES service application and data dispatchers aren't entirely clear. I would expect what you describe as an "Opes service application" that sits on the provider-consumer flow to contain the architectural elements you describe under "data dispatcher". Section 2.2 ----------- Where you say "one or more OPES service applications" and "one or more data dispatchers" I think you mean "zero or more". Later you mention "zero or more..." 2nd para: I found this description rather woolly. Would any significant meaning be lost if the second sentence of this paragraph were to be deleted? Section 2.3 ----------- It seems to me that the OPES rules are a cornerstone of the architecture, but very little is said about them. Section 2.4 ----------- Maybe this is just a personal preference, but talking about "executing" a ruleset seems to be very implementation-choice-oriented; would "evaluating" not be closer to what you mean here? You also discuss using "the OPES callout protocol", which seems to say there is a single such protocol. It is not clear to me why there needs to be a single such protocol, as different dispatcher/server combinations might use different protocols according to the needs of the application. For example, I'd imagine a session-oriented protocol appropriate for an HTTP callout service, but for processing email flows a callout protocol based on email style messaging, or file sharing, might be more appropriate. Maybe there are reasons for defining a single protocol here: if so, I think they should be explained. The final sentence of the final paragraph is impenetrable to me. What's this "...service aware vectoring capability that parses the data flow according to the ruleset..."? And a typo in the final para: "detremine". Section 2.6 ----------- I think this section is very weak. It manages to impose questionable implementation decisions without providing any real guidance about how tracing is to be provided. Specifically, it calls for "in-band annotation through header extensions on the application protocol". I believe that this approach will mean that the tracing facility is effectively unusable at Internet scale, because it depends on protocol extensions that will be largely unimplemented by the end systems who need access to the diagnostic information. I recently encountered a real problem that will illustrate my concern here: my wife works from home as editorial manager for a website. Recently, she was reviewing website content and was getting old data when all the other parties involved were getting new data. This occurred with different browsers, after cache-flushing, etc., so was almost certainly not a local problem. It most likely was a fault in an intermediate transparent cache. Now, I think this is exactly the kind of problem that OPES tracing should be able to diagnose. For this to be useful, I'd say it must be possible to access the traces without any extensions to the protocol whose flow is being serviced by OPES. The sort of design I might suggest would be that an OPES intermediary maintains an audit of services that are applied, possibly for a limited time. This audit should be accessible to affected clients using standard features of the protocol whose flow is being OPES-serviced. Section 3 --------- I think this whole section needs more work -- I found this had a kind of motherhood-and-apple-pie flavour, without providing much in the way of real information about how the security issues are to be handled. Or at least determining what OPES component is responsible for what aspects of the security issues raised. Section 3.2 ----------- This touches on an area where I take issue with the IAB requirements on OPES (and have posted my comments elsewhere). [[ The primary data flow occurs between the data provider and the data consumer. OPES must not interfere with the capability of these parties to use end-to-end authentication and confidentiality. ]] Consider the case of an employee working for a corporation. I is the employee or the corporation considered to be the "data provider" or "data consumer" here. I particular, is OPES required to allow an employee to send encrypted data out of the organization without examination by an intermediary system? In terms of OPES architecture (as I understand it), I think the employee is the end system here, and the corporate network may contain OPES intermediaries that prohibit the data flows that OPES is hereby prohibited from interfering with. That is how content filtering systems with which I am familiar are deployed. I think the requirements need to be refined. #g -- At 10:01 PM 5/18/02 -0400, Markus Hofmann wrote: >Since there haven't been any comments on the published OPES Architecture >draft so far, we're issuing a Working Group last call on this draft: > >This is an OPES Working Group Last Call for comments on >draft-ietf-opes-architecture-00. This last call closes Sunday, June 2, >2002. Please post any final comments you have on the draft to this list by >that date. If there are no substantive technical issues raised by June 2, >we will forward this document to the IESG for publication as Informational. > >The draft is available at > >http://www.ietf.org/internet-drafts/draft-ietf-opes-architecture-00.txt ------------------- Graham Klyne From owner-ietf-openproxy@mail.imc.org Mon May 20 08:21:18 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10429 for ; Mon, 20 May 2002 08:21:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4KBv1820701 for ietf-openproxy-bks; Mon, 20 May 2002 04:57:01 -0700 (PDT) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KBv0L20697 for ; Mon, 20 May 2002 04:57:00 -0700 (PDT) Received: from kalia (dhcpd253.dbc.mtview.ca.us [64.168.10.253]) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g4KBa2d19764; Mon, 20 May 2002 04:36:02 -0700 (PDT) Date: Mon, 20 May 2002 04:55:32 -0700 From: Marshall Rose To: "Graham Klyne" Cc: ietf-openproxy@imc.org Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 Message-Id: <20020520045532.1163d0e7.mrose@dbc.mtview.ca.us> In-Reply-To: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> References: <3CE70770.7060500@mhof.com> <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit [ i've trimed the cc list, because those markus, ned, and allison should be on the mailing list... ] > There's nothing like a last-call to raise a reviewer's priorities, right?-) my interests in this is primarily process, but since i was on the subteam that produced the document, i'd figure i'd answer what questions that i could... > I approach this document on the assumption that (based on its title) it is > to be a basis for designing and understanding OPES protocol elements. I > think it starts off quite well, but then descends into a morass of vague > hand-waving whose design intent is hard to fathom. Much of the later parts > of the document seem to be a catalogue of requirements rather than the > design elements that I would expect in an "architecture". For example, I > would expect an "architecture" document to enumerate the various components > that must be specified to make up the OPES specification. i'm not sure i agree with your characterizations. the job of an architectural document is to enumerate components and their relationships. sometimes, as a part of that, the document has to discuss mechanism. in general, i think that the existing document adheres to those principles. however, it's only a draft (and one that was written from scratch), so some tuning might be needed. > And I think that, as a starting point for other aspects of OPES design, it > would be appropriate to include a collected glossary in this document. my position, in all working groups, has been that putting glossaries in documents is the signature of poor writing. at best, they're redundant, at worst, they're contradictory. if the document can't define terms in context as they are used, then there is a more fundamental problem in the document... > And so to detail: > > Section 1 > --------- > > The first paragraph mentions customization based on geographical > locality. Taking this as an example, I didn't notice anything later in the > document about the source of information that an OPES processor might use > as the basis for customization services. I think some discussion might be > appropriate; e.g. is any such customization to be based on information > provided by the party with respect of whom the customization is being > performed? Or conversely, If I connect via an ISP in a foreign country, > might I expect to get information customized for that country? I think > such sources of information should at least be clearly identified in any > trace information. > Section 2.0 > ----------- > Do OPES entiries include the provider and consumer? It's not clear to > me. The second bullet here suggests "yes", but elsewhere suggests "no". from an architectural perspective, i think the answer is no...hence the "zero, or more" text appearing througout with respect to opes service applications. of course, you can't have an opes flow without the provider or consumer, and perhaps this is why it's counter-intuitive? > Section 2.1 > ----------- > The distinctive roles of OPES service application and data dispatchers > aren't entirely clear. I would expect what you describe as an "Opes > service application" that sits on the provider-consumer flow to contain the > architectural elements you describe under "data dispatcher". i personally think the names are confusing as the diagrams later on try to make clear that the "data dispatcher" is the fundamental thing. so, yes, this needs to get cleaned up. > Section 2.2 > ----------- > Where you say "one or more OPES service applications" and "one or more data > dispatchers" I think you mean "zero or more". Later you mention "zero or > more..." agree. > 2nd para: I found this description rather woolly. Would any significant > meaning be lost if the second sentence of this paragraph were to be deleted? agree. > Section 2.3 > ----------- > It seems to me that the OPES rules are a cornerstone of the architecture, > but very little is said about them. because *architecturally*, very little need to be said, the rest of the document defines the boundaries that the rules operate in... > Section 2.4 > ----------- > Maybe this is just a personal preference, but talking about "executing" a > ruleset seems to be very implementation-choice-oriented; would > "evaluating" not be closer to what you mean here? agree, poor wording. > You also discuss using "the OPES callout protocol", which seems to say > there is a single such protocol. It is not clear to me why there needs to > be a single such protocol, as different dispatcher/server combinations > might use different protocols according to the needs of the > application. For example, I'd imagine a session-oriented protocol > appropriate for an HTTP callout service, but for processing email flows a > callout protocol based on email style messaging, or file sharing, might be > more appropriate. hmmm. i thought that the architecture was saying that there was only one kind of OCP, regardless of the protocol being used in the data flow. in other words, there is no "seems to say" about it, it "says" there's only one. > Maybe there are reasons for defining a single protocol here: if so, I > think they should be explained. so, what you are really asking, and what the working group should discuss is this issue. > The final sentence of the final paragraph is impenetrable to me. What's > this "...service aware vectoring capability that parses the data flow > according to the ruleset..."? agree, poor wording. > And a typo in the final para: "detremine". agree. > Section 2.6 > ----------- > I think this section is very weak. It manages to impose questionable > implementation decisions without providing any real guidance about how > tracing is to be provided. hmmm. again, i think it sets some architectural boundaries, but doesn't make any implementation choices (questionable or not). > Specifically, it calls for "in-band annotation through header extensions on > the application protocol". I believe that this approach will mean that the > tracing facility is effectively unusable at Internet scale, because it > depends on protocol extensions that will be largely unimplemented by the > end systems who need access to the diagnostic information. i think that "Internet scale" means different things. there's also a counter-balancing set of concerns dealing on the impact on the opes entities. my interpretation, which could be wrong, of the iab concerns, was that the working group could get away with diagnosis after the fact. and if you believe that (it's certainly open to discussion), then i think that the logic of simplicity inevitably takes you to what the document says now... (albeit with perhaps more simple wording!) > I recently encountered a real problem that will illustrate my concern > here: my wife works from home as editorial manager for a > website. Recently, she was reviewing website content and was getting old > data when all the other parties involved were getting new data. This > occurred with different browsers, after cache-flushing, etc., so was almost > certainly not a local problem. It most likely was a fault in an > intermediate transparent cache. Now, I think this is exactly the kind of > problem that OPES tracing should be able to diagnose. For this to be > useful, I'd say it must be possible to access the traces without any > extensions to the protocol whose flow is being serviced by OPES. i agree that problems like this should be subject to diagnosis. i don't think it's > The sort of design I might suggest would be that an OPES intermediary > maintains an audit of services that are applied, possibly for a limited > time. This audit should be accessible to affected clients using standard > features of the protocol whose flow is being OPES-serviced. i'm with you right up to the "using standard features of the protocol" ... because your own argument argues against that. maintaining an audit of what's going on is fine (and real systems will do that regardless of what the architecture document says). figuring out how to transparently tap into the audit information is problematic... > Section 3 > --------- > I think this whole section needs more work -- I found this had a kind of > motherhood-and-apple-pie flavour, without providing much in the way of real > information about how the security issues are to be handled. Or at least > determining what OPES component is responsible for what aspects of the > security issues raised. i more or less agree. > Section 3.2 > ----------- > This touches on an area where I take issue with the IAB requirements on > OPES (and have posted my comments elsewhere). > > [[ > The primary data flow occurs between the data provider and the data > consumer. OPES must not interfere with the capability of these > parties to use end-to-end authentication and confidentiality. > ]] > > Consider the case of an employee working for a corporation. I is the > employee or the corporation considered to be the "data provider" or "data > consumer" here. I particular, is OPES required to allow an employee to > send encrypted data out of the organization without examination by an > intermediary system? > > In terms of OPES architecture (as I understand it), I think the employee is > the end system here, and the corporate network may contain OPES > intermediaries that prohibit the data flows that OPES is hereby prohibited > from interfering with. That is how content filtering systems with which I > am familiar are deployed. I think the requirements need to be refined. i agree that one can interpret the IAB concerns as saying that corporations can not address this security issue using OPES. my reading of the document is that the architecture allows OPES to be realized to address this security issue. my understanding of the IESG's perspective on the IAB concerns is that if a cogent argument is made as to why OPES isn't consistent with certain aspects of the IAB concerns, then that's okay... > #g > -- thanks! i look forward to seeing a lively discussion in the working group. speaking of which: as a co-chair, my words on technical matters don't have any more weight than anyone else's. i just happen to have the phone bills from sitting in on the conference calls that produced the architectural document, so i thought i'd reply... /mtr From owner-ietf-openproxy@mail.imc.org Mon May 20 13:51:30 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24221 for ; Mon, 20 May 2002 13:51:30 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4KHS6N05272 for ietf-openproxy-bks; Mon, 20 May 2002 10:28:06 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KHS5L05268 for ; Mon, 20 May 2002 10:28:05 -0700 (PDT) Received: from oskar3 ([65.96.167.167]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020520172802.VBBM18801.rwcrmhc52.attbi.com@oskar3>; Mon, 20 May 2002 17:28:02 +0000 From: "Oskar Batuner" To: "Markus Hofmann" , "OPES Group" Cc: "Allison Mankin" , "Ned Freed" Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Mon, 20 May 2002 13:28:01 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3CE70770.7060500@mhof.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Some notes on the OPES Architecture draft.. > 1. Introduction >In some cases it may be impossible to offer the customization service >at either the provider or the consumer applications. In this case, >one or more additional application entities may participate in the >data stream service. This term - "impossible" - may leave an impression that this is the only, or at least main justification to use OPES. This does not look right. The only scenario (from existing draft-beck-opes-esfnep) where OPES is the only way to implement the service is request filtering for hand-held devices, in all other cases service can be implemented either at the server side or at the client side, or both. Still use of OPES may be beneficial, so I'd suggest ether to use a different wording, like: "In some cases in may be beneficial to provide a customization service at network location instead of deploying it at either the provider or the consumer host. For certain services performed on end-user behalf this may be the only option of service deployment". > 2. The Architecture > - OPES rules: these determine how a given data flow is modified by > an OPES entity. This definition looks too restrictive. From the rest of the document and previous discussions rules are used to determine when the transformation has to be involved. The definition above suggests that the only OPES applications permitted by this architecture are "rules interpreters". I don't think this is what really was intended. > 2.1 OPES Entities The usage of terms "OPES service application" and "data dispatcher" is not always consistent and sometimes even confusing. According to the definition in 2.1 service application is invoked by data dispatcher. If this is always a case (an according to the definition it is so) Figure 1 should look like this: +----------------+ | OPES service | | application | +----------------+ |data dispatcher | +----------------+ | | | HTTP | | | +----------------+ | TCP/IP | +----------------+ | ... | +----------------+ Figure 1: An OPES protocol stack It also may have sense to point out explicitly that OPES application may be executed either on the same box (or even in the same application environment) with the dispatcher or on different box through OCP. This was on of important features in initially discussed architecture, there were even terms like "proxylet" flying in the air. I thing it has sense to emphasize this possibility and to provide a figure like this: +--------------------------+ | +----------+ | | | OPES | | | | service | | | | appl | | | +----------+ | +----------------+ | || | | | | +----------------------+ | | +--------+ | | | data dispatcher | | | | Service| | | +----------------------+ | | | App2 | | | | HTTP | OCP | | | +--------+ | | +------------| |===(2)====| OCP | | | | TCP/IP | | | | +--------+ | | +------------+---------+ | | | +-------||-----------------+ | callout server | || +----------------+ ...........(1) This is a kind of combination of figures 1, 3 and 4. It also emphasizes some questions that remain unclear from the use of different terms in different places: - What is "OPES flow" - (1), (2) of both? Figure 2 suggests (1), Figure 3 suggests (2), Figure 4 suggests (1). Maybe we need several terms to distinguish between different data flows? - What is "OPES processor"? Figures 2 and 4 suggest different interpretations: is this a "processing point" in the data flow that functionally combines both boxes above (as in Figure 2) or just an infusion point, as in Figure 4? I'd suggest former, otherwise we are putting too much emphasis on application execution point, but again we may need more developed terminology. > 2.3 OPES rules. > In this model, all data filters are > invoked for all data. This is very ambiguous. Again, depends on what is a "data filter". If this is an OPES application this just does not look right. If this is a specific rule this makes more sense but looks too restrictive - unambiguous rule resolution may be checked at the compilation time and then there is no need to go though all rules after one of them has fired. At least I'd not include this as an architecture requirement. >2.4 Callout Servers > The OPES ruleset is executed within a data dispatcher, which triggers > the execution of local OPES service applications. How the ruleset is > executed is not the subject of the architecture. ... The word "executed" here is used three times. First and second uses have a different meaning, the meaning of the third one is unclear. I'd suggest "interpreted" for the first use. For the third one - do you mean "implemented"? How does this come along with "the OPES ruleset schema [6] which defines the syntax and semantics of the rules interpreted by a data dispatcher" proposed in Summary? >> Figure 3. Why do we prescribe the use of TCP/IP for OCP in all cases? I agree this may be the most practical way to implement OCP but I would not carve it into the RFC. >2.5 Policy Enforcement > compiled ruleset I'd suggest using the word "combined" - the word "compiled" may be applied to the same ruleset in efficiency considerations (as opposed to direct interpretation), and this may create some ambiguity. >.............. >dispatcher constitutes an enhanced Policy Enforcement Point (PEP), Use of PEP abbreviation may be a little confusing: this document references RFC 3238, which uses this abbreviation in a different sense - performance-enhancing proxies, originating in RFC 3135 (see RFC 3238, p.4). > 2. The Architecture - general composition. The introduction lists three bullets, then we have 2.1, 2.2 and 2.3 explaining each of them in turn, very good documentation practice. But then we have also 2.4, 2.5 and 2.6 - these breaks the composition. I'd suggest moving 2.4 (callout servers) within 2.1 (maybe as 2.1.1) and the rest (2.5 and 2.6) to part 3. >> Ruleset definition. In fact ruleset is defined in several places - 2.3, 2.4 and 2.5, each one adds some more to the definition. It may have sense to combine all of them in complete definition and place it in 2.3. > 3. Security and Privacy Considerations It looks like we are looking at one general scenario: there is a data provider, there is a data consumer and there is an OPES server that just happened to be in between - and now we are prescribing the rules for legitimate coexistence. While this is a valid general scenario I'd suggest to look at two more: - CDN scenario: OPES architecture is used to build a content distribution network and OPES servers in fact constitute an integral part of data provider. In this case such servers have an absolute trust of data provider and the end user has no more right or reason to question/interfere with there functionality than it has now in relation to the architecture of the provider's site web servers farm. - Incoming/outging data filter (company/library/school, etc.). In this case OPES server has an absolute trust of data consumer (which in this case is an entity different from the end user's browser), and as such it may block all attempts of the end user application (be it browser or other) to interfere with OPES functionality and trace changes. Rules of engagement in these three scenarios are very different, and it is very important to include them into the consideration from the very beginning. It was (and still is) one of main problems in web caching world: all protocols are build for the case of "indpendent facilitator" scenario", and when web caches are used as part of web site or CDN people start building the architecture to circumvent protocol limitations. In the web caches case historically these use cases emerged long after protocols were developed, but for OPES these use scenarios should be built into the architecture from the very beginning. I believe this may save us a lot of pain and heated IETF discussions. > 4. Summary. > - the OPES callout protocol (OCP) I think we are in fact talking about family of protocols. OPES may be used with different application protocols and this may require different OCPs. This should be stated explicitly and for each proposed OCP applicability description should be included. Oskar Batuner From owner-ietf-openproxy@mail.imc.org Mon May 20 14:29:47 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27928 for ; Mon, 20 May 2002 14:29:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4KI8O106246 for ietf-openproxy-bks; Mon, 20 May 2002 11:08:24 -0700 (PDT) Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KI8NL06241 for ; Mon, 20 May 2002 11:08:23 -0700 (PDT) Received: from alethea.demon.co.uk ([194.222.10.198]) by anchor-post-36.mail.demon.net with esmtp (Exim 3.35 #1) id 179ra1-000NKf-0a; Mon, 20 May 2002 19:08:22 +0100 Date: Mon, 20 May 2002 18:04:01 +0100 From: Ian Cooper To: OPES Group cc: Graham Klyne , Markus Hofmann Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 Message-ID: <601679.1021917841@localhost> In-Reply-To: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> References: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Monday, May 20, 2002 10:47 +0100 Graham Klyne wrote: > Section 1 > --------- > > The first paragraph mentions customization based on geographical > locality. Taking this as an example, I didn't notice anything later in > the document about the source of information that an OPES processor might > use as the basis for customization services. I think some discussion > might be appropriate; e.g. is any such customization to be based on > information provided by the party with respect of whom the customization > is being performed? Or conversely, If I connect via an ISP in a foreign > country, might I expect to get information customized for that country? > I think such sources of information should at least be clearly identified > in any trace information. Agree with that last part, and I think that first paragraph needs some clarification (or more accurate examples). Geographic location and the prevailing language are related, but linking them as in the example is perhaps a bad idea (which is I think what you're suggesting also Graham). Customisation based on language is more likely to be useful where the requesting system doesn't want the material presented in the prevailing language, surely? "resource availability" doesn't work for me on first parsing since I took the resource to be the requested entity, not the entity on which it was being displayed (but it might only be me that has that problem). > Section 2.0 > ----------- > Do OPES entiries include the provider and consumer? It's not clear to > me. The second bullet here suggests "yes", but elsewhere suggests "no". Agree that it's not clear. My initial reaction would be that by the definition given neither the provider nor consumer are *in* the network (they are at opposite edges of the network). Of course, this is a simplification since the protocol specific output from an OPES intermediary could be a "provider" to things downstream of it :-) > Section 2.1 > ----------- > The distinctive roles of OPES service application and data dispatchers > aren't entirely clear. I would expect what you describe as an "Opes > service application" that sits on the provider-consumer flow to contain > the architectural elements you describe under "data dispatcher". My reading is that the data dispatcher case is an OPES processor that provides the OPES entity by callout/vectoring, while an OPES service application is the system that can do the transformations (either within a single system or on the servicing end of the callout/vectoring system). Seeing Section 2.4 I'm not sure if that's the desired reading or not. A diagram might help here? (On which note, I'm not sure Figure 1 really serves any useful purpose, and appears to force an HTTP over TCP/IP implementation.) > Section 2.2 > ----------- > Where you say "one or more OPES service applications" and "one or more > data dispatchers" I think you mean "zero or more". Later you mention > "zero or more..." Agree. > 2nd para: I found this description rather woolly. Would any significant > meaning be lost if the second sentence of this paragraph were to be > deleted? I don't see any particular need for that second sentence. I'm not particularly keen with the way the 3rd paragraph is worded. One fix it to just not refer to a "data flow" at all. My attempts at re-writing the first paragraph to introduce the term "OPES flow" with respect to being a specific type of data flow seemed to be rather cumbersome. > Section 2.4 > ----------- > Maybe this is just a personal preference, but talking about "executing" a > ruleset seems to be very implementation-choice-oriented; would > "evaluating" not be closer to what you mean here? I'd prefer "evaluating" too. > You also discuss using "the OPES callout protocol", which seems to say > there is a single such protocol. It is not clear to me why there needs > to be a single such protocol, as different dispatcher/server combinations > might use different protocols according to the needs of the application. > For example, I'd imagine a session-oriented protocol appropriate for an > HTTP callout service, but for processing email flows a callout protocol > based on email style messaging, or file sharing, might be more > appropriate. > > Maybe there are reasons for defining a single protocol here: if so, I > think they should be explained. I imagine that the lack of explanation might simply be due to historical reasons. That said, simple re-wording in the text following Figure 3 would allow for multiple OCPs. Unfortunately [7] is referenced (certainly later in the document) in a way that suggests there's one protocol while it actually refers to a requirements document. Speaking of Figure 3, it's not immediately clear what's going on, making the appearance of the data dispatcher box different to the callout servers might help. > The final sentence of the final paragraph is impenetrable to me. What's > this "...service aware vectoring capability that parses the data flow > according to the ruleset..."? > > And a typo in the final para: "detremine". > > > Section 2.6 > ----------- > I think this section is very weak. It manages to impose questionable > implementation decisions without providing any real guidance about how > tracing is to be provided. > > Specifically, it calls for "in-band annotation through header extensions > on the application protocol". I believe that this approach will mean > that the tracing facility is effectively unusable at Internet scale, > because it depends on protocol extensions that will be largely > unimplemented by the end systems who need access to the diagnostic > information. True. This may also limit the number of protocols for which the architecture may be useful, though that might not necessarily be a bad thing. > I recently encountered a real problem that will illustrate my concern > here: my wife works from home as editorial manager for a website. > Recently, she was reviewing website content and was getting old data when > all the other parties involved were getting new data. This occurred with > different browsers, after cache-flushing, etc., so was almost certainly > not a local problem. It most likely was a fault in an intermediate > transparent cache. Now, I think this is exactly the kind of problem that > OPES tracing should be able to diagnose. For this to be useful, I'd say > it must be possible to access the traces without any extensions to the > protocol whose flow is being serviced by OPES. Well... this is a demonstration of why you need that out-of-band access to the audit trail rather than a reliance on headers that are defined in the protocol spec. but are rarely used :-) > The sort of design I might suggest would be that an OPES intermediary > maintains an audit of services that are applied, possibly for a limited > time. This audit should be accessible to affected clients using standard > features of the protocol whose flow is being OPES-serviced. Seems reasonable, though would only work for a subset of the protocols that might benefit from modifications these systems might offer. E.g. if video stream is modified I'm not sure that it would be possible to use the streaming delivery protocol to get acccess to the audit trail. It does work for HTTP which was the primary target of this body of work though. I'm also a little confused as to the apparent urgency to take this document WG (and presumably wider) Last Call when many of the supporting documents appear expired/non-existent in the I-D directory (perhaps it's just the titles that have changed? I thought I had an up-to-date mirror of the directory) making it impossible for the reader to fully understand this document. (I.E. surely this document is just going to sit in RFC-Editor's queue anyway.) From owner-ietf-openproxy@mail.imc.org Mon May 20 15:47:24 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04914 for ; Mon, 20 May 2002 15:47:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4KJOi107992 for ietf-openproxy-bks; Mon, 20 May 2002 12:24:44 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KJOiL07988 for ; Mon, 20 May 2002 12:24:44 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([212.159.36.62]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g4L32I410543; Mon, 20 May 2002 20:02:19 -0700 Message-Id: <5.1.0.14.2.20020520191112.00ab6370@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 20 May 2002 20:18:25 +0100 To: Marshall Rose From: Graham Klyne Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 Cc: ietf-openproxy@imc.org In-Reply-To: <20020520045532.1163d0e7.mrose@dbc.mtview.ca.us> References: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> <3CE70770.7060500@mhof.com> <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: To pursue a few comments... At 04:55 AM 5/20/02 -0700, Marshall Rose wrote: >i'm not sure i agree with your characterizations. the job of an >architectural document is to enumerate components and their >relationships. Actually, I agree with that. And this is what I felt the document didn't adequately address (though, as I said before, it did start out quite well.) Mainly, in this area, I think it needs more work to clarify the components and their interactions, and in particular their role in addressing the security and diagnostic concerns. > > And I think that, as a starting point for other aspects of OPES design, it > > would be appropriate to include a collected glossary in this document. > >my position, in all working groups, has been that putting glossaries >in documents is the signature of poor writing. at best, they're >redundant, at worst, they're contradictory. if the document can't >define terms in context as they are used, then there is a more >fundamental problem in the document... If this document were the end of a process, I might agree. But (I presume) it's laying some groundwork for ongoing cooperative design work, and for that I think some common, easily referenced vocabulary is particularly useful, in a FAQ kind of way. > > Section 2.6 > > ----------- > > I think this section is very weak. It manages to impose questionable > > implementation decisions without providing any real guidance about how > > tracing is to be provided. > >hmmm. again, i think it sets some architectural boundaries, but >doesn't make any implementation choices (questionable or not). > > > > Specifically, it calls for "in-band annotation through header > extensions on > > the application protocol". I believe that this approach will mean that > the > > tracing facility is effectively unusable at Internet scale, because it > > depends on protocol extensions that will be largely unimplemented by the > > end systems who need access to the diagnostic information. > >i think that "Internet scale" means different things. there's also a >counter-balancing set of concerns dealing on the impact on the opes >entities. > >my interpretation, which could be wrong, of the iab concerns, was >that the working group could get away with diagnosis after the >fact. and if you believe that (it's certainly open to discussion), >then i think that the logic of simplicity inevitably takes you to >what the document says now... (albeit with perhaps more simple >wording!) I think diagnosis after-the-fact is fine. > > I recently encountered a real problem that will illustrate my concern > > here: my wife works from home as editorial manager for a > > website. Recently, she was reviewing website content and was getting old > > data when all the other parties involved were getting new data. This > > occurred with different browsers, after cache-flushing, etc., so was > almost > > certainly not a local problem. It most likely was a fault in an > > intermediate transparent cache. Now, I think this is exactly the kind of > > problem that OPES tracing should be able to diagnose. For this to be > > useful, I'd say it must be possible to access the traces without any > > extensions to the protocol whose flow is being serviced by OPES. > >i agree that problems like this should be subject to diagnosis. i >don't think it's > > > > The sort of design I might suggest would be that an OPES intermediary > > maintains an audit of services that are applied, possibly for a limited > > time. This audit should be accessible to affected clients using standard > > features of the protocol whose flow is being OPES-serviced. > >i'm with you right up to the "using standard features of the >protocol" ... because your own argument argues against that. > >maintaining an audit of what's going on is fine (and real systems >will do that regardless of what the architecture document >says). figuring out how to transparently tap into the audit >information is problematic... Well... does it need to be "transparent"? When I wrote my comments, I was thinking that there might be HTTP access to the audit trail (with appropriate authentication) from the client system in whose admin domain the OPES intermediary was operating. That presumes the client knows what URL to use to query the audit, so its not transparent (in the sense of being automatically available), but I think that is information that could easily be made available. (That was assuming an OPES intermediary on an HTTP flow; for (say) an email flow, some variant of the mechanisms suggested by multipart/external might be used. The key issue here is that an end user with standard off-the-shelf client software can access the diagnostic information, without dependence on protocol extensions.) > > Section 3.2 > > ----------- > > This touches on an area where I take issue with the IAB requirements on > > OPES (and have posted my comments elsewhere). > > > > [[ > > The primary data flow occurs between the data provider and the data > > consumer. OPES must not interfere with the capability of these > > parties to use end-to-end authentication and confidentiality. > > ]] > > > > Consider the case of an employee working for a corporation. I is the > > employee or the corporation considered to be the "data provider" or "data > > consumer" here. I particular, is OPES required to allow an employee to > > send encrypted data out of the organization without examination by an > > intermediary system? > > > > In terms of OPES architecture (as I understand it), I think the > employee is > > the end system here, and the corporate network may contain OPES > > intermediaries that prohibit the data flows that OPES is hereby prohibited > > from interfering with. That is how content filtering systems with which I > > am familiar are deployed. I think the requirements need to be refined. > >i agree that one can interpret the IAB concerns as saying that >corporations can not address this security issue using OPES. > >my reading of the document is that the architecture allows OPES to >be realized to address this security issue. > >my understanding of the IESG's perspective on the IAB concerns is >that if a cogent argument is made as to why OPES isn't consistent >with certain aspects of the IAB concerns, then that's okay... Well, yes... I was trying to point out that I thought there was an important case here that the design should allow for, and acknowledging that it wasn't strictly (to my reading) aligned with the IAB requirements. #g ------------------- Graham Klyne From owner-ietf-openproxy@mail.imc.org Mon May 20 15:47:50 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04954 for ; Mon, 20 May 2002 15:47:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4KJPLs08005 for ietf-openproxy-bks; Mon, 20 May 2002 12:25:21 -0700 (PDT) Received: from anchor-post-36.mail.demon.net (anchor-post-36.mail.demon.net [194.217.242.94]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KJPKL08001 for ; Mon, 20 May 2002 12:25:20 -0700 (PDT) Received: from alethea.demon.co.uk ([194.222.10.198]) by anchor-post-36.mail.demon.net with esmtp (Exim 3.35 #1) id 179smV-000AQT-0a; Mon, 20 May 2002 20:25:20 +0100 Date: Mon, 20 May 2002 20:13:06 +0100 From: Ian Cooper To: OPES Group cc: Oskar Batuner , Markus Hofmann Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Message-ID: <929674.1021925586@localhost> In-Reply-To: References: X-Mailer: Mulberry/2.2.1 (Mac OS X) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit --On Monday, May 20, 2002 13:28 -0400 Oskar Batuner wrote: > > Some notes on the OPES Architecture draft.. > >> 1. Introduction > >> In some cases it may be impossible to offer the customization service >> at either the provider or the consumer applications. In this case, >> one or more additional application entities may participate in the >> data stream service. > > This term - "impossible" - may leave an impression that this is the > only, or at least main justification to use OPES. This does not look > right. The only scenario (from existing draft-beck-opes-esfnep) where > OPES is the only way to implement the service is request filtering > for hand-held devices, in all other cases service can be implemented > either at the server side or at the client side, or both. In fairness I think it's fair to say that there are cases where it's impossible to insert localised advertisements without something like an OPES intermediary. > Still use of OPES may be beneficial, so I'd suggest ether to use > a different wording, like: > > "In some cases in may be beneficial to provide a customization service > at network location instead of deploying it at either the provider or > the consumer host. For certain services performed on end-user behalf > this may be the only option of service deployment". That seems limiting and doesn't seem (to me) to convey the aspect that some content can only be produced with the cooperation of (possibly non-exportable) information available to the ISP/IAP. The problem is that without concrete examples (which are frequently limiting in themselves) it becomes very difficult to write introductory text like this. The existing text (plus the introductory paragraph you omitted) seems, to me, a better approach to articulate the problem. >> 2.1 OPES Entities > > The usage of terms "OPES service application" and "data dispatcher" > is not always consistent and sometimes even confusing. According to > the definition in 2.1 service application is invoked by data dispatcher. > If this is always a case (an according to the definition it is so) > Figure 1 should look like this: > > > +----------------+ > | OPES service | > | application | > +----------------+ > |data dispatcher | > +----------------+ > | | > | HTTP | > | | > +----------------+ > | TCP/IP | > +----------------+ > | ... | > +----------------+ > > Figure 1: An OPES protocol stack > > > It also may have sense to point out explicitly that OPES application > may be executed either on the same box (or even in the same application > environment) with the dispatcher or on different box through OCP. > This was on of important features in initially discussed architecture, > there were even terms like "proxylet" flying in the air. Agree > I thing it has sense to emphasize this possibility and to provide a > figure like this: > > > +--------------------------+ > | +----------+ | > | | OPES | | > | | service | | > | | appl | | > | +----------+ | +----------------+ > | || | | | > | +----------------------+ | | +--------+ | > | | data dispatcher | | | | Service| | > | +----------------------+ | | | App2 | | > | | HTTP | OCP | | | +--------+ | > | +------------| |===(2)====| OCP | | > | | TCP/IP | | | | +--------+ | > | +------------+---------+ | | | > +-------||-----------------+ | callout server | > || +----------------+ > ...........(1) > > This is a kind of combination of figures 1, 3 and 4. I like this diagram >> 2.5 Policy Enforcement > >> compiled ruleset > > I'd suggest using the word "combined" - the word "compiled" may be > applied to the same ruleset in efficiency considerations (as opposed > to direct interpretation), and this may create some ambiguity. > >> .............. >> dispatcher constitutes an enhanced Policy Enforcement Point (PEP), > > Use of PEP abbreviation may be a little confusing: this document > references RFC 3238, which uses this abbreviation in a different > sense - performance-enhancing proxies, originating in RFC 3135 > (see RFC 3238, p.4). Thanks for bringing that one up; I'd had similar thoughts on the source of potential confusion. >> 3. Security and Privacy Considerations > > It looks like we are looking at one general scenario: there is a data > provider, there is a data consumer and there is an OPES server that > just happened to be in between - and now we are prescribing the > rules for legitimate coexistence. > While this is a valid general scenario I'd suggest to look at > two more: > > - CDN scenario: OPES architecture is used to build a content > distribution network and OPES servers in fact constitute an > integral part of data provider. In this case such servers have > an absolute trust of data provider and the end user has no more > right or reason to question/interfere with there functionality > than it has now in relation to the architecture of the > provider's site web servers farm. Agree, though I'm not sure I see anything that suggests otherwise. (Apologies if I'm missing something in my jetlag induced haze.) From owner-ietf-openproxy@mail.imc.org Mon May 20 17:45:45 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14422 for ; Mon, 20 May 2002 17:45:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4KLOIP12627 for ietf-openproxy-bks; Mon, 20 May 2002 14:24:18 -0700 (PDT) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KLOGL12623 for ; Mon, 20 May 2002 14:24:16 -0700 (PDT) Received: from kalia (dhcpd253.dbc.mtview.ca.us [64.168.10.253]) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g4KL3Id22014; Mon, 20 May 2002 14:03:18 -0700 (PDT) Date: Mon, 20 May 2002 14:23:50 -0700 From: Marshall Rose To: "Graham Klyne" Cc: ietf-openproxy@imc.org Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 Message-Id: <20020520142350.68e24f61.mrose@dbc.mtview.ca.us> In-Reply-To: <5.1.0.14.2.20020520191112.00ab6370@joy.songbird.com> References: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> <3CE70770.7060500@mhof.com> <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> <5.1.0.14.2.20020520191112.00ab6370@joy.songbird.com> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > > And I think that, as a starting point for other aspects of OPES design, it > > > would be appropriate to include a collected glossary in this document. > > > >my position, in all working groups, has been that putting glossaries > >in documents is the signature of poor writing. at best, they're > >redundant, at worst, they're contradictory. if the document can't > >define terms in context as they are used, then there is a more > >fundamental problem in the document... > > If this document were the end of a process, I might agree. But (I presume) > it's laying some groundwork for ongoing cooperative design work, and for > that I think some common, easily referenced vocabulary is particularly > useful, in a FAQ kind of way. all your comments were useful, but i'm going to focus on this one and let others in the design team focus on the rest. we're not starting in a vacuum. part of the problem with the opes specification documents is that they are too long, verbose, etc., etc. the only way to get agreement is to continually simplify and refine until either: a) there's concensus on what's there, or b) what's there isn't worth doing. either is an acceptable outcome to me. what isn't acceptable is spending a year on bofs producing documents that very few folks can understand. so, the current architecture document tries to avoid the problematic nature of the previous set of pre-working group contributions by simply focusing on the basics. as a part of that, some niceties, e.g., glossaries get lost. i can live with that, because i'd rather not spend time having folks argue about definitions and spend yet another year making no forward progress... others' mileage may vary, obviously. /mtr From owner-ietf-openproxy@mail.imc.org Mon May 20 17:56:03 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15053 for ; Mon, 20 May 2002 17:56:03 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4KLWdC12965 for ietf-openproxy-bks; Mon, 20 May 2002 14:32:39 -0700 (PDT) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KLWcL12961 for ; Mon, 20 May 2002 14:32:38 -0700 (PDT) Received: from kalia (dhcpd253.dbc.mtview.ca.us [64.168.10.253]) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g4KLBQd22055; Mon, 20 May 2002 14:11:26 -0700 (PDT) Date: Mon, 20 May 2002 14:31:55 -0700 From: Marshall Rose To: "Ian Cooper" Cc: ietf-openproxy@imc.org, GK-lists@ninebynine.org, markus@mhof.com Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 Message-Id: <20020520143155.09db55e9.mrose@dbc.mtview.ca.us> In-Reply-To: <601679.1021917841@localhost> References: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> <601679.1021917841@localhost> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit ian - let me respond to your last comment: > I'm also a little confused as to the apparent urgency to take this document > WG (and presumably wider) Last Call when many of the supporting documents > appear expired/non-existent in the I-D directory (perhaps it's just the > titles that have changed? I thought I had an up-to-date mirror of the > directory) making it impossible for the reader to fully understand this > document. (I.E. surely this document is just going to sit in RFC-Editor's > queue anyway.) the document was published two weeks before the last call and there were ZERO comments on the list. maybe everyone's on vacation, or everyone thinks its perfect, or everyone has stopped caring. maybe all three. the only way to test that assertion is to do a working group last call and see what happens... based on your note and graham's note and oskar's note, the last call message had the desired effect. now, we need to see what others think and whether the discussion leads to a concensus on the existing document or what needs to go into the next revision... /mtr From owner-ietf-openproxy@mail.imc.org Mon May 20 18:05:31 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15805 for ; Mon, 20 May 2002 18:05:31 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4KLjR913301 for ietf-openproxy-bks; Mon, 20 May 2002 14:45:27 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KLjRL13297 for ; Mon, 20 May 2002 14:45:27 -0700 (PDT) Received: from oskar3 ([65.96.167.167]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020520214524.BJHJ18801.rwcrmhc52.attbi.com@oskar3>; Mon, 20 May 2002 21:45:24 +0000 From: "Oskar Batuner" To: "Markus Hofmann" , "OPES Group" Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Mon, 20 May 2002 17:45:24 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <3CE70770.7060500@mhof.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Two typos: Chapter 3.1: line 3: > Stepwise means A delegates to B and B delegates to C and so force. should be "so forth". line 8: data "provider" color. The only colors that are defined are data the "provider" and the data "consumer". Should be: data "provider" color. The only colors that are defined are the data "provider" and the data "consumer". - Oskar From owner-ietf-openproxy@mail.imc.org Tue May 21 01:21:49 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09659 for ; Tue, 21 May 2002 01:21:49 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4L4sR524887 for ietf-openproxy-bks; Mon, 20 May 2002 21:54:27 -0700 (PDT) Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4L4sPL24880 for ; Mon, 20 May 2002 21:54:26 -0700 (PDT) Received: from bigmail.research.att.com (bigmail.research.att.com [135.207.30.101]) by mail-blue.research.att.com (Postfix) with ESMTP id 25B4A4CE35; Tue, 21 May 2002 00:54:30 -0400 (EDT) Received: from research.att.com ([135.210.96.90]) by bigmail.research.att.com (8.8.8/8.8.8) with ESMTP id AAA21463; Tue, 21 May 2002 00:54:29 -0400 (EDT) Message-ID: <3CE9D3EB.F79F64D5@research.att.com> Date: Tue, 21 May 2002 00:58:19 -0400 From: Robin Chen Organization: AT&T Labs - Research X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Ian Cooper , Oskar Batuner Cc: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-architecture-00: CDN scenario References: <929674.1021925586@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Ian and Oskar, Some comments on the CDN scenario: > > 3. Security and Privacy Considerations > > > > It looks like we are looking at one general scenario: there is a data > > provider, there is a data consumer and there is an OPES server that > > just happened to be in between - and now we are prescribing the > > rules for legitimate coexistence. > > While this is a valid general scenario I'd suggest to look at > > two more: > > > > - CDN scenario: OPES architecture is used to build a content > > distribution network and OPES servers in fact constitute an > > integral part of data provider. In this case such servers have > > an absolute trust of data provider and the end user has no more > > right or reason to question/interfere with there functionality > > than it has now in relation to the architecture of the > > provider's site web servers farm. > > Agree, though I'm not sure I see anything that suggests otherwise. > (Apologies if I'm missing something in my jetlag induced haze.) The architecture document does not exclude the CDN scenario - check out Section 3.1 (Trust Domains) that talks about delegation of authority. The CDN scenario is also covered by the "Surrogate Overlay" section in the original OPES model draft: http://www.ietf.org/internet-drafts/draft-tomlinson-opes-model-01.txt > 4.4 Surrogate Overlays > > A surrogate overlay is a specific type of 'content service > network', which is delegated the authority to provide 'content > services' on behalf of, and typically in close co-operation with, > one or more 'origin servers'. Surrogate overlays can be seen as > logical extension of 'origin servers'. > Note also that the term "authroritative domain" (instead of trust domain) was used in the original model draft. An upcoming OPES scenario document will cover the scenarios of surrogate overlay (server-centric), delegate overlay (client-centric), and the enterprise scenario (data providers, data consumers, and all OPES entities are in the same trust domain) - stay tuned ... -- Robin Chen AT&T Labs - Research chen@research.att.com -------------------------------------------------------------- Room E219, 180 Park Avenue, Florham Park, NJ 07932-0971 phone:(973)-360-8653 http://www.research.att.com/info/chen From owner-ietf-openproxy@mail.imc.org Tue May 21 01:23:12 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09718 for ; Tue, 21 May 2002 01:23:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4L504h25004 for ietf-openproxy-bks; Mon, 20 May 2002 22:00:04 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4L503L25000 for ; Mon, 20 May 2002 22:00:03 -0700 (PDT) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout02.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.6 (built Apr 26 2002)) with ESMTP id <0GWG006DF381OR@mtaout02.icomcast.net> for ietf-openproxy@imc.org; Tue, 21 May 2002 01:00:01 -0400 (EDT) Date: Tue, 21 May 2002 01:00:01 -0400 From: Markus Hofmann Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 To: Graham Klyne Cc: OPES Group Message-id: <3CE9D451.8000706@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 References: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Graham, > There's nothing like a last-call to raise a reviewer's priorities, > right?-) It can even overcome dead silence... :) Thanks for your feedback and for breaking the ice. While trying to catch up with emails, let me pursue some of your comments... I would expect some of the ID authors to jump in as well. > Section 1 --------- > > The first paragraph mentions customization based on geographical > locality. Taking this as an example, I didn't notice anything > later in the document about the source of information that an OPES > processor might use as the basis for customization services. I > think some discussion might be appropriate; e.g. is any such > customization to be based on information provided by the party with > respect of whom the customization is being performed? Or > conversely, If I connect via an ISP in a foreign country, might I > expect to get information customized for that country? I think > such sources of information should at least be clearly identified > in any trace information. Should this kind of service-specific information (e.g. the source of customization information) really be part of the general OPES trace information? Wouldn't it be sufficient for OPES to provide trace information that identifies the performed OPES service, and provide a pointer from where an interested endpoint could obtain more detailed information (e.g. the source of customization information for that specific service)? This would be more flexible and scale better, since it seems challenging for general OPES traces to provide all possible aplication-specific trace information. OPES could just supply a "trace pointer" that would allow the endpoints to obtain the more (application-specific) information if desired. > Section 2.0 ----------- Do OPES entiries include the provider and > consumer? It's not clear to me. The second bullet here suggests > "yes", but elsewhere suggests "no". From an OPES perspective, I would assume "no", so we need some re-wording here. Maybe something like "OPES flows: data flows that are cooperatively realized by a data provider, a data consumer, and zero or more OPES entities." This would also need some re-wording in the last paragraph of section 2.1, maybe something like "The OPES architecture is largely independent of the protocol that is used by the DATA CONSUMER AND THE DATA PROVIDER to exchange data." > Section 2.1 ----------- The distinctive roles of OPES service > application and data dispatchers aren't entirely clear. I would > expect what you describe as an "Opes service application" that sits > on the provider-consumer flow to contain the architectural elements > you describe under "data dispatcher". The "data dispatcher" is meant to be sort of a filter that determines which messages have to passed on to which "OPES service application(s)". The "data dispatcher" always sits on a data processor box, while an "OPES service application" can reside on either a data processor box or a callout server. Messages always pass through a "data dispatcher" before possibly being hand over to an "OPES service application", which can reside locally on the same data processor box as the "data dispatcher", or remotely on a separate "callout server". Not sure whether the above might help, but I agree that we need some cleanup here. > Section 2.2 ----------- Where you say "one or more OPES service > applications" and "one or more data dispatchers" I think you mean > "zero or more". Later you mention "zero or more..." Yup, also one might say that if there are zero OPES service applications and zero data dispatchers, this is just a regular data flow, no OPES at all. Maybe it should read "one or more data dispatchers" and "zero or more OPES service applications", since an OPES system is charaterized through the existence of a data dispatcher (i.e. all messages go through this data dispatcher), but it is not necessary that an OPES service appliation always gets executed. > 2nd para: I found this description rather woolly. Would any > significant meaning be lost if the second sentence of this > paragraph were to be deleted? I'd assume no, although one interesting aspect might be that data processors and callout servers can reside in different admin domains... > Section 2.3 ----------- It seems to me that the OPES rules are a > cornerstone of the architecture, but very little is said about > them. For the architecture we just need to describe their existence and where/how they fit in, but not their (internal) details. > Section 2.4 ----------- Maybe this is just a personal preference, > but talking about "executing" a ruleset seems to be very > implementation-choice-oriented; would "evaluating" not be closer > to what you mean here? Agreed. > You also discuss using "the OPES callout protocol", which seems to > say there is a single such protocol. It is not clear to me why > there needs to be a single such protocol, as different > dispatcher/server combinations might use different protocols > according to the needs of the application. For example, I'd > imagine a session-oriented protocol appropriate for an HTTP callout > service, but for processing email flows a callout protocol based on > email style messaging, or file sharing, might be more appropriate. The goal is to have a single callout protocol independent from the protocol being used in the data flow. Whether this is possible or not, we'll see. Also, our current charter is restricted to HTTP and RTP/RTSP in the data flow. > Maybe there are reasons for defining a single protocol here: if > so, I think they should be explained. Yes, agreed, but this should be the outcome of some discussion in the WG. > The final sentence of the final paragraph is impenetrable to me. > What's this "...service aware vectoring capability that parses the > data flow according to the ruleset..."? Yup, wording is somehow confusing. I believe it means to say that although the OCP itelf is application agnostic, the data dispatcher must very well be aware of the syntax and the sematics of the data flow protocol (see previous discussion on this list on "no-transform & warning"). > The sort of design I might suggest would be that an OPES > intermediary maintains an audit of services that are applied, > possibly for a limited time. This audit should be accessible to > affected clients using standard features of the protocol whose flow > is being OPES-serviced. Would you say that the current draft rules out such a design? I could imagine that the general OPES tracing simply provides pointers and information to the endpoints on (a) which OPES services had been executed on the message, and (b) how the endpoints could retrieve more information about these services, possibly including an audit. I don't see the current draft would exclude something like that. > Section 3.2 ----------- This touches on an area where I take issue > with the IAB requirements on OPES (and have posted my comments > elsewhere). > > [[ The primary data flow occurs between the data provider and the > data consumer. OPES must not interfere with the capability of > these parties to use end-to-end authentication and confidentiality. > ]] > > Consider the case of an employee working for a corporation. I is > the employee or the corporation considered to be the "data > provider" or "data consumer" here. I particular, is OPES required > to allow an employee to send encrypted data out of the organization > without examination by an intermediary system? Hm, one view expressed earlier is that the employee is the enduser and the corporation runs the OPES system. Per employment agreement, the enduser gives the corporation (i.e. the OPES provider) the right to filter the data, i.e. the employee allows the corporation to install the corresponding OPES rules. That might be controversial, but one possible view. An alternative would be to rule out the possibility to use OPES for these kinds of services... -Markus From owner-ietf-openproxy@mail.imc.org Tue May 21 01:44:59 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA10784 for ; Tue, 21 May 2002 01:44:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4L5OOM25930 for ietf-openproxy-bks; Mon, 20 May 2002 22:24:24 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4L5ONL25925 for ; Mon, 20 May 2002 22:24:23 -0700 (PDT) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with ESMTP id <0GWG00H324CMX9@mtaout01.icomcast.net> for ietf-openproxy@imc.org; Tue, 21 May 2002 01:24:22 -0400 (EDT) Date: Tue, 21 May 2002 01:24:22 -0400 From: Markus Hofmann Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 To: Ian Cooper Cc: OPES Group Message-id: <3CE9DA06.4000004@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 References: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> <601679.1021917841@localhost> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Ian Cooper wrote: > Speaking of Figure 3, it's not immediately clear what's going on, making > the appearance of the data dispatcher box different to the callout > servers might help. Hm, when looking at Figure 3 i nthe draft... I would assume the term "callout server" refers to the box itself, thus being the correspondence to "data processor", rather than being part of the protocol stack as shown in Figure 3. It seems to me that something like that would be more accurate. data callout callout callout processor server server server +----------+ +---------+ +---------+ +---------+ | data | | service | | servive | | service | |dispatcher| | applic. | | applic. | | applic. | +----------+ +---------+ +---------+ +---------+ | | | | | | | | | OCP | | OCP | | OCP | ... | OCP | | | | | | | | | +----------+ +---------+ +---------+ +---------+ | TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP | +----------+ +---------+ +---------+ +---------+ || || || || ||================ || ... || || || || ||============================== || || || ================================================ >> The sort of design I might suggest would be that an OPES intermediary >> maintains an audit of services that are applied, possibly for a limited >> time. This audit should be accessible to affected clients using standard >> features of the protocol whose flow is being OPES-serviced. > > > Seems reasonable, though would only work for a subset of the protocols > that might benefit from modifications these systems might offer. E.g. > if video stream is modified I'm not sure that it would be possible to > use the streaming delivery protocol to get acccess to the audit trail. > It does work for HTTP which was the primary target of this body of work > though. Why restrict it to the standard features of the data flow protocol? I would assume it's possible to indicate within the OPES trace HOW an endpoint could access such audits, potentially allowing/using other standard protocols (e.g. HTTP, FTP, or whatever). Architectural wise, this should be covered by the current draft... > I'm also a little confused as to the apparent urgency to take this > document WG (and presumably wider) Last Call when many of the supporting > documents appear expired/non-existent in the I-D directory (perhaps it's > just the titles that have changed? I thought I had an up-to-date mirror > of the directory) making it impossible for the reader to fully > understand this document. (I.E. surely this document is just going to > sit in RFC-Editor's queue anyway.) Marshall already responded on that one, and I fully second his comments. -Markus From owner-ietf-openproxy@mail.imc.org Tue May 21 01:56:24 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA11307 for ; Tue, 21 May 2002 01:56:23 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4L5aFE26191 for ietf-openproxy-bks; Mon, 20 May 2002 22:36:15 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4L5aDL26187 for ; Mon, 20 May 2002 22:36:13 -0700 (PDT) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with ESMTP id <0GWG00I4Q4WD4G@mtaout01.icomcast.net> for ietf-openproxy@imc.org; Tue, 21 May 2002 01:36:13 -0400 (EDT) Date: Tue, 21 May 2002 01:36:13 -0400 From: Markus Hofmann Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 To: Graham Klyne Cc: ietf-openproxy@imc.org Message-id: <3CE9DCCD.5020909@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 References: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> <3CE70770.7060500@mhof.com> <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> <5.1.0.14.2.20020520191112.00ab6370@joy.songbird.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Graham, > When I wrote my comments, I was thinking that there might be HTTP access > to the audit trail (with appropriate authentication) from the client > system in whose admin domain the OPES intermediary was operating. That > presumes the client knows what URL to use to query the audit, so its not > transparent (in the sense of being automatically available), but I think > that is information that could easily be made available. I agree, and it seems to me that Section 2.6 is basically refering to someting like that when stating "...One of those annotations could be a URL with more detailed information on the transformation that occurred to the data on the OPES flow." -Markus From owner-ietf-openproxy@mail.imc.org Tue May 21 07:04:23 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA04203 for ; Tue, 21 May 2002 07:04:22 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LAWqk05272 for ietf-openproxy-bks; Tue, 21 May 2002 03:32:52 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LAWpL05266 for ; Tue, 21 May 2002 03:32:51 -0700 (PDT) Received: from GK-VAIO.ninebynine.org (dyn160-41.sftm-212-159.plus.net [212.159.41.160]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g4LIAN411911; Tue, 21 May 2002 11:10:24 -0700 Message-Id: <5.1.0.14.2.20020521112056.03d657b0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 May 2002 11:37:23 +0100 To: Markus Hofmann From: Graham Klyne Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 Cc: OPES Group In-Reply-To: <3CE9D451.8000706@mhof.com> References: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 01:00 AM 5/21/02 -0400, Markus Hofmann wrote: >Wouldn't it be sufficient for OPES to provide trace information that >identifies the performed OPES service, and provide a pointer from where an >interested endpoint could obtain more detailed information (e.g. the >source of customization information for that specific service)? Yes, that works for me. > > Section 2.3 ----------- It seems to me that the OPES rules are a > > cornerstone of the architecture, but very little is said about > > them. > >For the architecture we just need to describe their existence and >where/how they fit in, but not their (internal) details. I agree, not their internal details. But some kind of indication of the scope of possible "conditions" and "related actions" would be useful; e.g. for the conditions, presumably there are expected to be mechanisms for testing the protocol parameters and data content? And if examining data content, what sort of level of analysis is expected to be supported? I guess this boils down to identifying some (broad) requirements on the standardized rule schema. At least to the extent of giving some understanding of how much is expected to be handled by the filtering rules, and how much is left to a callout processor. > > You also discuss using "the OPES callout protocol", which seems to > > say there is a single such protocol. It is not clear to me why > > there needs to be a single such protocol, as different > > dispatcher/server combinations might use different protocols > > according to the needs of the application. For example, I'd > > imagine a session-oriented protocol appropriate for an HTTP callout > > service, but for processing email flows a callout protocol based on > > email style messaging, or file sharing, might be more appropriate. > >The goal is to have a single callout protocol independent from the >protocol being used in the data flow. Whether this is possible or not, >we'll see. Also, our current charter is restricted to HTTP and RTP/RTSP in >the data flow. I thought about this a little more - is it a goal to have multi-vendor interoperability between data dispatchers and callout servers? If so, the role of OCP is clearer. > > The sort of design I might suggest would be that an OPES > > intermediary maintains an audit of services that are applied, > > possibly for a limited time. This audit should be accessible to > > affected clients using standard features of the protocol whose flow > > is being OPES-serviced. > >Would you say that the current draft rules out such a design? My my reading, yes, since it seems to depend on protocol extensions. > I could imagine that the general OPES tracing simply provides pointers > and information to the endpoints on (a) which OPES services had been > executed on the message, and (b) how the endpoints could retrieve more > information about these services, possibly including an audit. I don't > see the current draft would exclude something like that. As far as it goes, that's fine. So why are protocol extension headers needed? (See also my response to Marshall's comment about transparency.) [later] Yes, I see you responded too. Maybe I misread the intent here. The sentence that disturbs me is this: [[ The OPES architecture **requires** that tracing be feasible on the OPES flow per OPES processor **using in-band annotation** through header **extensions** on the application protocol that is used (e.g., HTTP). ]] I think the requirement here should be that tracing is feasible *without* using extensions on the application protocol. (Not saying that extensions MAY NOT be used, just not required to get at tracing information.) > > Section 3.2 ----------- This touches on an area where I take issue > > with the IAB requirements on OPES (and have posted my comments > > elsewhere). > > > > [[ The primary data flow occurs between the data provider and the > > data consumer. OPES must not interfere with the capability of > > these parties to use end-to-end authentication and confidentiality. > > ]] > > > > Consider the case of an employee working for a corporation. I is > > the employee or the corporation considered to be the "data > > provider" or "data consumer" here. I particular, is OPES required > > to allow an employee to send encrypted data out of the organization > > without examination by an intermediary system? > >Hm, one view expressed earlier is that the employee is the enduser and the >corporation runs the OPES system. Per employment agreement, the enduser >gives the corporation (i.e. the OPES provider) the right to filter the >data, i.e. the employee allows the corporation to install the >corresponding OPES rules. That might be controversial, but one possible >view. An alternative would be to rule out the possibility to use OPES for >these kinds of services... The first scenario you describe is consistent with my experience of the actual deployment of such software. I think it would be very unfortunate if OPES couldn't handle this common case. However, my reading of the IAB requirements didn't allow for that, so I'm thinking that it at least needs to be drawn out more clearly. #g ------------------- Graham Klyne From owner-ietf-openproxy@mail.imc.org Tue May 21 11:17:47 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14371 for ; Tue, 21 May 2002 11:17:45 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LEtoK22713 for ietf-openproxy-bks; Tue, 21 May 2002 07:55:50 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LEtmL22707 for ; Tue, 21 May 2002 07:55:49 -0700 (PDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LEulUL023280; Tue, 21 May 2002 10:56:47 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LEthk21433; Tue, 21 May 2002 10:55:43 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA25584; Tue, 21 May 2002 10:55:43 -0400 (EDT) Message-ID: <3CEA5FEE.7060209@mhof.com> Date: Tue, 21 May 2002 10:55:42 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Klyne CC: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 References: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> <5.1.0.14.2.20020521112056.03d657b0@joy.songbird.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Klyne wrote: > I guess this boils down to identifying some (broad) requirements on the > standardized rule schema. At least to the extent of giving some > understanding of how much is expected to be handled by the filtering > rules, and how much is left to a callout processor. I agree, but I thought this would rather be part of the "endpoint authorization and enforcement requirements" document (which is also on our charter) rather than the architecture document. > I thought about this a little more - is it a goal to have multi-vendor > interoperability between data dispatchers and callout servers? If so, > the role of OCP is clearer. Absolutely, yes. Maybe this should be stated. >> I could imagine that the general OPES tracing simply provides >> pointers and information to the endpoints on (a) which OPES services >> had been executed on the message, and (b) how the endpoints could >> retrieve more information about these services, possibly including an >> audit. I don't see the current draft would exclude something like that. > > As far as it goes, that's fine. So why are protocol extension headers > needed? We somehow need to get these (tracing) pointers to the enduser - and one way of doing this is in-band. > I think the requirement here should be that tracing is feasible > *without* using extensions on the application protocol. (Not saying > that extensions MAY NOT be used, just not required to get at tracing > information.) If there's no extensions/addition at all, how would we get the trace pointers to the enduser, so that the enduser can retrieve the more detailed information fro mthe OPES boxes? > The first scenario you describe is consistent with my experience of the > actual deployment of such software. I think it would be very > unfortunate if OPES couldn't handle this common case. However, my > reading of the IAB requirements didn't allow for that, so I'm thinking > that it at least needs to be drawn out more clearly. Point taken. We need to see what the concensus of the WG is and than make a clear case for it. -Markus From owner-ietf-openproxy@mail.imc.org Tue May 21 14:10:30 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22782 for ; Tue, 21 May 2002 14:10:29 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LHmuq00608 for ietf-openproxy-bks; Tue, 21 May 2002 10:48:56 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LHmtL00604 for ; Tue, 21 May 2002 10:48:55 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LHmjY26453; Tue, 21 May 2002 13:48:46 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 13:48:49 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754023F677A@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Oskar Batuner , Markus Hofmann , OPES Group Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Tue, 21 May 2002 13:48:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C200EF.C79B8B9E" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C200EF.C79B8B9E Content-Type: text/plain; charset="iso-8859-1" noted, abbie > -----Original Message----- > From: Oskar Batuner [mailto:batuner@attbi.com] > Sent: Monday, May 20, 2002 5:45 PM > To: Markus Hofmann; OPES Group > Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 > > > > Two typos: > > Chapter 3.1: > > line 3: > > Stepwise means A delegates to B and B delegates to C and so force. > > should be "so forth". > > line 8: > data "provider" color. The only colors that are defined > are data the > "provider" and the data "consumer". > > Should be: > data "provider" color. The only colors that are defined > are the data > "provider" and the data "consumer". > > - Oskar > ------_=_NextPart_001_01C200EF.C79B8B9E Content-Type: text/html; charset="iso-8859-1" RE: WG Last Call: draft-ietf-opes-architecture-00

noted,

abbie

> -----Original Message-----
> From: Oskar Batuner [mailto:batuner@attbi.com]
> Sent: Monday, May 20, 2002 5:45 PM
> To: Markus Hofmann; OPES Group
> Subject: RE: WG Last Call: draft-ietf-opes-architecture-00
>
>
>
> Two typos:
>
> Chapter 3.1:
>
> line 3:
> >  Stepwise means A delegates to B and B delegates to C and so force.
>
> should be "so forth".
>
> line 8:
>    data "provider" color.  The only colors that are defined
> are data the
>    "provider" and the data "consumer".
>
> Should be:
>    data "provider" color.  The only colors that are defined
> are the data
>    "provider" and the data "consumer".
>
> - Oskar
>

------_=_NextPart_001_01C200EF.C79B8B9E-- From owner-ietf-openproxy@mail.imc.org Tue May 21 14:10:41 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22798 for ; Tue, 21 May 2002 14:10:40 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LHnPu00698 for ietf-openproxy-bks; Tue, 21 May 2002 10:49:25 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LHnPL00694 for ; Tue, 21 May 2002 10:49:25 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LHmcV11154; Tue, 21 May 2002 13:48:38 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 13:48:40 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754023F6779@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Graham Klyne , Markus Hofmann Cc: OPES Group Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Tue, 21 May 2002 13:48:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C200EF.BE017328" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C200EF.BE017328 Content-Type: text/plain; charset="iso-8859-1" thanks for the responces, see remarks inline abbie > -----Original Message----- > From: Graham Klyne [mailto:GK-lists@ninebynine.org] > Sent: Tuesday, May 21, 2002 6:37 AM > To: Markus Hofmann > Cc: OPES Group > Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 > SNIP > > > Section 2.3 ----------- It seems to me that the OPES rules are a > > > cornerstone of the architecture, but very little is said about > > > them. > > > >For the architecture we just need to describe their existence and > >where/how they fit in, but not their (internal) details. > > I agree, not their internal details. > > But some kind of indication of the scope of possible "conditions" and > "related actions" would be useful; e.g. for the conditions, > presumably > there are expected to be mechanisms for testing the protocol > parameters and > data content? And if examining data content, what sort of level of > analysis is expected to be supported? > > I guess this boils down to identifying some (broad) > requirements on the > standardized rule schema. At least to the extent of giving some > understanding of how much is expected to be handled by the > filtering rules, > and how much is left to a callout processor. > The purpose of the architecture document is just to mention the rules. The details need not be part of it. If there is enough interest, the need for an example document may arise, and then some examples of the rules may be presented. Here keep in mind, the architecture documnet needed to be focused and to the point. SNIP > >The goal is to have a single callout protocol independent from the > >protocol being used in the data flow. Whether this is > possible or not, > >we'll see. Also, our current charter is restricted to HTTP > and RTP/RTSP in > >the data flow. > yes, the goal is to have a single OCP that is seperate from the one that is used in the data flow. > I thought about this a little more - is it a goal to have > multi-vendor > interoperability between data dispatchers and callout > servers? If so, the > role of OCP is clearer. > > > > The sort of design I might suggest would be that an OPES > > > intermediary maintains an audit of services that are applied, > > > possibly for a limited time. This audit should be accessible to > > > affected clients using standard features of the protocol > whose flow > > > is being OPES-serviced. > > > >Would you say that the current draft rules out such a design? > > My my reading, yes, since it seems to depend on protocol extensions. agreed. SNIP > > Yes, I see you responded too. Maybe I misread the intent here. > The sentence that disturbs me is this: > [[ > The OPES architecture **requires** that tracing be feasible > on the OPES flow per OPES processor **using in-band > annotation** through > header **extensions** on the application protocol that is used (e.g., > HTTP). > ]] > > I think the requirement here should be that tracing is > feasible *without* > using extensions on the application protocol. (Not saying > that extensions > MAY NOT be used, just not required to get at tracing information.) > The problem here is that tracing can be in-band or out of band. in band will require header extensions. Out of band will not, but the question will be where and by whom it is supported. The IAB requires the architeture to provide tracing. SNIP abbie ------_=_NextPart_001_01C200EF.BE017328 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG Last Call: draft-ietf-opes-architecture-00

thanks for the responces,

see remarks inline

abbie


> -----Original Message-----
> From: Graham Klyne [mailto:GK-lists@ninebynine.org]
> Sent: Tuesday, May 21, 2002 6:37 AM
> To: Markus Hofmann
> Cc: OPES Group
> Subject: Re: WG Last Call: = draft-ietf-opes-architecture-00
>
SNIP

> > > Section 2.3 ----------- It seems to me = that the OPES rules are a
> > > cornerstone of the architecture, but = very little is said about
> > > them.
> >
> >For the architecture we just need to = describe their existence and
> >where/how they fit in, but not their = (internal) details.
>
> I agree, not their internal details.
>
> But some kind of indication of the scope of = possible "conditions" and
> "related actions" would be = useful;  e.g. for the conditions,
> presumably
> there are expected to be mechanisms for testing = the protocol
> parameters and
> data content?  And if examining data = content, what sort of level of
> analysis is expected to be supported?
>
> I guess this boils down to identifying some = (broad)
> requirements on the
> standardized rule schema.  At least to the = extent of giving some
> understanding of how much is expected to be = handled by the
> filtering rules,
> and how much is left to a callout = processor.
>

The purpose of the architecture document is just to = mention the rules. The details need not be part of it. If there is = enough interest, the need for an example document may arise, and then = some examples of the rules may be presented. Here keep in mind, the = architecture documnet needed to be focused and to the point.


SNIP

> >The goal is to have a single callout = protocol independent from the
> >protocol being used in the data flow. = Whether this is
> possible or not,
> >we'll see. Also, our current charter is = restricted to HTTP
> and RTP/RTSP in
> >the data flow.
>

yes, the goal is to have a single OCP that is = seperate from the one that is used in the data flow.


> I thought about this a little more - is it a = goal to have
> multi-vendor
> interoperability between data dispatchers and = callout
> servers?  If so, the
> role of OCP is clearer.
>
> > > The sort of design I might suggest = would be that an OPES
> > > intermediary maintains an audit of = services that are applied,
> > > possibly for a limited time.  = This audit should be accessible to
> > > affected clients using standard = features of the protocol
> whose flow
> > > is being OPES-serviced.
> >
> >Would you say that the current draft rules = out such a design?
>
> My my reading, yes, since it seems to depend on = protocol extensions.


agreed.

SNIP

>
> Yes, I see you responded too.  Maybe I = misread the intent here.
> The sentence that disturbs me is this:
> [[
> The OPES architecture **requires** that tracing = be feasible
> on the OPES flow per OPES processor = **using  in-band
> annotation** through
> header **extensions** on the application = protocol that is used (e.g.,
> HTTP).
> ]]
>
> I think the requirement here should be that = tracing is
> feasible *without*
> using extensions on the application = protocol.  (Not saying
> that extensions
> MAY NOT be used, just not required to get at = tracing information.)
>

The problem here is that tracing can be in-band or = out of band.
in band will require header extensions. Out of band = will not, but the question will be where and by whom it is = supported.

The IAB requires the architeture to provide = tracing.


SNIP


abbie
 

------_=_NextPart_001_01C200EF.BE017328-- From owner-ietf-openproxy@mail.imc.org Tue May 21 14:24:35 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23213 for ; Tue, 21 May 2002 14:24:35 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LI4OZ01208 for ietf-openproxy-bks; Tue, 21 May 2002 11:04:24 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LI4NL01203 for ; Tue, 21 May 2002 11:04:23 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LI3id13006; Tue, 21 May 2002 14:03:44 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 14:03:46 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754023F67CD@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Graham Klyne , Markus Hofmann Cc: OPES Group , Allison Mankin , Ned Freed Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Tue, 21 May 2002 14:03:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C200F1.DCD155A0" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C200F1.DCD155A0 Content-Type: text/plain; charset="iso-8859-1" see remarks inline abbie > -----Original Message----- > From: Graham Klyne [mailto:GK-lists@ninebynine.org] > Sent: Monday, May 20, 2002 5:47 AM > To: Markus Hofmann > Cc: OPES Group; Allison Mankin; Ned Freed > Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 > > SNIP > Section 1 > --------- > > The first paragraph mentions customization based on geographical > locality. Taking this as an example, I didn't notice > anything later in the > document about the source of information that an OPES > processor might use > as the basis for customization services. I think some > discussion might be > appropriate; e.g. is any such customization to be based on > information > provided by the party with respect of whom the customization is being > performed? Or conversely, If I connect via an ISP in a > foreign country, > might I expect to get information customized for that > country? I think > such sources of information should at least be clearly > identified in any > trace information. > here, i agree with Markus comments, basically, it is sufficient for OPES to provide trace information that identifies the performed OPES service. > > Section 2.0 > ----------- > Do OPES entiries include the provider and consumer? It's not > clear to > me. The second bullet here suggests "yes", but elsewhere > suggests "no". > > No, this will be clarified in the text. > Section 2.1 > ----------- > The distinctive roles of OPES service application and data > dispatchers > aren't entirely clear. I would expect what you describe as an "Opes > service application" that sits on the provider-consumer flow > to contain the > architectural elements you describe under "data dispatcher". > > the data dispatcher is responsible for invoking (for the lack of a better work) the opes application service. if this is not clear in the text, then we should revisit it. > Section 2.2 > ----------- > Where you say "one or more OPES service applications" and > "one or more data > dispatchers" I think you mean "zero or more". Later you > mention "zero or > more..." > zero means regular data flow, so we will revisit this one. > 2nd para: I found this description rather woolly. Would any > significant > meaning be lost if the second sentence of this paragraph were > to be deleted? > no > > Section 2.3 > ----------- > It seems to me that the OPES rules are a cornerstone of the > architecture, > but very little is said about them. > and i see no problem with that. this document is not a rule specification document. > Section 2.4 > ----------- > Maybe this is just a personal preference, but talking about > "executing" a > ruleset seems to be very implementation-choice-oriented; would > "evaluating" not be closer to what you mean here? > yes, we will address it. > You also discuss using "the OPES callout protocol", which > seems to say > there is a single such protocol. yes, SNIP > Section 2.6 > ----------- > I think this section is very weak. It manages to impose questionable > implementation decisions without providing any real guidance > about how > tracing is to be provided. > > Specifically, it calls for "in-band annotation through header > extensions on > the application protocol". I believe that this approach will > mean that the > tracing facility is effectively unusable at Internet scale, > because it > depends on protocol extensions that will be largely > unimplemented by the > end systems who need access to the diagnostic information. > disagree, if you have followed the discussion and debate on these issues you would have noted that traceability is intended for the qualified user and not the general purpose user. The objective here is to allow a qualified administrator to trace what happended to the data when the end user gets errors. > I recently encountered a real problem that will illustrate my concern > here: my wife works from home as editorial manager for a > website. Recently, she was reviewing website content and was > getting old ... SNIP see previous remark. SNIP abbie ------_=_NextPart_001_01C200F1.DCD155A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG Last Call: draft-ietf-opes-architecture-00

see remarks inline

abbie


> -----Original Message-----
> From: Graham Klyne [mailto:GK-lists@ninebynine.org]
> Sent: Monday, May 20, 2002 5:47 AM
> To: Markus Hofmann
> Cc: OPES Group; Allison Mankin; Ned = Freed
> Subject: Re: WG Last Call: = draft-ietf-opes-architecture-00
>
>
 SNIP

> Section 1
> ---------
>
> The first paragraph mentions customization = based on geographical
> locality.  Taking this as an example, I = didn't notice
> anything later in the
> document about the source of information that = an OPES
> processor might use
> as the basis for customization services.  = I think some
> discussion might be
> appropriate;  e.g. is any such = customization to be based on
> information
> provided by the party with respect of whom the = customization is being
> performed?  Or conversely, If I connect = via an ISP in a
> foreign country,
> might I expect to get information customized = for that
> country?  I think
> such sources of information should at least be = clearly
> identified in any
> trace information.
>

here, i agree with Markus comments, basically, it is = sufficient for OPES to provide trace
information that identifies the performed OPES = service.

>
> Section 2.0
> -----------
> Do OPES entiries include the provider and = consumer?  It's not
> clear to
> me.  The second bullet here suggests = "yes", but elsewhere
> suggests "no".
>
>

No, this will be clarified in the text.


> Section 2.1
> -----------
> The distinctive roles of OPES service = application and data
> dispatchers
> aren't entirely clear.  I would expect = what you describe as an "Opes
> service application" that sits on the = provider-consumer flow
> to contain the
> architectural elements you describe under = "data dispatcher".
>
>

the data dispatcher is responsible for invoking (for = the lack of a better work) the opes application service. if this is not = clear in the text, then we should revisit it.

> Section 2.2
> -----------
> Where you say "one or more OPES service = applications" and
> "one or more data
> dispatchers" I think you mean "zero = or more".  Later you
> mention "zero or
> more..."
>

zero means regular data flow, so we will revisit this = one.


> 2nd para:  I found this description rather = woolly.  Would any
> significant
> meaning be lost if the second sentence of this = paragraph were
> to be deleted?
>

no


>
> Section 2.3
> -----------
> It seems to me that the OPES rules are a = cornerstone of the
> architecture,
> but very little is said about them.
>

and i see no problem with that. this document is not = a rule specification document.


> Section 2.4
> -----------
> Maybe this is just a personal preference, but = talking about
> "executing" a
> ruleset seems to be very = implementation-choice-oriented;  would
> "evaluating" not be closer to what = you mean here?
>
yes, we will address it.


> You also discuss using "the OPES callout = protocol", which
> seems to say
> there is a single such protocol. 

yes,

SNIP

> Section 2.6
> -----------
> I think this section is very weak.  It = manages to impose questionable
> implementation decisions without providing any = real guidance
> about how
> tracing is to be provided.
>
> Specifically, it calls for "in-band = annotation through header
> extensions on
> the application protocol".  I believe = that this approach will
> mean that the
> tracing facility is effectively unusable at = Internet scale,
> because it
> depends on protocol extensions that will be = largely
> unimplemented by the
> end systems who need access to the diagnostic = information.
>

disagree, if you have followed the discussion and = debate on these issues you would have noted that traceability is = intended for the qualified user and not the general purpose = user.

The objective here is to allow a qualified = administrator to trace what happended to the data when the end user = gets errors.


> I recently encountered a real problem that will = illustrate my concern
> here:  my wife works from home as = editorial manager for a
> website.  Recently, she was reviewing = website content and was
> getting old
...
SNIP

see previous remark.

SNIP

abbie


------_=_NextPart_001_01C200F1.DCD155A0-- From owner-ietf-openproxy@mail.imc.org Tue May 21 15:42:50 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26388 for ; Tue, 21 May 2002 15:42:49 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4LJLrA04118 for ietf-openproxy-bks; Tue, 21 May 2002 12:21:53 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LJLqL04114 for ; Tue, 21 May 2002 12:21:52 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([212.159.36.207]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g4M2xQ412444; Tue, 21 May 2002 19:59:26 -0700 Message-Id: <5.1.0.14.2.20020521201706.0381bca0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 May 2002 20:20:38 +0100 To: "Abbie Barbir" From: Graham Klyne Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Cc: OPES Group In-Reply-To: <87609AFB433BD5118D5E0002A52CD754023F67CD@zcard0k6.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 02:03 PM 5/21/02 -0400, Abbie Barbir wrote: > > Section 2.6 > > ----------- > > I think this section is very weak. It manages to impose questionable > > implementation decisions without providing any real guidance > > about how > > tracing is to be provided. > > > > Specifically, it calls for "in-band annotation through header > > extensions on > > the application protocol". I believe that this approach will > > mean that the > > tracing facility is effectively unusable at Internet scale, > > because it > > depends on protocol extensions that will be largely > > unimplemented by the > > end systems who need access to the diagnostic information. > > > >disagree, if you have followed the discussion and debate on these issues >you would have noted that traceability is intended for the qualified user >and not the general purpose user. > >The objective here is to allow a qualified administrator to trace what >happended to the data when the end user gets errors. In which case, I don't think that's an adequate level of tracing capability. That is, I don't think it fully addresses the spirit of the IAB requirements. I refer you to the example I mentioned, of a problem with an ISP's transparent caching. I don't think it's acceptable that only the ISP's administrator can find out what happened, because in practice the ISP won't bother and will spin some lie about it being (say) a browser problem. I think it's crucial to put diagnostic capability in the hands of the endpoint on whose behalf (authority) the service is being performed. (Even if the endpoint isn't given any choice about having the service.) #g ------------------- Graham Klyne From owner-ietf-openproxy@mail.imc.org Tue May 21 15:43:24 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26420 for ; Tue, 21 May 2002 15:43:24 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LJLoW04113 for ietf-openproxy-bks; Tue, 21 May 2002 12:21:50 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LJLnL04109 for ; Tue, 21 May 2002 12:21:49 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([212.159.36.207]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g4M2xO412441; Tue, 21 May 2002 19:59:24 -0700 Message-Id: <5.1.0.14.2.20020521200721.0381eec0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 21 May 2002 20:13:17 +0100 To: Markus Hofmann From: Graham Klyne Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 Cc: OPES Group In-Reply-To: <3CEA5FEE.7060209@mhof.com> References: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> <5.1.0.14.2.20020521112056.03d657b0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 10:55 AM 5/21/02 -0400, Markus Hofmann wrote: >>I think the requirement here should be that tracing is feasible *without* >>using extensions on the application protocol. (Not saying that >>extensions MAY NOT be used, just not required to get at tracing information.) > >If there's no extensions/addition at all, how would we get the trace >pointers to the enduser, so that the enduser can retrieve the more >detailed information fro mthe OPES boxes? The short answer is: out of band. In-band would be nice if it could be achieved without protocol extensions. I presume that the OPES intermediary would be communicating with the endpoint in whose admin domain it is operating, so some local arrangement is not unreasonable. Returning to my earlier example (ISP web cache), the link for tracing information could be provided through a web page that is accessed through a login mechanism similar to that used for retrieving mail via a web browser. Note, I'm not saying extensions cannot be used, just that obtaining the diagnostics should not depend on the endpoint having implemented such extensions. #g ------------------- Graham Klyne From owner-ietf-openproxy@mail.imc.org Tue May 21 15:54:36 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26843 for ; Tue, 21 May 2002 15:54:36 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LJXaw04553 for ietf-openproxy-bks; Tue, 21 May 2002 12:33:36 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LJXZL04549 for ; Tue, 21 May 2002 12:33:35 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LJWr715963; Tue, 21 May 2002 15:32:54 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 15:32:57 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754023F692D@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Graham Klyne Cc: OPES Group Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Tue, 21 May 2002 15:33:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C200FE.532A673A" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C200FE.532A673A Content-Type: text/plain; charset="iso-8859-1" see inline, > -----Original Message----- > From: Graham Klyne [mailto:GK-lists@ninebynine.org] > Sent: Tuesday, May 21, 2002 3:21 PM > To: Barbir, Abbie [CAR:1A00:EXCH] > Cc: OPES Group > Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 > SNIP > > > >The objective here is to allow a qualified administrator to > trace what > >happended to the data when the end user gets errors. > > In which case, I don't think that's an adequate level of tracing > capability. That is, I don't think it fully addresses the > spirit of the > IAB requirements. > > I refer you to the example I mentioned, of a problem with an ISP's > transparent caching. I don't think it's acceptable that only > the ISP's > administrator can find out what happened, because in practice > the ISP won't > bother and will spin some lie about it being (say) a browser problem. > > I think it's crucial to put diagnostic capability in the hands of the > endpoint on whose behalf (authority) the service is being > performed. (Even > if the endpoint isn't given any choice about having the service.) > > #g > > > ------------------- > Graham Klyne > > > This is why header extensions may be needed. simply keeping a log will suffer from the same problems that u mention plus it does not scale. abbie ------_=_NextPart_001_01C200FE.532A673A Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG Last Call: draft-ietf-opes-architecture-00

see inline,

> -----Original Message-----
> From: Graham Klyne [mailto:GK-lists@ninebynine.org]
> Sent: Tuesday, May 21, 2002 3:21 PM
> To: Barbir, Abbie [CAR:1A00:EXCH]
> Cc: OPES Group
> Subject: RE: WG Last Call: = draft-ietf-opes-architecture-00
>
SNIP

> >
> >The objective here is to allow a qualified = administrator to
> trace what
> >happended to the data when the end user = gets errors.
>
> In which case, I don't think that's an adequate = level of tracing
> capability.  That is, I don't think it = fully addresses the
> spirit of the
> IAB requirements.
>
> I refer you to the example I mentioned, of a = problem with an ISP's
> transparent caching.  I don't think it's = acceptable that only
> the ISP's
> administrator can find out what happened, = because in practice
> the ISP won't
> bother and will spin some lie about it being = (say) a browser problem.
>
> I think it's crucial to put diagnostic = capability in the hands of the
> endpoint on whose behalf (authority) the = service is being
> performed.  (Even
> if the endpoint isn't given any choice about = having the service.)
>
> #g
>
>
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
>
>

This is why header extensions may be needed. simply = keeping a log will suffer from the same problems that u mention plus it = does not scale.

abbie


------_=_NextPart_001_01C200FE.532A673A-- From owner-ietf-openproxy@mail.imc.org Tue May 21 16:12:06 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27708 for ; Tue, 21 May 2002 16:12:06 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LJptX05335 for ietf-openproxy-bks; Tue, 21 May 2002 12:51:55 -0700 (PDT) Received: from mgr2.xmission.com (mgr2.xmission.com [198.60.22.202]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LJpsL05331 for ; Tue, 21 May 2002 12:51:54 -0700 (PDT) Received: from mail by mgr2.xmission.com with spam-scanned (Exim 3.35 #1) id 17AFfo-0004BV-00 for ietf-openproxy@imc.org; Tue, 21 May 2002 13:51:56 -0600 Received: from [198.60.22.22] (helo=mail.xmission.com) by mgr2.xmission.com with esmtp (Exim 3.35 #1) id 17AFfo-0004BL-00 for ietf-openproxy@imc.org; Tue, 21 May 2002 13:51:56 -0600 Received: from [166.70.8.74] (helo=alum.mit.edu) by mail.xmission.com with esmtp (Exim 3.22 #1) id 17AFfn-00067E-00 for ietf-openproxy@imc.org; Tue, 21 May 2002 13:51:56 -0600 Message-ID: <3CEAA52D.70203@alum.mit.edu> Date: Tue, 21 May 2002 13:51:09 -0600 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 References: <5.1.0.14.2.20020521201706.0381bca0@joy.songbird.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=8.0 tests= version=2.20 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Tracing is meant for the end system user as well as qualified administrators. Just like email headers. I run a mailing list that uses three separate methods of including "unsubscribe" information in every message. Still, for some combinations of mail agent and message, the enduser cannot see the information. They send haughty email to the list administrator complaining about how defective the list is. OPES tracing will have similar benefits and deficiencies in practice. The inband method means that the user will always have information stored locally and will always be able to show it to someone else, but there is no way to guarantee that all users will always have enough clues to use it. Just like anything else having to do with the Internet, computers, or motorcycles (don't ask). Hilarie From owner-ietf-openproxy@mail.imc.org Tue May 21 16:12:16 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27730 for ; Tue, 21 May 2002 16:12:15 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LJojZ05303 for ietf-openproxy-bks; Tue, 21 May 2002 12:50:45 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LJoiL05299 for ; Tue, 21 May 2002 12:50:45 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LJo7d24466; Tue, 21 May 2002 15:50:08 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 15:50:10 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754023F6973@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Graham Klyne , Markus Hofmann Cc: OPES Group Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Tue, 21 May 2002 15:50:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20100.BCCCD626" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20100.BCCCD626 Content-Type: text/plain; charset="iso-8859-1" so, there is no major diagreement. the architecture talks about out-of band. abbie > -----Original Message----- > From: Graham Klyne [mailto:GK-lists@ninebynine.org] > Sent: Tuesday, May 21, 2002 3:13 PM > To: Markus Hofmann > Cc: OPES Group > Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 > > > > At 10:55 AM 5/21/02 -0400, Markus Hofmann wrote: > >>I think the requirement here should be that tracing is > feasible *without* > >>using extensions on the application protocol. (Not saying that > >>extensions MAY NOT be used, just not required to get at > tracing information.) > > > >If there's no extensions/addition at all, how would we get the trace > >pointers to the enduser, so that the enduser can retrieve the more > >detailed information fro mthe OPES boxes? > > The short answer is: out of band. In-band would be nice if > it could be > achieved without protocol extensions. > > I presume that the OPES intermediary would be communicating with the > endpoint in whose admin domain it is operating, so some local > arrangement > is not unreasonable. Returning to my earlier example (ISP > web cache), the > link for tracing information could be provided through a web > page that is > accessed through a login mechanism similar to that used for > retrieving mail > via a web browser. > > Note, I'm not saying extensions cannot be used, just that > obtaining the > diagnostics should not depend on the endpoint having implemented such > extensions. > > #g > > > ------------------- > Graham Klyne > > > ------_=_NextPart_001_01C20100.BCCCD626 Content-Type: text/html; charset="iso-8859-1" RE: WG Last Call: draft-ietf-opes-architecture-00

so,

there is no major diagreement.
the architecture talks about out-of band.

abbie

> -----Original Message-----
> From: Graham Klyne [mailto:GK-lists@ninebynine.org]
> Sent: Tuesday, May 21, 2002 3:13 PM
> To: Markus Hofmann
> Cc: OPES Group
> Subject: Re: WG Last Call: draft-ietf-opes-architecture-00
>
>
>
> At 10:55 AM 5/21/02 -0400, Markus Hofmann wrote:
> >>I think the requirement here should be that tracing is
> feasible *without*
> >>using extensions on the application protocol.  (Not saying that
> >>extensions MAY NOT be used, just not required to get at
> tracing information.)
> >
> >If there's no extensions/addition at all, how would we get the trace
> >pointers to the enduser, so that the enduser can retrieve the more
> >detailed information fro mthe OPES boxes?
>
> The short answer is:  out of band.  In-band would be nice if
> it could be
> achieved without protocol extensions.
>
> I presume that the OPES intermediary would be communicating with the
> endpoint in whose admin domain it is operating, so some local
> arrangement
> is not unreasonable.  Returning to my earlier example (ISP
> web cache), the
> link for tracing information could be provided through a web
> page that is
> accessed through a login mechanism similar to that used for
> retrieving mail
> via a web browser.
>
> Note, I'm not saying extensions cannot be used, just that
> obtaining the
> diagnostics should not depend on the endpoint having implemented such
> extensions.
>
> #g
>
>
> -------------------
> Graham Klyne
> <GK@NineByNine.org>
>
>

------_=_NextPart_001_01C20100.BCCCD626-- From owner-ietf-openproxy@mail.imc.org Tue May 21 16:29:44 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28746 for ; Tue, 21 May 2002 16:29:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LK8F205795 for ietf-openproxy-bks; Tue, 21 May 2002 13:08:15 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LK8FL05790 for ; Tue, 21 May 2002 13:08:15 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LK88723792; Tue, 21 May 2002 16:08:08 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 16:08:11 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754023F69CE@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: "The Purple Streak (Hilarie Orman)" , OPES Group Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Tue, 21 May 2002 16:08:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20103.3D8A6F4C" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20103.3D8A6F4C Content-Type: text/plain; charset="iso-8859-1" Amen, abbie > -----Original Message----- > From: The Purple Streak (Hilarie Orman) [mailto:ho@alum.mit.edu] > Sent: Tuesday, May 21, 2002 3:51 PM > To: OPES Group > Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 > > > > Tracing is meant for the end system user as well as qualified > administrators. Just like email headers. I run a mailing > list that uses three separate methods of including "unsubscribe" > information in every message. Still, for some combinations of > mail agent and message, the enduser cannot see the information. > They send haughty email to the list administrator complaining > about how defective the list is. OPES tracing will have similar > benefits and deficiencies in practice. The inband method means > that the user will always have information stored locally and > will always be able to show it to someone else, but there is no > way to guarantee that all users will always have enough clues to > use it. Just like anything else having to do with the Internet, > computers, or motorcycles (don't ask). > > Hilarie > > ------_=_NextPart_001_01C20103.3D8A6F4C Content-Type: text/html; charset="iso-8859-1" RE: WG Last Call: draft-ietf-opes-architecture-00

Amen,

abbie

> -----Original Message-----
> From: The Purple Streak (Hilarie Orman) [mailto:ho@alum.mit.edu]
> Sent: Tuesday, May 21, 2002 3:51 PM
> To: OPES Group
> Subject: Re: WG Last Call: draft-ietf-opes-architecture-00
>
>
>
> Tracing is meant for the end system user as well as qualified
> administrators.  Just like email headers.  I run a mailing
> list that uses three separate methods of including "unsubscribe"
> information in every message.  Still, for some combinations of
> mail agent and message, the enduser cannot see the information.
> They send haughty email to the list administrator complaining
> about how defective the list is.  OPES tracing will have similar
> benefits and deficiencies in practice.  The inband method means
> that the user will always have information stored locally and
> will always be able to show it to someone else, but there is no
> way to guarantee that all users will always have enough clues to
> use it.  Just like anything else having to do with the Internet,
> computers, or motorcycles (don't ask).
>
> Hilarie
>
>

------_=_NextPart_001_01C20103.3D8A6F4C-- From owner-ietf-openproxy@mail.imc.org Tue May 21 16:30:27 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28868 for ; Tue, 21 May 2002 16:30:27 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LKA8a05846 for ietf-openproxy-bks; Tue, 21 May 2002 13:10:08 -0700 (PDT) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LKA7L05840 for ; Tue, 21 May 2002 13:10:07 -0700 (PDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LKB6UL028666; Tue, 21 May 2002 16:11:06 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LKA3k56637; Tue, 21 May 2002 16:10:03 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA12036; Tue, 21 May 2002 16:10:02 -0400 (EDT) Message-ID: <3CEAA99A.2060702@mhof.com> Date: Tue, 21 May 2002 16:10:02 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Klyne CC: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 References: <5.1.0.14.2.20020520095126.00a8e0e0@joy.songbird.com> <5.1.0.14.2.20020521112056.03d657b0@joy.songbird.com> <5.1.0.14.2.20020521200721.0381eec0@joy.songbird.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Klyne wrote: > I presume that the OPES intermediary would be communicating with the > endpoint in whose admin domain it is operating, so some local > arrangement is not unreasonable. Returning to my earlier example (ISP > web cache), the link for tracing information could be provided through a > web page that is accessed through a login mechanism similar to that used > for retrieving mail via a web browser. What about endpoints that are *not* located within the admin domain of the (faulty) OPES system? And how would an endpoint learn about which OPES systems have been involved at all? It's not only the OPES system in the enduser's admin domain that migth cause trouble, it might be any OPES system on the way betweem client and server. Therefore, the endpoint somehow needs to identify which OPES systems the message went through - and this is not static, it can be different on a per message basis. > Note, I'm not saying extensions cannot be used, just that obtaining the > diagnostics should not depend on the endpoint having implemented such > extensions. Please correct me if I'm wrong, but I think we're in agreement that an enduser would retrieve detailed tracing information from an OPES system out-of-band, via some standard mechanism (e.g. Web page etc.). I.e. there's no need to implement any extensiosn to retrieve the detailed tracing info. What remains open, though, is the question (a) how the enduser learns which OPES system(s) the message traveled through and, therefore, might have to be contacted, and (b) how to contact them. -Markus From owner-ietf-openproxy@mail.imc.org Tue May 21 16:46:19 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29524 for ; Tue, 21 May 2002 16:46:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LKLnk06152 for ietf-openproxy-bks; Tue, 21 May 2002 13:21:49 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LKLlL06148 for ; Tue, 21 May 2002 13:21:48 -0700 (PDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4LKLnEF004719; Tue, 21 May 2002 16:21:49 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4LKLhk57877; Tue, 21 May 2002 16:21:43 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA13177; Tue, 21 May 2002 16:21:42 -0400 (EDT) Message-ID: <3CEAAC56.4050008@mhof.com> Date: Tue, 21 May 2002 16:21:42 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Klyne CC: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 References: <5.1.0.14.2.20020521201706.0381bca0@joy.songbird.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Klyne wrote: > In which case, I don't think that's an adequate level of tracing > capability. That is, I don't think it fully addresses the spirit of the > IAB requirements. > > I refer you to the example I mentioned, of a problem with an ISP's > transparent caching. I don't think it's acceptable that only the ISP's > administrator can find out what happened, because in practice the ISP > won't bother and will spin some lie about it being (say) a browser problem. > > I think it's crucial to put diagnostic capability in the hands of the > endpoint on whose behalf (authority) the service is being performed. > (Even if the endpoint isn't given any choice about having the service.) I agree with your statement that OPES must give the enduser the capability to figure out what's going on and what might have gone wrong - it is *not* the intent to block this information from the enduser and to provide it only to an administrator. However, it might be ok to present this information in a form that might require a little bit more knowledge to interpret correctly, and it might not be shown to the enduser per default. I've the email system in mind - the email headers provide the information I need in order to determine which servers where involved. However, this information is not really intendend to be seen by every beginner or every home user. However, if there's a problem, you can look at the details and maybe ask somenone (your administrator?) to help you understand. I had something similar in mind when talking about OPES tracing. -Markus From owner-ietf-openproxy@mail.imc.org Wed May 22 08:18:34 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26420 for ; Wed, 22 May 2002 08:18:33 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MBppr03418 for ietf-openproxy-bks; Wed, 22 May 2002 04:51:51 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MBpoL03414 for ; Wed, 22 May 2002 04:51:50 -0700 (PDT) Received: from GK-VAIO.NineByNine.org (dyn135-40.sftm-212-159.plus.net [212.159.40.135]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g4MJTN413682 for ; Wed, 22 May 2002 12:29:23 -0700 Message-Id: <5.1.0.14.2.20020522094008.03ccdc70@joy.songbird.com> X-Sender: gk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 22 May 2002 13:02:39 +0100 To: OPES Group From: Graham Klyne Subject: OPES architecture - tracing and diagnostics Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I've received several responses about my comments regarding OPES tracing and access to diagnostics. Rather than get drawn into a repetitious series of overlapping emails, I'm going to try and deal with them all together. First a summary of my position: I think an endpoint-user needs to be able to access OPES diagnostic information using commonly-used legacy software. Requiring the endpoint-user to upgrade their software to access diagnostic information does not, in my view, adequately address the intent of the IAB requirements. I have no problem with protocol extensions being available to facilitate access to the information. I would also like to maintain some focus on the particular example I raised: I think it represents a common use-case that well illustrates the need for diagnostic information. It is the case of an intermediate cache that returns the wrong data in response to a web page request. Using a standard browser, how am I to use the OPES trace/log information to diagnose the problem? (I'm not claiming this is the *only* case that OPES should deal with, just that it's illustrative of an important case.) Objections to my position that I have noted are: - End users can't understand this diagnostic stuff - Only administrators need to access the traces Maybe many end-users won't understand it, but I see that as no reason to deny access to the information by those who can use it. My experience of over-stretched ISPs and corporate IT departments suggests that administrators won't bother - I feel strongly that Internet technology should not operate to deny self help to users at the network edge. I also think this principle informs the IAB requirements on OPES. - Inband signalling means the user will have a locally stored copy - Email system as model For email, I can see a case that in-band signalling could provide the needed information, but even there I'm not totally convinced. It is in the nature of email that messages are stored, complete with their headers, which are used for such purposes as constructing replies. I don't know if all email clients provide access to arbitrary header information, but I acknowledge that some (many?) do. But OPES is not just about email. Someone on this list mentioned that HTTP is the target of any initial protocol-specific design work. I claim that HTTP content is inherently transient. It is designed as a stateless protocol so servers don't have to hold on to request information, and in typical default use the results are displayed transiently at the client. (Yes, I know there's usually a browser cache, but that too is transient and as far as I have been aware it's only the HTTP response bodies and essential identifying information that are cached.) So, I remain unconvinced that in-band signalling is the way to persist diagnostic information. - In-band is needed for information from other administrative domains This is a fair point. Ad-hoc out-of-band mechanisms cannot really be expected to be effective across administrative domains. Thus it seems to me that accessing information about behaviours in other domains is going to be a tricky problem to solve well. In-band information may help, and I'm not opposed to using it (just not depending on it). The OPES architecture requires that each intermediary is operating under the authority of one or other endpoint (the colouring discussion). Further, even when the infrastructure providers may have little interest in resolving problems, the endpoints will often have reason to cooperate. So, it seems to me that always having out of band access from one endpoint or the other is a far better outcome than having none. - OPES operations are determined per-message - Keeping a log at an intermediary is insufficient Actually, I imagine that keeping a log could be quite sufficient, if sufficient information is logged. I understand that one of the OPES requirements is that any intermediary operates with the authorization of one of the endpoints, which implies that at least one endpoint should know about any OPES intermediary that manipulates some data in transit. Knowing the time, source and target of a request, it should be reasonably easy to identify a particular HTTP request and response from logging data kept at an intermediary. #g ------------------- Graham Klyne From owner-ietf-openproxy@mail.imc.org Wed May 22 09:55:44 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02483 for ; Wed, 22 May 2002 09:55:44 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MDSxA11263 for ietf-openproxy-bks; Wed, 22 May 2002 06:28:59 -0700 (PDT) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MDSwL11256 for ; Wed, 22 May 2002 06:28:58 -0700 (PDT) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id JAA20186; Wed, 22 May 2002 09:37:27 -0400 Date: Wed, 22 May 2002 09:37:26 -0400 From: Mark Baker To: Markus Hofmann Cc: OPES Group Subject: Callout (was Re: WG Last Call: draft-ietf-opes-architecture-00 Message-ID: <20020522093726.O16765@www.markbaker.ca> References: <3CE70770.7060500@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3CE70770.7060500@mhof.com>; from markus@mhof.com on Sat, May 18, 2002 at 10:01:20PM -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I just have one major comment ... As I've stated here before, I can see no reason why "callout" receives any mention in an architectural document. Callout is an implementation detail, where an OPES entity determines that it needs to go elsewhere to accomplish its task. Furthermore, not only do I not see a need to *identify* a callout protocol, I don't even see a need to standardize on one. The important interface is the one between entities, such as that provided by HTTP, or other transfer protocols. If you need to "callout" to a service, give it an HTTP interface and call it an entity. This is how things work today with HTTP intermediaries (firewalls, caches, etc..). From a practical point of view, this additional hop introduces unnecessary latency, when that processing could easily be done by the entity within the flow. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@acm.org http://www.markbaker.ca http://www.idokorro.com From owner-ietf-openproxy@mail.imc.org Wed May 22 10:23:58 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04169 for ; Wed, 22 May 2002 10:23:58 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4MDwqo12045 for ietf-openproxy-bks; Wed, 22 May 2002 06:58:52 -0700 (PDT) Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MDwpL12040 for ; Wed, 22 May 2002 06:58:51 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MDwEU08782; Wed, 22 May 2002 09:58:14 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 09:58:18 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754023F6D6A@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Graham Klyne , OPES Group Subject: [ OPES architecture] Final Points of Discussion: Tracing Date: Wed, 22 May 2002 09:58:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20198.BD4F863C" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20198.BD4F863C Content-Type: text/plain; charset="iso-8859-1" Graham and all, I am providing a summary of the current position and feedback. This will be points that we try to get agreement on. 1. endpoint-user must be able to access OPES diagnostic information using legacy s/w. 2. have no problem with protocol extensions being available to facilitate access to the information. 3. not opposed to using In-band information even if it means extensions 4. keeping a log could be quite sufficient 5. having out of band access from one endpoint or the other is a far better outcome than having none 6. (From mark baker) No need to standardize on a callout protocol. Here I propose that we start a new thread where each point is discussed and get solved. abbie ------_=_NextPart_001_01C20198.BD4F863C Content-Type: text/html; charset="iso-8859-1" [ OPES architecture] Final Points of Discussion: Tracing

Graham and all,

I am providing a summary of the current position and feedback.
This will be points that we try to get agreement on.

1. endpoint-user must be able to access OPES diagnostic
   information using legacy s/w.
2. have no problem with protocol extensions being available to
   facilitate access to the information.
3. not opposed to using In-band information even if it means extensions
4. keeping a log could be quite sufficient
5. having out of band access from one endpoint or the other is a far better
   outcome than having none
6. (From mark baker) No need to standardize on a callout protocol.

Here I propose that we start a new thread where each point is discussed and get solved.

abbie

------_=_NextPart_001_01C20198.BD4F863C-- From owner-ietf-openproxy@mail.imc.org Wed May 22 12:48:18 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18071 for ; Wed, 22 May 2002 12:48:17 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4MGIcK19768 for ietf-openproxy-bks; Wed, 22 May 2002 09:18:38 -0700 (PDT) Received: from miz-mishtal.dbc.mtview.ca.us (adsl-64-168-10-250.dsl.scrm01.pacbell.net [64.168.10.250]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MGIbL19763 for ; Wed, 22 May 2002 09:18:37 -0700 (PDT) Received: from kalia (dhcpd253.dbc.mtview.ca.us [64.168.10.253]) by miz-mishtal.dbc.mtview.ca.us (8.11.0+3.3W/8.11.0) with SMTP id g4MFvMd00898; Wed, 22 May 2002 08:57:22 -0700 (PDT) Date: Wed, 22 May 2002 09:18:25 -0700 From: Marshall Rose To: "Mark Baker" Cc: ietf-openproxy@imc.org Subject: Re: Callout (was Re: WG Last Call: draft-ietf-opes-architecture-00 Message-Id: <20020522091825.69deaaa8.mrose@dbc.mtview.ca.us> In-Reply-To: <20020522093726.O16765@www.markbaker.ca> References: <3CE70770.7060500@mhof.com> <20020522093726.O16765@www.markbaker.ca> Organization: Dover Beach Consulting, Inc. X-Mailer: Sylpheed version 0.7.2claws (GTK+ 1.2.10; i386-unknown-netbsdelf1.5ZA) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > > I just have one major comment ... > > As I've stated here before, I can see no reason why "callout" receives > any mention in an architectural document. Callout is an implementation > detail, where an OPES entity determines that it needs to go elsewhere to > accomplish its task. Furthermore, not only do I not see a need to > *identify* a callout protocol, I don't even see a need to standardize on > one. The important interface is the one between entities, such as that > provided by HTTP, or other transfer protocols. If you need to "callout" > to a service, give it an HTTP interface and call it an entity. This is > how things work today with HTTP intermediaries (firewalls, caches, > etc..). mark - the reason that callout is in the architecture is because we standardize a callout protocol. if we didn't care to have the protocol standardized, then you and i are in agreement; however, everyone i talk to in this space tells me that a standardized callout protocol is a real-world requirement. so, there you have it. /mtr From owner-ietf-openproxy@mail.imc.org Wed May 22 13:33:59 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20963 for ; Wed, 22 May 2002 13:33:58 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MH4Mq21632 for ietf-openproxy-bks; Wed, 22 May 2002 10:04:22 -0700 (PDT) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MH4KL21628 for ; Wed, 22 May 2002 10:04:21 -0700 (PDT) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id NAA23275; Wed, 22 May 2002 13:12:52 -0400 Date: Wed, 22 May 2002 13:12:52 -0400 From: Mark Baker To: Marshall Rose Cc: ietf-openproxy@imc.org Subject: Re: Callout (was Re: WG Last Call: draft-ietf-opes-architecture-00 Message-ID: <20020522131252.U16765@www.markbaker.ca> References: <3CE70770.7060500@mhof.com> <20020522093726.O16765@www.markbaker.ca> <20020522091825.69deaaa8.mrose@dbc.mtview.ca.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20020522091825.69deaaa8.mrose@dbc.mtview.ca.us>; from mrose@dbc.mtview.ca.us on Wed, May 22, 2002 at 09:18:25AM -0700 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, May 22, 2002 at 09:18:25AM -0700, Marshall Rose wrote: > mark - the reason that callout is in the architecture is because we standardize a callout protocol. if we didn't care to have the protocol standardized, then you and i are in agreement; however, everyone i talk to in this space tells me that a standardized callout protocol is a real-world requirement. so, there you have it. Thanks, that explains why it's in the document. I just don't get why people think one is needed. If it's "obvious" to so many here, then I'll just save my breath for the callout requirements gathering phase. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@acm.org http://www.markbaker.ca http://www.idokorro.com From owner-ietf-openproxy@mail.imc.org Wed May 22 13:38:55 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21256 for ; Wed, 22 May 2002 13:38:54 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MHF2i22038 for ietf-openproxy-bks; Wed, 22 May 2002 10:15:02 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MHF1L22034 for ; Wed, 22 May 2002 10:15:01 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4MHEfl14786; Wed, 22 May 2002 13:14:41 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 13:14:45 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754023F706F@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Marshall Rose , Mark Baker Cc: ietf-openproxy@imc.org Subject: RE: Callout (was Re: WG Last Call: draft-ietf-opes-architecture-0 0 Date: Wed, 22 May 2002 13:15:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201B4.344D6F4A" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C201B4.344D6F4A Content-Type: text/plain; charset="iso-8859-1" marshal and all, please use the thread [ OPES architecture] Final Points of Discussion: Tracing that i have just started. abbie > -----Original Message----- > From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us] > Sent: Wednesday, May 22, 2002 12:18 PM > To: Mark Baker > Cc: ietf-openproxy@imc.org > Subject: Re: Callout (was Re: WG Last Call: > draft-ietf-opes-architecture-00 > > > > > > > I just have one major comment ... > > > > As I've stated here before, I can see no reason why > "callout" receives > > any mention in an architectural document. Callout is an > implementation > > detail, where an OPES entity determines that it needs to go > elsewhere to > > accomplish its task. Furthermore, not only do I not see a need to > > *identify* a callout protocol, I don't even see a need to > standardize on > > one. The important interface is the one between entities, > such as that > > provided by HTTP, or other transfer protocols. If you need > to "callout" > > to a service, give it an HTTP interface and call it an > entity. This is > > how things work today with HTTP intermediaries (firewalls, caches, > > etc..). > > > mark - the reason that callout is in the architecture is > because we standardize a callout protocol. if we didn't care > to have the protocol standardized, then you and i are in > agreement; however, everyone i talk to in this space tells me > that a standardized callout protocol is a real-world > requirement. so, there you have it. > > /mtr > ------_=_NextPart_001_01C201B4.344D6F4A Content-Type: text/html; charset="iso-8859-1" RE: Callout (was Re: WG Last Call: draft-ietf-opes-architecture-00

marshal and all,
please use the thread

[ OPES architecture] Final Points of Discussion: Tracing

that i have just started.

abbie

> -----Original Message-----
> From: Marshall Rose [mailto:mrose@dbc.mtview.ca.us]
> Sent: Wednesday, May 22, 2002 12:18 PM
> To: Mark Baker
> Cc: ietf-openproxy@imc.org
> Subject: Re: Callout (was Re: WG Last Call:
> draft-ietf-opes-architecture-00
>
>
>
> >
> > I just have one major comment ...
> >
> > As I've stated here before, I can see no reason why
> "callout" receives
> > any mention in an architectural document.  Callout is an
> implementation
> > detail, where an OPES entity determines that it needs to go
> elsewhere to
> > accomplish its task.  Furthermore, not only do I not see a need to
> > *identify* a callout protocol, I don't even see a need to
> standardize on
> > one.  The important interface is the one between entities,
> such as that
> > provided by HTTP, or other transfer protocols.  If you need
> to "callout"
> > to a service, give it an HTTP interface and call it an
> entity.  This is
> > how things work today with HTTP intermediaries (firewalls, caches,
> > etc..).
>
>
> mark - the reason that callout is in the architecture is
> because we standardize a callout protocol. if we didn't care
> to have the protocol standardized, then you and i are in
> agreement; however, everyone i talk to in this space tells me
> that a standardized callout protocol is a real-world
> requirement. so, there you have it.
>
> /mtr
>

------_=_NextPart_001_01C201B4.344D6F4A-- From owner-ietf-openproxy@mail.imc.org Wed May 22 16:33:50 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29182 for ; Wed, 22 May 2002 16:33:49 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4MK94O26827 for ietf-openproxy-bks; Wed, 22 May 2002 13:09:04 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MK93L26822 for ; Wed, 22 May 2002 13:09:03 -0700 (PDT) Received: from oskar3 ([24.60.133.29]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020522200900.NCKA2751.rwcrmhc52.attbi.com@oskar3>; Wed, 22 May 2002 20:09:00 +0000 From: "Oskar Batuner" To: "Ian Cooper" , "OPES Group" Cc: "Markus Hofmann" Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Wed, 22 May 2002 16:09:00 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <929674.1021925586@localhost> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Ian Cooper > Sent: Monday, May 20, 2002 3:13 PM > To: OPES Group > Cc: Oskar Batuner; Markus Hofmann > Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 > > > > --On Monday, May 20, 2002 13:28 -0400 Oskar Batuner > wrote: > > > - CDN scenario: OPES architecture is used to build a content > > distribution network and OPES servers in fact constitute an > > integral part of data provider. In this case such servers have > > an absolute trust of data provider and the end user has no more > > right or reason to question/interfere with there functionality > > than it has now in relation to the architecture of the > > provider's site web servers farm. > > Agree, though I'm not sure I see anything that suggests otherwise. > (Apologies if I'm missing something in my jetlag induced haze.) > Well, some practical implications of CDN scenario (or use of OPES architecture in web server farm): 1. Data producer may delegate signing authority to OPES server; 2. OPES server may respond to any security-related (trace-type) requests in exactly the same way the data origin would. More issues with security: It is not clear how to apply the proposed tracing and integrity verification mechanisms to truly dynamic data. Suppose a data producer wants to exploit XML processing abilities of the latest browsers but still want to serve older browsers with HTML data. He uses OPES to to perform XML transformation for certain user-agents. Here original data does not exist at all, nor there is a "real resource" Ian have mentioned in the previous message. Use of OPES for filtering also creates a different situation. The data consumer may have no trust authority at all. Authority belongs to the domain administrator, who is not present in the data flow and has to delegate this authority to some proxy - and this may be an OPES proxy. This breaks the model described in 3.1 were trust is propagated along the data distribution path. In fact in some cases data consumer may be not a "primary party" in the draft terminology. The statement "OPES must not interfere with the capability of these parties to use end-to-end authentication and confidentiality" does not work here. Oskar From owner-ietf-openproxy@mail.imc.org Wed May 22 16:33:53 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29195 for ; Wed, 22 May 2002 16:33:52 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4MK9E326839 for ietf-openproxy-bks; Wed, 22 May 2002 13:09:14 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MK9DL26835 for ; Wed, 22 May 2002 13:09:13 -0700 (PDT) Received: from oskar3 ([24.60.133.29]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020522200911.NCMR2751.rwcrmhc52.attbi.com@oskar3>; Wed, 22 May 2002 20:09:11 +0000 From: "Oskar Batuner" To: "Robin Chen" Cc: "OPES Group" Subject: RE: WG Last Call: draft-ietf-opes-architecture-00: CDN scenario Date: Wed, 22 May 2002 16:09:11 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3CE9D3EB.F79F64D5@research.att.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Robin, I've already sent comments to the initial thread, sorry, my participation today may be kind of erratic: ATT Broadband is in the process of another network overhaul, moving servers and addresses, so my connectivity is very unstable. Your message raises one fundamental question: what is the set of drafts the group is working on? My impression from the architecture document was that the document set is listed in references, older drafts are abandoned. My impression was that the model draft was an initial approach to the architecture description. Areas covered by these two documents are very much overlapped. It the model draft has to be revived both documents should be either released together or even merged. Can you please summarize - what is the current active document set? Thanks. Oskar From owner-ietf-openproxy@mail.imc.org Wed May 22 17:07:03 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00902 for ; Wed, 22 May 2002 17:07:02 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MKfRn27864 for ietf-openproxy-bks; Wed, 22 May 2002 13:41:27 -0700 (PDT) Received: from mgr3.xmission.com (mgr3.xmission.com [198.60.22.203]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MKfQL27860 for ; Wed, 22 May 2002 13:41:26 -0700 (PDT) Received: from mail by mgr3.xmission.com with spam-scanned (Exim 3.35 #1) id 17AcvI-0003K7-00; Wed, 22 May 2002 14:41:28 -0600 Received: from [198.60.22.22] (helo=mail.xmission.com) by mgr3.xmission.com with esmtp (Exim 3.35 #1) id 17AcvI-0003K4-00; Wed, 22 May 2002 14:41:28 -0600 Received: from [166.70.13.243] (helo=alum.mit.edu) by mail.xmission.com with esmtp (Exim 3.22 #1) id 17AcvH-0007ol-00; Wed, 22 May 2002 14:41:28 -0600 Message-ID: <3CEC01FA.1090201@alum.mit.edu> Date: Wed, 22 May 2002 14:39:22 -0600 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: Oskar Batuner CC: OPES Group Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=8.0 tests= version=2.20 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Dynamic data creation would be evident in the OPES tracing information; further, the relationship between the request and the returned (created by OPES) object would be evident. In the case of the user's perogatives being subverted (errh, subsumed) by his local administrator, the security viewpoint here is that the end user has already "delegated" his authority to the local administrator (color me data consumer), and thus, OPES is not interfering with any ability that was not previously compromised. I.e., OPES can avoid interfering but it cannot fix the world. Hilarie Oskar Batuner wrote: > > >>-----Original Message----- >>From: owner-ietf-openproxy@mail.imc.org >>[mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Ian Cooper >>Sent: Monday, May 20, 2002 3:13 PM >>To: OPES Group >>Cc: Oskar Batuner; Markus Hofmann >>Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 >> >> >> >>--On Monday, May 20, 2002 13:28 -0400 Oskar Batuner >>wrote: >> >> > >>>- CDN scenario: OPES architecture is used to build a content >>>distribution network and OPES servers in fact constitute an >>>integral part of data provider. In this case such servers have >>>an absolute trust of data provider and the end user has no more >>>right or reason to question/interfere with there functionality >>>than it has now in relation to the architecture of the >>>provider's site web servers farm. >>> >>Agree, though I'm not sure I see anything that suggests otherwise. >>(Apologies if I'm missing something in my jetlag induced haze.) >> >> > > Well, some practical implications of CDN scenario (or use of OPES > architecture in web server farm): > > 1. Data producer may delegate signing authority to OPES server; > 2. OPES server may respond to any security-related (trace-type) > requests in exactly the same way the data origin would. > > More issues with security: > > It is not clear how to apply the proposed tracing and integrity > verification mechanisms to truly dynamic data. > > Suppose a data producer wants to exploit XML processing abilities of > the latest browsers but still want to serve older browsers with > HTML data. He uses OPES to to perform XML transformation for certain > user-agents. Here original data does not exist at all, nor there is a > "real resource" Ian have mentioned in the previous message. > > Use of OPES for filtering also creates a different situation. The data > consumer may have no trust authority at all. Authority belongs to the domain > administrator, who is not present in the data flow and has to > delegate this authority to some proxy - and this may be an OPES proxy. > This breaks the model described in 3.1 were trust is propagated along the > data distribution path. In fact in some cases data consumer may be not a > "primary party" in the draft terminology. The statement "OPES must not > interfere with the capability of these parties to use end-to-end > authentication and confidentiality" does not work here. > > Oskar > > > > > From owner-ietf-openproxy@mail.imc.org Wed May 22 17:17:18 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01667 for ; Wed, 22 May 2002 17:17:17 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MKoWU28057 for ietf-openproxy-bks; Wed, 22 May 2002 13:50:32 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MKoVL28053 for ; Wed, 22 May 2002 13:50:31 -0700 (PDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4MKpRUL043492; Wed, 22 May 2002 16:51:27 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4MKoQk64924; Wed, 22 May 2002 16:50:26 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id QAA28890; Wed, 22 May 2002 16:50:26 -0400 (EDT) Message-ID: <3CEC0491.4010000@mhof.com> Date: Wed, 22 May 2002 16:50:25 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Oskar Batuner CC: Robin Chen , OPES Group Subject: Re: WG Last Call: draft-ietf-opes-architecture-00: CDN scenario References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Oskar Batuner wrote: > Your message raises one fundamental question: what is the set of > drafts the group is working on? My impression from the architecture > document was that the document set is listed in references, older > drafts are abandoned. The list of docuemnts the WG is working on can be taken from our charter at http://www.ietf.org/html.charters/opes-charter.html. At the moment, an initial version of the architecture draft is published, initial proposals for the scenarios and protocol requirements draft are in the works, the other documents to follow. > My impression was that the model draft was an initial approach to > the architecture description. Areas covered by these two documents > are very much overlapped. It the model draft has to be revived both > documents should be either released together or even merged. Your impression is correct, the old models draft is *not* intended to become an official WG document, but relevant architectural information should be carried over/considered in the new architecture draft. -Markus From owner-ietf-openproxy@mail.imc.org Wed May 22 18:24:55 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05165 for ; Wed, 22 May 2002 18:24:55 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4MLxex00310 for ietf-openproxy-bks; Wed, 22 May 2002 14:59:40 -0700 (PDT) Received: from rwcrmhc53.attbi.com (rwcrmhc53.attbi.com [204.127.198.39]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MLxdL00306 for ; Wed, 22 May 2002 14:59:39 -0700 (PDT) Received: from oskar3 ([24.60.133.29]) by rwcrmhc53.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020522215937.RMGM11659.rwcrmhc53.attbi.com@oskar3>; Wed, 22 May 2002 21:59:37 +0000 From: "Oskar Batuner" To: "The Purple Streak \(Hilarie Orman\)" Cc: "OPES Group" Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Wed, 22 May 2002 17:59:37 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <3CEC01FA.1090201@alum.mit.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit > -----Original Message----- > From: The Purple Streak (Hilarie Orman) [mailto:ho@alum.mit.edu] > > In the case of the user's perogatives being subverted (errh, subsumed) > by his local administrator, the security viewpoint here is that the > end user has already "delegated" his authority to the local > administrator (color me data consumer), and thus, OPES is not > interfering with any ability that was not previously compromised. > I.e., OPES can avoid interfering but it cannot fix the world. > > Hilarie You are right, but this means OPES should adapt to this imperfect world. Specifically: Situation with trust/administrative authority being different from the end user (in the sense of end point of data reception) is completely valid and should be explicitly included in the security considerations. This configuration essentially means that there may be an intermediate point in the data path that has higher authority than end point. And symmetric configuration for CDN also moves "ultimate authority point" downstream in the data flow. I suggest to change the security model by introducing start of authority and end of authority points different from the start and the end of data flow. All the notion of end-to-end should be adjusted to the situation when dataflow path and authority propagation path are different. This is different from the proposed model: ---- 3.1 Trust Domains The delegation of authority starts at either a data consumer or data provider and moves to more distant entities in a "stepwise" fashion. ---- These "higher authority" points may specifically limit Tracing/enquiry abilities of the end user. On the other hand tracing should support the ability to find the source of authority. One more security mechanism to consider in addition to tracing is reporting. For example the data source may include a request to the end user to report specific change notifications. Or the end user may (automatically?) report suspected problems to the source of authority. Oskar From owner-ietf-openproxy@mail.imc.org Wed May 22 18:47:48 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05987 for ; Wed, 22 May 2002 18:47:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MMNFn00825 for ietf-openproxy-bks; Wed, 22 May 2002 15:23:15 -0700 (PDT) Received: from esarhaddon.ability.net (esarhaddon.ability.net [216.3.3.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MMNEL00820 for ; Wed, 22 May 2002 15:23:14 -0700 (PDT) Received: from [10.0.1.20] (66.safeclick.net [63.119.245.66]) by esarhaddon.ability.net (8.11.6/8.11.6) with ESMTP id g4MMMsH07508; Wed, 22 May 2002 18:22:54 -0400 Mime-Version: 1.0 X-Sender: john@mail.cdtmail.org Message-Id: In-Reply-To: <20020522131252.U16765@www.markbaker.ca> References: <3CE70770.7060500@mhof.com> <20020522093726.O16765@www.markbaker.ca> <20020522091825.69deaaa8.mrose@dbc.mtview.ca.us> <20020522131252.U16765@www.markbaker.ca> Date: Wed, 22 May 2002 18:22:52 -0400 To: Mark Baker From: John Morris Subject: Re: Callout (was Re: WG Last Call: draft-ietf-opes-architecture-00 Cc: Marshall Rose , ietf-openproxy@imc.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 1:12 PM -0400 5/22/02, Mark Baker wrote: >On Wed, May 22, 2002 at 09:18:25AM -0700, Marshall Rose wrote: > > mark - the reason that callout is in the architecture is because >we standardize a callout protocol. if we didn't care to have the >protocol standardized, then you and i are in agreement; however, >everyone i talk to in this space tells me that a standardized >callout protocol is a real-world requirement. so, there you have it. > >Thanks, that explains why it's in the document. I just don't get why >people think one is needed. > >If it's "obvious" to so many here, then I'll just save my breath for the >callout requirements gathering phase. > >MB >-- I would add an additional reason to address callouts. As I read it, the potential privacy implications of the use of callouts was one of the concerns addressed by the IAB. When the IAB wrote as a consideration: > (5.1) Privacy: The overall OPES framework must provide for mechanisms > for end users to determine the privacy policies of OPES > intermediaries. I think this means that the end user must be able to evaluate the privacy policies of any callout entity as well as as any OPES dispatcher. Thus, the OPES architecture needs to anticipate the existance of OPES callouts. John -------------------------------------------------- John Morris // CDT // http://www.cdt.org/standards -------------------------------------------------- From owner-ietf-openproxy@mail.imc.org Wed May 22 20:07:41 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09277 for ; Wed, 22 May 2002 20:07:41 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4MNi9i02506 for ietf-openproxy-bks; Wed, 22 May 2002 16:44:09 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MNi9L02502 for ; Wed, 22 May 2002 16:44:09 -0700 (PDT) Received: from GK-VAIO.ninebynine.org (dyn234-40.sftm-212-159.plus.net [212.159.40.234]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g4N7LX414382; Thu, 23 May 2002 00:21:34 -0700 Message-Id: <5.1.0.14.2.20020523005118.03c115a0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 23 May 2002 00:55:03 +0100 To: "Abbie Barbir" From: Graham Klyne Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing Cc: OPES Group In-Reply-To: <87609AFB433BD5118D5E0002A52CD754023F6D6A@zcard0k6.ca.norte l.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: 1-5 seem to broadly reflect my stated views. Regarding 6: contrary to the wording below, I now see, and agree, the desirability of a standard callout protocol, namely multivendor interworking between data dispatchers and service processes. #g -- At 09:58 AM 5/22/02 -0400, Abbie Barbir wrote: >Graham and all, > >I am providing a summary of the current position and feedback. >This will be points that we try to get agreement on. > >1. endpoint-user must be able to access OPES diagnostic > information using legacy s/w. >2. have no problem with protocol extensions being available to > facilitate access to the information. >3. not opposed to using In-band information even if it means extensions >4. keeping a log could be quite sufficient >5. having out of band access from one endpoint or the other is a far better > outcome than having none >6. (From mark baker) No need to standardize on a callout protocol. > >Here I propose that we start a new thread where each point is discussed >and get solved. > >abbie ------------------- Graham Klyne From owner-ietf-openproxy@mail.imc.org Wed May 22 20:48:20 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10739 for ; Wed, 22 May 2002 20:48:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4N0MiX03258 for ietf-openproxy-bks; Wed, 22 May 2002 17:22:44 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N0MgL03254 for ; Wed, 22 May 2002 17:22:42 -0700 (PDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4N0MbM08924; Wed, 22 May 2002 19:22:38 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 17:22:17 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C027BBD38@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Ian Cooper , OPES Group Cc: Oskar Batuner , Markus Hofmann Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Wed, 22 May 2002 17:22:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201EF.F5C00E72" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C201EF.F5C00E72 Content-Type: text/plain; charset="iso-8859-1" some comments inline..which might have already being discussed, but I'm starting to read the thread now... >-----Original Message----- >From: Ian Cooper [mailto:ian@the-coopers.org] >Sent: Monday, May 20, 2002 12:13 PM >To: OPES Group >Cc: Oskar Batuner; Markus Hofmann >Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 > > > >--On Monday, May 20, 2002 13:28 -0400 Oskar Batuner > >wrote: > >> >> Some notes on the OPES Architecture draft.. >> >>> 1. Introduction >> >>> In some cases it may be impossible to offer the >customization service >>> at either the provider or the consumer applications. In this case, >>> one or more additional application entities may participate in the >>> data stream service. >> >> This term - "impossible" - may leave an impression that this is the >> only, or at least main justification to use OPES. This does not look >> right. The only scenario (from existing draft-beck-opes-esfnep) where >> OPES is the only way to implement the service is request filtering >> for hand-held devices, in all other cases service can be implemented >> either at the server side or at the client side, or both. > >In fairness I think it's fair to say that there are cases where it's >impossible to insert localised advertisements without >something like an >OPES intermediary. concrete examples would be on the scenarios document. I'm not sure an architecture document should have examples. Maybe the best way is just to reference the scenarios document. > >> Still use of OPES may be beneficial, so I'd suggest ether to use >> a different wording, like: >> >> "In some cases in may be beneficial to provide a >customization service >> at network location instead of deploying it at either the provider or >> the consumer host. For certain services performed on end-user behalf >> this may be the only option of service deployment". > >That seems limiting and doesn't seem (to me) to convey the >aspect that some >content can only be produced with the cooperation of (possibly >non-exportable) information available to the ISP/IAP. The >problem is that >without concrete examples (which are frequently limiting in >themselves) it >becomes very difficult to write introductory text like this. >The existing >text (plus the introductory paragraph you omitted) seems, to >me, a better >approach to articulate the problem. > >>> 2.1 OPES Entities >> >> The usage of terms "OPES service application" and "data dispatcher" >> is not always consistent and sometimes even confusing. According to >> the definition in 2.1 service application is invoked by data >dispatcher. >> If this is always a case (an according to the definition it is so) >> Figure 1 should look like this: >> >> >> +----------------+ >> | OPES service | >> | application | >> +----------------+ >> |data dispatcher | >> +----------------+ >> | | >> | HTTP | >> | | >> +----------------+ >> | TCP/IP | >> +----------------+ >> | ... | >> +----------------+ >> >> Figure 1: An OPES protocol stack I have a problem with this picture since the OPES Service application and data dispatcher are not in the "protocol stack per se". They do talk to each other internally but not with outside entities, as shown in the proposed diagran below. Maybe what we need is to replace the word stack by "logical implementation" or something the like. >> >> >> It also may have sense to point out explicitly that OPES application >> may be executed either on the same box (or even in the same >application >> environment) with the dispatcher or on different box through OCP. >> This was on of important features in initially discussed >architecture, >> there were even terms like "proxylet" flying in the air. > >Agree > >> I thing it has sense to emphasize this possibility and to provide a >> figure like this: >> >> >> +--------------------------+ >> | +----------+ | >> | | OPES | | >> | | service | | >> | | appl | | >> | +----------+ | +----------------+ >> | || | | | >> | +----------------------+ | | +--------+ | >> | | data dispatcher | | | | Service| | >> | +----------------------+ | | | App2 | | >> | | HTTP | OCP | | | +--------+ | >> | +------------| |===(2)====| OCP | | >> | | TCP/IP | | | | +--------+ | >> | +------------+---------+ | | | >> +-------||-----------------+ | callout server | >> || +----------------+ >> ...........(1) >> >> This is a kind of combination of figures 1, 3 and 4. > >I like this diagram > ------_=_NextPart_001_01C201EF.F5C00E72 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG Last Call: draft-ietf-opes-architecture-00

some comments inline..which might have already being = discussed, but I'm starting to read the thread now...

>-----Original Message-----
>From: Ian Cooper [mailto:ian@the-coopers.org]
>Sent: Monday, May 20, 2002 12:13 PM
>To: OPES Group
>Cc: Oskar Batuner; Markus Hofmann
>Subject: RE: WG Last Call: = draft-ietf-opes-architecture-00
>
>
>
>--On Monday, May 20, 2002 13:28 -0400 Oskar = Batuner
><batuner@attbi.com>
>wrote:
>
>>
>> Some notes on the OPES Architecture = draft..
>>
>>> 1. Introduction
>>
>>> In some cases it may be impossible to = offer the
>customization service
>>> at either the provider or the consumer = applications.  In this case,
>>> one or more additional application = entities may participate in the
>>> data stream service.
>>
>> This term - "impossible" - may = leave an impression that this is the
>> only, or at least main justification to use = OPES. This does not look
>> right. The only scenario (from existing = draft-beck-opes-esfnep) where
>> OPES is the only way to implement the = service is request filtering
>> for hand-held devices, in all other cases = service can be implemented
>> either at the server side or at the client = side, or both.
>
>In fairness I think it's fair to say that there = are cases where it's
>impossible to insert localised advertisements = without
>something like an
>OPES intermediary.

concrete examples would be on the scenarios document. = I'm not sure an architecture document should have examples. Maybe the = best way is just to reference the scenarios document.


>
>> Still use of OPES may be beneficial, so I'd = suggest ether to use
>> a different wording, like:
>>
>> "In some cases in may be beneficial to = provide a
>customization service
>> at network location instead of deploying it = at either the provider or
>> the consumer host. For certain services = performed on end-user behalf
>> this may be the only option of service = deployment".
>
>That seems limiting and doesn't seem (to me) to = convey the
>aspect that some
>content can only be produced with the = cooperation of (possibly
>non-exportable) information available to the = ISP/IAP.  The
>problem is that
>without concrete examples (which are frequently = limiting in
>themselves) it
>becomes very difficult to write introductory = text like this. 
>The existing
>text (plus the introductory paragraph you = omitted) seems, to
>me, a better
>approach to articulate the problem.
>
>>> 2.1 OPES Entities
>>
>> The usage of terms "OPES service = application" and "data dispatcher"
>> is not always consistent and sometimes even = confusing. According to
>> the definition in 2.1 service application = is invoked by data
>dispatcher.
>> If this is always a case (an according to = the definition it is so)
>> Figure 1 should look like this:
>>
>>
>>         &= nbsp;           &= nbsp;        = +----------------+
>>         &= nbsp;           &= nbsp;        | OPES = service   |
>>         &= nbsp;           &= nbsp;        | = application    |
>>         &= nbsp;           &= nbsp;        = +----------------+
>>         &= nbsp;           &= nbsp;        |data dispatcher = |
>>         &= nbsp;           &= nbsp;        = +----------------+
>>         &= nbsp;           &= nbsp;        = |            = ;    |
>>         &= nbsp;           &= nbsp;        |    = HTTP        |
>>         &= nbsp;           &= nbsp;        = |            = ;    |
>>         &= nbsp;           &= nbsp;        = +----------------+
>>         &= nbsp;           &= nbsp;        |   TCP/IP&nbs= p;      |
>>         &= nbsp;           &= nbsp;        = +----------------+
>>         &= nbsp;           &= nbsp;        = |     ...        = |
>>         &= nbsp;           &= nbsp;        = +----------------+
>>
>>         &= nbsp;           = Figure 1: An OPES protocol stack


I have a problem with this picture since the OPES = Service application and data dispatcher are not in the "protocol = stack per se". They do talk to each other internally but not with = outside entities, as shown in the proposed diagran below. Maybe what we = need is to replace the word stack by "logical implementation" = or something the like.

>>
>>
>> It also may have sense to point out = explicitly that OPES application
>> may be executed either on the same box (or = even in the same
>application
>> environment) with the dispatcher or on = different box through OCP.
>> This was on of important features in = initially discussed
>architecture,
>> there were even terms like = "proxylet" flying in the air.
>
>Agree
>
>> I thing it has sense to emphasize this = possibility and to provide a
>> figure like this:
>>
>>
>>       = +--------------------------+
>>       | = +----------+          =    |
>>       | = |   OPES   = |            = ; |
>>       | = |  service = |            = ; |
>>       | = |   appl   = |            = ; |
>>       | = +----------+          =    |      +----------------+
>>       = |     = ||           &nbs= p;       |      = |            = ;    |
>>       | = +----------------------+ |      | = +--------+     |
>>       | = |     data dispatcher  | = |      | | Service|     = |
>>       | = +----------------------+ |      | |  = App2  |     |
>>       | = |   HTTP     | = OCP     | |      | = +--------+     |
>>       | = +------------|         = |=3D=3D=3D(2)=3D=3D=3D=3D|  OCP   = |     |
>>       | = |   TCP/IP   = |         | = |      | +--------+     = |
>>       | = +------------+---------+ |      = |            = ;    |
>>       = +-------||-----------------+      | callout = server |
>>         &= nbsp;     = ||           &nbs= p;            = +----------------+
>>         &= nbsp; ...........(1)
>>
>> This is a kind of combination of figures 1, = 3 and 4.
>
>I like this diagram
>

------_=_NextPart_001_01C201EF.F5C00E72-- From owner-ietf-openproxy@mail.imc.org Wed May 22 20:57:37 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11108 for ; Wed, 22 May 2002 20:57:37 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4N0VbR03497 for ietf-openproxy-bks; Wed, 22 May 2002 17:31:37 -0700 (PDT) Received: from zsc3s004.us.nortel.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N0VZL03493 for ; Wed, 22 May 2002 17:31:35 -0700 (PDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4N0V0520680; Wed, 22 May 2002 17:31:00 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 17:30:37 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C027BBD41@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Graham Klyne , Marshall Rose Cc: ietf-openproxy@imc.org Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Wed, 22 May 2002 17:31:07 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201F1.20F4CB18" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C201F1.20F4CB18 Content-Type: text/plain; charset="iso-8859-1" more comments inline.. >-----Original Message----- >From: Graham Klyne [mailto:GK-lists@ninebynine.org] >Sent: Monday, May 20, 2002 12:18 PM >To: Marshall Rose >Cc: ietf-openproxy@imc.org >Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 > > ........ > >Well... does it need to be "transparent"? > >When I wrote my comments, I was thinking that there might be >HTTP access to >the audit trail (with appropriate authentication) from the >client system in >whose admin domain the OPES intermediary was operating. That >presumes the >client knows what URL to use to query the audit, so its not >transparent (in >the sense of being automatically available), but I think that is >information that could easily be made available. > >(That was assuming an OPES intermediary on an HTTP flow; for (say) an >email flow, some variant of the mechanisms suggested by >multipart/external >might be used. The key issue here is that an end user with standard >off-the-shelf client software can access the diagnostic information, >without dependence on protocol extensions.) Taking the "Internet Scale" discussion of the table, I kind of agree with that. We had several discussions about this. My concern with headers extensions is that we would need to do that for every single protocol that OPES might use, which might slow down OPES adoption. Not only from an implementation perspective but also that all these extensions would need to go throught the IETF ptocess, sometimes spanning more than one working group. But the crux of the question then is, as you put it, how to convey this information to end user in a way that with off the shelf software he can check the audit trail. With HTTP would that be a Redirect? With email, would that be a mime/multipart as you put it? And how about RTP, FTP, etc? > > ------_=_NextPart_001_01C201F1.20F4CB18 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG Last Call: draft-ietf-opes-architecture-00

more comments inline..

>-----Original Message-----
>From: Graham Klyne [mailto:GK-lists@ninebynine.org]
>Sent: Monday, May 20, 2002 12:18 PM
>To: Marshall Rose
>Cc: ietf-openproxy@imc.org
>Subject: Re: WG Last Call: = draft-ietf-opes-architecture-00
>
>

<snip>....<snip>....<snip>

>
>Well... does it need to be = "transparent"?
>
>When I wrote my comments, I was thinking that = there might be
>HTTP access to
>the audit trail (with appropriate = authentication) from the
>client system in
>whose admin domain the OPES intermediary was = operating.  That
>presumes the
>client knows what URL to use to query the audit, = so its not
>transparent (in
>the sense of being automatically available), but = I think that is
>information that could easily be made = available.
>
>(That was assuming an OPES intermediary on an = HTTP flow;  for (say) an
>email flow, some variant of the mechanisms = suggested by
>multipart/external
>might be used.  The key issue here is that = an end user with standard
>off-the-shelf client software can access the = diagnostic information,
>without dependence on protocol = extensions.)

Taking the "Internet Scale" discussion of = the table, I kind of agree with that. We had several discussions about = this. My concern with headers extensions is that we would need to do = that for every single protocol that OPES might use, which might slow = down OPES adoption. Not only from an implementation perspective but = also that all these extensions would need to go throught the IETF = ptocess, sometimes spanning more than one working group.

But the crux of the question then is, as you put it, = how to convey this information to end user in a way that with off the = shelf software he can check the audit trail. With HTTP would that be a = Redirect? With email, would that be a mime/multipart as you put it? And = how about RTP, FTP, etc?

>
>

------_=_NextPart_001_01C201F1.20F4CB18-- From owner-ietf-openproxy@mail.imc.org Wed May 22 21:13:12 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11800 for ; Wed, 22 May 2002 21:13:12 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4N0jGm03755 for ietf-openproxy-bks; Wed, 22 May 2002 17:45:16 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N0jFL03751 for ; Wed, 22 May 2002 17:45:15 -0700 (PDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4N0jJM09714; Wed, 22 May 2002 19:45:20 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 17:44:59 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C027BBD51@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: Markus Hofmann , Ian Cooper Cc: OPES Group Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Wed, 22 May 2002 17:45:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201F3.2294A3C4" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C201F3.2294A3C4 Content-Type: text/plain; charset="iso-8859-1" more comments... >-----Original Message----- >From: Markus Hofmann [mailto:markus@mhof.com] >Sent: Monday, May 20, 2002 10:24 PM >To: Ian Cooper >Cc: OPES Group >Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 > > > >Ian Cooper wrote: > >> Speaking of Figure 3, it's not immediately clear what's >going on, making >> the appearance of the data dispatcher box different to the callout >> servers might help. > >Hm, when looking at Figure 3 i nthe draft... I would assume the term >"callout server" refers to the box itself, thus being the >correspondence to "data processor", rather than being part of the >protocol stack as shown in Figure 3. It seems to me that something >like that would be more accurate. > > > data callout callout callout > processor server server server > > +----------+ +---------+ +---------+ +---------+ > | data | | service | | servive | | service | > |dispatcher| | applic. | | applic. | | applic. | > +----------+ +---------+ +---------+ +---------+ > | | | | | | | | > | OCP | | OCP | | OCP | ... | OCP | > | | | | | | | | > +----------+ +---------+ +---------+ +---------+ > | TCP/IP | | TCP/IP | | TCP/IP | | TCP/IP | > +----------+ +---------+ +---------+ +---------+ > || || || || > ||================ || ... || > || || || > ||============================== || > || || > ================================================ > > yep, the same we did for the picture. The "upper entities" are not part of the stack per se >>> The sort of design I might suggest would be that an OPES >intermediary >>> maintains an audit of services that are applied, possibly >for a limited >>> time. This audit should be accessible to affected clients >using standard >>> features of the protocol whose flow is being OPES-serviced. >> >> >> Seems reasonable, though would only work for a subset of the >protocols >> that might benefit from modifications these systems might >offer. E.g. >> if video stream is modified I'm not sure that it would be >possible to >> use the streaming delivery protocol to get acccess to the >audit trail. >> It does work for HTTP which was the primary target of this >body of work >> though. I agree with that. Keeping up state in the OPES intermidiary it might sound good on paper but I'm not sure it will scale. It would be the same thing to ask a web server to be able to read through recent log files in order to provide this information to any user real time. > >Why restrict it to the standard features of the data flow protocol? I >would assume it's possible to indicate within the OPES trace HOW an >endpoint could access such audits, potentially allowing/using other >standard protocols (e.g. HTTP, FTP, or whatever). Architectural wise, >this should be covered by the current draft... > So, I kind of agree on what was proposed of conveying this info through alrady avalable means, but keeping state is touchy. Just like email, you get all the headers, now if the SMTP servers on the way, keep ot not that information is up to the administrator. -Reinaldo ------_=_NextPart_001_01C201F3.2294A3C4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG Last Call: draft-ietf-opes-architecture-00

more comments...

>-----Original Message-----
>From: Markus Hofmann [mailto:markus@mhof.com]
>Sent: Monday, May 20, 2002 10:24 PM
>To: Ian Cooper
>Cc: OPES Group
>Subject: Re: WG Last Call: = draft-ietf-opes-architecture-00
>
>
>
>Ian Cooper wrote:
>
>> Speaking of Figure 3, it's not immediately = clear what's
>going on, making
>> the appearance of the data dispatcher box = different to the callout
>> servers might help.
>
>Hm, when looking at Figure 3 i nthe draft... I = would assume the term
>"callout server" refers to the box = itself, thus being the
>correspondence to "data processor", = rather than being part of the
>protocol stack as shown in Figure 3. It seems to = me that something
>like that would be more accurate.
>
>
>          = ;  data         = callout       = callout        callout
>          = processor      = server        = server         server
>
>         = +----------+  +---------+   = +---------+     +---------+
>         = |   data   |  | service |   | = servive |     | service |
>         = |dispatcher|  | applic. |   | applic. = |     | applic. |
>         = +----------+  +---------+   = +---------+     +---------+
>         = |          |  = |         |   = |         = |     = |         |
>         = |   OCP    |  |   = OCP   |   |   OCP   | ... = |   OCP   |
>         = |          |  = |         |   = |         = |     = |         |
>         = +----------+  +---------+   = +---------+     +---------+
>         = |  TCP/IP  |  |  TCP/IP |   |  = TCP/IP |     |  TCP/IP |
>         = +----------+  +---------+   = +---------+     +---------+
>          = ;  = ||           &nbs= p;  = ||            = ||           &nbs= p;  ||
>          = ;  = ||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D   &nbs= p;        ||     = ...      ||
>          = ;  = ||           &nbs= p;           &nbs= p;    = ||           &nbs= p;  ||
>          = ;  = ||=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D         =      ||
>          = ;  = ||           &nbs= p;           &nbs= p;           &nbs= p;        ||
>          = ;  = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>
>

yep, the same we did for the picture. The "upper = entities" are not part of the stack per se

>>> The sort of design I might suggest would = be that an OPES
>intermediary
>>> maintains an audit of services that are = applied, possibly
>for a limited
>>> time.  This audit should be = accessible to affected clients
>using standard
>>> features of the protocol whose flow is = being OPES-serviced.
>>
>>
>> Seems reasonable, though would only work = for a subset of the
>protocols
>> that might benefit from modifications these = systems might
>offer.  E.g.
>> if video stream is modified I'm not sure = that it would be
>possible to
>> use the streaming delivery protocol to get = acccess to the
>audit trail. 
>> It does work for HTTP which was the primary = target of this
>body of work
>> though.


I agree with that. Keeping up state in the OPES = intermidiary it might sound good on paper but I'm not sure it will = scale. It would be the same thing to ask a web server to be able to = read through recent log files in order to provide this information to = any user real time.

>
>Why restrict it to the standard features of the = data flow protocol? I
>would assume it's possible to indicate within = the OPES trace HOW an
>endpoint could access such audits, potentially = allowing/using other
>standard protocols (e.g. HTTP, FTP, or = whatever). Architectural wise,
>this should be covered by the current = draft...
>

So, I kind of agree on what was proposed of conveying = this info through alrady avalable means, but keeping state is touchy. = Just like email, you get all the headers, now if the SMTP servers on = the way, keep ot not that information is up to the administrator. =

-Reinaldo

------_=_NextPart_001_01C201F3.2294A3C4-- From owner-ietf-openproxy@mail.imc.org Wed May 22 21:19:20 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA12040 for ; Wed, 22 May 2002 21:19:19 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4N0uCI03926 for ietf-openproxy-bks; Wed, 22 May 2002 17:56:12 -0700 (PDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N0uAL03922 for ; Wed, 22 May 2002 17:56:11 -0700 (PDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4N0uCM10001; Wed, 22 May 2002 19:56:13 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 22 May 2002 17:55:52 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C027BBD5D@zsc3c032.us.nortel.com> From: "Reinaldo Penno" To: "The Purple Streak (Hilarie Orman)" , OPES Group Subject: RE: WG Last Call: draft-ietf-opes-architecture-00 Date: Wed, 22 May 2002 17:56:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C201F4.A6D95868" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C201F4.A6D95868 Content-Type: text/plain; charset="iso-8859-1" yep, seems reasonable. We convey some information, but we surely cannot guarantee that we are going to keep state around waiting for some user to query it. This is definitely an implementation (or should I say administrator decision). And as Markus pointed previously, although in an email you get the headers, you surely cannot query a server in another domain/AS/whatver. -Reinaldo >-----Original Message----- >From: The Purple Streak (Hilarie Orman) [mailto:ho@alum.mit.edu] >Sent: Tuesday, May 21, 2002 12:51 PM >To: OPES Group >Subject: Re: WG Last Call: draft-ietf-opes-architecture-00 > > > >Tracing is meant for the end system user as well as qualified >administrators. Just like email headers. I run a mailing >list that uses three separate methods of including "unsubscribe" >information in every message. Still, for some combinations of >mail agent and message, the enduser cannot see the information. >They send haughty email to the list administrator complaining >about how defective the list is. OPES tracing will have similar >benefits and deficiencies in practice. The inband method means >that the user will always have information stored locally and >will always be able to show it to someone else, but there is no >way to guarantee that all users will always have enough clues to >use it. Just like anything else having to do with the Internet, >computers, or motorcycles (don't ask). > >Hilarie > > ------_=_NextPart_001_01C201F4.A6D95868 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG Last Call: draft-ietf-opes-architecture-00

yep, seems reasonable.

We convey some information, but we surely cannot = guarantee that we are going to keep state around waiting for some user = to query it. This is definitely an implementation (or should I say = administrator decision).

And as Markus pointed previously, although in an = email you get the headers, you surely cannot query a server in another = domain/AS/whatver.

-Reinaldo

>-----Original Message-----
>From: The Purple Streak (Hilarie Orman) [mailto:ho@alum.mit.edu]
>Sent: Tuesday, May 21, 2002 12:51 PM
>To: OPES Group
>Subject: Re: WG Last Call: = draft-ietf-opes-architecture-00
>
>
>
>Tracing is meant for the end system user as well = as qualified
>administrators.  Just like email = headers.  I run a mailing
>list that uses three separate methods of = including "unsubscribe"
>information in every message.  Still, for = some combinations of
>mail agent and message, the enduser cannot see = the information.
>They send haughty email to the list = administrator complaining
>about how defective the list is.  OPES = tracing will have similar
>benefits and deficiencies in practice.  The = inband method means
>that the user will always have information = stored locally and
>will always be able to show it to someone else, = but there is no
>way to guarantee that all users will always have = enough clues to
>use it.  Just like anything else having to = do with the Internet,
>computers, or motorcycles (don't ask).
>
>Hilarie
>
>

------_=_NextPart_001_01C201F4.A6D95868-- From owner-ietf-openproxy@mail.imc.org Thu May 23 11:19:03 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14318 for ; Thu, 23 May 2002 11:18:59 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NEfqY02510 for ietf-openproxy-bks; Thu, 23 May 2002 07:41:52 -0700 (PDT) Received: from esarhaddon.ability.net (esarhaddon.ability.net [216.3.3.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NEfoL02504 for ; Thu, 23 May 2002 07:41:51 -0700 (PDT) Received: from [10.0.1.20] (66.safeclick.net [63.119.245.66]) by esarhaddon.ability.net (8.11.6/8.11.6) with ESMTP id g4NEfg013406; Thu, 23 May 2002 10:41:42 -0400 Mime-Version: 1.0 X-Sender: john@mail.cdtmail.org Message-Id: In-Reply-To: <87609AFB433BD5118D5E0002A52CD754023F6D6A@zcard0k6.ca.nortel.com> References: <87609AFB433BD5118D5E0002A52CD754023F6D6A@zcard0k6.ca.nortel.com> Date: Thu, 23 May 2002 10:41:41 -0400 To: "Abbie Barbir" From: John Morris Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing Cc: OPES Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 9:58 AM -0400 5/22/02, Abbie Barbir wrote: >Graham and all, > >I am providing a summary of the current position and feedback. >This will be points that we try to get agreement on. > >1. endpoint-user must be able to access OPES diagnostic > information using legacy s/w. >2. have no problem with protocol extensions being available to > facilitate access to the information. >3. not opposed to using In-band information even if it means extensions >4. keeping a log could be quite sufficient >5. having out of band access from one endpoint or the other is a far better > outcome than having none >6. (From mark baker) No need to standardize on a callout protocol. > >Here I propose that we start a new thread where each point is >discussed and get solved. > >abbie Unless I've missed something (which is certainly possible), the draft may want to suggest how the OPES architecture will respond to the following IAB 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. The response may be that this consideration will be addressed in a requirements document -- for example by requiring the initial request from a client to a content provider to deliver a header flagging the client-centric OPES action to be performed. Although such a header may not have major "architectural" implications, in explaining and understanding an OPES flow it seems appropriate to state that there should be notice to the "other" primary party (i.e., the party not initially requesting the OPES transformation) of the planned OPES transformation or callout PRIOR to the transformation or callout actually happening. A small and unrelated point about 3.4 of the draft: >3.4 Privacy > > Some data from data consumers is considered "private" or "sensitive", > and OPES processors must both advise the primary parties of the their > privacy policy and respect the policies of the primary parties. The > privacy information must be conveyed on a per-flow basis. Especially as peer-to-peer technologies become more widely used, there will likely be times that data providers also have private or sensitive data. I suggest changing "data consumers is" to "data consumers or providers may be." John ---------------------------------------- John B. Morris, Jr. Director, Internet Standards, Technology & Policy Project Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 (202) 637-9800 (202) 637-0968 fax jmorris@cdt.org http://www.cdt.org ---------------------------------------- From owner-ietf-openproxy@mail.imc.org Thu May 23 12:41:21 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17551 for ; Thu, 23 May 2002 12:41:20 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4NG9P306951 for ietf-openproxy-bks; Thu, 23 May 2002 09:09:25 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NG9NL06947 for ; Thu, 23 May 2002 09:09:23 -0700 (PDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NG9GEF024195; Thu, 23 May 2002 12:09:20 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NG95k40006; Thu, 23 May 2002 12:09:05 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id MAA28094; Thu, 23 May 2002 12:09:02 -0400 (EDT) Message-ID: <3CED141E.2010500@mhof.com> Date: Thu, 23 May 2002 12:09:02 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Morris CC: OPES Group Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing References: <87609AFB433BD5118D5E0002A52CD754023F6D6A@zcard0k6.ca.nortel.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit John Morris wrote: > Unless I've missed something (which is certainly possible), the draft > may want to suggest how the OPES architecture will respond to the > following IAB 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. Section 2.6 of the draft should extend to include some form of notification of the OPES action to the originating party *when requested* by the originating party. Implicit notification mechanisms would not scale, but a content provider should be able to explicitly request notification in some form. >> 3.4 Privacy >> >> Some data from data consumers is considered "private" or "sensitive", >> and OPES processors must both advise the primary parties of the their >> privacy policy and respect the policies of the primary parties. The >> privacy information must be conveyed on a per-flow basis. > > > Especially as peer-to-peer technologies become more widely used, there > will likely be times that data providers also have private or sensitive > data. I suggest changing "data consumers is" to "data consumers or > providers may be." I would agree with that change. -Markus From owner-ietf-openproxy@mail.imc.org Thu May 23 13:12:29 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18641 for ; Thu, 23 May 2002 13:12:28 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NGlQ707727 for ietf-openproxy-bks; Thu, 23 May 2002 09:47:26 -0700 (PDT) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NGlOL07723 for ; Thu, 23 May 2002 09:47:25 -0700 (PDT) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id MAA10393; Thu, 23 May 2002 12:55:49 -0400 Date: Thu, 23 May 2002 12:55:49 -0400 From: Mark Baker To: Graham Klyne Cc: Abbie Barbir , OPES Group Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing Message-ID: <20020523125549.R16765@www.markbaker.ca> References: <87609AFB433BD5118D5E0002A52CD754023F6D6A@zcard0k6.ca.norte l.com> <5.1.0.14.2.20020523005118.03c115a0@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <5.1.0.14.2.20020523005118.03c115a0@joy.songbird.com>; from GK-lists@ninebynine.org on Thu, May 23, 2002 at 12:55:03AM +0100 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, May 23, 2002 at 12:55:03AM +0100, Graham Klyne wrote: > Regarding 6: contrary to the wording below, I now see, and agree, the > desirability of a standard callout protocol, namely multivendor > interworking between data dispatchers and service processes. I agree that multivendor internetworking is critical. I just believe that it should be achieved by agreeing on the "flow" protocols. For example, by building a language translator as an HTTP proxy. MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@acm.org http://www.markbaker.ca http://www.idokorro.com From owner-ietf-openproxy@mail.imc.org Thu May 23 14:05:01 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20774 for ; Thu, 23 May 2002 14:05:00 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NHamt09155 for ietf-openproxy-bks; Thu, 23 May 2002 10:36:48 -0700 (PDT) Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NHakL09150 for ; Thu, 23 May 2002 10:36:46 -0700 (PDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4NHbcUL054155; Thu, 23 May 2002 13:37:38 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4NHadk49772; Thu, 23 May 2002 13:36:39 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA03082; Thu, 23 May 2002 13:36:36 -0400 (EDT) Message-ID: <3CED28A4.10508@mhof.com> Date: Thu, 23 May 2002 13:36:36 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Baker CC: OPES Group Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing References: <87609AFB433BD5118D5E0002A52CD754023F6D6A@zcard0k6.ca.norte l.com> <5.1.0.14.2.20020523005118.03c115a0@joy.songbird.com> <20020523125549.R16765@www.markbaker.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Mark Baker wrote: > I agree that multivendor internetworking is critical. I just believe > that it should be achieved by agreeing on the "flow" protocols. For > example, by building a language translator as an HTTP proxy. This implies that requests AND responses will travel through the "box" the language translator is running on, which is not really required since it cares only about the responses. With a callout protocol, you vector out only the responses, letting the request go through directly. -Markus From owner-ietf-openproxy@mail.imc.org Thu May 23 14:08:56 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21044 for ; Thu, 23 May 2002 14:08:56 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NHiE209299 for ietf-openproxy-bks; Thu, 23 May 2002 10:44:14 -0700 (PDT) Received: from mgr1.xmission.com (mgr1.xmission.com [198.60.22.201]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NHiDL09295 for ; Thu, 23 May 2002 10:44:13 -0700 (PDT) Received: from mail by mgr1.xmission.com with spam-scanned (Exim 3.35 #1) id 17AwdL-0004Gd-00 for ietf-openproxy@imc.org; Thu, 23 May 2002 11:44:15 -0600 Received: from [198.60.22.22] (helo=mail.xmission.com) by mgr1.xmission.com with esmtp (Exim 3.35 #1) id 17AwdL-0004Ga-00 for ietf-openproxy@imc.org; Thu, 23 May 2002 11:44:15 -0600 Received: from [166.70.13.243] (helo=alum.mit.edu) by mail.xmission.com with esmtp (Exim 3.22 #1) id 17AwdK-0006Lo-00 for ietf-openproxy@imc.org; Thu, 23 May 2002 11:44:14 -0600 Message-ID: <3CED2995.5090708@alum.mit.edu> Date: Thu, 23 May 2002 11:40:37 -0600 From: "The Purple Streak (Hilarie Orman)" User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: OPES Group Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing References: <87609AFB433BD5118D5E0002A52CD754023F6D6A@zcard0k6.ca.nortel.com> <3CED141E.2010500@mhof.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=8.0 tests= version=2.20 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit I can see this as being an option for debugging, but making it mandantory for use in forensic analysis of "inappropriateness" by end users is simply outside the scope of protocol development. Hilarie Markus Hofmann wrote: > > John Morris wrote: > >> Unless I've missed something (which is certainly possible), the draft >> may want to suggest how the OPES architecture will respond to the >> following IAB 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. > > > Section 2.6 of the draft should extend to include some form of > notification of the OPES action to the originating party *when > requested* by the originating party. Implicit notification mechanisms > would not scale, but a content provider should be able to explicitly > request notification in some form. > From owner-ietf-openproxy@mail.imc.org Thu May 23 14:26:12 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21833 for ; Thu, 23 May 2002 14:26:11 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NHxUg09691 for ietf-openproxy-bks; Thu, 23 May 2002 10:59:30 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NHxTL09687 for ; Thu, 23 May 2002 10:59:29 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4NHxO506988 for ; Thu, 23 May 2002 13:59:24 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 23 May 2002 13:59:29 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD7540244854B@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: OPES Group Subject: FW: [OPES architecture] Standard Callout Protocol Date: Thu, 23 May 2002 13:59:46 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20283.9F8757F6" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C20283.9F8757F6 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Joseph Hui [mailto:Joseph.Hui@exodus.net] > Sent: Wednesday, May 22, 2002 9:44 PM > To: Graham Klyne; Barbir, Abbie [CAR:1A00:EXCH] > Cc: OPES Group > Subject: [OPES architecture] Standard Callout Protocol > > > OPES was widely (and is hopefully no longer?) perceived as > a precarious proposition due to the intermediaries between > two endpoints. Throwing callout semantics in the mix further > exacerbated the trepidation. A standardized callout protocol, > or a standardized callout interface to some protocols, will > IMV go a long way towards assuring potential users of OPES's > viability in terms of making callouts less untenable from > a security perspective. It's very hard, if not impossible, > to secure the unexpected; and non-standardization offers > plenty of surprises. > > Joe Hui > Exodus, a Cable & Wireless service > ========================================================= > > > -----Original Message----- > > From: Graham Klyne [mailto:GK-lists@ninebynine.org] > > Sent: Wednesday, May 22, 2002 4:55 PM > > To: Abbie Barbir > > Cc: OPES Group > > Subject: Re: [ OPES architecture] Final Points of > Discussion: Tracing > > > > > > > > 1-5 seem to broadly reflect my stated views. > > > > Regarding 6: contrary to the wording below, I now see, and > > agree, the > > desirability of a standard callout protocol, namely multivendor > > interworking between data dispatchers and service processes. > > > > #g > > -- > > > > At 09:58 AM 5/22/02 -0400, Abbie Barbir wrote: > > > > >Graham and all, > > > > > >I am providing a summary of the current position and feedback. > > >This will be points that we try to get agreement on. > > > > > >1. endpoint-user must be able to access OPES diagnostic > > > information using legacy s/w. > > >2. have no problem with protocol extensions being available to > > > facilitate access to the information. > > >3. not opposed to using In-band information even if it means > > extensions > > >4. keeping a log could be quite sufficient > > >5. having out of band access from one endpoint or the other > > is a far better > > > outcome than having none > > >6. (From mark baker) No need to standardize on a callout protocol. > > > > > >Here I propose that we start a new thread where each point > > is discussed > > >and get solved. > > > > > >abbie > > > > ------------------- > > Graham Klyne > > > > > > > ------_=_NextPart_001_01C20283.9F8757F6 Content-Type: text/html; charset="iso-8859-1" FW: [OPES architecture] Standard Callout Protocol

> -----Original Message-----
> From: Joseph Hui [mailto:Joseph.Hui@exodus.net]
> Sent: Wednesday, May 22, 2002 9:44 PM
> To: Graham Klyne; Barbir, Abbie [CAR:1A00:EXCH]
> Cc: OPES Group
> Subject: [OPES architecture] Standard Callout Protocol
>
>
> OPES was widely (and is hopefully no longer?) perceived as
> a precarious proposition due to the intermediaries between
> two endpoints.  Throwing callout semantics in the mix further
> exacerbated the trepidation.  A standardized callout protocol,
> or a standardized callout interface to some protocols, will
> IMV go a long way towards assuring potential users of OPES's
> viability in terms of making callouts less untenable from
> a security perspective.  It's very hard, if not impossible,
> to secure the unexpected; and non-standardization offers
> plenty of surprises.
>
> Joe Hui
> Exodus, a Cable & Wireless service
> =========================================================
>
> > -----Original Message-----
> > From: Graham Klyne [mailto:GK-lists@ninebynine.org]
> > Sent: Wednesday, May 22, 2002 4:55 PM
> > To: Abbie Barbir
> > Cc: OPES Group
> > Subject: Re: [ OPES architecture] Final Points of
> Discussion: Tracing
> >
> >
> >
> > 1-5 seem to broadly reflect my stated views.
> >
> > Regarding 6:  contrary to the wording below, I now see, and
> > agree, the
> > desirability of a standard callout protocol, namely multivendor
> > interworking between data dispatchers and service processes.
> >
> > #g
> > --
> >
> > At 09:58 AM 5/22/02 -0400, Abbie Barbir wrote:
> >
> > >Graham and all,
> > >
> > >I am providing a summary of the current position and feedback.
> > >This will be points that we try to get agreement on.
> > >
> > >1. endpoint-user must be able to access OPES diagnostic
> > >    information using legacy s/w.
> > >2. have no problem with protocol extensions being available to
> > >    facilitate access to the information.
> > >3. not opposed to using In-band information even if it means
> > extensions
> > >4. keeping a log could be quite sufficient
> > >5. having out of band access from one endpoint or the other
> > is a far better
> > >    outcome than having none
> > >6. (From mark baker) No need to standardize on a callout protocol.
> > >
> > >Here I propose that we start a new thread where each point
> > is discussed
> > >and get solved.
> > >
> > >abbie
> >
> > -------------------
> > Graham Klyne
> > <GK@NineByNine.org>
> >
> >
>

------_=_NextPart_001_01C20283.9F8757F6-- From owner-ietf-openproxy@mail.imc.org Thu May 23 14:27:13 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21913 for ; Thu, 23 May 2002 14:27:13 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4NI2It09782 for ietf-openproxy-bks; Thu, 23 May 2002 11:02:18 -0700 (PDT) Received: from scl8owa01.int.exodus.net ([66.35.230.241]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NI2FL09778 for ; Thu, 23 May 2002 11:02:17 -0700 (PDT) Received: from SJDCEX01.int.exodus.net ([165.193.27.80]) by scl8owa01.int.exodus.net with Microsoft SMTPSVC(5.0.2195.4905); Thu, 23 May 2002 11:02:47 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: Mail Check. Please ignore Date: Thu, 23 May 2002 11:02:46 -0700 Message-ID: <45258A4365C6B24A9832BFE224837D5523BB87@SJDCEX01.int.exodus.net> Thread-Topic: Mail Check. Please ignore Thread-Index: AcICg/jmffY8SJFrQLSFxea6vA9o7A== From: "Joseph Hui" To: X-OriginalArrivalTime: 23 May 2002 18:02:47.0748 (UTC) FILETIME=[0BD8A040:01C20284] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NI2HL09779 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit From owner-ietf-openproxy@mail.imc.org Thu May 23 14:57:04 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23030 for ; Thu, 23 May 2002 14:57:04 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NIVkZ10600 for ietf-openproxy-bks; Thu, 23 May 2002 11:31:46 -0700 (PDT) Received: from esarhaddon.ability.net (esarhaddon.ability.net [216.3.3.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIVjL10594 for ; Thu, 23 May 2002 11:31:45 -0700 (PDT) Received: from [10.0.1.20] (66.safeclick.net [63.119.245.66]) by esarhaddon.ability.net (8.11.6/8.11.6) with ESMTP id g4NIVj030419; Thu, 23 May 2002 14:31:46 -0400 Mime-Version: 1.0 X-Sender: john@mail.cdtmail.org Message-Id: In-Reply-To: <3CED2995.5090708@alum.mit.edu> References: <87609AFB433BD5118D5E0002A52CD754023F6D6A@zcard0k6.ca.nortel.com> <3CED141E.2010500@mhof.com> <3CED2995.5090708@alum.mit.edu> Date: Thu, 23 May 2002 14:31:44 -0400 To: "The Purple Streak (Hilarie Orman)" From: John Morris Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing Cc: OPES Group Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At least some content providers are going to want this capability for reasons other than an after-the-fact forensic analysis. Hypothetically, a big content site that offers both (a) free web based content, AND (b) a fee-based option to get the same content in a low-bandwidth wireless-friendly format, might want to block an end user from getting a third party OPES wireless-reformatter to make the conversion. Even though I personally am not thrilled about that hypothetical situation, I think it is very plausible, and one that should concern OPES intermediaries. A site could easily, in its terms of service or other clipwrap agreement, limit a user's license to view content to only a single format. At least arguably, if an OPES intermediary then transforms the content into a different format, the site might have a claim against the intermediary. Stated more generally, I can easily see situations in which an OPES intermediary would want to (or would be required to) have the abililty to allow either primary party to veto a planned OPES transformation. In many (but not all) cases, the end user might be able to exercise this veto simply by discarding the OPESized content. The approach that Markus suggests could give the content provider a similar veto (assuming the OPES intermediary honored the primary party's veto). To be clear, there are lots of arguments why a content provider should not be able to control how the user transforms the delivered content. But content owners are certainly going to want that capability, and the IAB discussed some reasons why that capability might in some cases be appropriate. One alternative would be for OPES dispatchers to recognize a blanket "DO NOT OPES" flag on content received from content providers. But if that is the only option a content provider has, we could see an unnecessarily high number of such flags on content (thereby marginalizing the client-centric OPES service market). John At 11:40 AM -0600 5/23/02, The Purple Streak (Hilarie Orman) wrote: >I can see this as being an option for debugging, but making it >mandantory for use in forensic analysis of "inappropriateness" >by end users is simply outside the scope of protocol development. > >Hilarie > >Markus Hofmann wrote: > >> >>John Morris wrote: >> >>>Unless I've missed something (which is certainly possible), the >>>draft may want to suggest how the OPES architecture will respond >>>to the following IAB 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. >> >> >>Section 2.6 of the draft should extend to include some form of >>notification of the OPES action to the originating party *when >>requested* by the originating party. Implicit notification >>mechanisms would not scale, but a content provider should be able >>to explicitly request notification in some form. From owner-ietf-openproxy@mail.imc.org Thu May 23 15:16:11 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23566 for ; Thu, 23 May 2002 15:16:10 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4NIpf811203 for ietf-openproxy-bks; Thu, 23 May 2002 11:51:41 -0700 (PDT) Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIpeL11199 for ; Thu, 23 May 2002 11:51:40 -0700 (PDT) Received: from oskar3 ([24.60.133.29]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020523185138.OXGE13253.rwcrmhc54.attbi.com@oskar3>; Thu, 23 May 2002 18:51:38 +0000 From: "Oskar Batuner" To: "Markus Hofmann" , "John Morris" Cc: "OPES Group" Subject: RE: [ OPES architecture] Final Points of Discussion: Tracing Date: Thu, 23 May 2002 14:51:38 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <3CED141E.2010500@mhof.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit 1. Referring to the "coloring schema" proposed in part 3.1 I'd suggest to limit notification requests by the area of the requesting party color. If the company or school administrator stops sport news and banner ads he/she has full right to do so - and has no obligation to report internal network settings nor to news media nor to advertisers. Attempt to mandate otherwise will just result in limiting OPES applicability area or in proprietary modifications that may be more dangerous to security and privacy than controlled standardized provisions. 2. "Coloring schema": I see a problem in starting authority propagation from the data consumer or initial data provider. In company/school/library case final data consumer has no authority, in CDN case authority is delegated to the CDN distribution points. I'd suggest to have a separate "start of authority" points for the color propagation. Oskar > -----Original Message----- > From: owner-ietf-openproxy@mail.imc.org > [mailto:owner-ietf-openproxy@mail.imc.org]On Behalf Of Markus Hofmann > Sent: Thursday, May 23, 2002 12:09 PM > To: John Morris > Cc: OPES Group > Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing > > > > John Morris wrote: > > > Unless I've missed something (which is certainly possible), the draft > > may want to suggest how the OPES architecture will respond to the > > following IAB 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. > > Section 2.6 of the draft should extend to include some form of > notification of the OPES action to the originating party *when > requested* by the originating party. Implicit notification mechanisms > would not scale, but a content provider should be able to explicitly > request notification in some form. > ...................... > -Markus > > From owner-ietf-openproxy@mail.imc.org Fri May 24 19:02:27 2002 Received: from above.proper.com (mail.imc.org [208.184.76.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18657 for ; Fri, 24 May 2002 19:02:26 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4OMToJ28121 for ietf-openproxy-bks; Fri, 24 May 2002 15:29:50 -0700 (PDT) Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4OMTjL28116 for ; Fri, 24 May 2002 15:29:45 -0700 (PDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4OMT8EF037524; Fri, 24 May 2002 18:29:08 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4OMT1k68386; Fri, 24 May 2002 18:29:01 -0400 (EDT) Received: from bell-labs.com ([135.5.126.183]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA20006; Fri, 24 May 2002 18:29:00 -0400 (EDT) Message-ID: <3CEEBE34.6020102@bell-labs.com> Date: Fri, 24 May 2002 17:27:00 -0500 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-US MIME-Version: 1.0 To: Internet-Drafts@ietf.org CC: Markus Hofmann , Marshall Rose , "ietf-openproxy@imc.org" Subject: draft-ietf-opes-protocol-reqs-00.txt Content-Type: multipart/mixed; boundary="------------050603090204050503070709" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This is a multi-part message in MIME format. --------------050603090204050503070709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi, Please publish the attached OPES WG draft as "draft-ietf-opes-protocol-reqs-00". --------------050603090204050503070709 Content-Type: text/plain; name="draft-ietf-opes-protocol-reqs-00.txt" Content-Disposition: inline; filename="draft-ietf-opes-protocol-reqs-00.txt" Content-Transfer-Encoding: 7bit Open Pluggable Edge Services A. Beck Internet-Draft M. Hofmann Expires: November 22, 2002 Lucent Technologies H. Orman Purple Streak Development R. Penno Nortel Networks A. Terzis Individual Consultant May 24, 2002 Requirements for OPES Callout Protocols draft-ietf-opes-protocol-reqs-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on November 22, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services [1]. The requirements are intended to help evaluating possible protocol candidates and to guide the development of such protocols. Beck, et al. Expires November 22, 2002 [Page 1] Internet-Draft Requirements for OPES Callout Protocols May 2002 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Functional Requirements . . . . . . . . . . . . . . . . . . 5 3.1 Callout Transactions . . . . . . . . . . . . . . . . . . . . 5 3.2 Callout Channels . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Reliability . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4 Congestion and Flow Control . . . . . . . . . . . . . . . . 6 3.5 Support for Keep-Alive Mechanism . . . . . . . . . . . . . . 6 3.6 Operation in NAT Environments . . . . . . . . . . . . . . . 7 3.7 Multiple Callout Servers . . . . . . . . . . . . . . . . . . 7 3.8 Multiple Data Processors . . . . . . . . . . . . . . . . . . 7 3.9 Support for Different Application Protocols . . . . . . . . 7 3.10 Capability and Parameter Negotiations . . . . . . . . . . . 7 3.11 Meta Data and Instructions . . . . . . . . . . . . . . . . . 8 3.12 Asynchronous Message Exchange . . . . . . . . . . . . . . . 9 3.13 Message Segmentation . . . . . . . . . . . . . . . . . . . . 9 4. Performance Requirements . . . . . . . . . . . . . . . . . . 11 4.1 Protocol Efficiency . . . . . . . . . . . . . . . . . . . . 11 5. Security Requirements . . . . . . . . . . . . . . . . . . . 12 5.1 Authentication, Confidentiality, and Integrity . . . . . . . 12 5.2 Hop-by-Hop Confidentiality . . . . . . . . . . . . . . . . . 12 5.3 Operation Across Un-trusted Domains . . . . . . . . . . . . 12 5.4 Privacy . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . 14 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 15 References . . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 Full Copyright Statement . . . . . . . . . . . . . . . . . . 18 Beck, et al. Expires November 22, 2002 [Page 2] Internet-Draft Requirements for OPES Callout Protocols May 2002 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2]. Beck, et al. Expires November 22, 2002 [Page 3] Internet-Draft Requirements for OPES Callout Protocols May 2002 2. Introduction The Open Pluggable Edge Services (OPES) architecture [1] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more data processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The execution of such services is governed by a set of filtering rules installed on the data processor. The rules enforcement can trigger the execution of service applications local to the data processor. Alternatively, the data processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers. As described in [1], a data processor communicates with and invokes services on a callout server by using a callout protocol. This document presents the requirements for such a protocol. The requirements in this document are divided into three categories - functional requirements, performance requirements, and security requirements. Each requirement is presented as one or more statements, followed by brief explanatory material as appropriate. Beck, et al. Expires November 22, 2002 [Page 4] Internet-Draft Requirements for OPES Callout Protocols May 2002 3. Functional Requirements 3.1 Callout Transactions The OPES callout protocol MUST enable an OPES data processor and a callout server to perform callout transactions with the purpose of exchanging partial or complete application-level protocol messages (or modifications thereof). More specifically, the callout protocol MUST enable an OPES data processor to forward a complete or partial application message to a callout server so that one or more OPES services can process the forwarded application message (or parts thereof). The result of the service operation may be a modified application message. The callout protocol MUST therefore enable the callout server to return a modified application message or the modified parts of an application message to the OPES data processor. A callout transaction is defined as a message exchange between an OPES data processor and a callout server consisting of a callout request and a callout response. Both, the callout request as well as the callout response, MAY each consist of one or more protocol messages, i.e. a series of protocol messages. Callout transactions are always initiated by a callout request from an OPES data processor and typically terminated by a callout response from a callout server. The OPES callout protocol MUST, however, also allow either endpoint of a callout transaction to terminate a callout transaction prematurely, i.e. before a callout request or response has been completely received by the corresponding endpoint. The callout protocol MAY provide an explicit (e.g. through a termination message) or implicit (e.g. through a connection tear-down) mechanism to terminate a callout transaction prematurely. Such a mechanism MUST ensure, however, that a premature termination of a callout transaction does not result in the loss of application message data. A premature termination of a callout transaction is required to support OPES services which may terminate even before they have processed the entire application message. Content analysis services, for example, may be able to classify a Web object after having processed just the first few bytes of a Web object. The callout protocol MUST further enable a callout server to report back to the OPES data processor the result of a callout transaction, e.g. in the form of a status code. 3.2 Callout Channels The OPES callout protocol MUST enable an OPES data processor and a callout server to perform multiple callout transactions over a Beck, et al. Expires November 22, 2002 [Page 5] Internet-Draft Requirements for OPES Callout Protocols May 2002 callout channel. A callout channel is defined as a logical connection at the application-layer between an OPES data processor and a callout server. Callout channels MUST always be established by an OPES data processor. A callout channel MAY be closed by either endpoint of the callout channel provided that all callout transactions associated with the channel have terminated. A callout channel MAY have certain parameters associated with it, for example parameters that control the fail-over behavior of channel endpoints. Callout channel parameters MAY be negotiated between OPES data processors and callout servers (see Section 3.10). 3.3 Reliability The OPES callout protocol MUST be able to provide ordered reliability for the communication between OPES data processor and callout server. Additionally, the callout protocol SHOULD be able to provide unordered reliability. In order to satisfy the reliability requirements, the callout protocol MAY specify that it must be used with a lower-level transport protocol which provides ordered reliability at the transport-layer. 3.4 Congestion and Flow Control The OPES callout protocol MUST ensure that congestion and flow control mechanisms are applied on all callout transactions. For this purpose, the callout protocol MAY specify callout protocol-specific mechanisms or refer to a lower-level transport protocol and discuss how its mechanisms provide for congestion and flow control. 3.5 Support for Keep-Alive Mechanism The OPES callout protocol MUST provide an optional keep-alive mechanism which, if used, would allow both endpoints of a callout channel to detect a failure of the other endpoint even in the absence of callout transactions. The callout protocol MAY specify that keep- alive messages be exchanged over existing callout channel connections or a separate connection between OPES data processor and callout server. The detection of a callout server failure may enable an OPES data processor to establish a channel connection with a stand-by callout server so that future callout transactions do not result in the loss of application message data. The detection of the failure of an OPES Beck, et al. Expires November 22, 2002 [Page 6] Internet-Draft Requirements for OPES Callout Protocols May 2002 data processor may enable a callout server to release resources which would otherwise not be available for callout transactions with other OPES data processors. 3.6 Operation in NAT Environments The OPES protocol SHOULD be NAT-friendly, i.e. its operation should not be compromised by the presence of one or more NAT devices in the path between an OPES data processor and a callout server. 3.7 Multiple Callout Servers The OPES callout protocol MUST allow an OPES data processor to simultaneously communicate with more than one callout server. In larger networks, OPES services are likely to be hosted by different callout servers. Therefore, an OPES data processor will likely have to communicate with multiple callout servers. The protocol design MUST enable an OPES data processor to do so. 3.8 Multiple Data Processors The OPES callout protocol MUST allow a callout server to simultaneously communicate with more than one OPES data processor. The protocol design MUST support a scenario in which multiple OPES data processors use the services of a single callout server. 3.9 Support for Different Application Protocols The OPES callout protocol MUST be application protocol-agnostic, i.e. it MUST not make any assumptions about the characteristics of the application-layer protocol used on the data path between data provider and data consumer. The OPES entities on the data path may use different application- layer protocols, including, but not limited to, HTTP [3] and RTP [4]. It would be desirable to be able to use the same OPES callout protocol for any such application-layer protocol. 3.10 Capability and Parameter Negotiations The OPES callout protocol MUST support the negotiation of capabilities and callout channel parameters between an OPES data processor and a callout server. This implies that the OPES data processor and the callout server MUST be able to exchange their capabilities and preferences and engage into a deterministic negotiation process at the end of which the two endpoints have either Beck, et al. Expires November 22, 2002 [Page 7] Internet-Draft Requirements for OPES Callout Protocols May 2002 agreed on the capabilities and parameters to be used for future callout channel transactions or determined that their capabilities are incompatible. Capabilities and parameters that could be negotiated between an OPES data processor and a callout server include (but are not limited to): callout protocol version, transport-layer protocol, fail-over behavior, heartbeat rate for keep-alive messages, security-related parameters etc. Channel parameters may also pertain to the characteristics of OPES callout services if, for example, callout channels are associated with one or more specific OPES services. An OPES service-specific parameter may, for example, specify which parts of an application message an OPES service requires for its operation. The parties to a callout protocol MAY use callout channels to negotiate all or some of their capabilities and parameters. They MAY also use a separate control connection for this purpose. If there is a need for callout channel parameters, then they MUST be negotiated on a per-callout channel basis and before any callout transactions are performed over the corresponding channel. Other parameters and capabilities, such as the fail-over behavior, MAY be negotiated between the two endpoints independently of callout channels. 3.11 Meta Data and Instructions The OPES callout protocol MUST provide a mechanism for the endpoints of a particular callout transaction to include in callout requests and responses meta data and instructions for the OPES data processor or callout server. Specifically, the callout protocol MUST enable an OPES data processor to include information about the forwarded application message in a callout request, e.g. in order to specify the type of the forwarded application message or to specify what part(s) of the application message are forwarded to the callout server. Likewise, the callout server MUST be able to include information about the returned application message. The OPES data processor MUST further be able to uniquely specify one or more OPES services which are to be performed on the forwarded application message. The callout protocol MAY also choose to associate callout channels with specific OPES services so that there is no need to identify OPES service on a per-callout transaction basis. Additionally, the OPES callout protocol MUST allow the callout server Beck, et al. Expires November 22, 2002 [Page 8] Internet-Draft Requirements for OPES Callout Protocols May 2002 to indicate to the OPES data processor the cacheability of callout responses. This implies that callout responses may have to carry cache-control instructions for the OPES data processor. The OPES callout protocol MUST further enable the OPES data processor to indicate to the callout server if it has kept a local copy of the forwarded application message (or parts thereof). This information enables the callout server to determine whether the forwarded application message must be returned to the OPES data processor even it has not been modified by an OPES service. The OPES callout protocol MUST also allow OPES data processors to comply with the tracing requirements of the OPES architecture as laid out in [1] and [5]. This implies that the callout protocol MUST enable a callout server to convey to the OPES data processor information about the OPES service operations performed on the forwarded application message. 3.12 Asynchronous Message Exchange The OPES callout protocol MUST support an asynchronous message exchange between an OPES data processor and a callout server. In order to allow asynchronous processing on the OPES data processor and callout server, it MUST be possible to separate request issuance from response processing. The protocol MUST therefore allow multiple outstanding requests and provide a method to correlate responses to requests. Additionally, the callout protocol MUST enable a callout server to respond to a callout request before it has received the entire request. 3.13 Message Segmentation The OPES callout protocol MUST allow an OPES data processor to forward an application message to a callout server in a series of smaller message fragments. The callout protocol MUST further enable the receiving callout server to assemble the fragmented application message. Likewise, the callout protocol MUST enable a callout server to return an application message to a data processor in a series of smaller message fragments. The callout protocol MUST enable the receiving data processor to assemble the fragmented application message. Depending on the application-layer protocol used on the data path, application messages may be very large in size (for example in the Beck, et al. Expires November 22, 2002 [Page 9] Internet-Draft Requirements for OPES Callout Protocols May 2002 case of audio/video streams) or of unknown size. In both cases, the OPES data processor has to initiate a callout transaction before it has received the entire application message to avoid long delays for the data consumer. The OPES data processor MUST therefore be able to forward fragments or chunks of an application message to a callout server as it receives them from the data provider or consumer. Likewise, the callout server MUST be able to process and return application message fragments as it receives them from the data processor. Beck, et al. Expires November 22, 2002 [Page 10] Internet-Draft Requirements for OPES Callout Protocols May 2002 4. Performance Requirements 4.1 Protocol Efficiency The OPES callout protocol SHOULD be efficient in that it minimizes the additionally introduced latency, for example by minimizing the protocol overhead. At a minimum, the callout protocol SHOULD satisfy the performance requirements of the application-layer protocol whose messages are forwarded from the OPES data processor to the callout server. As OPES callout transactions introduce additional latency to application protocol transactions on the data path, calllout protocol efficiency is crucial. Beck, et al. Expires November 22, 2002 [Page 11] Internet-Draft Requirements for OPES Callout Protocols May 2002 5. Security Requirements In the absence of any security mechanisms, sensitive information might be communicated between the OPES data processor and the callout server in violation of either endpoint's security and privacy policy through misconfiguration or a deliberate insider attack. By using strong authentication, message encryption, and integrity checks, this threat can be minimized to a smaller set of insiders and/or operator configuration errors. The OPES data processor and the callout servers SHOULD have enforceable policies that limit the parties they communicate with, that determine the protections to use based on identities of the endpoints and other data (such as enduser policies). In order to enforce the policies, they MUST be able to authenticate the callout protocol endpoints using cryptographic methods. 5.1 Authentication, Confidentiality, and Integrity The parties to the callout protocol MUST have a sound basis for binding authenticated identities to the protocol endpoints, and they MUST verify that these identities are consistent with their security policies. The OPES callout protocol MUST provide message authentication, confidentiality, and integrity between the OPES data processor and the callout server. It MUST provide mutual authentication. The callout protocol SHOULD use existing security mechanisms for this purpose. The callout protocol specification is not required to specify the security mechanisms, but it MAY instead refer to a lower- level security protocol and discuss how its mechanisms are to be used with the callout protocol. 5.2 Hop-by-Hop Confidentiality If encryption is a requirement for the content path, then this confidentiality MUST be extended to the communication between the callout servers and the OPES data processor. In order to minimize data exposure, the callout protocol MUST use a different encryption key for each encrypted content stream. 5.3 Operation Across Un-trusted Domains The OPES callout protocol MUST operate securely across un-trusted domains between the OPES data processor and the callout server. If the communication channels between the OPES data processor and callout server cross outside of the organization taking Beck, et al. Expires November 22, 2002 [Page 12] Internet-Draft Requirements for OPES Callout Protocols May 2002 responsibility for the OPES services, then endpoint authentication and message protection (confidentiality and integrity) MUST be used. 5.4 Privacy Any communication carrying information relevant to privacy policies MUST protect the data using encryption. Beck, et al. Expires November 22, 2002 [Page 13] Internet-Draft Requirements for OPES Callout Protocols May 2002 6. Security Considerations The security requirements for the OPES callout protocol are discussed in Section 5. Beck, et al. Expires November 22, 2002 [Page 14] Internet-Draft Requirements for OPES Callout Protocols May 2002 7. Acknowledgments This document is based in parts on previous work by Anca Dracinschi Sailer, Volker Hilt, and Rama R. Menon. Beck, et al. Expires November 22, 2002 [Page 15] Internet-Draft Requirements for OPES Callout Protocols May 2002 References [1] Barbir, A., "An Architecture for Open Pluggable Edge Services (OPES)", draft-ietf-opes-architecture-00 (work in progress), May 2002. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [3] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. [4] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [5] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002. Authors' Addresses Andre Beck Lucent Technologies 101 Crawfords Corner Road Holmdel, NJ 07733 US EMail: abeck@bell-labs.com Markus Hofmann Lucent Technologies Room 4F-513 101 Crawfords Corner Road Holmdel, NJ 07733 US Phone: +1 732 332 5983 EMail: hofmann@bell-labs.com Beck, et al. Expires November 22, 2002 [Page 16] Internet-Draft Requirements for OPES Callout Protocols May 2002 Hilarie Orman Purple Streak Development EMail: ho@alum.mit.edu URI: http://www.purplestreak.com Reinaldo Penno Nortel Networks 2305 Mission College Boulevard San Jose, CA 95134 US EMail: rpenno@nortelnetworks.com Andreas Terzis Individual Consultant 150 Golf Course Dr. Rohnert Park, CA 94928 US Phone: +1 707 586 8864 EMail: aterzis@sbcglobal.net Beck, et al. Expires November 22, 2002 [Page 17] Internet-Draft Requirements for OPES Callout Protocols May 2002 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. Beck, et al. Expires November 22, 2002 [Page 18] --------------050603090204050503070709-- From owner-ietf-openproxy@mail.imc.org Mon May 27 12:57:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21856 for ; Mon, 27 May 2002 12:57:46 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4RGK8319265 for ietf-openproxy-bks; Mon, 27 May 2002 09:20:08 -0700 (PDT) Received: from markbaker.ca (cpu2164.adsl.bellglobal.com [207.236.3.141]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RGK7J19261 for ; Mon, 27 May 2002 09:20:07 -0700 (PDT) Received: (from mbaker@localhost) by markbaker.ca (8.9.3/8.8.7) id MAA11031; Mon, 27 May 2002 12:28:55 -0400 Date: Mon, 27 May 2002 12:28:55 -0400 From: Mark Baker To: Markus Hofmann Cc: OPES Group Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing Message-ID: <20020527122855.G3265@www.markbaker.ca> References: <87609AFB433BD5118D5E0002A52CD754023F6D6A@zcard0k6.ca.norte <5.1.0.14.2.20020523005118.03c115a0@joy.songbird.com> <20020523125549.R16765@www.markbaker.ca> <3CED28A4.10508@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <3CED28A4.10508@mhof.com>; from markus@mhof.com on Thu, May 23, 2002 at 01:36:36PM -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Thu, May 23, 2002 at 01:36:36PM -0400, Markus Hofmann wrote: > Mark Baker wrote: > > > I agree that multivendor internetworking is critical. I just believe > > that it should be achieved by agreeing on the "flow" protocols. For > > example, by building a language translator as an HTTP proxy. > > This implies that requests AND responses will travel through the "box" > the language translator is running on, which is not really required > since it cares only about the responses. With a callout protocol, you > vector out only the responses, letting the request go through directly. Really, a callout service only cares about responses? So where in the architecture, would a service that translated outbound documents go? Why is a response-based service special? MB -- Mark Baker, CTO, Idokorro Mobile (formerly Planetfred) Ottawa, Ontario, CANADA. distobj@acm.org http://www.markbaker.ca http://www.idokorro.com From owner-ietf-openproxy@mail.imc.org Mon May 27 13:47:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22977 for ; Mon, 27 May 2002 13:47:31 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4RHEFk20401 for ietf-openproxy-bks; Mon, 27 May 2002 10:14:15 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RHEDJ20396 for ; Mon, 27 May 2002 10:14:13 -0700 (PDT) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout03.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with ESMTP id <0GWS007ZC57GV6@mtaout03.icomcast.net> for ietf-openproxy@imc.org; Mon, 27 May 2002 13:14:05 -0400 (EDT) Date: Mon, 27 May 2002 13:14:04 -0400 From: Markus Hofmann Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing To: Mark Baker Cc: OPES Group Message-id: <3CF2695C.1040706@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 References: <20020523125549.R16765@www.markbaker.ca> <3CED28A4.10508@mhof.com> <20020527122855.G3265@www.markbaker.ca> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Mark Baker wrote: > Really, a callout service only cares about responses? So where in the > architecture, would a service that translated outbound documents go? > Why is a response-based service special? There are services that care only about responses, services that care only about requests (or outbound messages), and services that care about both. -Markus From owner-ietf-openproxy@mail.imc.org Mon May 27 13:55:16 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23113 for ; Mon, 27 May 2002 13:55:16 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4RHL0O20581 for ietf-openproxy-bks; Mon, 27 May 2002 10:21:00 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4RHKwJ20577 for ; Mon, 27 May 2002 10:20:58 -0700 (PDT) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with ESMTP id <0GWS00DKC5IVH2@mtaout01.icomcast.net> for ietf-openproxy@imc.org; Mon, 27 May 2002 13:20:55 -0400 (EDT) Date: Mon, 27 May 2002 13:20:55 -0400 From: Markus Hofmann Subject: Re: [ OPES architecture] Final Points of Discussion: Tracing To: Mark Baker Cc: OPES Group Message-id: <3CF26AF7.2060608@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 References: <20020523125549.R16765@www.markbaker.ca> <3CED28A4.10508@mhof.com> <20020527122855.G3265@www.markbaker.ca> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Mark Baker wrote: >>This implies that requests AND responses will travel through the "box" >>the language translator is running on, which is not really required >>since it cares only about the responses. With a callout protocol, you >>vector out only the responses, letting the request go through directly. > > Really, a callout service only cares about responses? So where in the > architecture, would a service that translated outbound documents go? > Why is a response-based service special? Hm, may this did not become clear... you cannot only vector out responses, but also request, of course, or both, of course. If a service only cares about the response, you vector out only the response. If a service only cares about the request, you vector out only the request. If a service cares about both, you vector out both (which, in this case, could also be achieved via proxy). -Markus From owner-ietf-openproxy@mail.imc.org Wed May 29 08:05:07 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12654 for ; Wed, 29 May 2002 08:05:06 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4TBXhN05310 for ietf-openproxy-bks; Wed, 29 May 2002 04:33:43 -0700 (PDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TBXgJ05306 for ; Wed, 29 May 2002 04:33:42 -0700 (PDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11122; Wed, 29 May 2002 07:33:17 -0400 (EDT) Message-Id: <200205291133.HAA11122@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ietf-openproxy@imc.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-opes-protocol-reqs-00.txt Date: Wed, 29 May 2002 07:33:16 -0400 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Pluggable Edge Services Working Group of the IETF. Title : Requirements for OPES Callout Protocols Author(s) : A. Beck Filename : draft-ietf-opes-protocol-reqs-00.txt Pages : 18 Date : 28-May-02 This document specifies the requirements that the OPES (Open Pluggable Edge Services) callout protocol must satisfy in order to support the remote execution of OPES services [1]. The requirements are intended to help evaluating possible protocol candidates and to guide the development of such protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-reqs-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-opes-protocol-reqs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-opes-protocol-reqs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020528130821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-opes-protocol-reqs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-opes-protocol-reqs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020528130821.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ietf-openproxy@mail.imc.org Wed May 29 10:13:50 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18576 for ; Wed, 29 May 2002 10:13:50 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4TDckf16688 for ietf-openproxy-bks; Wed, 29 May 2002 06:38:46 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TDcjJ16683 for ; Wed, 29 May 2002 06:38:45 -0700 (PDT) Received: from GK-VAIO.NineByNine.org (dyn92-41.sftm-212-159.plus.net [212.159.41.92]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g4TLFd430392 for ; Wed, 29 May 2002 14:15:40 -0700 Message-Id: <5.1.0.14.2.20020529140349.044775f0@joy.songbird.com> X-Sender: gk@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 29 May 2002 14:18:10 +0100 To: OPES Group From: Graham Klyne Subject: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re qs-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This mostly looks pretty reasonable to me. A couple of comments below. I'm a little confused by terminology. The term "data processor" is not one I recall from the architecture document. I do recall the term "data dispatcher" (or something like that) which seems to be what is meant there. >3.12 Asynchronous Message Exchange > > The OPES callout protocol MUST support an asynchronous message > exchange between an OPES data processor and a callout server. > > In order to allow asynchronous processing on the OPES data processor > and callout server, it MUST be possible to separate request issuance > from response processing. The protocol MUST therefore allow multiple > outstanding requests and provide a method to correlate responses to > requests. > > Additionally, the callout protocol MUST enable a callout server to > respond to a callout request before it has received the entire > request. How far is asynchrony to be taken? In particular, I'm wondering if it is to be possible for a response to be received on a channel different from the request. (E.g. suppose a channel between data dispatcher and callout processor fails, and is re-established - can an outstanding response arrive on the re-established channel?) >4.1 Protocol Efficiency > > The OPES callout protocol SHOULD be efficient in that it minimizes > the additionally introduced latency, for example by minimizing the > protocol overhead. At a minimum, the callout protocol SHOULD satisfy > the performance requirements of the application-layer protocol whose > messages are forwarded from the OPES data processor to the callout > server. The sentence "At a minimum..." seems to be a bit vague, in the sense that it's not really possible to determine whether it is satisfied by any given callout protocol. Especially given that the callout protocol is required to be application protocol agnostic. I'm not sure that anything significant would be lost by deleting this sentence. >6. Security Considerations > > The security requirements for the OPES callout protocol are discussed > in Section 5. I think section 5 or section 6 should say something about honouring the security/privacy requirements of the endpoints of the "original" transfer (the provider and/or consumer). In particular, if either party has provided authority for limited kinds of processing to be performed, the extent of that authority should be communicated to the callout processor. Related to this, the callout processor should return an indication of the processing steps performed so that the OPES architectural requirements for tracing can be satisfied. #g ------------------- Graham Klyne From owner-ietf-openproxy@mail.imc.org Wed May 29 10:35:39 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19415 for ; Wed, 29 May 2002 10:35:39 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4TE8Fh27525 for ietf-openproxy-bks; Wed, 29 May 2002 07:08:15 -0700 (PDT) Received: from sainfoin.saclay.cea.fr (sainfoin.saclay.cea.fr [132.166.192.126]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TE8DJ27506 for ; Wed, 29 May 2002 07:08:13 -0700 (PDT) Received: from argiope.saclay.cea.fr (argiope.saclay.cea.fr [132.166.192.108]) by sainfoin.saclay.cea.fr (8.12.2/8.12.2/CEAnet-Internet.1.0) with ESMTP id g4TE9NRo013800 for ; Wed, 29 May 2002 16:09:23 +0200 (MEST) Received: from muguet.saclay.cea.fr (unverified) by argiope.saclay.cea.fr (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Wed, 29 May 2002 16:02:52 +0200 Received: from is002254.saclay.cea.fr (is002254.saclay.cea.fr [132.166.134.67]) by muguet.saclay.cea.fr (8.12.2/8.12.2/CEAnet-Interne.1.0) with ESMTP id g4TE9D0e012217; Wed, 29 May 2002 16:09:13 +0200 (MEST) Received: from basile by is002254.saclay.cea.fr with local (Exim 3.35 #1 (Debian)) id 17D47A-00050T-00; Wed, 29 May 2002 16:07:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <15604.57522.654818.846700@is002254.saclay.cea.fr> Date: Wed, 29 May 2002 16:07:46 +0200 To: : ietf-openproxy@imc.org Subject: Future of ICAP? X-Mailer: VM 7.03 under Emacs 21.2.1 From: Basile STARYNKEVITCH Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 8bit Dear All, What is the future of ICAP (see www.i-cap.org) = Internet Content Adaptation Protocol (IETF internet draft by J.Elson & A.Cerpa, editor)? Is ICAP in way of becoming (included in OPES?) an Internet Standard? regards N.B. Any opinions expressed here are only mine, and not of my organization. N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. --------------------------------------------------------------------- Basile STARYNKEVITCH ---- Commissariat à l Energie Atomique * France DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX phone:+33 1,6908.6055; fax: 1,6908.8395 home: 1,4665.4553; mobile: 6,8501.2359 work email: Basile point Starynkevitch at cea point fr home email: Basile at Starynkevitch point net From owner-ietf-openproxy@mail.imc.org Wed May 29 18:12:50 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05401 for ; Wed, 29 May 2002 18:12:50 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4TLLjG22788 for ietf-openproxy-bks; Wed, 29 May 2002 14:21:45 -0700 (PDT) Received: from lecs.cs.ucla.edu (Lecs.CS.UCLA.EDU [131.179.144.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TLLcJ22691 for ; Wed, 29 May 2002 14:21:39 -0700 (PDT) Received: from concorde.cs.ucla.edu (concorde.cs.ucla.edu [131.179.144.102]) by lecs.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id OAA10066; Wed, 29 May 2002 14:21:26 -0700 Received: from concorde.cs.ucla.edu (localhost [127.0.0.1]) by concorde.cs.ucla.edu (8.9.3/8.9.3) with ESMTP id OAA14550; Wed, 29 May 2002 14:21:25 -0700 Message-Id: <200205292121.OAA14550@concorde.cs.ucla.edu> From: Jeremy Elson To: Basile STARYNKEVITCH cc: ietf-openproxy@imc.org Subject: Re: Future of ICAP? In-Reply-To: <15604.57522.654818.846700@is002254.saclay.cea.fr> Date: Wed, 29 May 2002 14:21:25 -0700 Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: We're going to be submitting it as an Informational RFC in the next couple of weeks, with some minor changes over the current draft (mostly nontechnical; just wording issues). Jer Basile STARYNKEVITCH writes: > >Dear All, > >What is the future of ICAP (see www.i-cap.org) = Internet Content >Adaptation Protocol (IETF internet draft by J.Elson & A.Cerpa, >editor)? > >Is ICAP in way of becoming (included in OPES?) an Internet Standard? > >regards > >N.B. Any opinions expressed here are only mine, and not of my organization. >N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA. > >--------------------------------------------------------------------- >Basile STARYNKEVITCH ---- Commissariat à l Energie Atomique * France >DRT/LIST/DTSI/SLA * CEA/Saclay b.528 (p111f) * 91191 GIF/YVETTE CEDEX >phone:+33 1,6908.6055; fax: 1,6908.8395 home: 1,4665.4553; mobile: 6,8501.2359 >work email: Basile point Starynkevitch at cea point fr >home email: Basile at Starynkevitch point net From owner-ietf-openproxy@mail.imc.org Thu May 30 02:26:47 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23975 for ; Thu, 30 May 2002 02:26:47 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4U5qvP13610 for ietf-openproxy-bks; Wed, 29 May 2002 22:52:57 -0700 (PDT) Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4U5qu113606 for ; Wed, 29 May 2002 22:52:56 -0700 (PDT) Received: from mhof.com (bgp570928bgs.eatntn01.nj.comcast.net [68.39.0.215]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.1 HotFix 0.8 (built May 13 2002)) with ESMTP id <0GWW00IEMO42HC@mtaout04.icomcast.net> for ietf-openproxy@imc.org; Wed, 29 May 2002 23:52:50 -0400 (EDT) Date: Wed, 29 May 2002 23:52:50 -0400 From: Markus Hofmann Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re qs-00.txt To: Graham Klyne Cc: OPES Group Message-id: <3CF5A212.4030303@mhof.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc2) Gecko/20020510 References: <5.1.0.14.2.20020529140349.044775f0@joy.songbird.com> Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7BIT Graham, thanks for your comments. Let me offer some responses until the co-authors get a chance to reply. > I'm a little confused by terminology. The term "data processor" is > not one I recall from the architecture document. I do recall the > term "data dispatcher" (or something like that) which seems to be > what is meant there. Previous discussions already showed that we need to clarify these terms in the architecture document - point taken. The term "data processor" is used here in the sense as introduced in Figure 2 of the architecture document. Looking at Figure 3 in the architecture document, "data processor" refers to the box including the "data dispatcher", i.e. the "data dispatcher" is part of a "data processor". So, I believe the usage of "data processor" is correct here. > How far is asynchrony to be taken? In particular, I'm wondering if > it is to be possible for a response to be received on a channel > different from the request. (E.g. suppose a channel between data > dispatcher and callout processor fails, and is re-established - can > an outstanding response arrive on the re-established channel?) Hm, good question, anybody any opinions on that? > The sentence "At a minimum..." seems to be a bit vague, in the > sense that it's not really possible to determine whether it is > satisfied by any given callout protocol. Especially given that the > callout protocol is required to be application protocol agnostic. > I'm not sure that anything significant would be lost by deleting > this sentence. I agree that this is quite vague, we cannot really give any concrete numbers. The feeling was that it would be nice to have some comparison, trying to make the point that the callout protocol itself should not slow down the interaction between client and server significantly. Maybe that's already captured in the first sentence, and we don't realy need the second one. But I believe it's important that we have some requirement(s) about the expected performance of the callout protocol - otherwise we could end up with a protocol that slows down the communication so that's it's basically unusable. > I think section 5 or section 6 should say something about honouring > the security/privacy requirements of the endpoints of the > "original" transfer (the provider and/or consumer). In particular, > if either party has provided authority for limited kinds of > processing to be performed, the extent of that authority should be > communicated to the callout processor. Isn't that rather a requirement for "endpoint authorization and enforcement" rather than for the callout protocol? The callout protocol itself does not care about it, it simply does what the "data processor" asks it to do. Of course, the data processor would have to implement the kind of considerations you mention, probably in form of policies/rules. This has to be written down in the ""endpoint authorization and enforcement requirements". Or do you see a direct impact on the callout protocol itself? > Related to this, the callout processor should return an indication > of the processing steps performed so that the OPES architectural > requirements for tracing can be satisfied. Yes, agreed. I believe this is covered in Section 3.11 when saying "The OPES callout protocol MUST also allow OPES data processors to comply with the tracing requirements of the OPES architecture as laid out in [1] and [5]. This implies that the callout protocol MUST enable a callout server to convey to the OPES data processor information about the OPES service operations performed on the forwarded application message." Cheers, Markus From owner-ietf-openproxy@mail.imc.org Thu May 30 14:12:32 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16014 for ; Thu, 30 May 2002 14:12:32 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4UHh5l13618 for ietf-openproxy-bks; Thu, 30 May 2002 10:43:05 -0700 (PDT) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UHh4n13614 for ; Thu, 30 May 2002 10:43:04 -0700 (PDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4UHhgUL028114; Thu, 30 May 2002 13:43:42 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4UHgxo96065; Thu, 30 May 2002 13:42:59 -0400 (EDT) Received: from bell-labs.com ([135.104.20.66]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id NAA08296; Thu, 30 May 2002 13:42:58 -0400 (EDT) Message-ID: <3CF663BD.5080201@bell-labs.com> Date: Thu, 30 May 2002 12:39:09 -0500 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Klyne CC: Markus Hofmann , OPES Group Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re qs-00.txt References: <5.1.0.14.2.20020529140349.044775f0@joy.songbird.com> <3CF5A212.4030303@mhof.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham, Markus, see my comments inline. > > I'm a little confused by terminology. The term "data processor" is > > not one I recall from the architecture document. I do recall the > > term "data dispatcher" (or something like that) which seems to be > > what is meant there. > > Previous discussions already showed that we need to clarify these terms > in the architecture document - point taken. I agree that terminology needs be aligned across WG drafts. The architecture draft defines an "OPES processor" as a network element in the path between data provider and data consumer. The OPES entities "data dispatcher" and (local) "OPES services" reside inside the OPES processor. The protocol requirements draft uses the term "OPES data processor" in exactly this sense. > > How far is asynchrony to be taken? In particular, I'm wondering if > > it is to be possible for a response to be received on a channel > > different from the request. (E.g. suppose a channel between data > > dispatcher and callout processor fails, and is re-established - can > > an outstanding response arrive on the re-established channel?) > > Hm, good question, anybody any opinions on that? Our main motivation for requiring support for asynchronous message exchange was to allow for parallel callout transactions over a single callout channel. I am not yet convinced that we need to extend the asynchrony requirement to include scenarios like the one you described, but if there are good arguments for it, then we can certainly do so. > > I think section 5 or section 6 should say something about honouring > > the security/privacy requirements of the endpoints of the > > "original" transfer (the provider and/or consumer). In particular, > > if either party has provided authority for limited kinds of > > processing to be performed, the extent of that authority should be > > communicated to the callout processor. > > Isn't that rather a requirement for "endpoint authorization and > enforcement" rather than for the callout protocol? Yes, IMO the data dispatcher on the OPES processor is responsible for the enforcement of endpoint authorization and uses the callout protocol as a means to request the execution of specific OPES services on a remote callout server. So I don't think there is a need to communicate endpoint authorizations to callout servers. -Andre From owner-ietf-openproxy@mail.imc.org Thu May 30 18:14:59 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21025 for ; Thu, 30 May 2002 18:14:59 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4ULlr721514 for ietf-openproxy-bks; Thu, 30 May 2002 14:47:53 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ULlqn21510 for ; Thu, 30 May 2002 14:47:52 -0700 (PDT) Received: from GK-VAIO.ninebynine.org (dyn28-41.sftm-212-159.plus.net [212.159.41.28]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g4V5Oa432764; Thu, 30 May 2002 22:24:37 -0700 Message-Id: <5.1.0.14.2.20020530191645.035eb4e0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 30 May 2002 19:17:09 +0100 To: Andre Beck From: Graham Klyne Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re qs-00.txt Cc: OPES Group In-Reply-To: <3CF663BD.5080201@bell-labs.com> References: <5.1.0.14.2.20020529140349.044775f0@joy.songbird.com> <3CF5A212.4030303@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:39 PM 5/30/02 -0500, Andre Beck wrote: >> > How far is asynchrony to be taken? In particular, I'm wondering if >> > it is to be possible for a response to be received on a channel >> > different from the request. (E.g. suppose a channel between data >> > dispatcher and callout processor fails, and is re-established - can >> > an outstanding response arrive on the re-established channel?) >>Hm, good question, anybody any opinions on that? > >Our main motivation for requiring support for asynchronous message >exchange was to allow for parallel callout transactions over a single >callout channel. I am not yet convinced that we need to extend the >asynchrony requirement to include scenarios like the one you described, >but if there are good arguments for it, then we can certainly do so. I don't have a strong view, just trying to clarify the extent of the requirement. #g ------------------- Graham Klyne From owner-ietf-openproxy@mail.imc.org Thu May 30 18:15:36 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21038 for ; Thu, 30 May 2002 18:15:36 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4ULlvu21519 for ietf-openproxy-bks; Thu, 30 May 2002 14:47:57 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ULlvn21515 for ; Thu, 30 May 2002 14:47:57 -0700 (PDT) Received: from GK-VAIO.ninebynine.org (dyn28-41.sftm-212-159.plus.net [212.159.41.28]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g4V5Of432767; Thu, 30 May 2002 22:24:42 -0700 Message-Id: <5.1.0.14.2.20020530191752.035ed440@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 30 May 2002 19:20:05 +0100 To: Andre Beck From: Graham Klyne Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re qs-00.txt Cc: OPES Group In-Reply-To: <3CF663BD.5080201@bell-labs.com> References: <5.1.0.14.2.20020529140349.044775f0@joy.songbird.com> <3CF5A212.4030303@mhof.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 12:39 PM 5/30/02 -0500, Andre Beck wrote: >> > I think section 5 or section 6 should say something about honouring >> > the security/privacy requirements of the endpoints of the >> > "original" transfer (the provider and/or consumer). In particular, >> > if either party has provided authority for limited kinds of >> > processing to be performed, the extent of that authority should be >> > communicated to the callout processor. >>Isn't that rather a requirement for "endpoint authorization and >>enforcement" rather than for the callout protocol? > >Yes, IMO the data dispatcher on the OPES processor is responsible for the >enforcement of endpoint authorization and uses the callout protocol as a >means to request the execution of specific OPES services on a remote >callout server. So I don't think there is a need to communicate endpoint >authorizations to callout servers. I think that's OK if: (a) the callout processor can be trusted by the dispatcher to not save or distribute the information provided beyond the immediate requirements of processing, and (b) it is clear that the callout processor only performs transformations that are explicitly requested by the dispatcher. Should that much be mentioned in security considerations? #g ------------------- Graham Klyne From owner-ietf-openproxy@mail.imc.org Thu May 30 19:03:08 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21670 for ; Thu, 30 May 2002 19:03:07 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4UMb9A22515 for ietf-openproxy-bks; Thu, 30 May 2002 15:37:09 -0700 (PDT) Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UMb8n22511 for ; Thu, 30 May 2002 15:37:08 -0700 (PDT) Received: from scummy.research.bell-labs.com (H-135-104-2-10.research.bell-labs.com [135.104.2.10]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4UMb8EF090455; Thu, 30 May 2002 18:37:08 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by scummy.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4UMb1k11872; Thu, 30 May 2002 18:37:02 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA20215; Thu, 30 May 2002 18:36:58 -0400 (EDT) Message-ID: <3CF6A98A.5040902@mhof.com> Date: Thu, 30 May 2002 18:36:58 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Rochberger, Haim" CC: OPES Group Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re qs-00.txt References: <6682DE381343D511BFD400508BDD16E70188B064@ISMAILEXA> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Rochberger, Haim wrote: > Is it required in the callout server protocol that the OPES > dispacher (or engine...) is able to specify both: the services > needed to be performed on a specific message, and WHO is to perform > these services, and also the order it is to be done? Section 3.11 requires the protocol to provide a capability that allows indication of the service(s) to be performed on the message. The entity executing the requested service will be the destination of the callout message, i.e. you send the callout message to a callout server, and the callout server has to execute this service. There's no notion of chaining callout servers, or of further (iterative) dispatching. -Markus From owner-ietf-openproxy@mail.imc.org Thu May 30 19:06:10 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21726 for ; Thu, 30 May 2002 19:06:10 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4UMgHa22628 for ietf-openproxy-bks; Thu, 30 May 2002 15:42:17 -0700 (PDT) Received: from crufty.research.bell-labs.com (ns2.research.bell-labs.com [204.178.16.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UMgGn22624 for ; Thu, 30 May 2002 15:42:16 -0700 (PDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by crufty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4UMgJEF090487; Thu, 30 May 2002 18:42:19 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4UMgCo22306; Thu, 30 May 2002 18:42:13 -0400 (EDT) Received: from mhof.com (biena [135.180.160.86]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id SAA20301; Thu, 30 May 2002 18:42:12 -0400 (EDT) Message-ID: <3CF6AAC3.2030200@mhof.com> Date: Thu, 30 May 2002 18:42:11 -0400 From: Markus Hofmann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Graham Klyne CC: OPES Group Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re qs-00.txt References: <5.1.0.14.2.20020529140349.044775f0@joy.songbird.com> <3CF5A212.4030303@mhof.com> <5.1.0.14.2.20020530191752.035ed440@joy.songbird.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Graham Klyne wrote: > I think that's OK if: (a) the callout processor can be trusted by > the dispatcher to not save or distribute the information provided > beyond the immediate requirements of processing, and Yes (you probably refer to a "callout SERVER" whan talking about a "callout PROCESSOR", right :) > (b) it is clear that the callout processor only performs > transformations that are explicitly requested by the dispatcher. Yes. > Should that much be mentioned in security considerations? I wouldn't have a problem with mentioning that, except maybe that it does not directly relate to the protocol itself. I rather thought this would have to be included either in the architecture draft or maybe better in the "policy enforcement" document. -Markus From owner-ietf-openproxy@mail.imc.org Thu May 30 19:15:48 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21979 for ; Thu, 30 May 2002 19:15:48 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4UMlTZ22747 for ietf-openproxy-bks; Thu, 30 May 2002 15:47:29 -0700 (PDT) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UMlRn22743 for ; Thu, 30 May 2002 15:47:27 -0700 (PDT) Received: from il-tlv-mbdg2.icomverse.com (il-tlv-mbdg2.comverse.com [10.115.244.42]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g4UMVLX22970; Fri, 31 May 2002 01:31:21 +0300 Received: by il-tlv-mbdg2.icomverse.com with Internet Mail Service (5.5.2655.55) id ; Fri, 31 May 2002 01:47:23 +0300 Message-ID: <6682DE381343D511BFD400508BDD16E70188B097@ISMAILEXA> From: "Rochberger, Haim" To: Markus Hofmann Cc: OPES Group Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re qs-00.txt Date: Fri, 31 May 2002 01:47:22 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2082B.F58743B6" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2082B.F58743B6 Content-Type: text/plain; charset="iso-8859-1" Hi Markus, Is it still possible to add this requirement ? I mean chaining callout servers ? This may improve the performance in case you have a few callout servers that need to handle a specific message in order. I can see that the plurality of servers is needed due to the spatiality of each server - so they may not be able to all reside in one server. Unless it is either too late to add such a requirement or it is not acceptable from some reason, I can draft some description. Warm regards, Haim Rochberger System Architect Comverse Mobile Internet & Broadband Division Office: +972-3-766-9121 Mobile: +972-54-970-504 Email: Haim_rochberger@comverse.com -----Original Message----- From: Markus Hofmann [mailto:markus@mhof.com] Sent: Fri, May 31, 2002 1:37 AM To: Rochberger, Haim Cc: OPES Group Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re qs-00.txt Rochberger, Haim wrote: > Is it required in the callout server protocol that the OPES > dispacher (or engine...) is able to specify both: the services > needed to be performed on a specific message, and WHO is to perform > these services, and also the order it is to be done? Section 3.11 requires the protocol to provide a capability that allows indication of the service(s) to be performed on the message. The entity executing the requested service will be the destination of the callout message, i.e. you send the callout message to a callout server, and the callout server has to execute this service. There's no notion of chaining callout servers, or of further (iterative) dispatching. -Markus ------_=_NextPart_001_01C2082B.F58743B6 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: = http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re = qs-00.txt

Hi Markus,

Is it still possible to add this requirement ? I mean = chaining callout servers ?

This may improve the performance in case you have a = few callout servers that need to handle a specific message in = order.

I can see that the plurality of servers is needed due = to the spatiality of each server - so they may not be able to all = reside in one server.

Unless it is either too late to add such a = requirement or it is not acceptable from some reason, I can draft some = description.


Warm regards,

Haim Rochberger
System Architect
Comverse
Mobile Internet & Broadband Division
Office: +972-3-766-9121
Mobile: +972-54-970-504
Email: Haim_rochberger@comverse.com <mailto:Haim_rochberger@comv= erse.com>



-----Original Message-----
From: Markus Hofmann [mailto:markus@mhof.com]
Sent: Fri, May 31, 2002 1:37 AM
To: Rochberger, Haim
Cc: OPES Group
Subject: Re:
http://www.ietf.org/internet-drafts/draft-ietf-opes-pr= otocol- re
qs-00.txt


Rochberger, Haim wrote:

 > Is it required in the callout server = protocol that the OPES
 > dispacher (or engine...) is able to = specify both: the services
 > needed to be performed on a specific = message, and WHO is to perform
 > these services, and also the order it is = to be done?

Section 3.11 requires the protocol to provide a = capability that allows
indication of the service(s) to be performed on the = message. The
entity executing the requested service will be the = destination of the
callout message, i.e. you send the callout message = to a callout
server, and the callout server has to execute this = service. There's no
notion of chaining callout servers, or of further = (iterative) dispatching.

-Markus

------_=_NextPart_001_01C2082B.F58743B6-- From owner-ietf-openproxy@mail.imc.org Fri May 31 09:02:35 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14691 for ; Fri, 31 May 2002 09:02:34 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4VCZtv15594 for ietf-openproxy-bks; Fri, 31 May 2002 05:35:55 -0700 (PDT) Received: from jay.songbird.com (208.184.79.253.songbird.com [208.184.79.253] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VCZsg15589 for ; Fri, 31 May 2002 05:35:54 -0700 (PDT) Received: from GK-VAIO.ninebynine.org ([212.159.33.224]) (authenticated) by jay.songbird.com (8.11.6/8.11.3) with ESMTP id g4VKCa401566; Fri, 31 May 2002 13:12:36 -0700 Message-Id: <5.1.0.14.2.20020531134158.034a1ec0@joy.songbird.com> X-Sender: gk-lists@joy.songbird.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 31 May 2002 13:46:28 +0100 To: Markus Hofmann From: Graham Klyne Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol-re qs-00.txt Cc: OPES Group In-Reply-To: <3CF6AAC3.2030200@mhof.com> References: <5.1.0.14.2.20020529140349.044775f0@joy.songbird.com> <3CF5A212.4030303@mhof.com> <5.1.0.14.2.20020530191752.035ed440@joy.songbird.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: At 06:42 PM 5/30/02 -0400, Markus Hofmann wrote: >Graham Klyne wrote: > > > I think that's OK if: (a) the callout processor can be trusted by > > the dispatcher to not save or distribute the information provided > > beyond the immediate requirements of processing, and > >Yes (you probably refer to a "callout SERVER" whan talking about a >"callout PROCESSOR", right :) Yes... the terminology isn't burned into my neural paths yet. > > (b) it is clear that the callout processor only performs > > transformations that are explicitly requested by the dispatcher. > >Yes. > > > Should that much be mentioned in security considerations? > >I wouldn't have a problem with mentioning that, except maybe that it does >not directly relate to the protocol itself. I rather thought this would >have to be included either in the architecture draft or maybe better in >the "policy enforcement" document. The possible protocol issue I see is that the protocol must communicate (explicitly or implicitly) such information. Aside from that, if it's mentioned somewhere else, I suppose it's OK. (Maybe, in the longer term, it would help to collect the various security considerations into one place and cite that from all the documents? Security being more than just a sum-of-parts kind of matter.) #g ------------------- Graham Klyne From owner-ietf-openproxy@mail.imc.org Fri May 31 11:03:59 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18796 for ; Fri, 31 May 2002 11:03:58 -0400 (EDT) Received: by above.proper.com (8.11.6/8.11.3) id g4VEWYL22508 for ietf-openproxy-bks; Fri, 31 May 2002 07:32:34 -0700 (PDT) Received: from dirty.research.bell-labs.com (ns1.research.bell-labs.com [204.178.16.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VEWXg22502 for ; Fri, 31 May 2002 07:32:33 -0700 (PDT) Received: from grubby.research.bell-labs.com (H-135-104-2-9.research.bell-labs.com [135.104.2.9]) by dirty.research.bell-labs.com (8.12.2/8.12.2) with ESMTP id g4VEX7UL037527; Fri, 31 May 2002 10:33:07 -0400 (EDT) Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by grubby.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id g4VEWQo77562; Fri, 31 May 2002 10:32:26 -0400 (EDT) Received: from bell-labs.com ([135.5.126.183]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA06053; Fri, 31 May 2002 10:32:25 -0400 (EDT) Message-ID: <3CF788AB.3010103@bell-labs.com> Date: Fri, 31 May 2002 09:28:59 -0500 From: Andre Beck User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523 X-Accept-Language: en-US MIME-Version: 1.0 To: "Rochberger, Haim" CC: Markus Hofmann , OPES Group Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re qs-00.txt References: <6682DE381343D511BFD400508BDD16E70188B097@ISMAILEXA> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Content-Transfer-Encoding: 7bit Rochberger, Haim wrote: > Is it still possible to add this requirement ? I mean chaining callout > servers ? > > This may improve the performance in case you have a few callout servers > that need to handle a specific message in order. Callout server chaining would add a lot of complexity to callout transactions and callout servers, e.g. in terms of error handling, fail-over, tracing, trust relationships etc. I can only see performance benefits in cases where the distance between the callout servers is shorter than the distance between the OPES processor and the callout servers. However, I think whenever the performance of callout transactions is critical, it is much more likely that the callout servers will be co-located with the OPES processor, i.e. in the same domain. Hence the distance between the OPES processor and callout servers would be similar to the distance between the callout servers and there wouldn't be much of a performance benefit any more with callout chaining. -Andre From owner-ietf-openproxy@mail.imc.org Fri May 31 12:16:08 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21158 for ; Fri, 31 May 2002 12:16:08 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4VFRXS24956 for ietf-openproxy-bks; Fri, 31 May 2002 08:27:33 -0700 (PDT) Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VFRRg24949 for ; Fri, 31 May 2002 08:27:27 -0700 (PDT) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4VFQvc13598; Fri, 31 May 2002 11:26:57 -0400 (EDT) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Fri, 31 May 2002 11:26:57 -0400 Message-ID: <87609AFB433BD5118D5E0002A52CD754025760F0@zcard0k6.ca.nortel.com> From: "Abbie Barbir" To: Andre Beck , "Rochberger, Haim" Cc: Markus Hofmann , OPES Group Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re qs-00.txt Date: Fri, 31 May 2002 11:26:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C208B7.980D5766" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C208B7.980D5766 Content-Type: text/plain; charset="iso-8859-1" at a first cut, chaining gets second priority. however, the architetcture does not preclude it. chaining can be addressed later once the main issues are resolved. abbie > -----Original Message----- > From: Andre Beck [mailto:abeck@bell-labs.com] > Sent: Friday, May 31, 2002 10:29 AM > To: Rochberger, Haim > Cc: Markus Hofmann; OPES Group > Subject: Re: > http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re > qs-00.txt > > > > Rochberger, Haim wrote: > > Is it still possible to add this requirement ? I mean > chaining callout > > servers ? > > > > This may improve the performance in case you have a few > callout servers > > that need to handle a specific message in order. > > Callout server chaining would add a lot of complexity to callout > transactions and callout servers, e.g. in terms of error handling, > fail-over, tracing, trust relationships etc. I can only see > performance > benefits in cases where the distance between the callout servers is > shorter than the distance between the OPES processor and the callout > servers. However, I think whenever the performance of callout > transactions is critical, it is much more likely that the callout > servers will be co-located with the OPES processor, i.e. in the same > domain. Hence the distance between the OPES processor and callout > servers would be similar to the distance between the callout > servers and > there wouldn't be much of a performance benefit any more with callout > chaining. > > -Andre > > > ------_=_NextPart_001_01C208B7.980D5766 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: = http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re = qs-00.txt

at a first cut, chaining gets second priority.

however, the architetcture does not preclude it. = chaining can be addressed later once the main issues are = resolved.

abbie


> -----Original Message-----
> From: Andre Beck [mailto:abeck@bell-labs.com]
> Sent: Friday, May 31, 2002 10:29 AM
> To: Rochberger, Haim
> Cc: Markus Hofmann; OPES Group
> Subject: Re:
> http://www.ietf.org/internet-drafts/draft-ietf-opes-pr= otocol- re
> qs-00.txt
>
>
>
> Rochberger, Haim wrote:
> > Is it still possible to add this = requirement ? I mean
> chaining callout
> > servers ?
> >
> > This may improve the performance in case = you have a few
> callout servers
> > that need to handle a specific message in = order.
>
> Callout server chaining would add a lot of = complexity to callout
> transactions and callout servers, e.g. in terms = of error handling,
> fail-over, tracing, trust relationships etc. I = can only see
> performance
> benefits in cases where the distance between = the callout servers is
> shorter than the distance between the OPES = processor and the callout
> servers. However, I think whenever the = performance of callout
> transactions is critical, it is much more = likely that the callout
> servers will be co-located with the OPES = processor, i.e. in the same
> domain. Hence the distance between the OPES = processor and callout
> servers would be similar to the distance = between the callout
> servers and
> there wouldn't be much of a performance benefit = any more with callout
> chaining.
>
> -Andre
>
>
>

------_=_NextPart_001_01C208B7.980D5766-- From owner-ietf-openproxy@mail.imc.org Fri May 31 17:26:42 2002 Received: from above.proper.com (mail.proper.com [208.184.76.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05223 for ; Fri, 31 May 2002 17:26:42 -0400 (EDT) Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4VKr4J09116 for ietf-openproxy-bks; Fri, 31 May 2002 13:53:04 -0700 (PDT) Received: from il-tlv-smtpout1.icomverse.com (comversegw.icomverse.com [192.118.48.248]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4VKr0g09111 for ; Fri, 31 May 2002 13:53:01 -0700 (PDT) Received: from il-tlv-mbdg1.icomverse.com (il-tlv-mbdg1.comverse.com [10.116.200.32]) by il-tlv-smtpout1.icomverse.com (8.11.6/8.11.6) with ESMTP id g4VKaVX05244; Fri, 31 May 2002 23:36:31 +0300 Received: by il-tlv-mbdg1.comverse.com with Internet Mail Service (5.5.2655.55) id ; Fri, 31 May 2002 23:52:48 +0300 Message-ID: <6682DE381343D511BFD400508BDD16E70188B09A@ISMAILEXA> From: "Rochberger, Haim" To: Andre Beck Cc: Markus Hofmann , OPES Group Subject: RE: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re qs-00.txt Date: Fri, 31 May 2002 23:52:43 +0300 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C208E5.1B4E7ABA" Sender: owner-ietf-openproxy@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C208E5.1B4E7ABA Content-Type: text/plain; charset="iso-8859-1" Hi Andre, Thanks for the quick reply. I see your point, but since I see the callout servers as an "expert server" who is giving a specific, non trivial service, then I can see a model of such service providers who own those servers, and whoever has a trusting relations with - it may give that service to, and charge for it. Now I don't think the issue should be whether they are close by or not, but since there could be a situation that performance both on a specific message, and the OPES engine, is important, then the question is if I can propose to add an OPTION for the OPES engine to specify in the callout protocol (whatever it will be) a list of the trusted servers and their order, and insert a security signature on the list so that the chain of trust can be achieved, and billing too. and add mechanism so that each server on the chain must notify the OPES engine on his activity and status in a secured way, This can eventually be an option that in the local domain with no performance issues be ignored... but if the implementations WILL need it and will not have it standardized - will not use this OPES mechanism altogether. I do understand that this is a "second stage" issue now - as the first specification still on the way, but if someone volunteers to take this issue under their wings...? Are there other members who feel this should be at list optional ? Warm regards, Haim Rochberger System Architect Comverse Mobile Internet & Broadband Division Office: +972-3-766-9121 Mobile: +972-54-970-504 Email: Haim_rochberger@comverse.com -----Original Message----- From: Andre Beck [mailto:abeck@bell-labs.com] Sent: Fri, May 31, 2002 5:29 PM To: Rochberger, Haim Cc: Markus Hofmann; OPES Group Subject: Re: http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re qs-00.txt Rochberger, Haim wrote: > Is it still possible to add this requirement ? I mean chaining callout > servers ? > > This may improve the performance in case you have a few callout servers > that need to handle a specific message in order. Callout server chaining would add a lot of complexity to callout transactions and callout servers, e.g. in terms of error handling, fail-over, tracing, trust relationships etc. I can only see performance benefits in cases where the distance between the callout servers is shorter than the distance between the OPES processor and the callout servers. However, I think whenever the performance of callout transactions is critical, it is much more likely that the callout servers will be co-located with the OPES processor, i.e. in the same domain. Hence the distance between the OPES processor and callout servers would be similar to the distance between the callout servers and there wouldn't be much of a performance benefit any more with callout chaining. -Andre ------_=_NextPart_001_01C208E5.1B4E7ABA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: = http://www.ietf.org/internet-drafts/draft-ietf-opes-protocol- re = qs-00.txt

Hi Andre,

Thanks for the quick reply.
I see your point, but since I see the callout = servers as an "expert server" who is giving a specific, non = trivial service,

then I can see a model of such service providers who = own those servers, and whoever has a trusting relations with - it may = give that service to, and charge for it.

Now I don't think the issue should be whether they = are close by or not, but since there could be a situation that = performance both on a specific message, and the OPES engine, is = important, then the question is if I can propose to add an OPTION for = the OPES engine to specify in the callout protocol (whatever it will = be) a list of the trusted servers and their order, and insert a = security signature on the list so that the chain of trust can be = achieved, and billing too. and add mechanism so that each server on the = chain must notify the OPES engine  on his activity and status in a = secured way, This can eventually be an option that in the local domain = with no performance issues be ignored... but if the implementations = WILL need it and will not have it standardized - will not use this OPES = mechanism altogether.

I do understand that this is a "second = stage" issue now - as the first specification still on the way, = but if someone volunteers to take this issue under their = wings...?

Are there other members who feel this should be at = list optional ?

Warm regards,

Haim Rochberger
System Architect
Comverse
Mobile Internet & Broadband Division
Office: +972-3-766-9121
Mobile: +972-54-970-504
Email: Haim_rochberger@comverse.com <mailto:Haim_rochberger@comv= erse.com>



-----Original Message-----
From: Andre Beck [mailto:abeck@bell-labs.com]
Sent: Fri, May 31, 2002 5:29 PM
To: Rochberger, Haim
Cc: Markus Hofmann; OPES Group
Subject: Re:
http://www.ietf.org/internet-drafts/draft-ietf-opes-pr= otocol- re
qs-00.txt


Rochberger, Haim wrote:
> Is it still possible to add this requirement ? = I mean chaining callout
> servers ?
>
> This may improve the performance in case you = have a few callout servers
> that need to handle a specific message in = order.

Callout server chaining would add a lot of complexity = to callout
transactions and callout servers, e.g. in terms of = error handling,
fail-over, tracing, trust relationships etc. I can = only see performance
benefits in cases where the distance between the = callout servers is
shorter than the distance between the OPES processor = and the callout
servers. However, I think whenever the performance = of callout
transactions is critical, it is much more likely = that the callout
servers will be co-located with the OPES processor, = i.e. in the same
domain. Hence the distance between the OPES = processor and callout
servers would be similar to the distance between the = callout servers and
there wouldn't be much of a performance benefit any = more with callout
chaining.

-Andre

------_=_NextPart_001_01C208E5.1B4E7ABA--