Re: interception proxies
> From: Keith Moore <[EMAIL PROTECTED]> > ... > agree entirely. but for this to work there have to be folks within > the WG who are willing to raise a fuss. That's a good point, but there is another question that must always be asked. When there is no hope of influencing something, then it can be important to not participate. Participation even in opposition inevitably supports the official position. 30 years ago the word "co-opted" was used to describe the problem. 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. 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. Draft-cerpa-necp-02.txt must be read as advocating them, and not only for HTTP or whatever is meant by "Web." 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. ] From: Joe Touch <[EMAIL PROTECTED]> ] 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?) ] 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. Vernon Schryver[EMAIL PROTECTED]
Re: interception proxies
On Tue, 11 Apr 2000, Theodore Y. Ts'o wrote: > And the latest kludge which has been called to my attention is ISP's > that tamper with the MSS values in TCP SYN packets in flight. This is > done to work around smaller MTU's caused by PPP over Ethernet (and other > tunnelling mechanisms) interacting badly with Path MTU discovery > failures, which in turn are caused by firewalls that filter out the > wrong sorts of ICMP packets. > > Hmmm, yet another thing which IPSEC will break. Any specific ISP's that one could care to name? Coming from an ISP, what I've seen in general is that most routers have just enough cycles in the forwarding path to keep up with the offered traffic, much less sit around watching for SYN's in flight so as to mutate the MSS values. In fact, I'd think this would be more of an end system issue rather than a "core" or a "backbone" issue, where the end system is the box prior to the ISP handoff and not quite under the ISP's control and not the end system as in the end2end tcp/ip sense of the word. /vijay
Re: interception proxies
Date: Tue, 11 Apr 2000 16:47:04 -0600 (MDT) From: Vernon Schryver <[EMAIL PROTECTED]> Which is why it was depressing. Oh, well, perhaps a future version of the Problems draft will consider that issue and say as others wrote, it's not a problem and can be fixed with big buffers watching IP ID's, avoiding UDP, assuming good MSS's or discovery prevent TCP/IP fragmentation, or whatever. And the latest kludge which has been called to my attention is ISP's that tamper with the MSS values in TCP SYN packets in flight. This is done to work around smaller MTU's caused by PPP over Ethernet (and other tunnelling mechanisms) interacting badly with Path MTU discovery failures, which in turn are caused by firewalls that filter out the wrong sorts of ICMP packets. Hmmm, yet another thing which IPSEC will break. - Ted
Re: rfc-editor?
Can anyone send the faq that was sent out a few months ago.. thanks
Re: rfc-editor?
I found the following in rfc2028.. > 2.1 The Request for Comments Editor > >The RFC publication series [B] is managed by an Editor (which may in >practice be one or more individuals) responsible both for the >mechanics of RFC publication and for upholding the traditionally >high technical and editorial standards of the RFC series. >The functions of the RFC Editor are performed by one or more >individuals or organizations selected in accordance with the >procedures defined by the RFC Editor charter [G]. And [G] is simply.. >[G] RFC Editor Charter, Work in Progress. ..and perusal with various search engines/tools yields no further information about "RFC Editor Charter", and rfc2028 was written in late 1996. [EMAIL PROTECTED] said: > brought to you by most of the same folk it has been for years Well, uh, besides Joyce Reynolds, I'm curious as to who all are actively contributing to that role. Is it folks on the IAB? Is it folks at IANA (and, uh, who zactly these days is affiliated with IANA besides the well-known board? who're the doers?)? Is it just anybody at ISI? Is it part of being on the IESG being an AD? Is it WG chairs? Who gets to decide? How is it presently decided who may participate in acting in the RFC-Editor role? I'm just sorta curious cuz it seems to be an opaque object in the otherwise fairly well-defined works (of the IETF et al). thanks, JeffH
Re: rfc-editor?
> I have a question: so ~who~ is the RFC-Editor these days given that The > RFC-Editor (aka Jon Postel) has passed on? I've groveled thru the > www.ietf.org and the www.rfc-editor.org pages and can't see who all is > presently acting in this role, but perhaps I simply missed it. brought to you by most of the same folk it has been for years, sadly minus one. randy
rfc-editor?
I have a question: so ~who~ is the RFC-Editor these days given that The RFC-Editor (aka Jon Postel) has passed on? I've groveled thru the www.ietf.org and the www.rfc-editor.org pages and can't see who all is presently acting in this role, but perhaps I simply missed it. Am just overall curious. thanks, JeffH
Re: interception proxies
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 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. Joe
Re: interception proxies
> Call me a non-team playing scab, but I refuse to the honor the old guild > work rule that limits the questions I can consider. If sourcing > other-owned etc. or anything else is an architectural or other problem, > then professional pride ought to force one to raise the issue insetad of > waiting for the AD, IESG, IAB, or a plenary to redirect things. agree entirely. but for this to work there have to be folks within the WG who are willing to raise a fuss. Keith
Re: interception proxies
> This was a choice - in some larger sense, if sourcing other-owned IP > addresses or TCP connections is considered an architectural problem, > needs to come down from above, rather than up from WREC. sounds like a convenient excuse to me... where did the wrec folks get the idea that the IP specification was obsolete? Keith
Re: interception proxies
... > > Joining that mailing list would not be useful, prudent, or honest for > > people with sentiments like mine. Moving the question of the wisdom of > > such proxies to WREC would be equivalent to moving the question of the > > wisdom of wiretapping to the wiretapping working group. At best the group > > WG consensus can be predicted. At worst, the discussion would legitimately > > be considered disruptive and irrelevant. > > WREC is about proxies - there are plenty of 'architecturally conformant' > ways to do proxies. If the problems with transparent proxies is an > issue, WREC may be a good place (but not the only place) to solicit > input. Correction - slip of the keyboard. What I meant was that WREC is _NOT_ about proxies. It's about caching and replication. Proxies are one part of the architecture, but not the only part. Joe
Re: recommendation against publication of draft-cerpa-necp-02.txt
This whole thread is perhaps the best reason to have protocols go through working groups, so that concerns can be raised and documented, and so that the IESG can weigh in on correctness, risks, and yes, to a certain extent morality. 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 JavaScript/Java/Shockwave/... applet in an advertisement? And who would know it was me? Quoth John Martin: > [...] > Let me be absolutely clear, NECP is about communication between server > load-balancers (SLB) and the back-end servers they speak to. Were this so clear in your document my mailbox wouldn't be full of this stuff. > The document is not an IETF standard but it does describe a protocol. For > protocols to work correctly, there must be certain "mandatory" minimal > requirements on those implementing that protocol. If it looks like a duck and quacks like a duck, but it's not supposed to be a duck, the IESG ought to point out that it's a turkey by so indicating at the top of the document. Also, I'd like to understand why you're not going experimental, where it would be expected that you'll correct your mistakes. Your choice of "informational" seems unfortunate at best and as disingenuous marketing at worst. I can't tell which. > I can see one or two places where the word "standard" might be > misinterpreted by readers if used out of context. You somehow missed Section 1: ... NECP provides a standard method for this signaling. > > >2. A primary purpose of the NECP protocol appears to be to > >facilitate the operation of so-called interception proxies. > > Wrong. The primary purpose of NECP is to facilitate a load-balancing > between SLBs and the services to which they direct traffic. "so-called > interception proxies" are just one such service. The document says: NECP now provides a standard server-to-network signalling interface. This allows network elements in heterogenous environments to perform load balancing across a server farm, redirection to interception proxies, and cut-through of flows that can not be served by the farm. The fact that you mention interception proxies in the introduction has led to this flame war. Having used the words, you've mentioned none of the risks associated with such services both from the server side and the client side. > >Such proxies violate the Internet Protocol in several ways: > > This is not about those proxies - that is a different argument. > > I don't think it is appropriate to be drawn into an argument about the > rights and wrongs of "interception proxies" when discussing NECP. I am more > than happy to justify their existence - with hard facts, of course - in a > separate thread. In whatever thread, the document fails to mention the legitimate security concerns of those people who are concerned about interception. I would argue that our other flame war on wire tapping is (unfortunately) relevant. Eliot Lear Cisco Systems
Re: interception proxies
> From: Joe Touch <[EMAIL PROTECTED]> > ... > > The problems draft is interesting and depressing. All of the problems > > listed are technical nits. > > This was a choice - in some larger sense, if sourcing other-owned IP > addresses or TCP connections is considered an architectural problem, > needs to come down from above, rather than up from WREC. f Call me a non-team playing scab, but I refuse to the honor the old guild work rule that limits the questions I can consider. If sourcing other-owned etc. or anything else is an architectural or other problem, then professional pride ought to force one to raise the issue insetad of waiting for the AD, IESG, IAB, or a plenary to redirect things. But I realize that's a minority view, and not just in IETF working groups or even the IETF. If only I could have had one pre-IPO share for every time I've been told "we can't think about that; we'll have to ask to marketing" ... on the other hand, most of those shares would be merely expensive wallpaper. > >... That there is no mention of the problems that IP > > fragmentation can cause interception proxies is depressing. > > The problems of IP fragmentation are not unique to web caching or > replication proxies. They affect all interception proxies. The issue of > inteception proxies was around long before WREC, and is more than just a > caching or replication issue. Which is why it was depressing. Oh, well, perhaps a future version of the Problems draft will consider that issue and say as others wrote, it's not a problem and can be fixed with big buffers watching IP ID's, avoiding UDP, assuming good MSS's or discovery prevent TCP/IP fragmentation, or whatever. > ... > That's the property of WGs in general, by construction. These questions > sometimes get addressed in BOFs, but there is also often too much > momentum or political interest in establishing a 'standardizing > presence' in an area. By the time a WG is formed, the time for 'whether' > has often passed in favor of 'which'. Which was exactly the lament the other day. By the time a Last Call rolls around, it's months and $B of market cap late to worry about "whether?" There are always screams about the unfairness of raising "whether" at such a late date and vague reference to nearly completed implementations that will have billions of installations by the end of the quarter, or when IPv8 replaces IPv4 at the latest, exactly as we heard in response to the initial comments about draft-cerpa-necp-02.txt. I don't have a fix for the problem, except to steadfastly refuse to heed cries from partisans that "whether?" is out of order until it really is. ... ] From: "BookIII, Robert" <[EMAIL PROTECTED]> ] Joe, ]Am I to presume by your statement that you are of the mind that the ] time for considering whether vs. which has already come and gone? Is there ] anyone on this list who thinks that? I don't speak for Joe, but it's clearly over. Unlike the wiretapping question, interception proxies are too near to the technical interests (and pocketbooks) of too many IETF participants. You must admit that they sound like cool hacks, unlike merely forwarding copies of bits. Vernon Schryver[EMAIL PROTECTED]
Re: interception proxies
"BookIII, Robert" wrote: > > Joe, > Am I to presume by your statement that you are of the mind that the > time for considering whether vs. which has already come and gone? Is there > anyone on this list who thinks that? With respect to 'inside the WG', yes, the assumption has been (to me) that the time had passed, with respect to the WG charter. There is always time outside the WG to do so, or (if directed) to recharter, pending interest and approval of the WG as well. Joe
RE: interception proxies
Joe, Am I to presume by your statement that you are of the mind that the time for considering whether vs. which has already come and gone? Is there anyone on this list who thinks that? -Original Message- From: Joe Touch [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 11, 2000 4:03 PM To: Vernon Schryver Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject:Re: interception proxies Vernon Schryver wrote: > > > From: John Martin <[EMAIL PROTECTED]> > > > There has been a lot of discussion about the problems associated with > > so-called "interception proxies". This discussion is very much within the > > charter of the WREC WG. In fact, we even have a current draft whose sole > > purpose is to document such problems. > > > > The known problems draft is at: draft-ietf-wrec-known-prob-01.txt > > > > This is the first of two very useful documents being produced by WREC; the > > first, a taxonomy of terminology is available as: > > draft-ietf-wrec-taxonomy-03.txt; I would suggest you read this first. > > The problems draft is interesting and depressing. All of the problems > listed are technical nits. This was a choice - in some larger sense, if sourcing other-owned IP addresses or TCP connections is considered an architectural problem, needs to come down from above, rather than up from WREC. f > I don't know whether to be depressed, encouraged, or neutral that WREC > seems to not be about port 25 traffic redirection and interception proxies, > such as AOL's effort. That there is no mention of the problems that IP > fragmentation can cause interception proxies is depressing. The problems of IP fragmentation are not unique to web caching or replication proxies. They affect all interception proxies. The issue of inteception proxies was around long before WREC, and is more than just a caching or replication issue. > Joining that mailing list would not be useful, prudent, or honest for > people with sentiments like mine. Moving the question of the wisdom of > such proxies to WREC would be equivalent to moving the question of the > wisdom of wiretapping to the wiretapping working group. At best the group > WG consensus can be predicted. At worst, the discussion would legitimately > be considered disruptive and irrelevant. WREC is about proxies - there are plenty of 'architecturally conformant' ways to do proxies. If the problems with transparent proxies is an issue, WREC may be a good place (but not the only place) to solicit input. > It appears that the WREC working group is doing exactly as someone > lamented a day or two ago about working groups in general, and not > considering the question of whether the mechanisms they are working are > good ideas in the larger scheme of things. WREC is only concerned with > making them as good as possible. (Yes, I checked recent months of the > archives at ftp://cs.utk.edu/pub/wrec/) That's the property of WGs in general, by construction. These questions sometimes get addressed in BOFs, but there is also often too much momentum or political interest in establishing a 'standardizing presence' in an area. By the time a WG is formed, the time for 'whether' has often passed in favor of 'which'. Joe
Re: interception proxies
Vernon Schryver wrote: > > > From: John Martin <[EMAIL PROTECTED]> > > > There has been a lot of discussion about the problems associated with > > so-called "interception proxies". This discussion is very much within the > > charter of the WREC WG. In fact, we even have a current draft whose sole > > purpose is to document such problems. > > > > The known problems draft is at: draft-ietf-wrec-known-prob-01.txt > > > > This is the first of two very useful documents being produced by WREC; the > > first, a taxonomy of terminology is available as: > > draft-ietf-wrec-taxonomy-03.txt; I would suggest you read this first. > > The problems draft is interesting and depressing. All of the problems > listed are technical nits. This was a choice - in some larger sense, if sourcing other-owned IP addresses or TCP connections is considered an architectural problem, needs to come down from above, rather than up from WREC. f > I don't know whether to be depressed, encouraged, or neutral that WREC > seems to not be about port 25 traffic redirection and interception proxies, > such as AOL's effort. That there is no mention of the problems that IP > fragmentation can cause interception proxies is depressing. The problems of IP fragmentation are not unique to web caching or replication proxies. They affect all interception proxies. The issue of inteception proxies was around long before WREC, and is more than just a caching or replication issue. > Joining that mailing list would not be useful, prudent, or honest for > people with sentiments like mine. Moving the question of the wisdom of > such proxies to WREC would be equivalent to moving the question of the > wisdom of wiretapping to the wiretapping working group. At best the group > WG consensus can be predicted. At worst, the discussion would legitimately > be considered disruptive and irrelevant. WREC is about proxies - there are plenty of 'architecturally conformant' ways to do proxies. If the problems with transparent proxies is an issue, WREC may be a good place (but not the only place) to solicit input. > It appears that the WREC working group is doing exactly as someone > lamented a day or two ago about working groups in general, and not > considering the question of whether the mechanisms they are working are > good ideas in the larger scheme of things. WREC is only concerned with > making them as good as possible. (Yes, I checked recent months of the > archives at ftp://cs.utk.edu/pub/wrec/) That's the property of WGs in general, by construction. These questions sometimes get addressed in BOFs, but there is also often too much momentum or political interest in establishing a 'standardizing presence' in an area. By the time a WG is formed, the time for 'whether' has often passed in favor of 'which'. Joe
Re: interception proxies
wrec is supposed to be about *web* replication and caching. which probably doesn't include email. so I can hardly blame them for not talking about port 25. since other kinds of interception proxies exist, perhaps they should clarify their document slightly to say it's about web interception proxies. naturally I would encourage folks who are concerned about web interception proxies to join the wrec group and/or to submit comments and corrections about their documents. Keith
Re: OSP
Yixin Zhu wrote: > > Hi , > > I am interested in the Open Settlement Protocol for VoIP. I have check the > web site for GRIC and TransNexus, and got some information. It will be > appreciated if someone here can point to me more places to get info on > this topic. > > Thanks, > > Yixin (James) Zhu Hi, I have another link in my bookmarks which may be of som ehelp; http://www.oasis-open.org/cover/openSetProt.html Regards Himanshoo
Re: breaking the IP model (or not)
> From: Erik Fair <[EMAIL PROTECTED]> > Almost all of the pressure created by the growth of the Internet is > on the network operators and their vendors (e.g. router vendors), > rather than on the users and the end systems (and the end system > vendors Well, there are rational (?) structural reasons for this. i) There are more end systems than infrastructure boxes, so it's more work to change the former. ii) The end system boxes are often under the control of people who have less technical expertise, contacts, organization, etc than the infrastructure boxes, so it's more work to change them. All of which leads to solutions being jammed into the infrastructure boxes, which are easier to get to, rather than the end system boxes, where it may be desirable for architectural reasons. I wish a had some idea how to change this, but I don't (short of finding some killer app and bundling it with an end system architectural upgrade). > So, with nearly all the pressure on the operators and the vendors > that serve them, the "solutions" they come up with are necessarily > pretty ugly hacks (e.g. NAT, TCP spoofing, Firewalls) because they > have to deal with the reality that they can't change the end systems > themselves, or require them to be changed. There's another factor, which is that short-term fixes are less expensive in the here-and-now than fixes with a longer horizon. You see this effect operating even in areas that *don't* involve the end systems (e.g. routing). > This is a structural problem. Until the situation changes, we're > going to keep on seeing ugly hacks that do violence to the Internet > architectural model deployed, marketed, touted as "solutions." In the past, it has been a truism of system architecture that systems usually die because i) the basic architecture had things missing; ii) the 'improvements' done to rectify these problem are usually poorly thought-out/intergrated "warts" added by programmers who are new hires and don't really have the vision/confidence to fundamentally alter things; and iii) eventually the system crumbles under the addition of all these warts, and you have to throw it all out and start again from scratch. What's novel about the Internet is that i) the people making the additions are not all working for one company, but are a large collection of people without any central control, and ii) the process of "starting from scratch" will be even more painful, since you not only have to keep the old system running, but have it interoperate with the new one while the changeover is happening. (Think NCP->TCP conversion, but ^69th.) I'm not sure what the model is to make this happen, but I've come to the conclusion that the IETF process, as the IETF has evolved, is not the way to do it. Noel
OSP
Hi , I am interested in the Open Settlement Protocol for VoIP. I have check the web site for GRIC and TransNexus, and got some information. It will be appreciated if someone here can point to me more places to get info on this topic. Thanks, Yixin (James) Zhu
Re: interception proxies
> From: John Martin <[EMAIL PROTECTED]> > There has been a lot of discussion about the problems associated with > so-called "interception proxies". This discussion is very much within the > charter of the WREC WG. In fact, we even have a current draft whose sole > purpose is to document such problems. > > The known problems draft is at: draft-ietf-wrec-known-prob-01.txt > > This is the first of two very useful documents being produced by WREC; the > first, a taxonomy of terminology is available as: > draft-ietf-wrec-taxonomy-03.txt; I would suggest you read this first. The problems draft is interesting and depressing. All of the problems listed are technical nits. If you assume that "traffic redirection" and an "interception proxy" are good things, then you might well worry about the "lack of HTTP/1.1 compliance for proxy caches" or whether "interception proxies break client cache directives." You will not question their desirability or even their long term utility in the face of actions by users to protect their privacy or defend against censorship. You won't even worry about what's going to hit the fan when the big advertisers realize that their wonderful ads are being filtered and overwritten with other people's ads by interception proxies. I don't know whether to be depressed, encouraged, or neutral that WREC seems to not be about port 25 traffic redirection and interception proxies, such as AOL's effort. That there is no mention of the problems that IP fragmentation can cause interception proxies is depressing. > To join WREC, use the following: > mailto:[EMAIL PROTECTED]?Subject=subscribe > > ...or send a note to [EMAIL PROTECTED] with "subscribe" in the subject. > > I suggest we move this particular discussion to WREC. Joining that mailing list would not be useful, prudent, or honest for people with sentiments like mine. Moving the question of the wisdom of such proxies to WREC would be equivalent to moving the question of the wisdom of wiretapping to the wiretapping working group. At best the group WG consensus can be predicted. At worst, the discussion would legitimately be considered disruptive and irrelevant. It appears that the WREC working group is doing exactly as someone lamented a day or two ago about working groups in general, and not considering the question of whether the mechanisms they are working are good ideas in the larger scheme of things. WREC is only concerned with making them as good as possible. (Yes, I checked recent months of the archives at ftp://cs.utk.edu/pub/wrec/) It is interesting, but consistent with that observation that the problems draft contains no mention of problems should clients use end to end encryption or even just authentication with message authentication codes that care about the current time or the particular client. I don't know what to think of the absence of the string "https" in all three drafts. The passing, convoluted reference to encryption and SSL in section 9.2.2 of the taxonomy draft confuses me. If I were optimistic, I would hope that the taxonomy document is the wrong location is the reason its privacy section is so shallow. Vernon Schryver[EMAIL PROTECTED]
Re: prohibiting RFC publication
At 02:38 AM 4/9/00 +0100, Martin J.G. Williams wrote: >As far as i'm concerned (IMHO) if the standards bodies were to be driven >by the >vendors, then they would become no more >than sanitised purveyors of de facto standards, and je jure standards would be >relegated to being nothing more than "misty-eyed" memories. Are you saying that IETF specifications are de jure standards? If so, don't tell the State Department, they don't know that :^) IETF Specifications are indeed de facto standards - they are standards in part because the community calls them such, but mostly because the community implements them and uses them. I think what you meant to say is that they would be nothing more than purveyors of the proprietary protocols that vendors chose to make semi-public.
Re: breaking the IP model (or not)
> It's also bad that there is little or no integration of intermediate > system vendors with end system vendors (or vice versa), because that > results in insufficient sharing of information between those two > industry segments. The IETF should be facilitating information > exchange, but it isn't working as well as it should (otherwise we > wouldn't have these problems, right?). it's not clear that the problems are caused by lack of information exchange, given time-to-market pressures that cause folks to ship product now and deny causing problems later.
Re: breaking the IP model (or not)
Bernard Aboba wrote: ... > >- indicators that there is an important problem that needs to be > > solved in a technically sound fashion > > If this mail thread is any indication, I'd say the indicator is > shining brightly. There are many people wearing 3-month goggles who still just can't see it. Brian
Re: breaking the IP model (or not)
It's much worse than that. In the End to End model, far too many of our problems require changing all the end systems to solve. However, that's extremely difficult to do, particularly as there is little or no incentive (the DCA/DISA had guns, and control of the IMPs in 1982/1983 to force the NCP->TCP/IP conversion - there is no equivalent agency today). Almost all of the pressure created by the growth of the Internet is on the network operators and their vendors (e.g. router vendors), rather than on the users and the end systems (and the end system vendors, e.g. PCs, Macs, Suns, etc). It's also bad that there is little or no integration of intermediate system vendors with end system vendors (or vice versa), because that results in insufficient sharing of information between those two industry segments. The IETF should be facilitating information exchange, but it isn't working as well as it should (otherwise we wouldn't have these problems, right?). So, with nearly all the pressure on the operators and the vendors that serve them, the "solutions" they come up with are necessarily pretty ugly hacks (e.g. NAT, TCP spoofing, Firewalls) because they have to deal with the reality that they can't change the end systems themselves, or require them to be changed. This is a structural problem. Until the situation changes, we're going to keep on seeing ugly hacks that do violence to the Internet architectural model deployed, marketed, touted as "solutions." an author of RFC 1627, Erik <[EMAIL PROTECTED]>
Re: breaking the IP model (or not)
> >it's completely natural that people will try such approaches - > >they are trying to address real problems and they want quick > >solutions to those problems. > > In particular, they will try such approaches if they are not > presented with better alternatives. there's something odd to my ear about people needing to *be presented* with better alternatives than doing harm to the architecture as opposed to those people *developing* better alternatives. I suspect there's something about the current economic climate that favors development of quick fixes over development of sane ones. but the apparent shortsightedness still bothers me. Keith
