ietf-openproxy
[Top] [All Lists]

RE: draft-tomlinson-opes-model-00.txt

2001-07-26 19:41:49
Hi Gary/Markus,

First of all this is good stuff, really a major rewrite. Here it goes my
comments on the new draft:

General:

First IMO the draft it too biased on "Content Networks". OPES can provide
"Content Services" to any network that provide content to the user. 

If I am requesting content to a server directly, without any CDI
infrastructure in place, I can still benefit from OPES Services. Tying OPES
to Content Networks imply a coordination of devices following the CDI model,
in place, which may not be true and also makes the OPES more restrictive.
OPES exists independently of CDI.

Also, the term "content services" is a little bit vague. I believe that
different interpretations can be given to this term. I mean, is virus
scanning of email a content service? I believe the answer is yes, but then I
do not think CDN will be distributing emails, which goes back to my first
point.

The use of the term "overlay network" is also confusing. When I read overlay
networks I think of tunneling, MPLS VPNs, VR, etc. In other words a overlay
network is a virtual network that has a different IP addressing scheme or
purpose then the network used for transport. I hope I am not getting too
philosophical here.

Content Path should be subdivided on in-path and out-of-path. When OPES
devices are in-path of the normal data flow, content path and data path are
the same. Otherwise they are out of path. OPES, differently from MIDCOM,
deals also with OOP devices, that's why the need of protocols like ICAP,
SOAP, etc

Specifics.

Introduction, second paragraph:

In addition to talking about PDA, software upgrades, etc I think a good
straight to the point argument why we need OPES services is analogous to why
we need MIDCOM. In other words, this is a problem of intelligence, where
intelligence in the network will reside. In theory we could put all kinds of
funcionalities in routers or end clients, but this doesn't scale, is not
possible from a unique vendor perspective or some other reason. 

Section 4.1.1

Another scenario is where the OPES intermediary is owned by an access
provider, which resell its services to ISPs or enterprises. Very common
these days

'OPES Internmediary' is owned by an access provider: In this case the access
provider sell content services such as virus scanning and URL filtering to
the ISPs and enterprises that are connected to its network.

Section 4.1.2

small typo: cahce
should be: cache

Section 4.1.2.2

Saying that "Local operations typically run in the 'fast path' of the 'OPES
engine', since they generally can be performed at 'wire speed'" is not
correct. This depends on the application, operation performed on the
content, device, etc, etc

'Fast path' definition and use in the text should be totally seprated from
the fact if the operation is local or not. As you put more applications
in-path the less likely you are going to be doing them fast and efficiently.


Section 4.1.2.3, first paragraph

Again saying that "Remote operations run in 'slow path'..." is not correct.
I might put a virus scanning engine local to the OPES intermediary and the
loose peformance when compared if I offload it to a remote call-out server .
This slow and fast path is too dependent on several variables.

Section 4.1.2.3, second paragraph

"End-to-End encryption also precludes the use of any value-added services
through a 'remote call-out server'". 

This has to be further expanded.

In end-to-end encryption, the 'edge services' network does not disapear,
it's just moved near the IPsec termination device, and in this case user
might also get value added services. I can use a IpSec client, connect to my
company in the other side of the world and still get remote call out
services such as language translation and URL filtering.

This would be the "'OPES Intermediary' is owned by enterprise model" that
you mentioned.

Of course if the OPES intermediary is between the IPsec end points then I
agree.

Section 4.2

"..are usually employed in a OPES framework to either offload the OPES
Intermediary for better scalability.."

This is good example of why the fast path vs slow path should be avoided in
regards of where the operation is peformed. If they scale better as you said
then although they are out of the content path, they are in the 'fast path'
mode of operation.

Section 5.4, third paragraph

"If the coomunication channel between the OPES Intermediary and the remote
call-out server is snooped, the attacker may gain access to sensitive
information."

Information that will eventually be sent to the end user. So in this case we
should also encrypt the traffic between the end user and the OPES
Intermediary, which breaks the OPES model or require the OPES intermediary
be a encrytion device. 

If information is really sensitive, it would be encrypted end-to-end and the
only remote call out server which could insert/modify anything would reside
on the companies network. IMO This goes back to the discussion on section
4.1.2.3

hope this helps,

Reinaldo Penno
NortelNetworks








 
























<Prev in Thread] Current Thread [Next in Thread>