Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-17 Thread Fred Baker
At 12:44 AM 4/11/00 -0700, Derrell D. Piper wrote: And there you have the argument for publishing this document. I much prefer a model where we allow for free exchange of ideas, even bad ones. hear! hear! I tend to believe that if someone took the time to write up a document that there's

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-17 Thread Keith Moore
I think various people have made a good case for eventually publishing this particular document, once appropriate revisions have been made. I'm very supportive of the notion of free exchange of ideas, even through the RFC mechanism - with the understanding that: - IETF and the RFC Editor have

RE: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-14 Thread Steve Hultquist
Title: RE: recommendation against publication of draft-cerpa-necp-02.txt Keith Moore wrote: . . . 3. Aside from the technical implications of intercepting traffic, redirecting it to unintended destinations, or forging traffic from someone else's IP address - there are also

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-13 Thread John Martin
At 04:45 PM 11/04/00 -0700, Eliot Lear wrote: I wonder if any of the authors has explored the risks of modifying data in flight. How could this be abused by interlopers and evil doers? If I could hack into a router implementing NECP, what damage could I do? Could I start a nasty little

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-13 Thread Eliot Lear
Part of the problem here is that a knife may be used as a food utensil or a weapon. Safe handling, however, is always required, and should be documented. I would add two other comments. I tried to locate the RFC for HTTP/0.9, but the best I could find was a reference to a CERN ftp site for the

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-13 Thread John Martin
At 10:49 AM 13/04/00 -0700, Eliot Lear wrote: Part of the problem here is that a knife may be used as a food utensil or a weapon. Safe handling, however, is always required, and should be documented. Granted. I would add two other comments. I tried to locate the RFC for HTTP/0.9, but the best

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Keith Moore
Let's remember that a major goal of these facilities is to get a user to a server that is 'close' to the user. Having interception done only at distant, localized server farm facilities will not achieve that goal. granted, but... an interception proxy that gets the user to a server that

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Valdis . Kletnieks
On Mon, 10 Apr 2000 07:00:56 EDT, Keith Moore said: and a technology that only works correctly on the server end seems like a matter for the server's network rather than the public Internet - and therefore not something which should be standardized by IETF. Much the same logic can be applied

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Keith Moore
and a technology that only works correctly on the server end seems like a matter for the server's network rather than the public Internet - and therefore not something which should be standardized by IETF. Much the same logic can be applied to NAT (the way it's usually implemented).

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Francis Dupont
In your previous mail you wrote: But IP-layer interception has some fairly significant limitations for this application. ... There's a technical problem with IP intercepting that I've not seen mentioned, including in the draft. Any intercepting based on TCP or UDP port

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Derrell D. Piper
Bottom line is that IP-layer interception - even when done "right" - has fairly limited applicability for location of nearby content. Though the technique is so widely mis-applied that it might still be useful to define what "right" means. And there you have the argument for publishing

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Dick St.Peters
Let's remember that a major goal of these facilities is to get a user to a server that is 'close' to the user. Having interception done only at distant, localized server farm facilities will not achieve that goal. ... client -- Internet - ISP - Intercept - Internet - Server1

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Jon Crowcroft
Bottom line is that IP-layer interception - even when done "right" - has fairly limited applicability for location of nearby content. Though the technique is so widely mis-applied that it might still be useful to define what "right" means. That sounds overly optimistic. user

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Vernon Schryver
From: Jon Crowcroft [EMAIL PROTECTED] ... its the 21st century: f you dont use end2end crypto, then you gotta expect people to optimize their resources to give you the best service money can buy for the least they have to spend. ... That's an interesting idea. People might eventually

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Magnus Danielson
From: Vernon Schryver [EMAIL PROTECTED] Subject: Re: recommendation against publication of draft-cerpa-necp-02.txt Date: Mon, 10 Apr 2000 10:41:43 -0600 (MDT) From: Jon Crowcroft [EMAIL PROTECTED] ... its the 21st century: f you dont use end2end crypto, then you gotta expect people

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Patrik Fältström
At 11.50 -0400 2000-04-10, Dick St.Peters wrote: What is the fundamental difference between choosing the best path and choosing the best source? Arguments that the latter breaks the IP model are simply arguments that the IP model is broken for today's Internet and will be even more broken for

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Gary E. Miller
Yo Randy! On Mon, 10 Apr 2000, Randy Bush wrote: all these oh so brilliant folk on the anti-cacheing crusade should be sentenced to live in a significantly less privileged country for a year, where dialup ppp costs per megabyte of international traffic and an engineer's salary is $100-200

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Joe Touch
One other item: Neither this, nor many NAT I-D's, address the particular issue of sourcing IP addresses not assigned or owned by the host/gateway, e.g., as they affect the standards of RFCs 1122, 1123, and 1812. If a device creates (rewrites) IP source

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Keith Moore
Bottom line is that IP-layer interception - even when done "right" - has fairly limited applicability for location of nearby content. Though the technique is so widely mis-applied that it might still be useful to define what "right" means. And there you have the argument for

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Vernon Schryver
From: Randy Bush [EMAIL PROTECTED] ... That's an interesting idea. People might eventually finally start using end2end crpyto not for privacy or authnetication where they really care about either, but for performance and correctness, to defend against the ISP's who find it cheaper to

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Keith Moore
its the 21st century: f you dont use end2end crypto, then you gotta expect people to optimize their resources to give you the best service money can buy for the least they have to spend. ... That's an interesting idea. People might eventually finally start using end2end crpyto

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Keith Moore
all these oh so brilliant folk on the anti-cacheing crusade should be sentenced to live in a significantly less privileged country for a year, where dialup ppp costs per megabyte of international traffic and an engineer's salary is $100-200 per month. and as long as we're talking about just

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-10 Thread Vernon Schryver
I tried to send this earlier, but got a response from [EMAIL PROTECTED] complaining that every line is a bogus majordomo command. My logs say I sent to [EMAIL PROTECTED] and not [EMAIL PROTECTED] or anything smilar. I did use the word "s-u-b-s-c-r-i-b-e-r-s" 3 times. This time I've replaced all

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-09 Thread Dave Crocker
At 01:39 PM 4/9/00 -0800, [EMAIL PROTECTED] wrote: However, I am fully in agreement that interception proxies imposed anyplace other than either endpoint of the connection is a Bad Idea, because a third Exactly. And after having read this specification, I also think these issues are

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-09 Thread ned . freed
At 01:39 PM 4/9/00 -0800, [EMAIL PROTECTED] wrote: However, I am fully in agreement that interception proxies imposed anyplace other than either endpoint of the connection is a Bad Idea, because a third Exactly. And after having read this specification, I also think these issues

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-09 Thread Dave Crocker
At 03:42 PM 4/9/00 -0800, [EMAIL PROTECTED] wrote: You are confusing topological locality with administrative locality. I was talking about the latter, and so, I believe, was Valdis. As my later comment meant to convey, I too was clear about the distinction, but yes I was definitely confused

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-09 Thread Patrik Fältström
At 14.35 -0700 2000-04-09, Dave Crocker wrote: Let's remember that a major goal of these facilities is to get a user to a server that is 'close' to the user. Having interception done only at distant, localized server farm facilities will not achieve that goal. Further, I'm unclear about the

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Patrik Fältström
At 15.20 -0400 2000-04-07, Bill Sommerfeld wrote: I think it's important to carefully distinguish between these sorts of redirection. Some clarifying text in the draft to this effect would be helpful. That is what I have asked the authors to do. The problems with "intercepting proxies" are

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Keith Moore
Peter, I think that by now I've made my points and defended them adequately and that there is little more to be acheived by continuing a public, and largely personal, point-by-point argument. If you want to continue this in private mail I'll consider it. The simple fact is that I believe

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Pyda Srisuresh
--- Keith Moore [EMAIL PROTECTED] wrote: ... stuff deleted As we have done with the NAT WG, it is often useful to accurately document the drawbacks of a common practice as well as to encourage exploration of alternatives. From my point of view there were significant forces within the

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Peter Deutsch in Mountain View
g'day, Keith Moore wrote: Peter, I think that by now I've made my points and defended them adequately and that there is little more to be acheived by continuing a public, and largely personal, point-by-point argument. If you want to continue this in private mail I'll consider it. Okay,

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Valdis . Kletnieks
On Sat, 08 Apr 2000 15:28:12 EDT, Keith Moore said: The simple fact is that I believe that the idea of interception proxies does not have sufficient technical merit to be published by IETF, and that IETF's publication of a document that tends to promote the use of such devices would

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Doug Royer
Peter Deutsch in Mountain View wrote: [in part you said] I still object to your notion that it's not censorship since people can always go elsewhere. Where does this lead? I see the day when people can't publish a new directory service protocol because "The IETF has endorsed LDAP for

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Keith Moore
Keith - I argued to keep the term "transparent routing" in the NAT terminology RFC (RFC 2663). The arguments I put forth were solely mine and not influenced by my employer or anyone else. didn't say that they were. Clearly, your point of view is skewed against NATs. It is rather

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Pyda Srisuresh
--- Keith Moore [EMAIL PROTECTED] wrote: Keith - I argued to keep the term "transparent routing" in the NAT terminology RFC (RFC 2663). The arguments I put forth were solely mine and not influenced by my employer or anyone else. didn't say that they were. Clearly, your point of

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Keith Moore
Publication under Informational and Experimental has typically been open to all wishing it. uh, no. this is a common myth, but it's not true, and hasn't been true for many years. I hope (and believe) that the *potential* for publication is open to all, and that the process isn't biased

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Pyda Srisuresh
--- Keith Moore [EMAIL PROTECTED] wrote: Sorry.. Your conclusion is based on a wrong premise. The NAT group's draft documents speak for themselves. My point exactly. regards, suresh __ Do You Yahoo!? Talk to your friends online with

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Peter Deutsch in Mountain View
Keith Moore wrote: The industry and their customers have already decided against you on this one. Industry people love to make such claims. They're just marketing BS. The Internet isn't in final form yet and I don't expect it to stabilize for at least another decade. There's still

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Keith Moore
the problem with a "NAT working group" is that it attracts NAT developers far more than it does the people whose interests are harmed by NATs - which is to say, Internet users in general. so by its very nature a "focused" NAT working group will produce misleading results. This bias

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Peter Deutsch in Mountain View
g'day, Lloyd Wood wrote: Well, look at the list of signatories to the Draft in question. technical merits, please. I was not arguing for the merits of the technology in question based upon who signed it. In fact, I haven't tried to address the technical merits of the specific document at

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Keith Moore
Peter, I don't think I would agree that NECP is out of scope for IETF. I think it's pefectly valid for IETF to say things like "NECP is intended to support interception proxies. Such proxies violate the IP architecture in the following ways: ... and therefore cause the following problems...

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-08 Thread Martin J.G. Williams
I've come into this discussion rather late, however there is at least one salient point which I believe that Keith Moore has argued rather well... In my understanding the role of the IETF is to promote the logical growth and evolution of the Internet Protocols. Whilst 'vendors' have massive

RE: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Bernard Aboba
The use of "load balancing" technologies is growing rapidly because these devices provide useful functionality. These devices utilize many different techniques, only some of which can be characterized as "interception proxies" or "reverse network address translation." For example, using MAC

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Keith Moore
I am writing to request that the RFC Editor not publish draft-cerpa-necp-02.txt as an RFC in its current form, for the following reasons: 2. A primary purpose of the NECP protocol appears to be to facilitate the operation of so-called interception proxies. Such proxies violate

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Keith Moore
The use of "load balancing" technologies is growing rapidly because these devices provide useful functionality. These devices utilize many different techniques, only some of which can be characterized as "interception proxies" or "reverse network address translation." For example, using MAC

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Stephen Kent
Keith, Without comments on other aspects of the technology in question, I would like to make some observations about the security aspects of the processing you cite as violating IP. By now we all should know that it is a bad idea to rely on an unauthenticated IP address as a basis for

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Leslie Daigle
Howdy, Stephen Kent wrote: Thus, if anyone is really concerned about know with whom they are communicating, and whether a packet was modified in transit, they should be using these standards security technologies. Many web sites for which these security concerns are significant already

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Keith Moore
By now we all should know that it is a bad idea to rely on an unauthenticated IP address as a basis for determining the source of a packet. Similarly. the IP header checksum offers no security. We have a variety of IETF standard protocols (e.g., IPsec and TLS) that provide suitable

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Stephen Kent
Leslie, I understand your point, but we leave ourselves open to many forms of attacks, or errors, by assuming that "what you receive is what was sent" in this era of the Internet. Security is not black and white, but the gray area we're discussing does bother me. If one cares about knowing

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Valdis . Kletnieks
On Fri, 07 Apr 2000 13:07:29 EDT, Stephen Kent said: but the gray area we're discussing does bother me. If one cares about knowing where the data originated, and that it has not been altered, then one needs to make use of the tools provided to address that concern. if one doesn't use the

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Leslie Daigle
A fine argument in the abstract, but reality bites. Stephen Kent wrote: sent" in this era of the Internet. Security is not black and white, but the gray area we're discussing does bother me. If one cares about knowing where the data originated, and that it has not been altered, then one

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Peter Deutsch
Keith Moore wrote: . . . 3. Aside from the technical implications of intercepting traffic, redirecting it to unintended destinations, or forging traffic from someone else's IP address - there are also legal, social, moral and commercial implications of doing so. You will need

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Vernon Schryver
From: [EMAIL PROTECTED] ... they ARE concerned about spam, hackers, etc. Unfortunately, a lot of them Get It Very Wrong, and do stuff like bounce SMTP 'MAIL FROM:', or Do The Wrong Thing with NTP traffic, etc etc. I have to conclude that there's a lot of sites that *do* care very much,

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Dennis Glatting
Leslie Daigle wrote: As an end-user, I can be as aware as I like about the security issues, but if client software doesn't support security, and/or my ISP, services don't support it, there's nothing I can do. Huh? You have a choice: (a) obtain a client that does support security; and (b)

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Valdis . Kletnieks
On Fri, 07 Apr 2000 12:16:05 MDT, Vernon Schryver [EMAIL PROTECTED] said: It's worse than that, as AOL is demonstrating with their port 25 redirecting. Hmm.. I don't correspond with that many AOL people. What are they doing NOW? If your skin doesn't crawl at the thought of a third party

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Keith Moore
Applications can gain a lot of security by building on top of a lower layer secure communication substrate, such as that provided by IPsec or TLS. Such substrates allow the application developer to make assumptions about the security of the basic communication path, and have these

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Keith Moore
Stephen, perhaps the reason that the tools are not used is that they are not adequate for the task. but it certainly does not follow that "if one doesn't use the tools, then one does not care very much". Keith If one cares about knowing where the data originated, and that it has not been

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Valdis . Kletnieks
On Fri, 07 Apr 2000 11:25:40 PDT, Dennis Glatting said: Huh? You have a choice: (a) obtain a client that does support security; and (b) get a new ISP. Both are plentiful. Only if a client supporting security is available for your software (which might be be something other than Netscape/IE -

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Daniel Senie
Dennis Glatting wrote: Leslie Daigle wrote: As an end-user, I can be as aware as I like about the security issues, but if client software doesn't support security, and/or my ISP, services don't support it, there's nothing I can do. Huh? You have a choice: (a) obtain a client

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Stephen Kent
Keith, Stephen, perhaps the reason that the tools are not used is that they are not adequate for the task. but it certainly does not follow that "if one doesn't use the tools, then one does not care very much". or perhaps, one does not care enough ... Steve

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Paul Francis
In my 20+ years of security experience in the Internet community, it has often been the arguments for the need to make do with existing features or to adopt quick fix solutions that have retarded the deployment of better security technology. In retrospect, this approach has not

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Dennis Glatting
Getting a new ISP, however, is NOT necessarily an option. You'd argue I give up a cable modem for a dialup ISP? I don't think so. Application level security (SSL, TLS, SSH) work fine for my needs and transit the equipment I must use to exist on a cable modem. You have made the choice to

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Keith Moore
Keith Moore wrote: . . . 3. Aside from the technical implications of intercepting traffic, redirecting it to unintended destinations, or forging traffic from someone else's IP address - there are also legal, social, moral and commercial implications of doing so. You will

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Vernon Schryver
From: [EMAIL PROTECTED] ... If your skin doesn't crawl at the thought of a third party adding headers to your SMTP messages, you need to take some time out to think about things. You mean *other* than the required RFC822 Received: headers, and/or the RFC2476-approved re-writing? Gaak

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Keith Moore
perhaps the reason that the tools are not used is that they are not adequate for the task. but it certainly does not follow that "if one doesn't use the tools, then one does not care very much". or perhaps, one does not care enough ... or perhaps, that building tools that actually solve

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Stephen Kent
Paul, I have a time machine. I just went back 20 years in time, convinced everybody that it was always more important to implement proper security than to make do with existing features and quick fix solutions. Having thus changed the future, I went back forward in time. Guess what---there

RE: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Stephen Kent
Christian, Suppose, rhetorically, that we were to encrypt every IP packet using IPSEC. What happens if a box takes your packet and deliver it to the "wrong" address, for example to an ISP controlled cache? Well, the cache cannot do anything with it, except drop it to the floor. We are thus

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Theodore Y. Ts'o
Date: Fri, 07 Apr 2000 15:00:22 -0400 From: Daniel Senie [EMAIL PROTECTED] Ah, no. In the real world of the Internet today, we have LOTS of folks who get their Internet connectivity via cable modems and DSL. Many vendors of such services, in order to help preserve IP address

RE: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Christian Huitema
re; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: recommendation against publication of draft-cerpa-necp-02.txt Leslie, I understand your point, but we leave ourselves open to many forms of attacks, or errors, by assuming that "what you receive is wha

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Theodore Y. Ts'o
From: Keith Moore [EMAIL PROTECTED] Date: Fri, 07 Apr 2000 15:15:57 -0400 the problem is that one person's idea of improved service may be another person's idea of degraded service. getting stale data to me faster may not be much help. I would argue that it is up to the

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Peter Deutsch
Keith Moore wrote: . . . You seem to be saying that because we have a higher service layered on top of IP that we can disregard the IP service model. I disagree. No, I'm saying you purported to be offended by IP address redirection when what you really objected to was unauthorized

RE: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Ian King
- From: Paul Francis [mailto:[EMAIL PROTECTED]] Sent: Friday, April 07, 2000 12:13 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: recommendation against publication of draft-cerpa-necp-02.txt In my 2

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-07 Thread Keith Moore
Keith Moore wrote: . . . You seem to be saying that because we have a higher service layered on top of IP that we can disregard the IP service model. I disagree. No, I'm saying you purported to be offended by IP address redirection when what you really objected to was unauthorized

Re: recommendation against publication of draft-cerpa-necp-02.txt

2000-04-06 Thread Karl Auerbach
I am writing to request that the RFC Editor not publish draft-cerpa-necp-02.txt as an RFC in its current form, for the following reasons: 2. A primary purpose of the NECP protocol appears to be to facilitate the operation of so-called interception proxies. Such proxies violate the