Current Meeting Report
Slides


2.1.17 Open Pluggable Edge Services (opes) Bof

Current Meeting Report

Minutes, OPES Special Meeting
December 11, 2001
IETF 52
Ned Freed, Allison Mankin, Meeting Chairs
Reported by Ted Hardie

Nature of meeting: this was a special meeting, rather than a new BOF for the OPES chartering effort, in order for IESG to work with the IAB document on guidance to OPES and the OPES community, and try to get closer to a charter for a working group.

Note: Patrik Falstrom, who had been the shepherd for the OPES charter development before this, could not be present due to his attendance at the 100th Nobel Ceremonies.

Agenda:

- Presentation of IAB document providing guidance to OPES.
- Discussion of concerns presented in document.
- Charter discussion.

Decisions/Action Items:

Those present agreed that the IAB document (IAB Architectural and Policy Considerations for OPES) presented a valid set of concerns and that work on OPES could proceed according to the guidance of the document.

Those present agreed to move forward on drafting a charter by combining the proposals by Lee Rafalow and Markus Hoffman. Input includes ideas from those draft charters and from the presentation by Lee Rafalow, as it contains content which is only implicit in his draft charter.

The Meeting Chairs agreed to communicate the next steps in the process to the mailing list as soon as it had been established and confirmed a general intention to make the ongoing process as open as possible.

Meeting Review:

Ned noted that the focus of today's discussion is the IAB document on guidance concerns related to OPES. The IESG believes that the IAB has provided the guidance needed to move forward with this working group. Ned noted, however, that it is vital that the working group engage with that document.

Sally Floyd and Leslie Daigle presented IAB Architectural and Policy Considerations for OPES. Informational RFC status was approved for this draft in the normal IESG process for IAB documents.

Sally notes that the document provides a set of questions that must be answered to address the architectural concerns. There are few answers in the document; it is not prescriptive. It does attempt to point to previous IETF experience (such as 3135 on Performance Enhancing Proxies) where similar issues have been addressed.

To summarize the IAB issues: at least one party must consent to the use of the OPES intermediary; the OPES intermediary must be explicitly addressed at the IP layer by the end system; the OPES system must assist content providers in detecting and responding to client-centric actions that are deemed inappropriate by the content provider; the OPES system must assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries; the OPES architecture must not prevent users from accessing non-OPES content from content providers if such content is available; and it must be clear where such services are the result of URI resolution that the services do not constitute URI Resolution.

Questions/Discussion:

John Wroclawski: there is some assymetry in the notification language in draft; is it an asymmetric requirement?

Sally: there is intentional asymmetry. The content provider must have notification to know the changes to the content. The client has access to *somenon-OPES version from the content provider, so the notification is less stringent requirement.

Michael Condry: Commonly no non-OPES version, as the OPES device does a construction of content.

Lee Rafalow: There is presumption of a protocol when dealing with the client hitting a failure.

Sally: Imagine a virus scanner that refuses to let through a document on viruses or a language translation service that mangles an internationalization document; what recourse does the content owner have to know that an OPES intermediary is present and having an effect? That is the issue; the document is not prescriptive on how to deal with that.

Hilarie Orman: I have a range of concerns about the doc and its application to OPES. I do not have any problem with the emergence of this guidance, but I am concerned that it may produce an architecture that is less secure and less robust than is otherwise possible. As an example, the notification message requirement looks like something similar to ICMP message is required (rather than a signed manifest, e.g.).

Leslie: this is input to the working group; pushback is allowed when something scalable or workable is not possible. You must think about these things, though.

Hilarie also expressed concern that the success of the working group in getting a deployable standard is dependent on the IAB concerns.

Ned: the key thing is that these concerns must be addressed, but it is not assumed that every problem has a solution which will be developed within this working group.

Hilarie Orman: I see IPsec as a contrary example to much of this guidance, in that the service it provides is not under the users contral; there are OPES case similar to the IPsec case.

Sally: If you need to present an architecture that requires absolute transparency, then you need to deal with things like robustness enough to satisfy the overall Internet architecture.

Leslie: This is not a checklist, it is guidance, and the key thing here is to present reasoning that shows either that has been addressed or why a better overall result is achieved by not meeting this.

Leslie: Effectively, OPES is discussing extending the boundaries of a client or a server; the question that raises is whether that is really IETF work. There are lots of things inside clients or inside servers that do not meet these requirements, but those are not IETF work.

David Martin: Draft appears to require the ability to peer into different administrative domains (thinking mobility as an example).

Leslie: you can address this in terms of privacy concerns, but you need to be able to see this in terms of building blocks for an infrastructure. Whenever there is content manipulation, you have risks for content applications failing to interact correctly.

David: This goes beyond previous requirements though, to request a notification model.

Sally: yes. This is a detection mechanism that addresses failures of OPES intermediaries and related robustness issues.

Lee Rafalow: I am feeling more comfortable with recommendations than I previously felt. If this is an interactive process, we can develop answers in concert rather than getting slammed at the end of the process when stuff is in IETF last call.

Sally: If the process works well, the IAB won't hit this in the last call, but these issues remain fair game for IESG last call by any IETF participant.

Allison: The IAB considerations process has been part of charter review. The working group will be under IESG management, so it's important to note that it's IESG who will ask for the considerations to be addressed.

Ned: We cannot demand that the IAB stays involved, but we hope the document authors will stay engaged.

Leslie: We hope you internalize this, and that from this point on it works according to normal IETF principles.

Lee: Specific question on 4.2. What does this mean?

Leslie: That specific point is on reference validity, speaking to some of the text which just before it. What happens when a reference to something that has a composed nature escapes the OPES involvement--are these still universal? what are the consequences when these URIs escape?

Lee: So, what do I do here?

Leslie: I can't give you a solid answer at this moment, but you need to be able to document what will happen and give thought to it.

Lee: For example, the wsdl uddi references from W3C document specific URI behavior; is that the kind of solution we're talking about?

Leslie: No, this is not a request to register specific individual URIs. You might, however, note how registries or other resolution mechanisms help maintain the permanence of these URIs.

John Morris: The IAB document talks about server requested services or user requesed services. There were a few isp-requested services discussed on the mailing list (billing, etc.) Was this considered or discussed by the IAB?

Sally: I feel that the major concerns are about services which modify the data. If they don't modify the data, it is a privacy concern, but we have no consensus on the privacy requirements.

Leslie: You might argue that by selecting a service, you have bought into a realm but you haven't seen really seen an overt acceptance. I agree that we have not come to consensus on this.

Gary Tomlinson: This is guidance, not a set of requirements?

Leslie: These are things which must be spoken to in order to proceed.

Gary Tomlinson: So we move forward by clarifying this guidance and our our approach into requirements, until we have consensus.

Ned: There are various ways to approach this. That approach, turning the guidance into a requirements document is not a way I had seen for going forward, but it might work. I saw it as input into the development process; we have a mixed result with requirements documents -- some get us to clarity, some impose impossibilities. You can approach it either way, and the charter needs to make clear which way will be chosen.

Eliot Lear: In general, this document is great way for the IAB to show leadership. I do want to say. though, that using the client selecting an ISP to infer that the client buys into its trust realm or application architecture leads us down a slippery slope.

Leslie: true, and far more general than this specific work.

Andy Smollet: I am concerned that the document centric view of the guidance to OPES eliminates some of the original scope (streams, for example, or web services in general).

Leslie: This is the focus was presented to us, but the full scope needs to be part of the charter discussion. That scope can be informed by the document even if there is no direct match.

Andy: We need some discussion and guidance here on how those non-document parts of the scope are handled.

Sally: The document does mention things like transcoding, and speaking personally, streaming and operations like transcoding are important. Our concerns for robustness are just as valid here.

Leslie: I think these considerations apply. If you think there are bits that don't apply, then you need to document it and explain why they don't apply.

Andy: It would be useful to have the scope that OPES applies to settled beforehand so that we don't waste our time.

Allison: It needs to be specified in the charter what the scope should be; rtp and rtsp in the charter won't get there by accident or oversight.

Andy: We've got to avoid ratholing into topology discussion. We also need to recognize some enterprises may wish to enable services without a user by user approval (virus scans for example).

Leslie: Let's get some words on solutions rather than picking holes at the problem.

Ned: We need to make sure that the solutions are available, rather than making sure people use it. Think about mandatory to implement security issue. We may demand that TLS be present in a protocol, but it does not imply that all of it always runs on top of TLS.

Karen Sollins: There is a much more subtle set of problems on whether things will do what is intended related when dealing with the URI issues raised in our previous discussion of section 4.2. This is a broader problem than just breaking resolution.

Leslie: That was part of what we are trying to get out in the document.

John Wroclawski: Responding to Andy, limitation of scope is a big issue; we need to be aware that web architecture is evolving and less is strict client server issues. I think the document does this well. We need to think about the guidance very generally, not as a checklist. That way peer2peer applications and other architectures will be well treated. More generalization would be good to help us. John Wroclawski: We have to find a balance among the various people struggling to get their view heard. The IAB names that balance here as "you can protect your interests, but you have to tell people what you are doing". That's a good balance, and it is part of a good battle.

Leslie: I like the summary.

Hilarie: 3 points: It is not just responses which can be modified, requests can be modified; the document does not really focus on that. 2) there is a notion of correct and not correct. It's impossible to assign global meaning to those terms. You may have an idea of it, but there is no strong notion of correctness here (what is, for example, a correct transcoding?) 3) With regard to non-OPES content, there is already a solution. Any web server that supports SSL access supports a method of access that prevents OPES transformation, so it might be possible to push things back to servers.

Steve Bellovin: ISPs have firewalls that fake the termination by using certs traced to known CAs, often because the CAs are included in browsers they provide; users often don't know where the termination is.

Hilarie: But that's evil!

Leslie: I see correctness as something that is deterministic: you do the same thing again and you get the same result. There are objective guidelines.

Eliot: The content owner gets to say what is correct.

Sally: Who knows what the content provider will deem inappropriate? The language in the document does not describe correct there.

Gary Tomlinson: There are some areas in which coherency of URIs is already low; we can't increase that through an OPES proxy.

Leslie: Agreed.

Ned: Now on to charter discussion:

Lee Rafalow gave a short presentation on potential charter lines.
His slides can be found at http://rafalow.home.mindspring.com/opescharter.zip

Proposal for a start from almost-scratch charter. Apologies to any who he may offend. His sense is that in the year that we've been working on charter, the charter has lost coherence. Multiple edits have not helped.

He believes his draft is a change in the metaphor of how we think about the problem, not emphasis on wording. Its key points: recognize that we are dealing with the evolution of caching proxies specifically. The key difference in this proposal is to think about the problem not as services on the net, but as services provided in a specific domain belonging either to the client or the server. Services are authorized by client or its agent or the origin server or its agent and nothing else. Also, we need to address the IAB concerns.

Anwar Sadiki: What is "no other"? What are we elminating?

Lee: Not the ISP or other services; this is a metaphor change, not a focus shift.

Hilarie: So no matter what it is, we are calling it client or server centric.

Lee: Yes, there maybe some arbitrariness at times, but we should be able to live within these definitions.

John: It's crystal clear that there are third parties that play in this game. What I thought you were saying: we are limiting the scope to situations/things that could be described as client or server. That's a scope limitation and puts the larger problem to later. If you mean instead: we can bash anything into client/server, then we shouldn't go there.

Lee: It's not in our purview to deal with the legal issues of who has the right to be a third party. I think we have to limit things to things that are server-centric or user-centeric; we are not dealing with any situation where there is no consent.

Andy: In Midcom, on a similar issue, we decided to avoid a rathole by agreeing not to concern ourselves with out of path agents; it might happen or be enabled it was not a requirement. Here, we have a similar situation. We're not setting up a requirement for anything other than server or client centric models.

Lee: I think of this as the client distributing some of its application function. Virus scanning software can be on my desktop or I can use one provided by the service provider. Function moves from one location to another.

Anwar Sadiki: Doesn't this kill peer to peer functionality within this model?

Lee: Yes, but it is only within this model--there are other application models like direct addressing of virus checkers.

Karen: Do you envision an intermediary that will only be used if both sides agree to?

Lee: I am expressly not saying that. Let's discuss that later.

Sally: What makes this architecture different is that the client no longer has access to the input to the transformed data; how do the client or content provider find out that the data has been transformed before the client see it? This issue does not change just because you have called it a distributed application.

Lee: If the control plane has the data and the data plane the transformed data, does that meet the requirement?

Sally: I personally believe that it would add considerably to the robustness.

Hilarie: It seems like we have a requirement for notification in proxies that is not present for end clients.

Henrik Nielsen: I am concerned about this notion that there is one true client way of interpreting data. There is no "true" client, and any client can throw away data if they don't care about it.

John: I think we can take notification too literally; it's a high level concept and we can take it in several ways.

Marcus Hoffman: I am not sure that the term "administrative domain" used in the presentation is the right model, I think you mean authority scope or trust domain.

Lee: I agree.

Lee then presented a page assembly example that compounded client and server realms.

Lee: Whether you call this client centric or server centric doesn't matter; you've combined two administrative scopes. The canonical model is unchanged, despite the fact that one box contains both.

Harald Alvestrand: We have examples in places like email where the two parts of the model are separated by one line in the C code; we still have to make that clear in the specification that there are two parts to the model.

Andy: There is a difference between disclosure and notification. Disclosure means letting interested parties know; notification seems to imply a bunch of traffic that no one may care about. I believe our real requirement is for disclosure.

Ned: This is a useful point, but discussion should be postponed until after the charter discussion, possibly as pushback to IAB requirements documents.

Allison: Let's work our next charter discussion to make comparison, by working from Markus Hoffman's recharter draft.

Markus: First of all, sorry for short notice. I see us building an overlay network that it is entered by intermediaries; I've written the charter with that model, and taken some of the IAB guidance in slightly different way as a result of

Leslie: Lee's charter is clearer in its focus on what will be done rather than why it will be done. Take the second paragraph as an example.

Markus: I am concerned about Lee's second paragraph, in that it has too large a scope.

Leslie: Can you tease out from yours the why from the what, so it focuses on what is to be done?

Hilarie: We have been so reactive in the charter over the past year that we've lost the meaning. We're not creating a distributed application and it is not an application layer network. It is an intermediate that is riding on top of the network, within to the delivery path. These intermediaries are only appropriate in those contexts.

John Noernberg: I liked Lee's presentation, but Markus identifies the goals more specifically. Specificity is good.

Markus: Lee, do you see any fundamental difference between the two?

Lee: The fundamental difference I see: how prescriptive the charter is about the specific focus on what an application is. I don't have a problem with more specificity, but I don't like the words you use to narrow the scope.

Andy: In midcom, we had a lot of terminology and religious issues; if we can in the charter focus on an early deliverable about getting the terminology down, followed by a really clear target for what we are going to accomplish and when that would be good. We need a set of targets in order to have a sense of forward motion.

Markus: I tried to avoid using terms that took over the job of the models document.

Andy: I think there is room for a really effective hybrid.

David Martin: We may not want to use specific terms like "tracing" in the charter, we may want to back up to "develop a notification architecture".

Lee: Start with mine and fold Markus's in; avoid requirements.

Allison: We don't know who will write the charter, so it may be that we need to take care of two procedural issues: we may need requirements in the charter to keep things out of the weeds, and we need to make sure that implicit content (present in Lee's presentation) gets put into the charter.

Lee: We need to avoid putting mechanisms into the charter; we need to explictly address the IAB guidelines, but that does not mean we grab "disclosure" or "notification"

Andy: We may even be able to deal with disclosure considerations instead of very specific mechanisms.

Michael: Are there major concerns to starting with Lee's?

John: Markus is very explicit about the end to end nature of the communiccation; Lee is not so clear. We need to be clear on that.

Hilarie: I have a process request: This has gone on a long time; there has been some opaqueness about the process up to this point. What will the process be from this point on?

Allison: We will commit to making the process more open as we go through it. We also commit to more timely response. We don't have a clear sense of how we're going to proceed.

Ned: We'll make it clear on the mailing list as soon as we can.

Renaldo: Since we are re-chartering, are we certain that we wish to leave smtp out of the charter?

Michael, Ned: It has to stay out of the charter for now.

David Martin: I'm concerned about some previous statements. I feel it should be explictly stated that we don't guarantee end to end data integrity. It's too heavy a requirement and we don't want it.

Hilarie: I have published a paper on fine-grained data integrity with these services. There are things that are possible and which work.

Sally: I don't think the charter should say guarantee end to end data integrity, but it should address the IAB concerns about end to end data integrity.

Henrik: The documents discuss SOAP, but with no detail. What are the details?

Lee: There is a draft on that, and it goes along with ICAP in the documents.

Ned: That wraps us up, thanks everybody.

Slides

None received.