Re: Topic drift Re: An Internet Draft as reference material
Greg Minshall wrote: i think there are two issues. one is that when I-Ds were created, there was some controversy, mainly revolving around the notion that we already had a forum for people putting out ideas (known as RFCs), and that the fact that the public concept of RFC was different from our intent, we should stick by our intent (and work on educating the public). if i remember correctly, it was within this part of the discussion that we decided that I-Ds would be ephemeral documents. A couple of people are claiming to represent the intent of people "back then" - maybe I should go back to the Historical Internet Drafts Directory and review that debate to see whether everyone is remembering history correctly. Ooops, I can't do that until there *is* an Historical Internet Drafts directory! :-) Sorry to poke fun, I *do* respect your opinion of what was the group think intent from tat period, but frankly time has moved on and we all have different needs than we did back then. I remember this whole thread getting a treatment something like a year ago and I argued then for institutional memory. I also argued that some of the participants of the IETF seem to have developed an exagerated sense of the group's real importance and ability to control how others perceive it. Bottom line is that access to historical information is useful. The IETF should (and I'm glad to hear, will) make this material available. As Martha Stewart says, "And this is good". - peterd if *we*, as an organization (or whatever we are) decide that I-Ds should no longer be ephemeral documents, then we probably pop right back up in the middle of the "should we have two archival document series" discussion again. (though frankly i'm not sure the energy is there for at least the "RFC is the one" side of the discussion.) the second issue, as many have pointed out, is that there is no way to stop http://www.internetdraftsforever.com from springing up (hey, maybe it's already there!). certainly, no one is (seriously) trying to prevent that from happening. i think of the current (officially ephemeral) I-Ds as being like Usenet postings (remember those?). people *do* cite them in articles occasionally, dejanews (or whatever) does hang on to them forever, you can (or you could, in the past at least) buy CDs full of them. but, they don't have the "cachet" of an RFC. i personally would vote for keeping the I-Ds "officially ephemeral", and if deja-id pops up to archive them, i'll probably occasionally poke around in there myself. cheers, Greg Part 1.2 Type: application/pgp-signature -- Peter Deutsch work email: [EMAIL PROTECTED] Technical Leader Content Services Business Unit private: [EMAIL PROTECTED] Cisco Systems or : [EMAIL PROTECTED] Alcohol and calculus don't mix. Never drink and derive.
Re: draft-ietf-nat-protocol-complications-02.txt
g'day, Masataka Ohta wrote: . . . If IETF makes it clear that AOL is not an ISP, it will commercially motivate AOL to be an ISP. Not to be unkind, since the IETF has done some good work, but the above statement is incorrect. If you'd written "If AOL perceives that the market would punish them if the IETF makes it clear that AOL is not an ISP, it will commercially motivate AOL to be an ISP" you might be closer to the mark. The bottom line is, the world isn't waiting for us to tell them the right way to do what they want and the clever solutions we came up with as solutions to the networking problems of 1970, or 1980, or 1990 don't demand that they adopt our proposals for solving their problems of 2000. We're in serious danger of surrendering to the same elitist posturing for which we used to vilify the mainframe community. Pity, but we'll have only ourselves to blame if and when the users pass us by... - peterd (feeling testy this evening) -- Peter Deutsch work email: [EMAIL PROTECTED] Engineerng Manager Caching Content Routing Content Services Business Unit private: [EMAIL PROTECTED] Cisco Systems "I want to die quietly and peacefully in my sleep like my granfather, not screaming in terror like his passengers..." - Emo Phillips
Re: prohibiting RFC publication
g'day, Tripp Lilley wrote: On Sun, 9 Apr 2000, Peter Deutsch in Mountain View wrote: readily accessible. I still see value in having documents come out as "Request For Comments" in the traditional sense, but it certainly wouldn't hurt to find ways to better distinguish between the Standards track and other documents. Here's a novel idea: we could stop calling them all "RFCs". Call them by the designators they get once they're blessed (ie: STD, INF, EXP, etc.), and stop ourselves citing them as RFC [0-9]+. Change begins at home, as they say... Yeah, although I'd personally hum for keeping the RFC nomencalture for the Standard and Experimental class RFCs, as the name is understand to encompass that anyways. The rest we could lump under something like "OFI" (Offered For Information? The marketing guys here agree that they wont write code if I don't name products... ;-) Anyways, we need to draw a clearer line between the standards which have been wrought by the IETF, and information which has been captured and tamed, so to speak... - peterd -- Peter Deutsch work email: [EMAIL PROTECTED] Technical Leader Content Services Business Unit private: [EMAIL PROTECTED] Cisco Systems or : [EMAIL PROTECTED] Alcohol and calculus don't mix. Never drink and derive.
Re: prohibiting RFC publication
g'day, Dave Crocker wrote: . . . It strikes me that it would be much, much more productive to fire up a working group focused on this topic, since we have known of the application level need for about 12 years, if not longer. Which raises the interesting question as to what the participants would hope to be the outcome of such a working group and whether we could possibly move towards something ressembling a technical consensus, given the current polarity of the debate. There are certainly more people than Keith who would brand the relevant practices as evil and immoral. For sure you'd hear strong views against endorsing transparent proxies, NATs and other things already touched upon here over the past few months. I could mention a few more, at least as controversial, which I'd see as coming into scope in the near future but frankly I'm not personally willing to spend any energy trying to engage in any form of consensus building on such things right now. The parties are simply too far apart for me to expect there to be anything but grief at the other end. I've seen us spend a lot of time engaging in working groups in which some number of the participants has as their goal the invalidating of the underlying concept or torpedoing the process itself. Having been there, done that and collected the T-shirt a couple of times myself, I wouldn't go through that again just because I have a soft spot, either for the IETF or in my head. That isn't to say I disagree with you, Dave. There's definitely work to be done here. It's just that this is one hairy tarball, and although there's going to be lots done in this area over the next couple of years we've probably reached a fork in the road where the IETF has to take stock of itself before it can play a useful role. If it doesn't do that I predict that some of the major architectural and implementation decisions in this particular subspace will be taking place outside the IETF. And clearly, some would think that a good thing. - peterd -- -- Peter Deutsch work email: [EMAIL PROTECTED] Technical Leader Content Services Business Unit private: [EMAIL PROTECTED] Cisco Systems or : [EMAIL PROTECTED] Alcohol and calculus don't mix. Never drink and derive. --
Re: recommendation against publication of draft-cerpa-necp-0
Hi Patrik, Patrik Fältström wrote: At 17.29 -0700 2000-04-07, Peter Deutsch wrote: LD is intended to sit in front of a cluster of cache engines containing similar data, performing automatic distribution of incoming requests among the multiple caches. It does this by intercepting the incoming IP packets intended for a specific IP address and multiplexing it among the caches. What you are doing is giving a product to the service provider, which is the one which owns the services which you load balance between. In the case of a transparent proxy which is discussed in this thread, the interception is done neither by the service provider (i.e. CNN or whoever) nor by the customer, and neither of them are informed about what is happening. That is a big difference. I agree, and would welcome a BCP document pointing out this distinction and explaining why the later is harmful. Banning publication of technologies a priori (as I argue elsewhere) wont stop the technology being developed, wont stop the practice and just leads to the IETF abdicating it role as a meeting point for technical innovation. - peterd
Re: recommendation against publication of draft-cerpa-necp-02.txt
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, but I'd like to make clear that I don't regard this as a "largely personal...argument". On the contrary, I've drunk beer with you, I like you as a person and would be happy to drink beer with you again. I am engaging here *only* because I think the principles I'm defending are so important. It really is nothing personal. 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 actually be harmful to Internet operation and its ability to support applications. Fair enough, but my primary goal was not to justify this particular technique, but to address the issue of whether we should be preventing the publication of particular techniques, and under what ground rules. The industry and their customers have already decided against you on this one. I'm wondering about the future of an IETF that consistently takes itself out of play in this way. I'm sure there are other techniques on their way that are going to allow us to find out... p.s. I think the term you're looking for is "nihil obstat". Yup, that's it. Thanks... - peterd
Re: recommendation against publication of draft-cerpa-necp-02.txt
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 lots of time for people to correct brain damage. Well, I don't share the view of a monotonic march towards the "correct" Internet. Just as the first single celled giving off massive amounts of waste oxygen created an environment which led eventually to the furry mammals, the Internet responds and evolves from instantiation to instantiation. I hear talk about products which people expect to only have a lifetime of a few years, or even a period of months, until evolution moves us all on. Some of the things that you find so offensive may not even be relevant in a couple of years. But (you knew they'd be a but, didn't you?) there is a substantial market for products based upon interception or redirection technologies today. I don't offer this as a technical argument for their adoption. I was merely pointing out that the market has voted on this technique and judged it useful despite what the IETF might or might not decree. Short of punishing those poor misguided users, I don't know what else you can accomplish on this one... I'm wondering about the future of an IETF that consistently takes itself out of play in this way. IETF's job is to promote technical sanity, not to support unsound vendor practices. Well there you go. You think the IETF's Seal of Approval and promotion of technical sanity can prevent our unsound vendor practices from perpetrating Marketing BS on poor users. You're right - the positions are fairly clear at this point. I'll try to quieten down now... - peterd
Re: recommendation against publication of draft-cerpa-necp-02.txt
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 all. I was addressing the issue that Keith was declaring a technique (IP address interception) as out of scope for the IETF and was, in doing so, cutting the IETF off from an area of work that finds widespread application on the net. This seemed inappropriate considering the claims for the organization in such places as: http://www.ietf.org/tao.html#What_Is_IETF Note in particular the claims " It is the principal body engaged in the development of new Internet standard specifications" and "Its mission includes: ... Providing a forum for the exchange of information within the Internet community between vendors, users, researchers, agency contractors and network managers." IP address interception is a widely used technique that would not be developed or documented through the IETF if Keith had his way. Since it is a widely used technique for vendors and network managers, we'd have to ask Gary Malkin to revise his document if we agree to Keith's request. To be explicit, this is a metadiscussion about the IETF. I specifically disclaim any interest or standing in a debate about NECP itself. Frankly, I hope we are going to be able to arrest this dangerous trend. So, I engaged last year when I saw the broadcast industry being run out of town over the TV: URL draft whose technical content I recall as being a few lines of incorrect EBNF notation that didn't parse. But hey, they were generating a _lot_ of signatories with their write-in campaign. Again, I did not engage in a debate about the technical merits of their claims, I was (and am) pointing out that the IETF claims to be a gathering place to educate and exchange ideas and is not as good at that as it used to be (IMHO). Yes, and those of us who object to this degradation of the original concept of the IETF I'd like a reference for the original concept of the IETF, please; I worry about history being rewritten. What was the original concept of 'RFC Editor', exactly? I'm away from my archives, and my history only goes back about 10 years, so I'll leave that for others who were there, but I refer you again to the Tao of the IETF. To me the appropriate reponse when someone sees danger in a technology is another document, making your case. ...which is why Keith began this thread in the first place. Or don't mailing list posts count as documents? Well, that's not the way I read his initial messages. He basically said "I tried to stop them at the drafting stage, but couldn't so I ask that we not let this go out the door with our name on it". Originally the response to an RFC you disagreed with was an RFC explaining the problems you perceive. It is true that things have become more formal over time, but nowhere is it carved in stone tablets that we can't identify problems with current trends and make some adjustments to our processes. That's not a call for less peer review. It's a call for less of a single world view, and more tolerance for multiple world views. In effect, I'd also rather we worry more about what technical people do with our documents and less with what marketing people do with our documents. Note, nobody talks in terms of getting something "blessed by the IETF", but in terms of how the IETF would slow the work down and get in the way so shouldn't be a part of the process. Peer review slows things down. This is unavoidable in exposing the work to a larger audience, but has long-term societal benefits unfortunately not quantifiable on a balance sheet. I guess I didn't explain that very well. The question was not whether the work would be submited to peer review, but whether the IETF was an appropriate forum for that peer review. The view I've heard expressed several times has been that the IETF has ossified and would not be receptive to new ideas so just slowed things down. The implication being that the IETF was no longer relevant to the engineering process. You are not going to hear this opinion expressed here from people who have already moved on, so I thought I'd pass it on. Note, I am *not* suggesting Cisco has abandoned the IETF. Heck, such a decision would be so way out of my pay grade (and not the way I see this company working at all). I'm just suggesting that at least some individuals I know (and not just at Cisco) are starting to feel that the IETF is less relevant to their needs than it used to be. Some people are going to say "great, that'll cut down on the marketing BS".. I happen to say "Houston, we have a problem here..." - peterd
