ietf-openproxy
[Top] [All Lists]

Draft of OPES Special Meeting minutes

2002-01-14 11:29:49


Thanks to Ted Hardie for the superb job on these!  A few
bits of chair-editing took us too long, but do still let us
of any glitches in the minutes.  

Ned, Patrik and I are actively discussing the charter process
now, and we hope to give you news on that soon.

Allison and Ned

------
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 is a variety 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.

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 network.  Function moves from one
function 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
side 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 ACAP in the
documents.

Ned: That wraps us up, thanks everybody.

- ------- End of Forwarded Message


------- End of Forwarded Message


<Prev in Thread] Current Thread [Next in Thread>