Subject: RE: WG Review: Open Pluggable Edge Services (opes)

From: "Maciocco, Christian" <[email-masked]>
Date: Wed, 20 Jun 2001 10:09:22 -0700

> but this isn't what's controversial about OPES.  what's controversial is
the notion that > the transformations enabled by OPES might also occur in
the interior of the 
> network, without being explicitly authorized by either the source or the
destination.

Keith, 
From what I read from the charter below it seems to at least address some of
your concerns. Answer to these concerns should come from a collaborative
architecture/engineering effort within an IETF WG.

<FROM CHARTER>
Intermediary services provided in this way are not transparent: They have to
be authorized by either the content requestor or the provider, corresponding
to who the service being provided for.

As part of the development of this protocol the working group will produce
an analysis of the security implications of this architecture.  

A secondary task for this working group is to enumerate the requirements for
management policies and associated administrative protocols that allow these
services to be specified and deployed. This includes requirements on the
rule systems used to specify conditions under which services are executed. 
</FROM CHARTER>

Christian

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 9:19 AM
> To: Abbie Barbir
> Cc: Paul Hoffman / IMC; [email-masked]; [email-masked]; Michael
> W. Condry
> Subject: Re: WG Review: Open Pluggable Edge Services (opes) 
> 
> 
> 
> > Content/data is/are already being 
> changed/modified/adapted/etc  in transit and
> > the IETF must deal with it sooner or later.
> 
> that follows only if the IETF can make a useful contribution 
> by "dealing with it".
> it's not clear whether this is the case.
>  
> > Ensuring that the edge is dumb is not the way to protect 
> the end-to-end model.
> > The proper way to do it is to ensure that the edge is an 
> extension of the
> > source/origin. 
> 
> agree, though I would add "or destination" to the end.
> 
> but this isn't what's controversial about OPES.  what's 
> controversial is the notion 
> that the transformations enabled by OPES might also occur in 
> the interior of the 
> network, without being explicitly authorized by either the 
> source or the destination.
> 
> Keith
>

---

From: Keith Moore <[email-masked]>
Date: Wed, 20 Jun 2001 15:51:38 -0400

> your concerns. 

There's a couple of subtle points here.  

- First of all, the WG does not have a charter yet.  It has drafted a
  charter, but IESG and IAB are not required to accept that charter
  verbatim.  Before approving a charter, IESG may change it in any way
  that it sees fit (and that is required to get IESG and IAB to approve
  it).

- The message sent to the new-work list (and thus to ietf-announce)
  contains a description of the work, which is not the same as the
  charter.  It is this description to which I was objecting.  

  Since we do not know what version of the charter will actually be
  discussed by IESG, the message to the new-work list is the best we
  have to go on.

- Now please notice the difference between the text that you quoted 
  (apparently from the WG's draft charter) and the description posted 
  to new-work:

From the draft charter:

] Intermediary services provided in this way are not transparent: They have to
] be authorized by either the content requestor or the provider, corresponding
] to who the service being provided for.

From the description posted to new-work:

] Intermediary services provided in this way are not transparent: 
] Either the content requestor or provider will be aware that a 
] tranformation has been performed.

> Answer to these concerns should come from a collaborative

Obviously the details could not entirely be worked out by IESG.
But this work is potentially so dangerous that IMHO IESG should either
place strict constraints on the WG while chartering it at all, or 
require those details to be worked out by the WG before chartering
it to do further work.

Keith