Subject: RE: Strawman OPES Charter

From: "Abbie Barbir" <[email-masked]>
Date: Tue, 13 Jul 2004 07:42:14 -0400

All,

See inline.

Abbie

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]] 
> Sent: Tuesday, July 13, 2004 1:58 AM
> To: Markus Hofmann
> Cc: OPES Group
> Subject: Re: Strawman OPES Charter
> 
> 
SNIP

> > In addition, the WG will define one or more methods for specifying 
> > rules that enable application endpoints to control the execution of 
> > OPES services. These methods are purely for controlling the 
> invocation 
> > of services. They are not aimed at implementing the actual services.
> 
> The reference to "application endpoints [controlling] the 
> execution of OPES services" confuses me. It seems to imply 
> that endpoints are controlling the execution of services. We 
> usually say that endpoints authorize the execution of 
> services (and may supply the rules), but execution is done by 
> the OPES dispatcher.

--- abbie 
agree
> 
> Also, "purely for ... invocation" may be read as "and not for 
> selection of which services to invoke".
> 
> Finally, can we be more precise than "methods for specifying 
> rules"? Do we really intend to specify more than one method? 
> Can it be anything other than some sort of configuration 
> language like IRML or P?
> 
> How about:
> 
>   In addition, the WG will define a configuration language to
>   control OPES dispatcher selection and execution of OPES services.
>   Defining language(s) for implementing OPES services is out of the WG
>   scope.
> 
--- abbie
agree, we need to be specific here.

> > The working group will have a design goal that the methods be 
> > compatible with existing policy work within the IETF (e.g. 
> IETF Policy 
> > Framework) and be able to interface with systems automating 
> > distribution of policies to multiple endpoints. It will be out of 
> > scope for this WG to develop the policy framework and specify 
> > multiple-endpoint policy distribution.
> 
> > The group's new work items can be listed as:
> >
> > - Define a SMTP profile to supplement OCP core.
> 
> To partially address SMTP agent concerns, how about:
> 
>   - Define a SMTP profile(s) to supplement OCP core.
> 
> > - Define specification method(s) and rules for controlling
> >    invocation of OPES services operating on HTTP/SMTP
> >    messages.
> 

-- abbie 
agree

SNIP

> I would also consider changing the deadlines to OCT04. It 
> does not take long to publish a draft. Some even consider the 
> deadlines like the first one above meaningless because the 
> "initial document" can be a placeholder, but we can play the 
> game and have an extra "Done" on our record.
> 

--- abbie
agree, but no games here. the imnitial document is a place holder.

SNIP

> 
> Other concerns:
> 
> Would it be appropriate to mention that the rules work will 
> be based on P language specification that WG has already 
> worked on? Or are we going to re-select among P, IRML, and 
> others as a starting point?
> 
> If we are going to re-select, should we start with a 
> "language requirements" document?
> 

-- abbie
obsultly, yes we should do a requirement document.

> Even if not based on P, OPES rules language is likely to have 
> modules/parts that are application protocol specific (e.g., 
> SMTP and HTTP modules). Are we implying that the WG will 
> specify those modules for HTTP and SMTP? Are we implying that 
> the WG will specify those modules inside a single "OPES rules 
> language" specification? I think those modules should be 
> described separately from the language itself. Like "C and 
> stdlib" or "Java and J2EE". Can/should we reflect that in the Charter?

-- abbie
yes, we need to be as specific as we can.

> 
> Finally, are the following items in scope?
> 
> 	- Defining how available services become known
> 	  to the rules language interpreter? (At least
> 	  OCP-speaking services)
> 
-- abbie
yes, even if we state that is hard coded (in the least case)

> 	- Defining an interface between rules language
> 	  and service (at least OCP-speaking service)
> 	  How to pass parameters to services? How to
> 	  get the result of service application, including
> 	  errors, back to the language/program?
> 
--- abbie
this is a muddy situation. we can rely on other work or at least reference
how they handel it (examples, BPEL, CDL etc..)

-- abbie

other objectives:

1. Security for OCP, should we mention that the group might attempt to do
that as part of the charter or not. It can be a MAY deleiverable.

2. Need to ensure that IAB requirements are still applicable to any new
protocol we address. This MUST be in the charter. Our previous work
addressed the general acrhitcecture but has focused on HTTP.

ABbie

---

From: Markus Hofmann <[email-masked]>
Date: Tue, 13 Jul 2004 10:17:09 -0400

> obsultly, yes we should do a requirement document. 

I disagree on this one. We already spent plenty of time discussing 
requirements and writing them down in the "Policy, Authorization and 
Enforcement Requirements of OPES" document. I don't want to start all 
over again.

I assume that the rules work will be based on "P", as we've already 
burned many cycles over this. Unless somethig imprtant has changed, 
let's start from there.

> yes, even if we state that is hard coded (in the least case) 

Service discovery is out-of-scope for this round.

> this is a muddy situation. we can rely on other work or at least
> reference how they handel it (examples, BPEL, CDL etc..)

Not sure whether we all talk about the same thing here. To me, all we 
need is a way that allows us to specify parameters to be passed on to 
a service and to consider the result of a service invocation in later 
rules.

For example something like

  if (condition is true)
   invoke (Service A with parameters x, y, z)
  if (result of Service A was OK)
   do this.

> other objectives: 
> 
> 1. Security for OCP, should we mention that the group might attempt to
> do that as part of the charter or not. It can be a MAY deleiverable.

No MAY deliverables. Either we do it or we don't. At the moment, I 
would *not* feel comfortable to broaden the scope. Let's get the 
currently discussed items done, and then we can take on new ones.

> addressed the general acrhitcecture but has focused on HTTP.

This is already in the proposed charter, you probably overlooked it. 
It says "Each deliverable must follow the previously developed OPES 
architecture. As each deliverable is developed, it must address the 
IAB considerations specified in RFC 3238.'

Thanks,
   Markus

---

From: Alex Rousskov <[email-masked]>
Date: Tue, 13 Jul 2004 09:54:28 -0600 (MDT)

> obsultly, yes we should do a requirement document.

Abbie,

Just to make sure: which of the following you consider essential:

	a) forget about P choice, start from scratch, write a
	   formal "language requirements" document, then select among
	   IRML, P, and possibly other candidates.

	b) confirm past P choice, but write a "language requirements"
	   document or section, before proceeding with polishing P

	c) confirm P choice, and do not write a "language
	   requirements" document/section

> reference how they handel it (examples, BPEL, CDL etc..)

I think there is an important difference between reusing existing work
and not doing any work.

First, we need to decide whether we should define the said interface.
The first charter draft does not seem to include it. Iff we are
chartered to define the rules-services interface, then I would look at
reusing WSDL core for describing OCP-talking callout services and
describing a P:WSDL mapping of sorts (a BPEL equivalent for OPES?).
However, if we are not chartered to define the rules-services
interface, then WSDL and other W3C-technologies reuse becomes
irrelevant/future work.

It seems to me that we must have a P-services interface because
without it, how will P interpreters map service calls to OCP
transactions? How will they make service parameters available to P
programmers to set? Will P interpreters report service failures in a
consistent way across implementations? All these questions were
already on P and even IRML to-do list, IIRC.

If we decide to go down that path, the second question becomes whether
the P-services interface is OCP specific or more general? Do we want
to restrict P-invokable services to OCP-talking services? To any
WSDL-describable services? To something else? Should this important
decision be done now or after we finish the new charter. That is, do
we add the answer or just the action item to the charter?

> 1. Security for OCP, should we mention that the group might attempt
> to do that as part of the charter or not. It can be a MAY
> deleiverable.

I was under impression that we agreed that security is very important,
but we have not enough cycles to include it in the new charter. OCP
security features may be described in individual draft(s) that the WG
might adopt later, through a charter modification. Can you give me an
example wording for a "MAY deliver" of OCP security specs?

> 2. Need to ensure that IAB requirements are still applicable to any
> new protocol we address. This MUST be in the charter. Our previous
> work addressed the general acrhitcecture but has focused on HTTP.

Markus already has the following wording:

	As each deliverable is developed, it must address the
	IAB considerations specified in RFC 3238.

It seems sufficient to me. Do you want more text added?

Thanks,

Alex.