Re: Charter updates, changes, etc.
2001-03-27 20:37:26
At 01:49 PM 3/26/2001 -0800, Ian Cooper wrote:
I've attempted to combine both Michael's and Hilarie's comments together
below.
At 08:13 3/23/2001 -0800, Ian Cooper wrote:
At 07:21 3/23/2001 -0800, Michael W. Condry wrote:
Description of Working Group:
The Open Pluggable Edge Service (OPES) working group primary
task is to define a protocol to be used to extend
participating transit intermediaries to incorporate services
executed on application data transported by HTTP and
possibly RTP protocol suite. The protocol provides a framework for
integrating a wide range of services into arbitrary
intermediaries. Intermediaries may employ either local or
remote ("callout") servers to perform a service, and as a
result, the data may be diverted temporarily over a closed
loop pathway different from the transit pathway.
The value of the "remote" or "callout" server is that it can be
provisioned elsewhere on the network, not in the transit pathway.
Michael wrote:
I thought that was clear it was out of the transit pathway. What's confusing?
It's not confusing, and the paragraph wasn't meant to stand on its own.
I may be projecting my own thoughts, but in the meeting we said that
SMTP should be out of scope, since services such as virus checking are
typically provided by the introduction of another SMTP relay (and this
notion in SMTP is well established). Service introduction in HTTP could
also be provisioned within a proxy on the transit path. The use of a
callout server "only" seems to gain you some control over possible loops
and the avoidance of complication of transit pathways.
Michael:
Ian, yes SMTP was out of scope. Just how do you read it in?
Hilarie:
[Yes, we did say that SMTP was out of scope, but the charter
seems to be fairly clear on that point, does it not?]
Yes, the proposed charter made the scope clear. (That doesn't necessarily
mean that the scope of the proposed charter is "valid" until the list
comes to consensus. I wanted to provide those folks who didn't manage to
attend the meeting some additional context since this charter was being
rushed to last call before the minutes of the meeting were available anywhere.)
I probably didn't do a particularly good job of /explaining myself.
My understanding of the specific exclusion of SMTP was that (to
paraphrase) "to provide services in that model, you simply pass things
through another SMTP relay". Fine. You *could* allow the callout
mechanism to include SMTP within scope, though it seems the group doesn't
want that. Fine. (Why?)
I believe that the charter covers more than enough material. After some
developments
from he working group such as callout server protocol(s) and an understanding
of the policies, then we can expand things along avenues that are discovered to
be suitable for this framework.
I think my point is that the initial text wasn't particularly clear that
the whole point of the service provision model in OPES is built around the
notion of a callout server, and the control protocols of OPES devices.
That is the first deliverable. Are you thinking that an OPES device that
decides
to do something locally conflicts with a hidden agenda of WEBI?
"Intermediaries may employ either local or
remote ("callout") servers to perform a service, and as a
result, the data may be diverted temporarily over a closed
loop pathway different from the transit pathway."
I know my issues are with network architecture (for the large part), but
if you're using the transit pathway to get the services, you could just as
easily provide the services on an upstream within-transit-pathway proxy
and do without the callout. And yet that's explicitly out of
scope. Perhaps you're trying to cover too many issues in a short amount
of text?
Local services are not the focus today. This does not exclude them from being
in a re-charter as we discover the protocols that the IETF needs to focus on
in that environment. For example, administrative protocols may be defined
regardless of the service being a callout or not. No hidden agendas here,
we will certainly consider this in a re-charter if things are suitable to do
that way.
I'd also suggest removing the parentheses around "callout", since that -
to me - suggests that it's only a callout in the case of a remote
server. And if it's not a callout on a local server (what's the
difference between the OPES intermediary and the "local server?) then what
is it?
I believe that we have been using the "callout" and "remote" server terms
interchangeably.
Intermediary services provided in this way are not
transparent: Either the content requestor or provider will
be aware that a transformation has been performed.
Did we remove the case where the access provider is the one controlling
the transformation?
I misread this part of the text. My bad.
As part of the development of this protocol the working
group will produce an analysis of the security implications
of this architecture.
I'm not too sure how I see this as being different to the security
considerations part of any protocol documents.
Michael:
I think that Hilarie's point is quit interesting and worth discussing.
I don't disagree with you. I was commenting on the *context* of where the
discussion would be reported, that's all.
Hilarie:
[The WG needs to discuss this; my understanding of the
charter is that the 'integrity' of the content and authorization
of services based on roles and identities and signatures is
all part and parcel of the 'security considerations' in this case.
Also, the assurance of the 'awareness' of the authorizing
parties for each (?) service action.]
My point was that the wording of the paragraph strongly suggested that the
group will produce a security implications *document*. Of course a WG
would have to discuss security consideration - you're unlikely to get very
far with IESG without it. And that's my point. I guess there's little
harm in including the above wording, but it seems rather redundant?
(That said, 2186/7 cover this stuff separately, so there probably isn't
too much of an issue.)
The iCAP protocol already provides similar functionality and
this working group may elect to use iCAP as a starting point
for its work. However, the working group is not obliged to
retain any level of compatibility with iCAP.
This paragraph seems redundant. It seems to make more sense to have
iCAP as a draft for consideration within the group, but I'm not sure it
belongs within the charter description text.
Michael:
lets see what other's think.
Hilarie: (former co-chair, you went and changed just to make it hard!)
[I agree]
Yes, we could drop that. Having one direction to consider is not
a bad idea. I would like the thoughts of others.
That makes two of us :)
Jul 01: iCAP Protocol document last call.
But you said you wouldn't be obliged to maintain compatibility with iCAP.
So either you're using the name to mean "something that doesn't look
like iCAP does at the moment" or you mean "we may recharter to change
this goal".
Hilarie:
[I read this as "being as you've got to start from ICAP, you might as well
ratify it as an existence proof of there being at least one acceptable
protocol. You can later decide that you've got requirements that
supercede ICAP, but ICAP will still be useful for some solutions."]
We do not have others submitted. I am hoping to get some alternative
discussions started at our next workshop (early June timeframe).
Whoa! Who said we *have* to start from iCAP?
I assume, at the least, that the plan is to take iCAP to Informational.
iCAP has been submitted. Are you ready to submit an alternative one
on our schedule?
Michael W. Condry
Director, Network Edge Technology
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Charter updates, changes, etc., Michael W. Condry
- Re: Charter updates, changes, etc., Hilarie Orman
- Re: Charter updates, changes, etc., Thomas Hardjono
- Re: Charter updates, changes, etc., Hilarie Orman
- Re: Charter updates, changes, etc., Ian Cooper
- Re: Charter updates, changes, etc., Thomas Hardjono
|
|
|