Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, Mar 19, 2006 at 04:17:24PM -0800, william(at)elan.net [EMAIL PROTECTED] wrote a message of 92 lines which said: Either all submissions are rejected due to load or none. I disagree. Even with good and honest engineers, there are enough people in the world to overload the IESG. But when you take into account trolls and protocol-kiddies, you *need* a laugh test to eliminate quickly the works of these people. (It is exactly the method we all use to skip quickly over Banan or Morfin's messages on a mailing list.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, Mar 19, 2006 at 01:46:30AM -0800, Mohsen BANAN [EMAIL PROTECTED] wrote a message of 73 lines which said: In general, I consider the garbage that IESG puts in non-IETF RFCs as a badge of honor for the author. For example, the negative IESG note in the original HTTP specs and the success of HTTP demonstrated IESG's attitude and its eventual relevance. It is true that the IESG Notes in RFC 1945 and RFC 1630 are quite embarassing for the IETF today but you are not Tim Berners-Lee. For one genius who had trouble being recognized at the beginning, there are thousands of monkeys-with-keyboards who are rightly ignored. Your reasoning is the same fallacy as saying Galileo was persecuted and he was right, I am persecuted so I am right. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Title: Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) The comments on http are rather amusing when you consider we spent the next five years trying to act on them. At the time the CERN connection to the internet was a T1. Everyone including Tim thought caching was essential. The note was in the http draft to alert readers to the need to follow the http working group. Http 1.0 did not scale, it provided such a compelling value that it drove deployment of the necessary support infrastructure. That is not an approach to encourage. isn't this a bit late to bring it up? What is esro anyway? I seem to have survived not knowing about it. -Original Message- From: Mohsen BANAN [mailto:[EMAIL PROTECTED]] Sent: Sun Mar 19 01:48:09 2006 To: Harald Alvestrand Cc: RFC Editor; ietf@ietf.org Subject: Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) On Sun, 19 Mar 2006 04:56:57 +0100, Harald Alvestrand [EMAIL PROTECTED] said: Harald Mohsen BANAN wrote: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) Harald The IESG pointed some of the issues out to the RFC Editor, who handled Harald the communication with the author; that was the procedure at that time. Harald Nevertheless, the RFC Editor felt that the document was worthy of Harald publication, and published anyway. As the written record clearly shows, this is factually incorrect. In the case of RFC-2188 the RFC Editor was no more than an IESG puppet. Publication was held up for more than 7 months, until finally Scott Bradner (Transport Area Director at the IESG) made it happen -- emphatically *not* the RFC Editor. Scott can step in, if he wishes. Full communication records are available at: http://www.esro.org/communicationRecord/rfc2188Publication/maillist.html And then there is the communication record of what happened when the IESG invited us to put ESRO on the standards track. http://www.esro.org/noStdTrack/main.html Harald The IESG note put on this document says: In general, I consider the garbage that IESG puts in non-IETF RFCs as a badge of honor for the author. For example, the negative IESG note in the original HTTP specs and the success of HTTP demonstrated IESG's attitude and its eventual relevance. Harald In this case [RFC-2524], too, the RFC Harald Editor exercised the RFC Editor's Harald independent judgment and published the Harald document. Had it not been for my very public RFC-2188 complaint, I do not believe RFC-2524 would have been published at all. Please note the time of my complaint and of the RFC-2524 publication. How many other non-IETF RFCs have ever been published by the RFC Editor in the face of IESG opposition? I believe the answer is very few if not zero. If I am wrong, I ask the RFC Editor/IESG to correct the record. Please name the RFCs. Harald This was eight years ago. ... Lack of true independence of the RFC Editor was the issue then, and it is the issue now. ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
HTTP archaeology [Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)]
... Hallam-Baker, Phillip wrote: The comments on http are rather amusing when you consider we spent the next five years trying to act on them. At the time the CERN connection to the internet was a T1. Er, the CERN connection to the NSFnet was a T1, or possibly an E1 by then. CERN had much more b/w than that to the European part of the Internet, where the majority of CERN users were (and are). Brian, who was there at the time ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: HTTP archaeology [Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)]
... Hallam-Baker, Phillip wrote: The comments on http are rather amusing when you consider we spent the next five years trying to act on them. At the time the CERN connection to the internet was a T1. Er, the CERN connection to the NSFnet was a T1, or possibly an E1 by then. CERN had much more b/w than that to the European part of the Internet, where the majority of CERN users were (and are). Brian, who was there at the time CERN had at least 11 Mbps ... http://museum.media.org/eti/Prologue04.html Carl, who visited at the time. :) Carl ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 04:56:57 +0100, Harald Alvestrand [EMAIL PROTECTED] said: Harald Mohsen BANAN wrote: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) Harald The IESG pointed some of the issues out to the RFC Editor, who handled Harald the communication with the author; that was the procedure at that time. Harald Nevertheless, the RFC Editor felt that the document was worthy of Harald publication, and published anyway. As the written record clearly shows, this is factually incorrect. In the case of RFC-2188 the RFC Editor was no more than an IESG puppet. Publication was held up for more than 7 months, until finally Scott Bradner (Transport Area Director at the IESG) made it happen -- emphatically *not* the RFC Editor. Scott can step in, if he wishes. Full communication records are available at: http://www.esro.org/communicationRecord/rfc2188Publication/maillist.html And then there is the communication record of what happened when the IESG invited us to put ESRO on the standards track. http://www.esro.org/noStdTrack/main.html Harald The IESG note put on this document says: In general, I consider the garbage that IESG puts in non-IETF RFCs as a badge of honor for the author. For example, the negative IESG note in the original HTTP specs and the success of HTTP demonstrated IESG's attitude and its eventual relevance. Harald In this case [RFC-2524], too, the RFC Harald Editor exercised the RFC Editor's Harald independent judgment and published the Harald document. Had it not been for my very public RFC-2188 complaint, I do not believe RFC-2524 would have been published at all. Please note the time of my complaint and of the RFC-2524 publication. How many other non-IETF RFCs have ever been published by the RFC Editor in the face of IESG opposition? I believe the answer is very few if not zero. If I am wrong, I ask the RFC Editor/IESG to correct the record. Please name the RFCs. Harald This was eight years ago. ... Lack of true independence of the RFC Editor was the issue then, and it is the issue now. ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 04:56:57 +0100, Harald Alvestrand [EMAIL PROTECTED] said: On Sat, 18 Mar 2006 21:10:10 -0800, Dave Crocker [EMAIL PROTECTED] said: Harald What's the point of reposting this message now? Dave Seems like there ought to be a statute of limitations. In response to both of you: the point of referring to eight-year old history is not to disinter the corpse of the past. The point is that this history is directly relevent to a current discussion thread. I believe I made the point of reposting clear in the following header: Mohsen [ This is a repost from 6 Nov 1998. Mohsen In particular the section on: Mohsen o Separate The RFC Publication Service from the IETF/IESG/IAB. Mohsen is relevant to the current: MohsenSTRAW PROPOSAL RFC Editor charter Mohsen thread. ] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun Mar 19 09:46:30 2006, Mohsen BANAN wrote: For example, the negative IESG note in the original HTTP specs and the success of HTTP demonstrated IESG's attitude and its eventual relevance. For the crowd watching who were curious, but not curious enough to bother looking, RFC1945 (HTTP/1.0), which of course is NOT the original HTTP spec at all, carries the note: The IESG has concerns about this protocol, and expects this document to be replaced relatively soon by a standards track document. RFC2068, HTTP/1.1, was published a little over half a year later, which would appear to be relatively soon. Something appears to be wrong with your DNS, so reading your webpages is somewhat impractical. FWIW, I reviewed EMSD a little while ago, to see whether there was anything worth raising for Lemonade, and decided that the IESG note on that still stands, except more so, as various problems they noted have become more important as time has passed. [For the crowd, EMSD is a wireless replacement for the Submission protocol, but does not support anything but ASCII, has no authentication, and insists on using its own message format in ASN.1] But back to your argument, which appears to be that if the RFC editor function were utterly independent from the IAB/IETF/IESG, your protocols would have been published without those notes, and without the review those notes required. Which part is the problem, the review, or the note attached to the document? Dave. -- You see things; and you say Why? But I dream things that never were; and I say Why not? - George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Harald The IESG pointed some of the issues out to the RFC Editor, who handled Harald the communication with the author; that was the procedure at that time. Harald Nevertheless, the RFC Editor felt that the document was worthy of Harald publication, and published anyway. As the written record clearly shows, this is factually incorrect. In the case of RFC-2188 the RFC Editor was no more than an IESG puppet. Publication was held up for more than 7 months, until finally Scott Bradner (Transport Area Director at the IESG) made it happen -- emphatically *not* the RFC Editor. Scott can step in, if he wishes. I will go on record to say that I was the IESG member who did the most to discourage publication of your document as an RFC. Contrary to your perception of things, the RFC Editor published it over my strong objections, and also insisted on diluting the IESG note that was originally written for that document. I don't recall the reasons for the delay other than the high workload of IESG (we were reviewing dozens of documents per week, the fact that IESG discussed things in conference calls every two weeks, and there were several iterations of back-and-forth with the RFC Editor regarding your document. It is my recollection that your document was handled much more quickly than working group documents -- because unlike WG documents which proceeded normally though the IESG's queue (and for which the speed of processing was sensitive to IESG's workload), the RFC Editor had a policy of giving IESG a limited amount of time to comment on independent submissions that had the perverse side-effect of giving priority to those submissions. It was and still is my opinion that RFC 2188 was not suitable for publication as an RFC, as it is poorly designed and has numerous technical flaws. To have published this document IMHO dilutes the quality of the RFC series and may confer an undeserved appearance of acceptance on ESRO. Perhaps more importantly, the discussion about this document wasted a colossal amount of time that could have been put to much better use reviewing working group output (on the part of the IESG) and editing better quality documents (on the part of the RFC Editor). As Harald points out, this was eight years ago, and the process has changed significantly since that time. Also, I'm no longer on the IESG and don't expect to ever be on the IESG again. Life is too short. Since all of the circumstances and nearly all of the people have changed since this incident, I don't see how it's relevant now. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
I too agree with Mohsen's comments, overall. What Mohsen points out as true eight years ago continues to be true even now. Not a lot changed, IMHO. I believe, it had gotten worse. IESG continues to wield enormous influence over the independent submissions sent to the RFC editor. The RFC editor needs to be independent. regards, suresh --- Mohsen BANAN [EMAIL PROTECTED] wrote: On Sun, 19 Mar 2006 04:56:57 +0100, Harald Alvestrand [EMAIL PROTECTED] said: On Sat, 18 Mar 2006 21:10:10 -0800, Dave Crocker [EMAIL PROTECTED] said: Harald What's the point of reposting this message now? Dave Seems like there ought to be a statute of limitations. In response to both of you: the point of referring to eight-year old history is not to disinter the corpse of the past. The point is that this history is directly relevent to a current discussion thread. I believe I made the point of reposting clear in the following header: Mohsen [ This is a repost from 6 Nov 1998. Mohsen In particular the section on: Mohsen o Separate The RFC Publication Service from the IETF/IESG/IAB. Mohsen is relevant to the current: MohsenSTRAW PROPOSAL RFC Editor charter Mohsen thread. ] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 09:42:50 -0800 (PST), Pyda Srisuresh [EMAIL PROTECTED] wrote: I too agree with Mohsen's comments, overall. What Mohsen points out as true eight years ago continues to be true even now. Not a lot changed, IMHO. I believe, it had gotten worse. IESG continues to wield enormous influence over the independent submissions sent to the RFC editor. The RFC editor needs to be independent. Why? There are plenty of other publication venues. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Right, that is the foced outcome of the current practice. Without an independent channel, people find other avenues outside the IETF to get their work done. regards, suresh --- Steven M. Bellovin [EMAIL PROTECTED] wrote: On Sun, 19 Mar 2006 09:42:50 -0800 (PST), Pyda Srisuresh [EMAIL PROTECTED] wrote: I too agree with Mohsen's comments, overall. What Mohsen points out as true eight years ago continues to be true even now. Not a lot changed, IMHO. I believe, it had gotten worse. IESG continues to wield enormous influence over the independent submissions sent to the RFC editor. The RFC editor needs to be independent. Why? There are plenty of other publication venues. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 10:17:13 -0800 (PST), Pyda Srisuresh [EMAIL PROTECTED] wrote: Right, that is the foced outcome of the current practice. Without an independent channel, people find other avenues outside the IETF to get their work done. More precisely, to publish their work. My question is why this is bad for anyone except those who want the RFC label on their work. Put another way, the real question is what RFC means. Given the confusion that already exists in the market (We implement RFC 1149!), I'd rather there were more IETF controls on what bears that label. I'm not saying it should be completely an IETF publishing venue (though frankly, I wouldn't mind it at all if the IETF could trademark RFC), but I do think that avoiding gratuitous confusion is a good idea. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006 11:23:45 +, Dave Cridland [EMAIL PROTECTED] said: Dave On Sun Mar 19 09:46:30 2006, Mohsen BANAN wrote: For example, the negative IESG note in the original HTTP specs and the success of HTTP demonstrated IESG's attitude and its eventual relevance. Dave For the crowd watching who were curious, but not curious enough to Dave bother looking, RFC1945 (HTTP/1.0), which of course is NOT the Dave original HTTP spec at all, carries the note: DaveThe IESG has concerns about this protocol, and expects this document Daveto be replaced relatively soon by a standards track document. Dave RFC2068, HTTP/1.1, was published a little over half a year later, Dave which would appear to be relatively soon. The primary author of Informational RFC1945 with the negative IESG note is Tim Berners-Lee. He then pulled out of the IETF/IESG and formed W3C. Why do you think that happened? And where is IETF/IESG with W3C now? In my opinion what started with the Informational RFC1945 is the most significant advancement since formation of IETF/IESG/IAB/... Almost always innovation comes from outside of committees. Dave But back to your argument, which appears to be that if the RFC editor Dave function were utterly independent from the IAB/IETF/IESG, your Dave protocols would have been published without those notes, and without Dave the review those notes required. Which part is the problem, the Dave review, or the note attached to the document? None of those. My concern is not my own RFCs. I got them published despite of the IETF/IESG opposition. The IESG note is a badge of honor similar to Tim Berners-Lee's. The perspective that the world needs the IESG note to be able to judge the merits of a protocol is at best comical. The scope and purpose of the IESG note should be limited to relevance and overlap with current or planned IETF work. An independent RFC Editor should enforce this and put the IESG in its place. That is what the then BCP -- RFC-2026 -- said. Of course, things work differently in a cult. I suspect that lots of direct independent RFC submissions are being censored by the IESG. The community is being fragmented. And the trend appears to be for the situation to only be getting worse. Again, all of this is in the context of: STRAW PROPOSAL RFC Editor charter where the key topics are: - Independence of RFC Publication Service - Relationship of IETF/IESG/IAB with the RFC Publication Service - Use of the RFC Publication Service by the Internet Community Tony gets it: On Sun, 19 Mar 2006 09:28:17 -0800, Tony Hain [EMAIL PROTECTED] said: Tony The point is that the past IESG practice which has driven out those who Tony would submit individual submissions, resulting in the current ratios, MUST Tony NOT become the guide for what SHOULD happen going forward. The RFC editor Tony role needs to be extricated from the overbearing IESG and returned to its Tony independent role. Doing otherwise further fragments the community which will Tony only lead to its downfall. From my perspective, based on past performance, the IETF/IESG/IAB can not be trusted to control the RFC Publication Service. ...Mohsen ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Dave RFC2068, HTTP/1.1, was published a little over half a year later, Dave which would appear to be relatively soon. The primary author of Informational RFC1945 with the negative IESG note is Tim Berners-Lee. He then pulled out of the IETF/IESG and formed W3C. Why do you think that happened? Because he had specific ideas he wanted to pursue, and wanted staff to work on them. That required a different model than the IETF. Pulled out is an exaggeration, however. W3C has sent people to IETF meetings ever since it was founded. And where is IETF/IESG with W3C now? Cooperating quite well and respecting each others' areas of competence, I think. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Keith, You have totally confused ESRO with EMSD. RFC-2188 is different from RFC-2524. 1) RFC-2188 (ESRO) As far as I know the RFC-2188 complaint had nothing to do with you. Everything is fully documented. We are talking about historic facts, not opinions. IESG did not object to publication of ESRO (RFC-2188). I declined IESG's invitation to put ESRO on standards track. That was my choice. The problem was that it took 7 months. 2) RFC-2524 (EMSD) You lost. I managed to convince the RFC Editor of the merits of publication. I used the RFC-2188 complaint to strengthen the RFC Editor's independence. There has never been any formal complaints related to RFC-2524. The only part of the IESG note that can be considered to have any aspect of legitimacy is: -- In the near future, the IESG may charter a working group to define an Internet standards-track protocol for efficient transmission of electronic mail messages, which will be highly compatible with existing Internet mail protocols, and which wil be suitable for operation over the global Internet, including both wireless and wired -- links. And that was in 1999. I am curious to know what happened. In the mean time of course there has been the proprietary and patent full BlackBerry. Our real enemy are proprietary patented protocols. It would be hard to argue that existence of the WhiteBerry concept has done any harm. http://www.freeprotocols.org/operationWhiteberry/index.html Back to the topic at hand: Keith ... I don't see how it's relevant now. Again, all of this is in the context of: STRAW PROPOSAL RFC Editor charter where the key topics are: - Independence of RFC Publication Service - Relationship of IETF/IESG/IAB with the RFC Publication Service - Use of the RFC Publication Service by the Internet Community Tony gets it: On Sun, 19 Mar 2006 09:28:17 -0800, Tony Hain [EMAIL PROTECTED] said: Tony The point is that the past IESG practice which has driven out those who Tony would submit individual submissions, resulting in the current ratios, MUST Tony NOT become the guide for what SHOULD happen going forward. The RFC editor Tony role needs to be extricated from the overbearing IESG and returned to its Tony independent role. Doing otherwise further fragments the community which will Tony only lead to its downfall. From my perspective, based on past performance, the IETF/IESG/IAB can not be trusted to control the RFC Publication Service. ... Mohsen On Sun, 19 Mar 2006 08:08:10 -0500, Keith Moore moore@cs.utk.edu said: Harald The IESG pointed some of the issues out to the RFC Editor, who handled Harald the communication with the author; that was the procedure at that time. Harald Nevertheless, the RFC Editor felt that the document was worthy of Harald publication, and published anyway. As the written record clearly shows, this is factually incorrect. In the case of RFC-2188 the RFC Editor was no more than an IESG puppet. Publication was held up for more than 7 months, until finally Scott Bradner (Transport Area Director at the IESG) made it happen -- emphatically *not* the RFC Editor. Scott can step in, if he wishes. Keith I will go on record to say that I was the IESG member who did the most Keith to discourage publication of your document as an RFC. Contrary to Keith your perception of things, the RFC Editor published it over my strong Keith objections, and also insisted on diluting the IESG note that was Keith originally written for that document. I don't recall the reasons for Keith the delay other than the high workload of IESG (we were reviewing Keith dozens of documents per week, the fact that IESG discussed things in Keith conference calls every two weeks, and there were several iterations of Keith back-and-forth with the RFC Editor regarding your document. It is my Keith recollection that your document was handled much more quickly than Keith working group documents -- because unlike WG documents which proceeded Keith normally though the IESG's queue (and for which the speed of Keith processing was sensitive to IESG's workload), the RFC Editor had a Keith policy of giving IESG a limited amount of time to comment on Keith independent submissions that had the perverse side-effect of giving Keith priority to those submissions. Keith It was and still is my opinion that RFC 2188 was not suitable for Keith publication as an RFC, as it is poorly designed and has numerous Keith technical flaws. To have published this document IMHO dilutes the Keith quality of the RFC series and may confer an undeserved appearance of Keith acceptance on ESRO. Perhaps more importantly, the discussion about Keith this document wasted a colossal amount of time that could have been Keith put to much better use reviewing working group output (on the part of Keith the IESG) and editing better quality
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Dave Crocker wrote: This was eight years ago. The IESG that the complaint was made against was: Seems like there ought to be a statute of limitations. In the IETF process, that's two months. I presume that anybody who found the RFC 3932 (BCP 92) procedures unsatisfactory would have complained in 2004 when it was approved. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
You have totally confused ESRO with EMSD. RFC-2188 is different from RFC-2524. I stand corrected. Tony gets it: Tony The point is that the past IESG practice which has driven out those who Tony would submit individual submissions, resulting in the current ratios, MUST Tony NOT become the guide for what SHOULD happen going forward. The RFC editor Tony role needs to be extricated from the overbearing IESG and returned to its Tony independent role. Doing otherwise further fragments the community which will Tony only lead to its downfall. I strongly disagree with Tony that the IESG has been overbearing. From my perspective IESG has been too permissive. But perhaps this is beside the point. I believe that we need to have high standards for RFC publication - not just for working group documents or standards track documents but for all documents that are labeled RFCs. In order for that to happen, _someone_ has to do a thorough technical review of those documents, and that _someone_ has to be willing and empowered to reject documents that don't cut it. There are advantages to having IESG do that review (e.g. uniformity, lower cost) and advantages to having another party do that review (e.g. spreading the workload). I don't have a strong opinion about who does the review of non-standards-track, non-working-group documents, as long as the review is done and the document series is held to high standards. I will however caution against the assumption that IESG is inherently overbearing and a separate review function is inherently more reasonable. No matter who does the review there will always be the potential for capriciousness on the part of the reviewer. Similarly, no matter who does the review there will always be those who will insist that IETF lend its imprimatur to their flaky designs or poorly written documents, and who will consume valuable resources trying to degrade the RFC series. IMHO, it is vitally important that we avoid wasting either volunteer energy or money on such foolishness. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun Mar 19 20:59:46 2006, Mohsen BANAN wrote: The only part of the IESG note that can be considered to have any aspect of legitimacy is: I say again, I examined RFC2524 is some detail, both because it was prior art in an area that was under heavy discussion at the time in Lemonade, and because you'd suggested it be a reference in the Lemonade Profile Bis draft, and concluded that the IESG note was correct in all its points, save that I cannot claim to have enough experience to look at ESRO in detail. Do you object to: a) The censorship of RFCs based on technical merit? (In other words, would you prefer to be able to publish any technical document, no matter how bad?) b) That the IESG is providing the technical review needed by the RFC Editor to ensure the RFC series maintains quality? c) That the RFC Editor chooses to publish the IESG's review, on occasion, in the actual document? As to your free protocol foundation and whiteberry projects, I'd never heard of either until you brought them up. That's certainly causing no harm. If they were popular projects pulling useful input away from the IETF and Lemonade respectively, I'd classify that as harm. Dave. -- You see things; and you say Why? But I dream things that never were; and I say Why not? - George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
I will however caution against the assumption that IESG is inherently overbearing and a separate review function is inherently more reasonable. No matter who does the review there will always be the potential for capriciousness on the part of the reviewer. It seems to me that while many prefer IESG review some believe it may not always be fair and balanced. So if I can make a suggestion, it would be good while defaulting to IESG review to also specify that submitter may challenge their review results and/or request an independent review from another source. So it would be good if we had some other organization or specified procedure on how RFC-Editor can request review from somebody other then IESG or some other then IETF-related body. Also it seems that not specifying how long review should take allows to delay document indefinitely, which is a form of rejection without officially saying so - so maximum time that review can take should be specified (say 6 months) and if results are not made available to author and RFC-Editor by end of this time, RFC-Editor default choice should be to publish as-is without any IESG note. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006, Dave Cridland wrote: If they were popular projects pulling useful input away from the IETF and Lemonade respectively, I'd classify that as harm. Why? Harm to who and in what way? -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
I will however caution against the assumption that IESG is inherently overbearing and a separate review function is inherently more reasonable. No matter who does the review there will always be the potential for capriciousness on the part of the reviewer. It seems to me that while many prefer IESG review some believe it may not always be fair and balanced. Again, this will be true no matter who does the review. So if I can make a suggestion, it would be good while defaulting to IESG review to also specify that submitter may challenge their review results and/or request an independent review from another source. That sounds like an appeals process to me. It's not at all clear to me that we can afford the resources to give the privilege of appeal to mere individuals. Also it seems that not specifying how long review should take allows to delay document indefinitely That's a bit like saying that an SMTP server should not be able to delay mail indefinitely no matter how much SPAM it gets. There are a near-infinite number of simians with keyboards, while IETF review resources are (and always will be) finite and precious. So no matter who does the review for individual submissions, I think that it's perfectly reasonable for that reviewer to be able to say Sorry, we receive too many invididual submissions to review them all, and yours doesn't pass the smell test. You may wish to seek publication through other channels. This is no different than any other publisher. IETF is not a vanity press. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
On Sun, 19 Mar 2006, Keith Moore wrote: I will however caution against the assumption that IESG is inherently overbearing and a separate review function is inherently more reasonable. No matter who does the review there will always be the potential for capriciousness on the part of the reviewer. It seems to me that while many prefer IESG review some believe it may not always be fair and balanced. Again, this will be true no matter who does the review. True. But if you want to make RFC-Editor a separate function from IETF/IESG you must allow it choices on who would do a review So if I can make a suggestion, it would be good while defaulting to IESG review to also specify that submitter may challenge their review results and/or request an independent review from another source. That sounds like an appeals process to me. Both appeals process and process where submitter if he thinks IETF is not fair in its reviews can request independent review in the first place (though IESG would still need to provide its review as to if there are any conflicts and may choose to provide additional technical review as additional input as well). The point being that technical reviews do not have to come exclusively from IESG and that rfc-editor should have access to multiple inputs deciding if publication is appropriate. It's not at all clear to me that we can afford the resources to give the privilege of appeal to mere individuals. Excuse me? What do you think IETF is or do you really prefer to see it officially turn into IVTF? Also it seems that not specifying how long review should take allows to delay document indefinitely That's a bit like saying that an SMTP server should not be able to delay mail indefinitely no matter how much SPAM it gets. It should not. If server is loaded with processing existing email, it should not delay processing longer and longer internally but directly start answering with 400 error. To turn this analogy (which I don't think is very good in the first place) to publication process - RFC editor can say that its overloaded and will not accept submissions in the first place, but if it accepted submission - there should be finite time in which it should be delayed within IESG review stage. There are a near-infinite number of simians with keyboards, while IETF review resources are (and always will be) finite and precious. So no matter who does the review for individual submissions, I think that it's perfectly reasonable for that reviewer to be able to say Sorry, we receive too many invididual submissions to review them all, and yours doesn't pass the smell test. No smell tests please just because you're overworked and don't have time for substantial review. Either all submissions are rejected due to load or none. RFC-Editor can report to ISOC and IETF if it begins to experience too high a load with individual reviews and request additional funding or input to improve its process to deal with this. However if I understand current situation, the individual publications requests directly to RFC Editor have not been anything close to serious issue and its IETF's own documents that require IESG review that put greatest stress on IESG workload and delays in RFC publication. You may wish to seek publication through other channels. This is no different than any other publisher. IETF is not a vanity press. The question here is about RFC Editor and its process. Original function of RFCs after all was to document internet protocols and how to use them to allow others to know what each protocol is about from common easily searchable source. IETF on the other hand is organization responsible with engineering standards for certain internet functions - that means it goes quite a bit further then just publication or approval of documents but actually is engaged in group effort to engineer the service/protocol where the need for such functionality exists. -- William Leibzon Elan Networks [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
It's not at all clear to me that we can afford the resources to give the privilege of appeal to mere individuals. Excuse me? What do you think IETF is or do you really prefer to see it officially turn into IVTF? IETF is, or should be, an engineering organization. Not a vanity press. IETF exists to benefit the entire Internet community, rather than authors wanting recognition or vendors wanting endorsement for their products. It's more important for IETF to produce good engineering than it is for anyone to be able to exhaust IETF's resources trying to get his or her way. Also it seems that not specifying how long review should take allows to delay document indefinitely That's a bit like saying that an SMTP server should not be able to delay mail indefinitely no matter how much SPAM it gets. It should not. If server is loaded with processing existing email, it should not delay processing longer and longer internally but directly start answering with 400 error. To turn this analogy (which I don't think is very good in the first place) to publication process - RFC editor can say that its overloaded and will not accept submissions in the first place, but if it accepted submission - there should be finite time in which it should be delayed within IESG review stage. SMTP servers can bounce with 400 errors also. There are a near-infinite number of simians with keyboards, while IETF review resources are (and always will be) finite and precious. So no matter who does the review for individual submissions, I think that it's perfectly reasonable for that reviewer to be able to say Sorry, we receive too many invididual submissions to review them all, and yours doesn't pass the smell test. No smell tests please just because you're overworked and don't have time for substantial review. Either all submissions are rejected due to load or none. Strongly disagree. When we reject a document we generally expect the reviewer to supply good reasons for rejecting and to explain what would make the document more deserving of publication. It's relatively easy to competently sift potential wheat from chaff. It's much harder to do full reviews where you explain what's wrong and how to fix it, and get into iterative negotiation with the author. RFC-Editor can report to ISOC and IETF if it begins to experience too high a load with individual reviews and request additional funding or input to improve its process to deal with this. I believe flow control is needed at every point in the system. However if I understand current situation, the individual publications requests directly to RFC Editor have not been anything close to serious issue if working with the Internet for 20 years has taught me anything, it's that any hole that exists will someday be exploited, and soon after that, will be exploited massively. You may wish to seek publication through other channels. This is no different than any other publisher. IETF is not a vanity press. The question here is about RFC Editor and its process. Original function of RFCs after all was to document internet protocols and how to use them to allow others to know what each protocol is about from common easily searchable source. most things evolve over time, including RFCs and IETF. either that or they become extinct. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
At 02:44 20/03/2006, Keith Moore wrote: It's not at all clear to me that we can afford the resources to give the privilege of appeal to mere individuals. Excuse me? What do you think IETF is or do you really prefer to see it officially turn into IVTF? IETF is, or should be, an engineering organization. Not a vanity press. IETF exists to benefit the entire Internet community, rather than authors wanting recognition or vendors wanting endorsement for their products. Sorry. This was before RFC 3935. The IETF exists to infuence people on the way to design use and manage the Internet. And this is worth gold. It's more important for IETF to produce good engineering than it is for anyone to be able to exhaust IETF's resources trying to get his or her way. Agreed. The problem is the IANA. A key registry is worth gold too. Good engineering or not, some interests want to go through. jfc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
[ This is a repost from 6 Nov 1998. In particular the section on: o Separate The RFC Publication Service from the IETF/IESG/IAB. is relevant to the current: STRAW PROPOSAL RFC Editor charter thread. ] Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) Mohsen Banan mohsen at neda.com November 5, 1998 This is a complaint against the IESG and the RFC-Editor about publication of RFC-2188 (Efficient Short Remote Operations - ESRO) as an Informational RFC. A lot went wrong in the process of publication of RFC-2188. The highlights are: o The publication of the RFC was delayed for *8 months* for no good reason. o During the period from the day of submission to the day of publication (8 months) there was only one technical email exchange related to this RFC and the RFC was published exactly as it was submitted (plus the IESG note). o The IESG was irresponsible and negligent in fulfilling its role. o The RFC-Editor was negligent in fulfilling its role. o In practice, the publicized processes and procedures for the Informational RFC publication were not being followed neither by the IESG and nor by the RFC-Editor. o In practice, RFC-Editor was reduced to a puppet of IESG acting as a glorified secretary and an inefficient messenger. o The IESG over stepped the scope of its authority and displayed an arrogant an dictatorial attitude which caused serious delays in the publication of the RFC. I (Mohsen Banan -- mohsen at neda.com) have used very strong words in the above list to characterize the problems in this specific case. Use of those words are in no way extreme. Use of ALL of those words are justified in this message. The fact that a lot went wrong in the case of publication of RFC-2188 is known to many. Steve Coya and Scott Brander have admitted that there were a number of problems and have apologized for them. Scott Bradner ... the iesg fucked up and I'm trying to fix the issue ... Steve Coya You DO have a valid complaint, but not with the RFC Editors. Scott Bradner ... As I said things slipped through Scott Bradner the cracks and I am sorry that happened. ... I accepted their apologies and after the publication of RFC-2188 I was going to let this drop. However, since then I have seen even more evidence of the IESG being way out of control and now feel that something needs to be done. This note is complete and includes all that is necessary to allow people to judge for themselves the validity of my complaints. My goal is to PRESERVE the so far mostly open Informational RFC publication process from censorship by the likes of IESG. We need to find a way to ensure that what went wrong in this case never happens again. I am preparing this complaint because I think that it can help a number of areas which are critical to the continued success of the Internet. In the absence of any sort of accountability by the IESG and the RFC-Editor to anyone, I am hoping that peer pressure and public embarrassment can be used as tools to bring the IESG under control and restore the Information RFC publication process to the open process that it is supposed to be. Internet Standards are better than other standards because we realize that no entity (IETF/IESG/IAB) has exclusivity on good ideas. Many (if not most) good/successful Internet protocols have come from outside of committees, task forces, groups or boards. (If you are looking for examples, consider the web.) Fair and equitable access to the RFC publication service is fundamental to the success and growth of the Internet. Good protocols (as well as bad protocols) coming from outside of the IETF should have access to the RFC publication service, so that they can be used and even sometimes compete with IETF/IESG work. The network and the market place ultimately decides the winners and the loosers. Now, my experience with the publication of RFC-2188 has convinced me that: o the IESG frequently abuses its authority and in fact is allowed to delay the publication of RFCs indefinitely and even engage in censorship of material that it just does not like or that it does not understand. o both the IESG and the RFC-Editor operate with an authority oriented attitude as opposed to a responsibility oriented attitude. o in practice there are not adequate checks and balances in the process to guard against mistakes by the IESG or the RFC-Editor. If any of the above is true we have a problem. Unfortunately, this note clearly demonstrates that all of the above were true in the case of RFC-2188. I am also now convinced that the problems in the case of RFC-2188 were not isolated to that case alone. There is a serious problem. The rest of this note substantiates my claims
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Mohsen BANAN wrote: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) Mohsen Banan mohsen at neda.com November 5, 1998 I suppose I should make a note to this, since I was apps AD at the time: I think ESRO is a badly designed protocol that would have been harmful to the Internet if it had ever been deployed at scale. The IESG pointed some of the issues out to the RFC Editor, who handled the communication with the author; that was the procedure at that time. Nevertheless, the RFC Editor felt that the document was worthy of publication, and published anyway. The IESG note put on this document says: IESG Note This protocol has not had the benefit of IETF Working Group review, but a cursory examination reveals several issues which may be significant issues for scalability. A site considering deployment should conduct a careful analysis to ensure they understand the potential impacts. That's more or less consistent with the now-standard note put on all RFC Editor independent submissions, but at that time, it was an unusually strong statement. Of course, it was far milder than the one put on the EMSD spec, RFC 2524, published in February 1999: IESG Note The protocol specified in this document may be satisfactory for limited use in private wireless IP networks. However, it is unsuitable for general-purpose message transfer or for transfer of messages over the public Internet, because of limitations that include the following: - Lack of congestion control EMSD is layered on ESRO [RFC 2188], which does not provide congestion control. This makes EMSD completely unsuitable for end-to-end use across the public Internet. EMSD should be considered for use in a wireless network only if all EMSD email exchanged between the wireless network and the public Internet will transit an EMSD-SMTP gateway between the two regions. - Inadequate security The document specifies only clear-text passwords for authentication. EMSD should be used across a wireless network only if sufficiently strong encryption is in use to protect the clear-text password. - Lack of character set internationalization EMSD has no provision for representation of characters outside of the ASCII repertoire or for language tags. - Poorly defined gatewaying to and from Internet Mail Because Internet Mail and EMSD have somewhat different and conflicting service models and different data models, mapping between them may provide good service only in limited cases, and this may cause operational problems. The IESG therefore recommends that EMSD deployment be limited to narrow circumstances, i.e., only to communicate with devices that have inherent limitations on the length and format of a message (no more than a few hundred bytes of ASCII text), using either: a. wireless links with adequate link-layer encryption and gatewayed to the public Internet, or b. a private IP network that is either very over-provisioned or has some means of congestion control. In the near future, the IESG may charter a working group to define an Internet standards-track protocol for efficient transmission of electronic mail messages, which will be highly compatible with existing Internet mail protocols, and which wil be suitable for operation over the global Internet, including both wireless and wired links. In this case, too, the RFC Editor exercised the RFC Editor's independent judgment and published the document. The Internet seems to have survived the publication, but I can't see any tangible benefit to the Internet from their publication either. WRT formalities, Google found this reply to the posting of the note: http://www1.ietf.org/mail-archive/web/ietf/current/msg08332.html which seems to indicate that the IAB archives should show what happened afterwards; the mailing list also had a followup discussion that might be of interest. This was eight years ago. The IESG that the complaint was made against was: Alvestrand, Harald Applications Bradner, Scott Transport Burgan, JeffInternet Curran, JohnOperations Management Halpern, Joel Routing Moore, KeithApplications Narten, Thomas Internet O'Dell, Michael Operations Management Reynolds, Joyce User Services Romanow, Allyn Transport Schiller, Jeff Security What's the point of reposting this message now? Harald ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
This was eight years ago. The IESG that the complaint was made against was: Seems like there ought to be a statute of limitations. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
