![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
Vernon Schryver wrote: > > My impression from the two WG documents is that in the WG consensus is > that HTTP interception proxies are at least tolerable and often necessary > and good, and by extension probably also for SMTP and everything else. The arch document defines, it doesn't condone or condemn. As to the known-probs doc, that focuses on problems of the sort that TCPIMPL did - errors in the implementation, not deliberately changing specs. > Yes, I noticed that "W" in "WREC" doesn't stand for "mail". It's also > clear that intercepting or proxying are at most aspects of the "RE" and > the "C", although I don't see how that is relevant to whether the WG is > committed to interception proxies. Intercepting is also done in other contexts: - DNS - email - TCP for relay over subnets e.g., over wireless or intermittently-connected links > Yes, I realize that draft wasn't a product of the WREC WG. The two WREC > documents cannot be read as deprecating interception proxies and can be > read as advocating them by what they fail to say. I do not agree with this statement. Failing to condemn cannot be taken as an endorsement. It means only that the documents define, rather than compare or advocate, architectural components. > ] From: Joe Touch <touch at ISI.EDU> > > ] FWIW, there _was_ discussion in WREC of the hazards of transparent web > ] caching. I dug up an old e-mail, describing the hazards of transparent > ] web caching which I summarized at the time, when WREC was forming. > ] > ] A copy of the note, admittedly very rough (just an outline, and a very > ] rough one at that) is at: > ] > ] http://www.isi.edu/touch/pubs/hazards-outline.txt > > I really like "in effect, it is a use of IP spoofing to do replay attacks." > > (Why a 3rd document instead of added to Problems?) Because problems focuses on errors of implementation, not of architectural design. I would advocate that there is the need for a separate statement on design in this case. > ] I would be glad to host further discussion on the WREC maillist as to > ] how to augment the list and flesh it out to a full I-D before the next > ] IETF, if there is sufficient interest. > > Do you two think that either the IETF or the WREC working group might > agree with the thrust of that outline? It sounds as if your answer is > "yes" and that my sense of WREC, IETF, and maybe industry sentiment is > wrong. I'll take that over to WREC, and we can have that discussion there first. Joe
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.