ietf-openproxy
[Top] [All Lists]

Some comments on draft-beck-opes-esfnep-01.txt

2000-12-04 17:55:09
Some general comments, hopefully constructive :) :

Throughout the document reference is made to caching proxies being used as the platform on which services will be offered. While the majority of such boxes deployed today probably do act primarily as content stores, and they provide some obvious benefits where caching is practicable, there is certainly no requirement for them to be *caching* proxies. (And one could argue that caching, at even the simplest level, might be provided as a service rather than as an intrinsic part of the platform.)


In section 2 you introduce virus scanning in the context of email based viruses, then move on to discuss scanning of Web pages and file transfers. A couple of comments on this: 1) When some of the initial "extensible proxies" discussion took place there was an idea that these devices might operate with the content on more than one port, thereby enabling SMTP scanning, for example. I'm not sure I see that any more. 2) In the absence of any reference to non-port-80 scanning, is it sensible to introduce the subject in the context of email based viruses, and then move on to the a Web centric view? (and 3) if you're discussing something like SMTP caching, obviously you want to depreciate the caching nature of the proxy, since it's not going to be too beneficial in that case.)


Section 3 discusses ad insertion. It's a business point, but the key issue of localized ad insertion is the ability to 1) better target adverts to end users (you have a much better understanding of where they are in the network), and 2) to provide an additional revenue stream to the entity whose boxes are doing the insertion (because they're closer to the users). I'm also in some disagreement that a standard model for identifying the ad space is required. It's the content providers content, and they have deals with folks who know the size and types of ads that should be inserted. I'm not suggesting it's the best model, but one possibility is simply to parse "comments" within the HTML/XML. Part of the problem with a well defined content (and therefore presumably stable) structure is that it makes it inherently easy for ad-strippers to do their work.


Sections 6 and 7, in my mind, discuss very similar things. And in fact, section 7 doesn't consider the important aspect of bandwidth adaptation where there's actually *more* bandwidth (where richer interaction could be provided).


Section 12 is rather interesting (for personal reasons). There are quite a few academic references to this sort of work... I'll try to dig them out and pass them along if that would be useful. For 12.3, one could possibly use CIP (see RFC2651), perhaps.