We held an OPES workshop adjacent to the CND2001 conference on Feburary 20,
2001.
It was an active workshop with all attendees participating in the
discussion and adding to
the vision behind OPES.
The topics presented and the main speakers were:
o Introduction and OPES IETF status report - Condry
o Rule and proxylet specifications ? Beck and Hofmann
o Rule language and rule engine processing requirements clarification
? Yang
o Proxylet naming and meta-data - Maciocco
o Protocol characteristics for rulets and proxylet downloading ?
Maciocco and Yang
o Some details on examples ? Beck and Hofmann
o Using BXXP for extended proxy services - Orman
o An API for generic proxy services - Orman
o Open discussion - all
Associated with the presentations were many items identified were
discussion is needed within
the OPES architecture.
1. Rule Ordering ? the service requests are defined by a set of rules
indicating when action
should take place on associated proxylets, code fragments, that indicate
the action to be
preformed when indicated by the rules.
* The IRML, previously PSRL, language is one means of specifying
rules. Overall
collection of dependencies between rules was thought of being out of scope
of IRML
and to be handled separately. The question came up whether there should be a
separate language for describing these dependencies or whether IRML should be
extended to allow for these dependencies?
* Pattern matching is the key indicator by the rule system. What
about other service
considerations, such a local environment conditions?
* What is the process for sequencing the rules? Is this a policy
framework? Even if this
is vendor dependent some requirements and process for achieving the desired
policy
needs to be specified.
2. Are there distinctions for the rules for surrogate vs avatar
systems? (Beck)
3. In the policy the rule "owner" needs clarification. Currently
"owner-id" appears to be an
overloaded term. A mixture of "security needs" and "rule specifier"
overload the term.
4. A "valid through" concepts needs to be added to IRML. For example,
a way to specify
that a rule is valid only for a certain time or certain days.
5. Should rules (and proxylets) be allowed to be contained within the
content. There were
mixed opinions here, many view the rules in a less dynamic manner. Possibly
a solution
would be to expectations of meta-data and the rules act upon the content's
meta-data
and thus can provide the necessary dynamic features because the meta-data
can be
changed with the content.
6. The administration characteristics with rules needs further
specification. Some
environments have a single administration box for several OPES boxes. Do we
need to
specify a protocol for the communication between the administration box and
OPES units
or are existing ones adequate.
7. Some actions, such as transcoding, have rules as well. Are these
represented in our rule
system or in some outside source? For example, in transcoding should the
desired
characteristics of the transcoding operation be passed on to the
transcoding process
(internal or callout server) or do the rules qualify the particular
transcoding operation and
that particular process is called. If all items were transcoded each time
this might not be
an issue; but if we need to select between a cached transcoded item and the
conversion
process its becomes more complex. How is this determined and represented?
Part of this
problem space is "out of scope" but we need to clarify the scope in this area.
8. What are the requirements for the content that gets passed on after
any OPES service
transformation? How are things marked (headers, meta-data, etc.)? What
conditions
allow for changing this information for the next box in the sequence? This
came up later
in examining what might be modified in headers in moving the data through
the OPES
process chain.
9. Some examples showed state in the rule base. How do we keep from
creating state as
part of the rule set? Again marking and meta-data may be the avenue here
for preventing
unnecessary state management.
10. Proxylet and callout service binding needs clarification.
11. Would it be a good idea to keep a "hash" of the proxylet code in
the name rather than a
separate name and code specification.
12. Much of the callout service model to date was focused on iCAP.
However it became clear
that other services will exist. Is there some meta-data for callout
services. A repeated
thought is the transcoding problem noted earlier. The meta-data seems to be
the avenue
to determine what is in the cache and if a transcoding operation is necessary.
13. Should the proxylet specification include some operational rules
that are indicated to
execute the proxylet. We have been looking at rules as coming from the
customer (or
receiver), service provider (opes provider), and content owner (CDN).
Discussion did
indicate that the proxylet should have a final say in the condition of
execution which
implies that the proxylet has this final condition set.
14. The protocols between the control planes and data planes were
discussed. Should we
use existing ones like FTP or email? What about SOAP and LDAP? This was
left as a
TBD with additional functional clarification needed for the architecture.
15. Understanding the informational data model is needed and should be
added to the
requirements.
16. Request process needs to be clarified. Can the end-user request for
attributes? Should
they? (Hilarie)
17. Examples allow for many forms of services and others were
discussed. Although the end
target will allow for these services does it make the problem space too
complex for the
IETF to make progress so would focusing on less services for now be better?
18. BEEP has some interesting characteristics that might be employed in
the OPES
environment. This needs to be examined in more detail and we will hold a
discussion at
our next meeting/BOF.
19. A generic API needs to be defined in order for "open" proxylets to
be written. APIs are
generally viewed as an "in the box" rather than "in the network" and thus
not considered
at the IETF. This has to be sorted out.
20. One more issue that was discussed in many side conversations was
how rule modules
affect cacheability. Here is an example: a rule is defined to call an icap
service only
between the hours of 9 and 5, but the icap service itself does not know
this. I would say
that the result is cacheable only until 5:00, even though the icap service
has not reflected
this in the cache directives. There are a broad class of similar problems:
if a rule module
is updated, for example, does that invalidate cached entries? How does
that affect
dowstream proxies that may have cached the result?
21. The edge concepts does break existing IETF ideas in the end-to-end
delivery model (like
IPSEC). Edge services are going to happen and having the IETF embrace them
at this
stage rather than ignoring them would be best for all.
22. The lack of communication from the APPS area directors has made
this a challenging
project to keep alive within the IETF community. However, the momentum is
getting
stronger. How do we help resolve whatever problems are causing this so that
the efforts
can move forward?
Attendees:
Michael Condry condry(_at_)intel(_dot_)com
Sherif Kottapurath sherif(_at_)india(_dot_)sun(_dot_)com
Jeff Einarson jeff(_dot_)einarson(_at_)intel(_dot_)com
Jeff Noah jeff(_dot_)noah(_at_)intel(_dot_)com
Lily Yang lily(_dot_)l(_dot_)yang(_at_)intel(_dot_)com
Markus Hofmann hofmann(_at_)bell-labs(_dot_)com
Andre Beck abeck(_at_)bell-labs(_dot_)com
Micah Beck mbeck(_at_)cs(_dot_)utk(_dot_)edu
Lee Rafalow rafalow(_at_)raleigh(_dot_)ibm(_dot_)com
Phil Rzewski philr(_at_)inktomi(_dot_)com
R. McElrath rmcelrath(_at_)anystream(_dot_)com
Jayanth Mysore jayanth(_dot_)mysore(_at_)motorola(_dot_)com
Christian Maciocco christian(_dot_)maciocco(_at_)intel(_dot_)com
Paul Eastham eastham(_at_)netapp(_dot_)com
Hilarie Orman horman(_at_)novell(_dot_)com
Craig Blitz cblitz(_at_)novell(_dot_)com
Mark Nottingham mnot(_at_)akamai(_dot_)com
Please reply to Condry(_at_)intel(_dot_)com for comments and additions to the
workshop.
Michael W. Condry
Director, Network Edge Technology