RE: Strawman OPES Charter

All,

See inline.

Abbie


> -----Original Message-----
> From: Alex Rousskov [mailto:[email protected]] 
> 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