[Top] [All Lists]

Re: Charter updates, changes, etc.

2001-03-26 14:49:28
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.

Ian, yes SMTP was out of scope. Just how do you read it in?

[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 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.

"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?

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?

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.

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.

[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.

lets see what other's think.

Hilarie: (former co-chair, you went and changed just to make it hard!)
[I agree]

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".

[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."]

Whoa! Who said we *have* to start from iCAP?

I assume, at the least, that the plan is to take iCAP to Informational.

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