On Fri, 7 Nov 2003, Geetha Manjunath wrote:
Using a language like 'P' (or something similar) to control
activities at the OPES can throw up several interesting
opportunities...
* The P language (interpreted) would help one to define the dynamic
behaviour of an OPES processor.
* The above control to change the behaviour can be left to the
administrator to support QOS needs. However, interesting
possibilities and challenges will open up if we let 'others' define
the behaviour.
* For example, if a user is able to define his/her own 'P' program
(ruleset) and send a link to that as a part of the request itself,
the request/response would get modified somewhere along the path
whereever that service is available! That is a good thing for the
user! Ofcourse, the fallback action on failure to do so would also
be provided by the user.
* Similarly, the content provider could define a P program and send
it across as one of the response headers (in HTTP for eg). Now,
depending upon the local characteristics of the network, a specific
adaptor would be invoked. This adaptor can be provided by the
content provider himself. [ I understand that IRML supports
specification of rules by client and content provider but there is
no standard way of communicating the same to an OPES processor...]
There are two distinct (IMO) things that you are mixing above. First,
is the rule authorship. I agree that there are 2.5 possible authors
here: data provider, data consumer, and intermediary administrator
acting on behalf of provider or consumer. All these authors are in
scope and must be supported by OPES. All other authors are out of
scope (but may still be supported as a side effect, of course).
We indeed have not documented authorization aspects related to ruleset
authorship versus content ownership versus hop ownership versus
service ownership. I suspect there are existing solutions here such as
IETF Policy Framework mentioned in our current charter.
The second thing you mention is message-embedded rulesets. This is the
"Active Networks" territory and we are going to alienate at least half
of IETF folks if we are not extra careful. Combining Active Networks
with OPES Adaptations in one context is likely to cause an explosion
of emotions within IAB and IESG. However, I do not think that any
direction should be banned for that reason alone. Can you provide a
couple of specific use cases that we could address with
message-embedded rulesets? Is there a real need? If we have specific
use cases in mind, we may be able to achieve what you want without
disturbing the Active Adaptation daemons.
Note that one of the P goal was to allow for embedded rulesets. Now it
is time to ask the question whether that feature is needed and, if
yes, how we can address those needs.
Now , this may inturn throw up standardization needs for the following:
* how does one specify/name an OPES service?
We tackled that when doing OPES Communication draft. OPES service can
be identified by one or more URIs. If we can agree on the URI-based
identification, the rest is probably out of P scope.
* discover an OPES service,
This should be out of WG scope for the next round, IMO.
* authorization and authentication of the person to deploy a P
program on an OPES processor
The core of this problem (adaptation authorization and authentication)
is out of P scope, but, ideally, the WG should address this problem.
It is in our charter, but there are no specific deliveries.
* some work in sand boxing capability to P language itself
Yes. And this is unrelated to embedded rulesets and other items above.
* Definition of protocol specific interfaces available from P
Yes, we need to define HTTP and possibly other modules. I have
included that on my suggested items list as well.
* Specifying mandatory protocols that need to be supported by an
OPES
I do not think any application protocol support can be mandatory. We
cannot require OPES to support HTTP or SMTP, for example. Or did you
mean something else?
* Way of negotiating on where a specific filter is best executed
Sounds like a sub-problem to service identification above and, hence,
an external to P issue?
* If we allow the user-specified modifications (or end point requested
adaptation) to look at lower layers (IP and below), it throws up another
possibility of end nodes defining the protocol to some extent...
I see no good reason to limit P or OPES adaptations to any specific
layer on a protocol level. The only question is whether this WG
should, for example, define an IP adaptation module/specification? I
doubt because we do not have the expertise and are in the wrong IETF
area (but others can do that). However, we can define a P module that
provides (read-only) IP-level information, for example. We would need
good use cases to justify such development, I guess.
I guess we could use some existing protocols for some of the above
needs or modify some existing ones - but it definitely needs some
serious exploration/consensus as per my understanding...Is it worth
putting these under the purview of OPES?
IMO, some of the things you mentioned are in OPES scope, and some
others can be in scope if you manage to convince the group and IESG
with good rationale/examples. Please see detailed comments above.
Thank you,
Alex.