Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
Mohsen BANAN <mohsen@neda.com> Fri, 06 November 1998 11:23 UTC
Received: (from adm@localhost) by ietf.org (8.8.5/8.8.7a) id GAA24746 for ietf-outbound.10@ietf.org; Fri, 6 Nov 1998 06:23:13 -0500 (EST)
Received: from rostam.neda.com ([198.62.92.1]) by ietf.org (8.8.5/8.8.7a) with ESMTP id GAA24676; Fri, 6 Nov 1998 06:15:02 -0500 (EST)
Received: (from mohsen@localhost) by rostam.neda.com (8.9.1/8.9.1) id DAA16817; Fri, 6 Nov 1998 03:04:45 -0800 (PST)
Date: Fri, 06 Nov 1998 03:04:45 -0800
Message-Id: <199811061104.DAA16817@rostam.neda.com>
MIME-Version: 1.0
From: Mohsen BANAN <mohsen@neda.com>
To: IETF Mailing List <ietf@ietf.org>
CC: iesg-secretary@ietf.org, iesg@ietf.org, RFC Editor <rfc-ed@isi.edu>, Internet Architecture Board <iab@isi.edu>, records@neda.com
Subject: Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO)
X-Mailer: VM 6.33 under 19.15p7 XEmacs Lucid
Content-Type: text/plain; charset="US-ASCII"
Complaints Against The IESG and The RFC-Editor About Publication of RFC-2188 (ESRO) Mohsen Banan mohsen@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@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 about the problem. Because this deals with a concrete and specific case, because it deals with history of what has already happened, because it is a complete case, I hope that this note can be used to identify and fix the serious problems that exist. Because this note is documentation of a complete case, it is somewhat lengthy. This note is organized in 4 sections. 1. A summary analysis of the publication process for non IETF Informational RFCs both in "theory" and in "practice". 2. Recommendations For Improvements. 3. Summary of ALL The Communications Records from the date of submission to the date of publication. In this section, I substantiate all of the above mentioned claims and problems. 4. A Message Digest for ALL email exchanges from the date of submission to the date of publication. Info RFC Publication In Theory and in Practice ============================================== In theory, "The Internet Standards Process" (BCP-9, RFC-2026) defines at a high level a very reasonable process for publication of non IETF protocols as Informational RFCs. The problem is that in practice that process is not followed. The IESG is allowed to indefinitely delay the publication of RFCs or simply reject them because the IESG does not get them or because the IESG does not like them. Info RFC Publication In Theory ------------------------------ The highlights of the process of publication of non IETF protocols as Informational RFCs (taken from sections 4.2.2 and 4.2.3 of RFC-2026) are: o Informational designation does not represent an Internet recommendation of any sort. o Publication of Informational RFCs is supposed to be "timely". o The RFC-Editor (and NOT the IESG) is responsible for determining suitability for publication based on: -- Relevance to Internet activity -- Meets the technical standard for RFCs -- Meets the editorial standard for RFCs o The RFC-Editor refers the document to the IESG for review which is to be in a timely manner. The scope of IESG's review of the document is to identify areas of overlap with on going or future IETF activities. -- The IESG can recommend that the document be brought in the IETF. -- The IESG can determine that the document conflicts with or is inimical to an established IETF effort. In that case the document may still be published as an Informational RFC with an IESG disclaimer. This process is very reasonable. Irrelevant or sub-standard specifications (such as Internet Porn Protocol - IPP) will be stoped by the RFC-Editor. Reasonable protocols get a chance to be published in a timely manner. The IESG is not allowed to censor anything in favor of its own activities or opinions. Practice -------- In practice the role of the RFC Editor for documents coming from outside of the IETF/IESG/IAB has been reduced to that of a glorified clerk of the IESG. In other words in practice the IESG has already expanded its limited role as a conflict detector to a commentator and the authorative reviewer and the final decision maker. In practice, the RFC Editor is not in charge the IESG is. Neither the IESG, nor the RFC Editor have any respect for the requirement of "timely" processing of the non IETF Informational RFCs. Un-Answered Questions --------------------- During the process of publication of RFC-2188 when it became obvious that the process being followed is not that of BCP-9. I started asking the following questions. These questions were asked a number of times from the RFC-Editor and the IESG. They have never responded to any of them. They remain unanswered. o What process is the RFC Editor following for the publication of Informational RFCs (since it clearly is not the process define in BCP-9)? o What do "reasonable period of time" and "timely" mean to the RFC Editor and the IESG? o What does the IESG think the scope and purpose of its review of the non IETF RFCs are? o What is the RFC Editor expected to do when the IESG does not review the document in a reasonable period of time? o Who do the RFC Editor and the IESG find themselves accountable to? o What should the Author of an RFC do when its repeated questions and concerns are simply ignored? In light of everything that happened in the case of RFC-2188, I consider all of these questions valid and legitimate. These questions have been asked many times to no avail. They remain unanswered. Recommendations For Improvements ================================ Because of the RFC-2188 experience and other interactions that I have had with the IESG and the RFC-Editor, I have some suggestions for improving the non IETF Informational RFC publication process and practice. o Recognize what IESG really is and what its role is supposed to be. Limit the IESG's role to what it is supposed to be. The IESG is a hand-full of volunteer engineers with a fancy group name. Based on my interactions with them, I have concluded that they hardly reach the "average" level of competence in my book -- both in their technical and in their management abilities. The IESG often has little relevant experience and knowledge in the specialized subject matter of the RFCs that it needs to review. Instead of functioning in its limited co-ordination and conflict detector role as defined in section 4.2.3, in practice the IESG has already expanded its own role and has assumed ultimate authority over publication/non-publication of non IETF originated Informational RFCs. The IESG should not be permitted to engage in censorship or delay of publication of work coming from outside of IETF because they just don't like it, because they don't understand it, because they think that it may be competing with IETF/IESG work or because they think that it may be bad for the Internet. Based on the case of RFC-2188, I have concluded that the IESG is out of control and irresponsible. It needs to be checked and managed. o Strengthen the RFC-Editor's Role. In practice the role of the RFC Editor for documents coming from outside of the IETF/IESG/IAB has been reduced to that of a glorified clerk of the IESG. If and when the IESG does not complete its review of the refered documents, it is the RESPONSIBILITY of the RFC Editor to go ahead and publish the document. The RFC Editor should not permit the IESG to introduce long delays in the publication of documents. The RFC Editor should ensure that the IESG note going into an Informational RFC is in fact reasonable and correct and provide the author an opportunity to see the IESG note prior to publication. The RFC Publication Service can benefit from additional resources. I am pretty sure that getting funding for such a critical service is not going to be difficult if we look at it the right way. o Ensure that the procedures of BCP-9 are followed in practice. The spirit of sections 4.2.2 and 4.2.3 of BCP-9 is just right. However, the case of RFC-2188 clearly shows that in practice the procedures of BCP-9 are not being followed. We need to find a way to make sure that what BCP-9 says is in fact what happens. o Introduce more accountability, structure and order to the RFC publication service. Tighten BCP-9 to be more clear about minimum technical requirements for RFCs. Introduce an appeals process for when a document is rejected. More clearly define "timely"... Provide mechanisms that safeguard against mistakes and negligence by the IESG or the RFC Editor. Define specifically, what is supposed to happen when the IESG does not complete its limited review in a timely manner. Re-orient everything towards responsibilities of the publication service providers instead of their authorities. o Separate The RFC Publication Service from the IETF/IESG/IAB. The RFC Editor task is primarily a Publication Service. The IETF/IESG/IAB is JUST one of the users/customers of the the RFC Publication Service. There has been talk of putting the RFC Publication Service under management and funding of IETF/IESG/IAB/ISOC. That would be totally wrong. There is an obvious inherent problem with allowing a common Publication Service to be managed and funded by one of its users. The problem is that IETF/IESG/IAB is likely to claim control over the entire RFC Publication Service and delay the publication or exclusion of protocols coming from outside of it and suppress standards competition even more. Clear separation of powers is a good thing. It is a good way of introducing accountability and checks and balances. A powerful and independent RFC Editor role which would oversee a fair and equitable RFC Publication service is ESSENTIAL for the Internet. In practice, the RFC Editor role has been weakened over the years. We need to strengthen it. Limiting IETF/IESG/IAB's role in the RFC Publication Process ------------------------------------------------------------ Let's look at what needs to happen in the bigger picture. Standardization process iterates through 4 essentially distinct steps. 1) Development of the Protocol. IETF/IESG are just one of the entities developing protocols. Many good protocols are developed by non-standards related entities. 2) Publication of the Protocol. A wide open, quick and fair publication service is needed to allow for anyone who wants to build or play with protocols to have access to its specification. The fundamental characteristics of the RFC Publication Service for the most part have been working real well. Any relevant protocol coming from essentially anywhere which meets a minimum technical and/or editorial standard should have speedy access to the RFC Publication Service. 3) Use of the Protocol. If it is anything useful and is done right, it will be used. How it gets used is very important and unpredictable. 4) Blessing of the Protocol. Some entity (e.g., IETF/IESG/IAB) blesses the protocol by putting some label on it. Although necessary, this function is mostly ceremonial. The real legitimacy comes from usage and the market place. Without a question, IETF/IESG/IAB should play some role in step (1). Without a question, IETF/IESG/IAB need to focus on step (4). But, I am saying that putting step (2) under management and funding of IETF/IESG/IAB/ISOC is WRONG. Because it has the potential of further suppressing the results of step (1) coming from outside of IETF/IESG. Note, that I don't have a problem with the spirit of the relationship between The RFC-Editor and IETF/IESG/IAB/ISOC as described in BCP-9. My point is that by making step (2) completely and truly independent of management and funding by IETF/IESG/IAB/ISOC, we will bring about the necessary checks and balances that are needed for a healthy overall process which needs to even encourage competition in step (1). Summary Of The Communication Records in Chronological Order =========================================================== All the communication between the Authors, the RFC Editor and the IESG were in the form of email exchanges. There were no phone calls or face-to-face conversations of any sort. The email exchanges are factually summarized below and reference to the actual email is included. Jan 11, 97 -- Authors To RFC-Editor: Mark Taylor (then of AT&T) submitted the ESRO protocol for publication as an Informational RFC. (Message-Id: <32D7FFCA@wddmssmtp.nwest.airdata.com>) Jan 15, 97 -- Mohsen BANAN To RFC-Editor: Shortly after that (on 1/15/97) I incorporated IANA's port assignment for the ESRO protocol and resubmitted it to the RFC-Editor. (Message-Id: <199701160714.XAA29795@jamshid.neda.com>) Jan 23, 97 -- RFC-Editor To Authors: On January 23rd, the RFC editor acknowledged receipt and placed it in the publication queue and forwarded it to the IESG/IETF for their review. (Message-Id: <199701231743.AA10376@zen.isi.edu>) Jan 29, 97 -- RFC-Editor To IETF-Announce: The ESRO protocol was put in the internet drafts directory on January 29th. (Message-Id: <9701300942.aa02647@ietf.org>) March 31, 97 -- Mohsen BANAN To RFC-Editor: On March 31st I checked on the current status of this RFC and expressed our desire to see it published soon. (Message-Id: <199704010128.RAA26066@jamshid.neda.com>) April 3, 97 -- RFC-Editor To Authors: On April 3th we were told that The IESG had requested that the ESRO document not be published at this time and that they would be in contact with us after their meeting that coming week in Memphis. (Message-Id: <199704032357.AA17887@zephyr.isi.edu>) April 3, 97 -- Mohsen BANAN To RFC-Editor: I immediately replied requesting an explanation of this delay and the name of the relevant IESG contact person. I again offered to discuss and respond to questions/comments regarding the ESRO protocol. (Message-Id: <199704040100.RAA07041@jamshid.neda.com> At that time our only contact point was the RFC Editor. The Editor neglected to reply to that message. Those questions remain unanswered even today. Had the RFC Editor responded to that message in April, we would have saved a lot of time. The above instance alone justifies my fair use of the word "negligently" with respect to the RFC Editor. July 28, 97 -- Mohsen BANAN To RFC-Editor: Having not heard from the RFC Editor since April 3rd (nearly 4 months), I prepared a detailed message which explained that the RFC Editor and IESG's treatment of this RFC is totally unreasonable. (Message-Id: <199707290658.XAA28413@jamshid.neda.com>) July 28, 97 -- RFC-Editor To Steve Coya: The RFC Editor (Mary Kennedy) forwarded my message to Steve Coya. (Message-Id: <199707291539.AA11953@zephyr.isi.edu>) August 4, 97 -- Mohsen BANAN To RFC-Editor and Steve Coya: At that time (6 months after initial submission and a week after my previous detailed request for explanation) Steve Coya and the IESG had still not responded to ANY of our messages and requests. Our repeated requests for an explanation kept being ignored. The IESG's actions up to that point combined with their dictatorial attitude and arrogance at that point, at a minimum, justifies my use of the words "negligent" and "irresponsible". (Message-Id: <199708041804.LAA07856@rostam.neda.com>) August 4, 97 -- Steve Coya to Authors: After more than 6 months, this is the first time that anyone at the IESG has communicated with us. In that message, Steve Coya tells us that the IESG requested that the document not be published. This is a clear violation of the procedures of BCP-9. No where in RFC 2026 is the IESG given the authority to stop the publication of a non IETF Informational RFC. Now, add to that the level of arrogance that says IESG can ignore the Authors' inquiries for 6 months and provide no explanation what-so-ever to why IESG has prevented the publication of the RFC. Then add to it, that later it becomes clear that Steve Coya was just wrong. (Message-ID: <Pine.WNT.3.96.970804141858.-301315F-100000@dell06.cnri.reston.va.us>) August 4, 97 -- Scott Bradner to Authors: Scott Bradner tells us that it appears that it might be worth while to issue an IETF last call on it and advance it as a proposed standard! Obviously that was contradictory to what Steve Coya had said earlier that same day. (Message-Id: <199708041935.PAA05510@newdev.harvard.edu>) August 4, 97 -- Mohsen BANAN To Scott Bradner: I re-iterate the sense of urgency here. August 6, 97 -- Mohsen BANAN To Scott Bradner: I check on status of progress and mention that a lot has gone wrong so far and that is why we are impatient. August 6, 97 -- Scott Bradner to Authors: Scott Bradner tells me that no abuse should be directed towards the RFC Editor. (Message-Id: <199708061908.PAA09003@newdev.harvard.edu>) August 7, 97 -- Mohsen BANAN To Scott Bradner: I explain that my use of the words "irresponsibly and negligently" do not constitute abuse towards the RFC Editor. And I justify them again. (Message-Id: <199708071844.LAA12806@rostam.neda.com>) August 7, 97 -- Scott Bradner to Mohsen BANAN: Scott Bradner in a message only to me suggests that if I can't see that the tone of my messages are abusive, I should talk to a friend. (Message-Id: <199708071924.PAA10978@newdev.harvard.edu>) I do not consider this a personal or private message. On a personal level, I wish to have no relationship what-so-ever with anyone on the IESG. I simply want them to fulfill their particular responsibilities with respect to facilitation of publication of my Informational RFCs. The key point not to be missed here is that if the IESG has been doing its job, we would not be discussing the tone of my messages. I did not dignify that message with a response. August 7, 97 -- Scott Bradner to Authors: Scott Bradner tell us that ex-transport co-AD feels that this ID represents a significant technical contribution and feels that it should be advanced on the IETF standards track. (Message-Id: <199708071943.PAA11036@newdev.harvard.edu>) Scott Bradner asks us to choose between the Informational RFC publication route or the Proposed Standard route. August 8, 97 -- Mohsen BANAN To Scott Bradner: The Authors choose the Informational RFC route because the urgency for publication in this case outweighs our interest in getting this document on the standards track. (Message-Id: <199708081853.LAA14067@rostam.neda.com>) August 8, 97 -- Scott Bradner to Authors: Scott Bradner asks: What is causing this feeling of urgency? (Message-Id: <199708082046.QAA01197@newdev.harvard.edu>) August 8, 97 -- Mohsen BANAN To Scott Bradner: I explain. (Message-Id: <199708082219.PAA14258@rostam.neda.com>) August 17, 97 -- Scott Bradner to Authors: Scott Bradner informs us of his recommendation of ESRO for publication and that he hopes we will put this specification on standards track when it is ready. (Message-Id: <199708180051.UAA08685@newdev.harvard.edu>) August 17, 97 -- Mohsen BANAN To Scott Bradner: I thanked him and said that I will. (Message-Id: <199708180434.VAA26606@rostam.neda.com>) August 18, 97 -- Scott Bradner to Authors: Scott Bradner forwards a technical comment from Harald Alvestrand to the Authors. This is the *ONLY* technical comment that we ever received from the IESG or the RFC Editor. (Message-Id: <199708181217.IAA09055@newdev.harvard.edu>) August 18, 97 -- Mohsen BANAN To Scott Bradner: I respond to that technical comment. (Message-Id: <199708181850.LAA27366@rostam.neda.com>) August 28, 97 -- Mohsen BANAN To Scott Bradner: I explicitly ask that he keeps me posted on his communications with the RFC Editor related to this RFC. (Message-Id: <199708282146.OAA11605@rostam.neda.com>) If there was to be an IESG Note, I wanted to have a chance and see it before publication. August 28, 97 -- Scott Bradner to Authors: Scott Bradner informs us that he publication was approved by the IESG. But does not mention anything about the IESG note. (Message-Id: <199708282229.SAA23730@newdev.harvard.edu>) September 9, 97 -- Mohsen BANAN To Scott Bradner: I ask about the expected publication date. September 9, 97 -- RFC Editor to IETF-Announce: The RFC Editor announces publication of RFC-2188. The text of RFC-2188 is materially same as what we submitted to the RFC Editor on Jan 15, 1997, with the exception of the IESG note. To our surprise we discovered the following IESG note in our RFC. --- 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. --- A few key points about this IESG Note: o The Authors were never given a chance to know about any of the issues that the note implies, even-though I had explicitly asked to be informed of communications related to this RFC. o After delaying the publication for 8 months, why is the IESG Note based on "a cursory examination". o If that IESG Note is true, then why were the Authors not given a chance to know about them and fix them? o If that IESG Note is true, then why did the Area Director want to put it on the Standards Track and issue a Last Call for it? o The IESG note is so vague that up until recently I thought that it was about the wrong perception of limitations of Service Access Points -- which was the ONLY technical issue that was ever discussed with the Authors. How can the IESG expect that such an unsubstantiated vague comment be of use to anyone? The best I can gather, this appears to have just been a "power trip" by an out of control IESG. o I am not saying that RFC-2188 is perfect and that no IESG note should have ever been put in it. I am saying that the IESG note that was put in there was done the wrong way and is of little use, if any. If any of my employees were to ever be responsible for a small fraction of the types of arrogance, negligence and mistakes that were commited during the process of publication of RFC-2188, I would fire or demote them immediately. But, the IESG is a collection of volunteers which answers to no one. Unless we can find a way to deal with problems like this and fix them, I am afraid that arrogance, negligence, irresponsibility and incompetence will be institutionalized inside of the IESG. Complete Message Digest ======================= ALL of the messages related to this case that I originated or received starting from the time of initial submission up until the time of publication of the RFC are included as 30 email messages below. Other than deleting the attachments of the original specification and deleting duplicate message digests, these messages have not been edited in any way. My interactions with individulas at the IESG and the RFC Editor were in the context of them functioning in their roles as Service Providers. I consider none of these email messages private, personal or confidential. ------- start of digest (30 messages) (RFC 934 encapsulation) ------- From: Mark Taylor <mtaylor@airdata.com> To: rfc editor <rfc-editor@isi.edu> Cc: JiaBing Cheng <jcheng@airdata.com>, "Jim Grams (Corporate)" <jim.grams@mccaw.com>, mst <mark.taylor@airdata.com>, "'Mohsen Banan (Neda)'" <mohsen@rostam.neda.com>, "'Murat Divringi (Neda)'" <muratd@rostam.neda.com> Subject: Informational RFC Submission Request -- ESRO Protocol Date: Sat, 11 Jan 97 13:00:00 PST Message-Id: <32D7FFCA@wddmssmtp.nwest.airdata.com> Please accept this informational RFC for Efficient Short Remote Operations (ESRO), a protocol we have developed over the past two years. In this context, "we" refers to AT&T Wireless Services, Inc., and Neda Communications, Inc. (under contract to AT&T). I am the Director of Strategic Engineering in the Wireless Data Division of AT&T Wireless Services. The purpose of the ESRO protocol is to better support applications such as Email over low-bandwidth media, such as Cellular Digital Packet Data or other wireless services. The editor for this informational RFC is Mohsen Banan, of Neda Communications (who can be reached at mohsen@neda.com). We have requested a port number assignment from IANA for this protocol on January 9, 1997; the RFC editor was sent a copy of this request. Following the assignment of a port number, section 4.6.3 will require a corresponding modification. Mr. Banan can provide a LaTeX-revisable version of this RFC. Please direct all future correspondence regarding this RFC to Mr. Banan at mohsen@neda.com with a courtesy copy to Mr. Jia-bing Cheng of AT&T at jcheng@airdata.com. Thank-you in advance for your assistance in the publication of this RFC. Regards, Mark Taylor Director of Strategic Engineering AT&T Wireless Services 10230 NE Points Dr. Kirkland, WA 98033 mark.taylor@airdata.com ------The RFC is a text file attached below ------- [[ ESROS.TXT : 3408 in ESROS.TXT ]] ------------------------------ From: Mohsen Banan <mohsen@rostam.neda.com> To: rfc-editor@isi.edu Cc: JiaBing Cheng <jcheng@airdata.com>, jim.grams@airdata.com, "Mark S. Taylor" <mark.taylor@airdata.com>, Murat Divringi-neda <muratd@rostam.neda.com>, Mohsen Banan-neda <mohsen@rostam.neda.com> Subject: Update: Informational RFC Submission Request -- ESRO Protocol Date: Wed, 15 Jan 1997 23:14:42 -0800 (PST) Message-Id: <199701160714.XAA29795@jamshid.neda.com> Following through with Mark Taylor's email of January 11, 97, I have incorporated IANA's port assignment for the ESRO protocol in section 4.6.3. I have also made other minor editorial changes to other sections. The attached updated Informational RFC is now ready for your review and publication. If you want to also have the LaTeX revisable form of this RFC, please drop me -- Mohsen Banan <mohsen@neda.com> -- a note. Let me know if you have any questions or if you want us to modify the document in any specific way. Thank you in advance. ...Mohsen. ------------------------------ From: rfc-ed@ISI.EDU To: mohsen@rostam.neda.com Cc: jcheng@airdata.com, jim.grams@airdata.com, mark.taylor@airdata.com, muratd@rostam.neda.com, rfc-editor@ISI.EDU Subject: Re: Update: Informational RFC Submission Request -- ESRO Protocol Date: Thu, 23 Jan 1997 09:43:49 -0800 Message-Id: <199701231743.AA10376@zen.isi.edu> Mohsen- We have received your RFC-to-be and have placed it in the publication queue. We have forwarded it to the IETF for their review. Sincerely, Mary Kennedy - USC/ISI Request for Comments Documents ------------------------------ From: Mohsen Banan <mohsen@rostam.neda.com> To: rfc-ed@ISI.EDU Cc: mohsen@rostam.neda.com, jcheng@airdata.com, Jia-Bing Cheng <JBCheng@attws-hq1.nwest.attws.com>, rfc-editor@ISI.EDU Subject: Status of publication of ESRO Protocol as an Informational RFC Date: Mon, 31 Mar 1997 17:28:47 -0800 (PST) Message-Id: <199704010128.RAA26066@jamshid.neda.com> >>>>> On Thu, 23 Jan 1997 09:43:49 -0800, rfc-ed@ISI.EDU said: rfc-ed> Mohsen- rfc-ed> We have received your RFC-to-be and have placed it in the publication rfc-ed> queue. We have forwarded it to the IETF for their review. rfc-ed> Sincerely, rfc-ed> Mary Kennedy - USC/ISI rfc-ed> Request for Comments Documents Can you please let us know what the status of publication of ESRO Protocol as an Informational RFC is? When do you expect to publish it as an RFC? The initial Submission of this RFC was January 11, 1997. It was made available in the on-line Internet-Drafts directories on Jan 29, 97. Title : AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2 Author(s) : M. Banan, M. Taylor, J. Cheng Filename : draft-rfced-info-banan-esro-00.txt Pages : 47 Date : 01/29/1997 We have received no feed-back on it since (neither from IETF, nor from the RFC Editor, nor from anybody else). My understanding of the publication process based on BCP-9/RFC-2029 "The Internet Standards Process -- Revision 3" Section 4.2.3 is that: "... The RFC Editor will wait two weeks after this publication [in the I-D directory] for comments before proceeding further. ...." draft-rfced-info-banan-esro-00.txt has been in the I-D directory for more then 2 months now. The Informational designation is intended to provide for timely publication. That is one of the reasons why we submitted ESRO with Informational designation. We would like to refer to ESRO Protocol as an RFC in the near future. Please let us know how we can help expedite the publication of ESRO as an Information RFC. Thank you in advance. Regards, - -- Mohsen Banan Neda Communications, Inc. tel: +1-206-644-8026 17005 S.E. 31st Place fax: +1-206-562-9591 Bellevue, Wa 98008 E-Mail: mohsen@neda.com U.S.A. URL: http://www.neda.com/ ------------------------------ From: rfc-ed@ISI.EDU (RFC Editor) To: mohsen@rostam.neda.com Cc: rfc-ed@ISI.EDU Subject: Re: Status of publication of ESRO Protocol as an Informational RFC Date: Thu, 3 Apr 1997 15:57:01 -0800 Message-Id: <199704032357.AA17887@zephyr.isi.edu> Moshen-- The IESG requested that your document not be published at this time. They will be in contact with you after their meeting this coming week in Memphis. Sincerely, Mary Kennedy - USC/ISI Request for Comments Documents ------------------------------ From: Mohsen Banan <mohsen@rostam.neda.com> To: rfc-ed@ISI.EDU (RFC Editor) Cc: mohsen@rostam.neda.com, Jia-Bing Cheng <JBCheng@attws-hq1.nwest.attws.com>, jim.grams@attws.com, Pean Lim-Neda <pean@rostam.neda.com> Subject: Re: Status of publication of ESRO Protocol as an Informational RFC Date: Thu, 3 Apr 1997 17:00:30 -0800 (PST) Message-Id: <199704040100.RAA07041@jamshid.neda.com> >>>>> On Thu, 3 Apr 1997 15:57:01 -0800, rfc-ed@ISI.EDU (RFC Editor) said: RFC-Editor> Moshen-- RFC-Editor> The IESG requested that your document not be published at this time. RFC-Editor> They will be in contact with you after their meeting this coming week RFC-Editor> in Memphis. RFC-Editor> Sincerely, RFC-Editor> Mary Kennedy - USC/ISI RFC-Editor> Request for Comments Documents Can you please let us know generally what the reason for the delay is? That document has been in the draft directory for more than 60 days and we have heard no comments about it. Can you tell us who the IESG contact person is for this Informational RFC? Non of the ESRO authors were planning to participate in the Memphis IETF. But, may be we can participate in the IESG meeting and address relevant questions and issues over the phone. Of course, I'll be happy to respond to questions/comments through email as well. Based on my understanding of the process of Informational RFC publication (RFC-2026 Sections 4.2.2 & 4.2.3), IESG's review relates to conflicts of the domain of the document with work that is being done or is expected to be done, within the IETF community. Is there a conflict? Sincerely, - -- Mohsen Banan Neda Communications, Inc. tel: +1-206-644-8026 17005 S.E. 31st Place fax: +1-206-562-9591 Bellevue, Wa 98008 E-Mail: mohsen@neda.com U.S.A. URL: http://www.neda.com/ ------------------------------ From: Mohsen Banan <mohsen@neda.com> To: rfc-editor@isi.edu, rfc-ed@isi.edu, Jon Postel <postel@isi.edu> CC: "Mark S. Taylor" <mtaylor@teledesic.com>, Jia-Bing Cheng <JBCheng@attws-hq1.nwest.attws.com>, Pean Lim-Neda <pean@neda.com>, Mohsen Banan-neda <mohsen@neda.com> Subject: Unexpected and Unreasonable delays in processing of Informational RFC (ESRO Protocol) Date: Mon, 28 Jul 1997 23:58:46 -0700 (PDT) Message-Id: <199707290658.XAA28413@jamshid.neda.com> More than 6 month ago we submitted the ESRO protcol for publication as an Informational RFC. It has not been published yet. Our requests to find out what the reason for the delays are, remain unanswered. This is unreasonable! We expect to see the ESRO protocol published as an Informational RFC as soon as possible. More than 6 months ago (on 1/11/97) Mark Taylor (then of AT&T) submitted the ESRO protocol for publication as an Informational RFC. (Message-Id: <32D7FFCA@wddmssmtp.nwest.airdata.com>) Shortly after that (on 1/15/97) I incorporated IANA's port assignment for the ESRO protocol and resubmitted it to the RFC-Editor. (Message-Id: <199701160714.XAA29795@jamshid.neda.com>) On January 23rd, the RFC editor acknowledged receipt and placed it in the publication queue and forwarded it to the IETF for their review. (Message-Id: <199701231743.AA10376@zen.isi.edu>) The ESRO protocol was put in the internet drafts directory on January 29th. (Message-Id: <9701300942.aa02647@ietf.org>) On March 31st I checked on the current status of this RFC and expressed our desire to see it published soon. (<199704010128.RAA26066@jamshid.neda.com>) On April 3th we were told that The IESG had requested that the ESRO document not be published at this time and that they would be in contact with us after their meeting that coming week in Memphis. (Message-Id: <199704032357.AA17887@zephyr.isi.edu>) I immediately replied requesting an explanation of this delay and the name of the relevant IESG contact person. I again offered to discuss and respond to questions/comments regarding the ESRO protocol. (Message-Id: <199704040100.RAA07041@jamshid.neda.com>) The above mentioned 7 messages are attached to the end of this message. Since April 3rd, we have not heard back from the RFC-Editor or the IESG regarding this Informational RFC. The Informational designation is intended to provide for timely publication. That is one of the reasons why we submitted ESRO with Informational designation. Considering that there has been adequate time (nearly 6 months) for the RFC Editor, the IESG, the IETF and the technical Internet community at large to review and comment on this document and that there has been no comments, again I request that the document be promptly published as an Informational RFC. It is my understanding that it is the responsibility of the RFC Editor to over see publication of Informational RFC according to the process described in BCP-9/RFC-2026 in a timely manner. It is unreasonable and unprofessional for IESG (or anybody else) to delay publication of an Informational RFC without providing any reason or explanation. I don't understand the reason for the RFC Editor and the IESG's failure of following the process defined for publication of Informational RFCs in the case of this document. We have done a significant amount of work on the specification and implementation of this useful protocol. We want to make it easy for others who wish to implement this protocol to access this document. Publication of this document as an Informational RFC accomplishes that. To the best of our knowledge there is nothing in the document that proposes something that conflicts with, or is actually inimical to, an established IETF effort. In short, this document has been in the queue for publication long enough. There has been ample time for through reviews. Since there has been no comments, I insist that RFC Editor publish it as an Informational RFC without any further delay. Regards, - -- Mohsen Banan Neda Communications, Inc. tel: +1-206-644-8026 17005 S.E. 31st Place fax: +1-206-562-9591 Bellevue, Wa 98008 E-Mail: mohsen@neda.com U.S.A. URL: http://www.neda.com/ - ------- start of digest (7 messages) (RFC 934 encapsulation) ------- .... - ------- end ------- ------------------------------ From: rfc-ed@ISI.EDU (RFC Editor) To: scoya@ietf.org Cc: mtaylor@teledesic.com, JBCheng@attws-hq1.nwest.attws.com, pean@neda.com, mohsen@neda.com, rfc-ed@ISI.EDU, postel@ISI.EDU Subject: Re: Unexpected and Unreasonable delays in processing of Informational RFC (ESRO Protocol) Date: Tue, 29 Jul 1997 08:39:59 -0700 Message-Id: <199707291539.AA11953@zephyr.isi.edu> Steve: Can you please look into this situation? Thanks, Mary Kennedy Request for Comments Documents - ------------------------------------- > From mohsen@jamshid.neda.com Tue Jul 29 00:02:17 1997 > Date: Mon, 28 Jul 1997 23:58:46 -0700 (PDT) > Mime-Version: 1.0 > From: Mohsen Banan <mohsen@neda.com> > To: rfc-editor@ISI.EDU, rfc-ed@ISI.EDU, Jon Postel <postel@ISI.EDU> > Cc: "Mark S. Taylor" <mtaylor@teledesic.com>, > Jia-Bing Cheng <JBCheng@attws-hq1.nwest.attws.com>, > Pean Lim-Neda <pean@neda.com>, Mohsen Banan-neda <mohsen@neda.com> > Subject: Unexpected and Unreasonable delays in processing of Informational RFC (ESRO Protocol) > X-Mailer: VM 6.22 under 19.15 XEmacs Lucid > Content-Type> : > text/plain> ; > charset=US-ASCII> > Content-Length: 18230 > > > > More than 6 month ago we submitted the ESRO protcol for publication as > an Informational RFC. It has not been published yet. Our requests to > find out what the reason for the delays are, remain unanswered. > > This is unreasonable! > > We expect to see the ESRO protocol published as an Informational RFC as > soon as possible. > > > > More than 6 months ago (on 1/11/97) Mark Taylor (then of AT&T) > submitted the ESRO protocol for publication as an Informational RFC. > (Message-Id: <32D7FFCA@wddmssmtp.nwest.airdata.com>) > > Shortly after that (on 1/15/97) I incorporated IANA's port assignment > for the ESRO protocol and resubmitted it to the RFC-Editor. > (Message-Id: <199701160714.XAA29795@jamshid.neda.com>) > > On January 23rd, the RFC editor acknowledged receipt and placed > it in the publication queue and forwarded it to the IETF for their review. > (Message-Id: <199701231743.AA10376@zen.isi.edu>) > > The ESRO protocol was put in the internet drafts directory on January > 29th. (Message-Id: <9701300942.aa02647@ietf.org>) > > On March 31st I checked on the current status of this RFC and > expressed our desire to see it published > soon. (<199704010128.RAA26066@jamshid.neda.com>) > > On April 3th we were told that The IESG had requested that the ESRO > document not be published at this time and that they would be in > contact with us after their meeting that coming week in Memphis. > (Message-Id: <199704032357.AA17887@zephyr.isi.edu>) > > I immediately replied requesting an explanation of this delay and the > name of the relevant IESG contact person. I again offered to discuss > and respond to questions/comments regarding the ESRO protocol. > (Message-Id: <199704040100.RAA07041@jamshid.neda.com>) > > The above mentioned 7 messages are attached to the end of this > message. > > Since April 3rd, we have not heard back from the RFC-Editor or the > IESG regarding this Informational RFC. > > The Informational designation is intended to provide for timely > publication. That is one of the reasons why we submitted ESRO with > Informational designation. > > Considering that there has been adequate time (nearly 6 months) for > the RFC Editor, the IESG, the IETF and the technical Internet > community at large to review and comment on this document and that > there has been no comments, again I request that the document be > promptly published as an Informational RFC. > > It is my understanding that it is the responsibility of the RFC Editor > to over see publication of Informational RFC according to the process > described in BCP-9/RFC-2026 in a timely manner. It is unreasonable and > unprofessional for IESG (or anybody else) to delay publication of an > Informational RFC without providing any reason or explanation. I don't > understand the reason for the RFC Editor and the IESG's failure of > following the process defined for publication of Informational RFCs in > the case of this document. > > We have done a significant amount of work on the specification and > implementation of this useful protocol. We want to make it easy for > others who wish to implement this protocol to access this document. > Publication of this document as an Informational RFC accomplishes > that. > > To the best of our knowledge there is nothing in the document that > proposes something that conflicts with, or is actually inimical to, an > established IETF effort. > > > In short, this document has been in the queue for publication long > enough. There has been ample time for through reviews. Since there has > been no comments, I insist that RFC Editor publish it as an > Informational RFC without any further delay. > > Regards, > > -- > Mohsen Banan > Neda Communications, Inc. tel: +1-206-644-8026 > 17005 S.E. 31st Place fax: +1-206-562-9591 > Bellevue, Wa 98008 E-Mail: mohsen@neda.com > U.S.A. URL: http://www.neda.com/ > > > ------- start of digest (7 messages) (RFC 934 encapsulation) ------- > .... > ------- end ------- > > ------------------------------ From: Mohsen Banan <mohsen@neda.com> To: rfc-ed@ISI.EDU (RFC Editor) Cc: scoya@ietf.org, mtaylor@teledesic.com, JBCheng@attws-hq1.nwest.attws.com, pean@neda.com, postel@ISI.EDU, Mohsen Banan-neda <mohsen@neda.com> Subject: Re: Unexpected and Unreasonable delays in processing of Informational RFC (ESRO Protocol) Date: Mon, 4 Aug 1997 11:04:00 -0700 (PDT) Message-Id: <199708041804.LAA07856@rostam.neda.com> >>>>> On Tue, 29 Jul 1997 08:39:59 -0700, rfc-ed@ISI.EDU (RFC Editor) said: RFC-Editor> Steve: RFC-Editor> Can you please look into this situation? RFC-Editor> Thanks, RFC-Editor> Mary Kennedy RFC-Editor> Request for Comments Documents RFC-Editor> ------------------------------------- Something is terribly wrong here. This is the 4th time that we are requesting to find out the reason(s) for the delay in publication of ESRO protocol (submitted more than 6 months ago) as an Informational RFC. The RFC Editor/IESG has been delaying the publication of this RFC-to-be without providing any reason or explanation. Our repeated requests for an explanation keep being ignored. Such seeming dictatorial attitude and arrogance has no place in the open RFC publication process. It is the responsibility of the RFC Editor to facilitate wide distribution of relevant technical information. Delaying publication of an Informational (the simplest and fastest category) RFC for more than half a year without any reason is not serving the Internet technical community. The RFC publication process does not belong to a select few. The Informational classification in specific is intended to facilitate distribution of technical work coming from outside of the IETF/IESG context. Last week Mary Kennedy forwarded my message to Steve Coya (to which we have not received a reply) referring to it as "this situation". Well, this situation has two dimensions. 1) Publication of ESRO document. 2) RFC Editor's failure to follow the publication process. I care greatly about both. On the first point, there should be no further delays in publication of the ESRO document. Considering that the ESRO protocol was forwarded to IETF on January 23rd, and that there been ample opportunity for its review in the Memphis meeting and afterwards, any further delay (e.g., waiting for the Munich IETF) is unreasonable. Our goal in submission of this document for publication as an Informational RFC was to use a rapid and widely accessible publication mechanism, not for IETF/IESG rubber-stamping. On the second point, Section 4.2.3 of RFC-2026 (BCP-9) refers to a two weeks wait period and IESG's review within a reasonable period of time. Is 6 months considered reasonable period of time? We are in the process of doing significant additional work for wireless Internet users based on the ESRO protocol. We hope to make all of that work openly available as well. However, the unexplained delay that we have experienced in the case of this document have been quite discouraging. We have been counting on the adherence to the RFC publication process which appears to have failed in the case of this document. This is having a significant adverse impact on our progress. If the RFC Editor does not intend to publish our document in the next few days, I wish to escalate this matter. Please let us know (i) if there is an escalation process for this situation and, if so, (ii) what it is. In any case, I expect a prompt response from the RFC-Editor to the following questions. - - What process is the RFC Editor following for the publication of Informational RFCs? - - What do "reasonable period of time" and "timely" mean to the RFC Editor and the IESG. - - What is the RFC Editor expected to do when the IESG does not review the document in a reasonable period of time? - - Who do the RFC Editor and the IESG find themselves accountable to? Regards, - -- Mohsen Banan Neda Communications, Inc. tel: +1-425-644-8026 17005 S.E. 31st Place fax: +1-425-562-9591 Bellevue, Wa 98008 E-Mail: mohsen@neda.com U.S.A. URL: http://www.neda.com/ ------------------------------ From: Steve Coya <scoya@ietf.org> To: Mohsen Banan <mohsen@neda.com> cc: rfc-ed@isi.edu Subject: Re: Unexpected and Unreasonable delays in processing of Informational RFC (ESRO Protocol) Date: Mon, 4 Aug 1997 14:25:34 -0400 (Eastern Daylight Time) Message-ID: <Pine.WNT.3.96.970804141858.-301315F-100000@dell06.cnri.reston.va.us> Mohsen, I apologize for the situation that no one from the IESG has conacted you. I can apprecaite your frustration, but you are aiming at the wrong folks. The RFC Editors are NOT delaying publication of your submission. The IESG requested that the document not be published, and some one was supposed to contact you. You DO have a valid complaint, but not with the RFC Editors. I will forward your message on to the apporpriate individuals, requesting that they contact you immediately. Steve ------------------------------ From: Scott Bradner <sob@harvard.edu> To: mohsen@neda.com Cc: allyn@eng.sun.com, iesg-secretary@ietf.org, JBCheng@attws-hq1.nwest.attws.com, mtaylor@teledesic.com, pean@neda.com Subject: Re: Unexpected and Unreasonable delays in processing of Informational Date: Mon, 4 Aug 1997 15:35:34 -0400 (EDT) Message-Id: <199708041935.PAA05510@newdev.harvard.edu> Mohsen, This document seems to have slipped through the cracks when we (the IESG) changed transport ADs. I'm trying to find out what the old transport co-AD had in mind when she asked to put the doc on hold - from the notes it looks like she felt that it might be worth while to issue an IETF last call on it and advance it as a proposed standard (if you are interested in doing that) I will get back to you as soon as I know more and I'm sorry for the delay. Scott ------------------------------ From: Mohsen Banan <mohsen@neda.com> To: Scott Bradner <sob@harvard.edu> Cc: allyn@eng.sun.com, iesg-secretary@ietf.org, JBCheng@attws-hq1.nwest.attws.com, mtaylor@teledesic.com, pean@neda.com Subject: Re: Unexpected and Unreasonable delays in processing of Informational Date: Mon, 4 Aug 97 15:16:16 PDT >>>>> On Mon, 4 Aug 1997 15:35:34 -0400 (EDT), Scott Bradner <sob@harvard.edu> said: Scott> Mohsen, Scott> This document seems to have slipped through the cracks when Scott> we (the IESG) changed transport ADs. I'm trying to find out what the Scott> old transport co-AD had in mind when she asked to put the doc on Scott> hold - from the notes it looks like she felt that it might be worth while Scott> to issue an IETF last call on it and advance it as a proposed standard Scott> (if you are interested in doing that) Our main concern is that it be published promptly. Scott> I will get back to you as soon as I know more and I'm sorry Scott> for the delay. Thank you -- after having waited for publication of this document for more than 6 months, I am sure you understand our sense of urgency. ...Mohsen. ------------------------------ From: Mohsen Banan <mohsen@neda.com> To: Scott Bradner <sob@harvard.edu> Cc: allyn@eng.sun.com, iesg-secretary@ietf.org, JBCheng@attws-hq1.nwest.attws.com, mtaylor@teledesic.com, pean@neda.com, RFC Editor <rfc-ed@isi.edu> Subject: Re: Unexpected and Unreasonable delays in processing of Informational Date: Wed, 6 Aug 97 11:33:26 PDT >>>>> On Mon, 4 Aug 1997 15:35:34 -0400 (EDT), Scott Bradner <sob@harvard.edu> said: Scott> Mohsen, Scott> This document seems to have slipped through the cracks when Scott> we (the IESG) changed transport ADs. I'm trying to find out what the Scott> old transport co-AD had in mind when she asked to put the doc on Scott> hold - from the notes it looks like she felt that it might be worth while Scott> to issue an IETF last call on it and advance it as a proposed standard Scott> (if you are interested in doing that) Scott> I will get back to you as soon as I know more and I'm sorry Scott> for the delay. Scott, How soon do you think that is going to be? Have you found out why the ESRO document is not being published? Please let me know one way or the other right away. Because of the pattern of having been told to wait and then being ignored for weeks and months, it is tough for me to accept any further unexplained delays. I believe that you have already seen my email explaining how irresponsibly and negligently the IESG and the RFC Editor have treated the publication of this document. I can email you a copy if you have not seen that. Regards, ...Mohsen ------------------------------ From: Scott Bradner <sob@harvard.edu> To: mohsen@neda.com Cc: allyn@eng.sun.com, iesg-secretary@ietf.org, JBCheng@attws-hq1.nwest.attws.com, mtaylor@teledesic.com, pean@neda.com, rfc-ed@isi.edu Subject: Re: Unexpected and Unreasonable delays in processing of Informational Date: Wed, 6 Aug 1997 15:08:21 -0400 (EDT) Message-Id: <199708061908.PAA09003@newdev.harvard.edu> Mohsen, As I told you - it seems like the old Transport AD had something in mind about this document - I have sent here a message but have not yet heard from her - I will be seeing here in Munich at the IETF meeting if she does not reply before then. I will then find out what she had in mind. As soon as I do I will let you know. > Because of the pattern of having been told to wait and then being > ignored for weeks and months, it is tough for me to accept any further > unexplained delays. sorry - I thought I was clear in my note to you > I believe that you have already seen my email explaining how > irresponsibly and negligently the IESG and the RFC Editor have treated > the publication of this document. I can email you a copy if you have > not seen that. the RFC editor was following the direction of the IESG as rfc 2026 tells it to do - so no abuse should be directed to them. As I said things slipped through the cracks and I am sorry that happened. Scott ------------------------------ Resent-Date: Thu, 7 Aug 1997 13:21:15 -0700 (PDT) Resent-Message-Id: <199708072021.NAA12905@rostam.neda.com> Resent-From: Pean Lim <pean@neda.com> Resent-To: mohsen@neda.com From: Mohsen Banan <mohsen@neda.com> To: Scott Bradner <sob@harvard.edu> Cc: allyn@eng.sun.com, iesg-secretary@ietf.org, JBCheng@attws-hq1.nwest.attws.com, mtaylor@teledesic.com, pean@neda.com, rfc-ed@isi.edu, Jon Postel <postel@isi.edu> Subject: Now: Improving the Informational RFCs Publication Process both in Theory and in Practice -- Was: Re:Unexpected and Unreasonable delays in processing of Informational Date: Thu, 7 Aug 1997 11:44:16 -0700 (PDT) Message-Id: <199708071844.LAA12806@rostam.neda.com> >>>>> On Wed, 6 Aug 1997 15:08:21 -0400 (EDT), Scott Bradner <sob@harvard.edu> said: >>> I believe that you have already seen my email explaining how >>> irresponsibly and negligently the IESG and the RFC Editor have treated >>> the publication of this document. I can email you a copy if you have >>> not seen that. Scott> the RFC editor was following the direction of the IESG as rfc 2026 Scott> tells it to do - so no abuse should be directed to them. I intended no abuse towards the RFC Editor. No abuse was directed to them. What "abuse" are you talking about? I hold a high degree of admiration and respect for those who have put in place and practice the open and fair RFC publication process. In general based on what I have seen and know, the RFC Editors are doing a great job of publishing information for the Internet technical community. Our thanks and keep up the good work. Kudos! However, in the specific case of our document, a lot has gone wrong and based on my reading of RFC 2026 part of the responsibility for what has gone wrong is the RFC Editor's. Later in this message, I will explicitly say what "irresponsibly and negligently" referred to. Scott> As I said things slipped through the cracks and Scott> I am sorry that happened. Apology accepted, of course. Let's turn all of this into something positive by focusing on the following explicit objectives. 1- Making sure our document gets published without any further delay. 2- Finding out what exactly went wrong in the case of this document. 3- Finding out how we can improve the process and procedures so a problem like this will not happen again. On the first point, I am glad that Scott has accepted the responsibility for overseeing the publication of ESRO without any further delay and that we are now back on track. I have made clear our sense of urgency in seeing this document published as an RFC. Scott, if you don't agree with any of the above paragraph, please let me know right away. On the second point, I think there is a lot more to this than "things slipped through the cracks". As a user of the RFC publication service I can provide you some feed-back which I had hoped you would find useful. On Jan 15, after we submitted our request for publication to the RFC Editor I expected that the RFC Editor will take on the responsibility of overseeing its progress towards publication in a timely manner. My email of April 3 1997 appears to have been totally ignored by the RFC Editor and the IESG. In that message I asked: Mohsen> Can you please let us know generally what the reason for the delay is? Mohsen> Can you tell us who the IESG contact person is for this Informational Mohsen> RFC? Mohsen> Based on my understanding of the process of Informational RFC Mohsen> publication (RFC-2026 Sections 4.2.2 & 4.2.3), IESG's review relates Mohsen> to conflicts of the domain of the document with work that is being Mohsen> done or is expected to be done, within the IETF community. Is there a Mohsen> conflict? At that time our only contact point was the RFC Editor. The Editor neglected to reply to that message. Those questions remain unanswered even today. Had the RFC Editor responded to that message in April, we would have save a lot of time. The above instance alone justifies my fair use of the word "negligently". There is no abuse there. My previous messages clearly shows how on several occasions the IESG neglected to respond to our inquiries. In my opinion the heart of the problem in this case is that the RFC-Editor seems to have been reduced to a puppet. Rather than managing the RFC publication process the RFC-Editor seems to be functioning as an inefficient messenger for the IESG. This is clearly in conflict with with the spirit of RFC-2026 Sections 4.2.2 & 4.2.3. On the third point, there are a number of ways that I can help out in addressing the above mentioned problems. I'll be happy to work with Scott on the next revision of RFC-2026 to make the text of 4.2.{2,3} more tight and clear. I'll also be happy to make the case that in practice the RFC-Editor needs to have a stronger and more independent role. We are all on the same side. Let's work together. ...Mohsen. P.S. I have been CCing Jon Postel on most of this thread and would love to know what he thinks of all of this. ------------------------------ From: Scott Bradner <sob@harvard.edu> To: mohsen@neda.com Subject: Re: Now: Improving the Informational RFCs Publication Process both in Theory and in Practice -- Was: Re:Unexpected and Unreasonable delays in processing of Informational Date: Thu, 7 Aug 1997 15:24:00 -0400 (EDT) Message-Id: <199708071924.PAA10978@newdev.harvard.edu> I'm sending this just to you I told you that the problem was in the the ball getting dropped by the IESG the RFC editor must follow what the IESG tells it to do and the IESG told the rfc editor not to publish your document until the transport ad talked to you. SO the rfc editor was doing exactly what it should have done If you do not understand that the tone of your notes is abusive I think it is time for you to talk to a friend - the iesg fucked up and I'm trying to fix the issue - you do not seem to want to listen - if I am wrong in my analysis tell me Scott ------------------------------ From: Scott Bradner <sob@harvard.edu> To: iesg-secretary@ietf.org, JBCheng@attws-hq1.nwest.attws.com, mohsen@neda.com, mtaylor@teledesic.com, pean@neda.com Cc: allyn@eng.sun.com Subject: ESRO ID Date: Thu, 7 Aug 1997 15:43:37 -0400 (EDT) Message-Id: <199708071943.PAA11036@newdev.harvard.edu> I have exchanged mail with the ex transport co-AD about this ID. She feels that this ID represents a significant technical contribution and feels that it should be advanced on the IETF standards track. The normal way to do that with a non-working group document is to issue a 4 week last-call to the general IETF community announcing the intention of the IESG to evaluate the ID as a Proposed Standard and asking for comments. After the end of that last-call period the IESG would evaluate the responses and proceed. If this is valuable technology then it would be a shame to miss the chance to get it on the standards track by a quick publication as an informational RFC (yes we could publish it as an info then do the last call but that would be unusual and potentially confusing later on when the RFC is referred to) So - I'd like the authors of the ID to let me know how you would like to proceed. I'm quite willing to be the IESG shepard for the ID if you are interested in proceeding to a last call. Scott ------------------------------ From: Mohsen Banan <mohsen@neda.com> To: Scott Bradner <sob@harvard.edu> Cc: iesg-secretary@ietf.org, JBCheng@attws-hq1.nwest.attws.com, mtaylor@teledesic.com, pean@neda.com, allyn@eng.sun.com, Mohsen Banan-neda <mohsen@neda.com> Subject: Re: ESRO ID Date: Fri, 8 Aug 1997 11:53:13 -0700 (PDT) Message-Id: <199708081853.LAA14067@rostam.neda.com> >>>>> On Thu, 7 Aug 1997 15:43:37 -0400 (EDT), Scott Bradner <sob@harvard.edu> said: Scott> I have exchanged mail with the ex transport co-AD about this ID. She feels Scott> that this ID represents a significant technical contribution and feels that Scott> it should be advanced on the IETF standards track. Thanks for overseeing the progress of this towards publication. Scott> The normal way to do that with a non-working group document is to issue Scott> a 4 week last-call to the general IETF community announcing the intention Scott> of the IESG to evaluate the ID as a Proposed Standard and asking for Scott> comments. After the end of that last-call period the IESG would Scott> evaluate the responses and proceed. Scott> If this is valuable technology then it would be a shame to miss Scott> the chance to get it on the standards track by a quick publication as Scott> an informational RFC (yes we could publish it as an info then do the Scott> last call but that would be unusual and potentially confusing later Scott> on when the RFC is referred to) Scott> So - I'd like the authors of the ID to let me know how you would like Scott> to proceed. I'm quite willing to be the IESG shepard for the ID if Scott> you are interested in proceeding to a last call. I have spoken with the other two authors (Mark Taylor and Jia-Bing Cheng) and we have a consensus amongst us that at this time we should go ahead with the immediate publication of ESRO ID as an Informational RFC. The urgency for publication in this case outweighs our interest in getting this document on the standards track. However, I am very interested in getting the next version of ESRO on the standards track. In addition, we also have been working on another protocol that uses ESRO which I believe represents enough of a technical contribution to merit being put on the standards track as well. I am hoping to have them ready for submission as RFCs-to-be by the end of next month. Again, thank you for all your help with this. ...Mohsen. ------------------------------ From: Scott Bradner <sob@harvard.edu> To: mohsen@neda.com, sob@harvard.edu Cc: allyn@eng.sun.com, iesg-secretary@ietf.org, JBCheng@attws-hq1.nwest.attws.com, mtaylor@teledesic.com, pean@neda.com Subject: Re: ESRO ID Date: Fri, 8 Aug 1997 16:46:35 -0400 (EDT) Message-Id: <199708082046.QAA01197@newdev.harvard.edu> - -- The urgency for publication in this case outweighs our interest in getting this document on the standards track. - -- for my information, what is causing this feeling of urgency? Scott ------------------------------ From: Mohsen Banan <mohsen@neda.com> To: Scott Bradner <sob@harvard.edu> Cc: allyn@eng.sun.com, iesg-secretary@ietf.org, JBCheng@attws-hq1.nwest.attws.com, mtaylor@teledesic.com, pean@neda.com, Mohsen Banan-neda <mohsen@neda.com> Subject: Re: ESRO ID Date: Fri, 8 Aug 1997 15:19:37 -0700 (PDT) Message-Id: <199708082219.PAA14258@rostam.neda.com> >>>>> On Fri, 8 Aug 1997 16:46:35 -0400 (EDT), Scott Bradner <sob@harvard.edu> said: Mohsen> -- Mohsen> The urgency for publication in this case outweighs our interest in Mohsen> getting this document on the standards track. Mohsen> -- Scott> for my information, what is causing this feeling of urgency? For the past several months we have been telling our partners and customers that the protocols our products use will soon be available via the Informational RFC mechanism. Our credibility goes down as time go by ... Our business strategy hinges on the openness of our solution which in turn hinges on the availability of ESRO protocol specification as an RFC. The absence of the RFC is delaying our marketing efforts. Other closed efficient transports for wireless applications exist. The value of an open alternative declines as time goes by ... ...Mohsen. ------------------------------ From: Scott Bradner <sob@harvard.edu> To: JBCheng@attws-hq1.nwest.attws.com, mohsen@neda.com, mtaylor@teledesic.com, pean@neda.com Subject: Re: ESRO ID Date: Sun, 17 Aug 1997 20:51:53 -0400 (EDT) Message-Id: <199708180051.UAA08685@newdev.harvard.edu> Mohsen, Now that the IETF meeting in Munich is over I have recomended to the IESG that your document be published as an Informational RFC. (there was no sense in doing so before the IETF meeting since nothing was going to happen with everyone at the meeting) I do hope that you will consider submitting the revised version you wrote about for consideration as a standards track RFC when it is ready. Scott ------------------------------ From: Mohsen Banan <mohsen@neda.com> To: Scott Bradner <sob@harvard.edu> Cc: JBCheng@attws-hq1.nwest.attws.com, mtaylor@teledesic.com, pean@neda.com, Mohsen Banan-neda <mohsen@neda.com> Subject: Re: ESRO ID Date: Sun, 17 Aug 1997 21:34:31 -0700 (PDT) Message-Id: <199708180434.VAA26606@rostam.neda.com> >>>>> On Sun, 17 Aug 1997 20:51:53 -0400 (EDT), Scott Bradner <sob@harvard.edu> said: Scott> Mohsen, Scott> Now that the IETF meeting in Munich is over I have recomended Scott> to the IESG that your document be published as an Informational RFC. (there Scott> was no sense in doing so before the IETF meeting since nothing was Scott> going to happen with everyone at the meeting) Great. Thank you. Scott> I do hope that you will consider submitting the revised version Scott> you wrote about for consideration as a standards track RFC when it is Scott> ready. I will. Promised. ...Mohsen. ------------------------------ From: Scott Bradner <sob@harvard.edu> To: JBCheng@attws-hq1.nwest.attws.com, mohsen@neda.com, mtaylor@teledesic.com, pean@neda.com Date: Mon, 18 Aug 1997 08:17:17 -0400 (EDT) Message-Id: <199708181217.IAA09055@newdev.harvard.edu> a comment from one of the IESG members about your draft Scott - -- >From hta@dale.uninett.no Mon Aug 18 08:05:50 1997 X-Mailer: exmh version 1.6.9 8/22/96 From: Harald.T.Alvestrand@uninett.no To: Scott Bradner <sob@harvard.edu> cc: iesg@ietf.org Subject: Re: draft-rfced-info-banan-esro-00.txt In-reply-to: Your message of "Sun, 17 Aug 1997 20:48:03 EDT." <199708180048.UAA08679@newdev.harvard.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 18 Aug 1997 12:47:04 +0200 Sender: hta@dale.uninett.no The broken part of the protocol is this line: >4.6.3 Use of lower layers > >ESRO protocol uses UDP port number 259. The protocol is an obvious alternate to "heavier" RPC protocols, but has only 8 bits of SAP to differentiate between different users. The "obviously right" thing to my mind is to say that the assignment of an UDP port is part of the application protocol. The document is also self-conflicting; see this paragraph: > 2.4.2 Performer-address > This parameter is the address of the ESROS Performer User which > consists of ESRO Service Access Point (SAP) Selector, Transport > Service Access Point (TSAP) Selector (e.g., port number), and Network > Service Access Point (NSAP) address (e.g., IP address). This > parameter has to be supplied by the invoker of the service. > ESROS Invoker User provides the Performer-address parameter for the > ESROS-INVOKE.request primitive. which seems to call the port part of the address. I have no objection to publication, but if you talk to them again, it might not hurt to clarify this part. Harald ------------------------------ Resent-Date: Mon, 18 Aug 1997 11:52:15 -0700 (PDT) Resent-Message-Id: <199708181852.LAA27378@rostam.neda.com> Resent-From: Pean Lim <pean@neda.com> Resent-To: mohsen@neda.com From: Mohsen Banan <mohsen@neda.com> To: Scott Bradner <sob@harvard.edu> Cc: JBCheng@attws-hq1.nwest.attws.com, mtaylor@teledesic.com, pean@neda.com, "Harald T. Alvestrand" <uunet!delab.sintef.no!harald.t.alvestrand@rostam.neda.com> Subject: Clarifications on ESRO SAP Addressing Date: Mon, 18 Aug 1997 11:50:29 -0700 (PDT) Message-Id: <199708181850.LAA27366@rostam.neda.com> >>>>> On Mon, 18 Aug 1997 08:17:17 -0400 (EDT), Scott Bradner <sob@harvard.edu> said: Scott> a comment from one of the IESG members about your draft Scott> Scott Harald's observations are correct. That part of the spec is not clear. I will fix this problem in the next rev of the spec. My responses to Harald's email follow: >> From hta@dale.uninett.no Mon Aug 18 08:05:50 1997 Harald> X-Mailer: exmh version 1.6.9 8/22/96 Harald> From: Harald.T.Alvestrand@uninett.no Harald> To: Scott Bradner <sob@harvard.edu> Harald> cc: iesg@ietf.org Harald> Subject: Re: draft-rfced-info-banan-esro-00.txt Harald> In-reply-to: Your message of "Sun, 17 Aug 1997 20:48:03 EDT." <199708180048.UAA08679@newdev.harvard.edu> Harald> Mime-Version: 1.0 Harald> Content-Type: text/plain; charset=us-ascii Harald> Date: Mon, 18 Aug 1997 12:47:04 +0200 Harald> Sender: hta@dale.uninett.no Harald> The broken part of the protocol is this line: Harald> 4.6.3 Use of lower layers Harald> Harald> ESRO protocol uses UDP port number 259. Agreed. Section 4.6.3 needs to be expanded to explain that the ESRO SAP Selector's range is only 16 (4 bits). That the assignment of a UDP port is part of the application layer. That port 259 (esro-gen) has been assigned for general usage of esro. Harald> The protocol is an obvious alternate to "heavier" RPC protocols, Glad you feel that way. Harald> but has only 8 bits of SAP to differentiate between different users. It is not 8 bits for the ESRO SAP Selector. It is only 4 bits (a total of 16). The design decision to accept a limited ESRO SAP Selector space for efficiency and to rely on UDP ports for wider use was deliberate. Harald> The "obviously right" thing to my mind is to say that the assignment Harald> of an UDP port is part of the application protocol. Agreed. Harald> The document is also self-conflicting; see this paragraph: The conflict is because section 4.6.3 needs to be expanded. Harald> 2.4.2 Performer-address Harald> This parameter is the address of the ESROS Performer User which Harald> consists of ESRO Service Access Point (SAP) Selector, Transport Harald> Service Access Point (TSAP) Selector (e.g., port number), and Network Harald> Service Access Point (NSAP) address (e.g., IP address). This Harald> parameter has to be supplied by the invoker of the service. Harald> ESROS Invoker User provides the Performer-address parameter for the Harald> ESROS-INVOKE.request primitive. Harald> which seems to call the port part of the address. Section 2.4.2 is correct. Section 4.6.3 needs clarification. Harald> I have no objection to publication, but if you talk to them again, Harald> it might not hurt to clarify this part. Thanks for your comments. ...Mohsen ------------------------------ From: Mohsen Banan <mohsen@neda.com> To: Scott Bradner <sob@harvard.edu> CC: Pean Lim-Neda <pean@neda.com>, Mohsen Banan-neda <mohsen@neda.com>, "Mark S. Taylor" <mtaylor@teledesic.com>, Jia-Bing Cheng <JBCheng@attws-hq1.nwest.attws.com> Subject: ESRO ID Date: Thu, 28 Aug 1997 14:46:21 -0700 (PDT) Message-Id: <199708282146.OAA11605@rostam.neda.com> Scott, Just wanted to make sure that subsequent to our last email exchanges you are not waiting on anything further from us for the publication of the ESRO protocol as an Informational RFC. I understand that you have asked the RFC Editor to publish the ESRO protocol as an Informational RFC and that it will be published soon. Please keep me posted on your communications with the RFC Editor related to this RFC. Regards, ...Mohsen. ------------------------------ From: Scott Bradner <sob@harvard.edu> To: mohsen@neda.com Subject: Re: ESRO ID Date: Thu, 28 Aug 1997 18:29:48 -0400 (EDT) Message-Id: <199708282229.SAA23730@newdev.harvard.edu> The IESG has to make teh recommendation to the RFC Editor not just one AD. As soon as we got back form Munich I recommended to the IESG that the ID be published as an Info RFC The publication was approved by the IESG today ( we had to wait until the iesg telechonference after the Munich meeting) Scott ------------------------------ From: Mohsen Banan <mohsen@neda.com> To: Scott Bradner <sob@harvard.edu>, RFC Editor <rfc-ed@isi.edu> CC: Mohsen Banan-neda <mohsen@neda.com>, Pean Lim-Neda <pean@neda.com>, Jia-Bing Cheng <JBCheng@attws-hq1.nwest.attws.com>, "Mark S. Taylor" <mtaylor@teledesic.com>, iesg-secretary@ietf.org Subject: Re: ESRO ID Date: Tue, 9 Sep 1997 10:16:31 -0700 (PDT) Message-Id: <199709091716.KAA27728@rostam.neda.com> >>>>> On Thu, 28 Aug 1997 18:29:48 -0400 (EDT), Scott Bradner <sob@harvard.edu> said: Scott> The IESG has to make teh recommendation to the RFC Editor not just Scott> one AD. As soon as we got back form Munich I recommended to the IESG Scott> that the ID be published as an Info RFC Scott> The publication was approved by the IESG today ( we had to wait until Scott> the iesg telechonference after the Munich meeting) Based on that approval, I take it that IESG had sent its recommendation to the RFC Editor that the ID be published as an Info RFC. I had hoped that by now it would have been published but the ESRO Informational RFC has not been published yet. Considering that our Information RFC publication request was submitted nearly 8 months ago, we are very anxious to see it published as soon as possible. Can you please tell us what the status towards the publication of this RFC is? In fact it would be great if the RFC Editor gives us a publication date in response to this message. Regards, ...Mohsen. P.S. Are there any other Informational RFCs in the RFC publication queue that have been there longer than this one? ------------------------------ From: rfc-ed@ISI.EDU (RFC Editor) To: mohsen@neda.com Cc: rfc-ed@ISI.EDU Subject: Re: ESRO ID Date: Tue, 9 Sep 1997 10:35:29 -0700 Message-Id: <199709091735.AA26117@zephyr.isi.edu> Mohsen, As a matter of fact your RFC was published yesterday. We wait 24 hours to send the announcement out. I will be sending out the announcement around 4pm PST. Sincerely, Alegre Ramos - USC/ISI Request for Comments Documents Voice: (310) 822-1511 x153 Fax: (310) 823-6714 EMAIL: RFC-ED@ISI.EDU ------------------------------ From: RFC Editor <rfc-ed@isi.edu> Sender: ietf-announce-request@ietf.org To: IETF-Announce: ; Cc: rfc-ed@isi.edu Subject: RFC 2188 on ESRO Date: Tue, 09 Sep 97 15:28:32 PDT Message-Id: <199709092228.AA15459@zephyr.isi.edu> Mime-Version: 1.0 Content-Length: -919 Content-Type: Multipart/Mixed; Boundary=NextPart - --NextPart A new Request for Comments is now available in online RFC libraries. RFC 2188: Title: AT&T/Neda's Efficient Short Remote Operations (ESRO) Protocol Specification Version 1.2 Author: M. Banan, M. Taylor, and J. Cheng Date: September 1997 Mailbox: mohsen@neda.com, mark.taylor@airdata.com, jcheng@airdata.com Pages: 57 Characters: 118374 Updates/Obsoletes: None URL: ftp://ds.internic.net/rfc/rfc2188.txt This document specifies the service model, the notation and protocol for Efficient Short Remote Operations (ESRO). The ESRO service is similar to and is consistent with other Remote Procedure Call services. The emphasis of ESRO service definition and the ESRO protocol is on efficiency. ESRO is designed specifically with wireless network (e.g., CDPD) usage in mind. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@ISI.EDU. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@ISI.EDU with the message body help: ways_to_get_rfcs. For example: To: rfc-info@ISI.EDU Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to admin@DS.INTERNIC.NET. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@ISI.EDU. Please consult RFC 1543, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Alegre Ramos USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. - --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" - --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <970909152124.RFC@ISI.EDU> SEND /rfc/rfc2188.txt - --OtherAccess Content-Type: Message/External-body; name="rfc2188.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="rfc" Content-Type: text/plain Content-ID: <970909152124.RFC@ISI.EDU> - --OtherAccess-- - --NextPart-- ------------------------------ From: Scott Bradner <sob@harvard.edu> To: mohsen@neda.com Subject: Re: ESRO ID Date: Wed, 10 Sep 1997 08:55:13 -0400 (EDT) Message-Id: <199709101255.IAA15230@newdev.harvard.edu> as I hope you have seen by now the RFC was published yesterday Sorry for the delays involved in the publication Scott ------- end -------
- Complaints Against The IESG and The RFC-Editor Ab… Mohsen BANAN
- Re: Complaints Against The IESG and The RFC-Edito… Jeffrey Altman
- Re: Complaints Against The IESG and The RFC-Edito… John Curran
- Re: Complaints Against The IESG and The RFC-Edito… Noel Chiappa
- Re: Complaints Against The IESG and The RFC-Edito… Tim Salo
- Re: Complaints Against The IESG and The RFC-Edito… Vernon Schryver
- Re: Complaints Against The IESG and The RFC-Edito… Lloyd Wood
- Re: Complaints Against The IESG and The RFC-Edito… John Curran
- Re: Complaints Against The IESG and The RFC-Edito… Perry E. Metzger
- Re: Complaints Against The IESG and The RFC-Edito… Paul Hoffman / IMC
- Re: Complaints Against The IESG and The RFC-Edito… Theodore Y. Ts'o
- Re: Complaints Against The IESG and The RFC-Edito… Mohsen BANAN
- Re: Complaints Against The IESG and The RFC-Edito… Tim Salo
- Re: Complaints Against The IESG and The RFC-Edito… Theodore Y. Ts'o
- Re: Complaints Against The IESG and The RFC-Edito… Billy Biggs
- Re: Complaints Against The IESG and The RFC-Edito… Marc Horowitz
- is discarded. Andy Bierman
- Re: Complaints Against The IESG and The RFC-Edito… Claus André Färber
- Re: Complaints Against The IESG and The RFC-Edito… Harald Tveit Alvestrand
- Re: Complaints Against The IESG and The RFC-Edito… John Curran
- Re: Complaints Against The IESG and The RFC-Edito… Brian E Carpenter
- Re: Complaints Against The IESG and The RFC-Edito… Brian E Carpenter
- Re: Complaints Against The IESG and The RFC-Edito… Vernon Schryver
- Re: Complaints Against The IESG and The RFC-Edito… braden
- Re: Complaints Against The IESG and The RFC-Edito… Lloyd Wood
- Re: Complaints Against The IESG and The RFC-Edito… Christian Huitema
- Re: Complaints Against The IESG and The RFC-Edito… Mohsen BANAN
- Re: Complaints Against The IESG and The RFC-Edito… Fred Baker
- Re: Complaints Against The IESG and The RFC-Edito… Brian E Carpenter
- A perspective on the FYI RFC Publication Process Fred Baker
- RE: A perspective on the FYI RFC Publication Proc… Mitch Denny
- Re: A perspective on the FYI RFC Publication Proc… Mohsen BANAN
- Re: A perspective on the FYI RFC Publication Proc… vinton g. cerf
- Re: A perspective on the FYI RFC Publication Proc… Brian E Carpenter
- Re: A perspective on the FYI RFC Publication Proc… Mohsen BANAN
- Complaints Against The IESG and The RFC-Editor Ab… Mohsen BANAN
- Re: Complaints Against The IESG and The RFC-Edito… Dave Crocker
- Re: Complaints Against The IESG and The RFC-Edito… Mohsen BANAN
- Re: Complaints Against The IESG and The RFC-Edito… Mohsen BANAN
- Re: Complaints Against The IESG and The RFC-Edito… Dave Cridland
- Re: Complaints Against The IESG and The RFC-Edito… Keith Moore
- Re: Complaints Against The IESG and The RFC-Edito… Pyda Srisuresh
- Re: Complaints Against The IESG and The RFC-Edito… Steven M. Bellovin
- Re: Complaints Against The IESG and The RFC-Edito… Pyda Srisuresh
- Re: Complaints Against The IESG and The RFC-Edito… Steven M. Bellovin
- Re: Complaints Against The IESG and The RFC-Edito… Mohsen BANAN
- Re: Complaints Against The IESG and The RFC-Edito… Harald Alvestrand
- Re: Complaints Against The IESG and The RFC-Edito… Mohsen BANAN
- Re: Complaints Against The IESG and The RFC-Edito… Brian E Carpenter
- Re: Complaints Against The IESG and The RFC-Edito… Keith Moore
- Re: Complaints Against The IESG and The RFC-Edito… Stephane Bortzmeyer
- Re: Complaints Against The IESG and The RFC-Edito… Dave Cridland
- Re: Complaints Against The IESG and The RFC-Edito… william(at)elan.net
- Re: Complaints Against The IESG and The RFC-Edito… william(at)elan.net
- Re: Complaints Against The IESG and The RFC-Edito… Keith Moore
- Re: Complaints Against The IESG and The RFC-Edito… william(at)elan.net
- Re: Complaints Against The IESG and The RFC-Edito… Keith Moore
- Re: Complaints Against The IESG and The RFC-Edito… JFC (Jefsey) Morfin
- Re: Complaints Against The IESG and The RFC-Edito… Stephane Bortzmeyer
- Re: Complaints Against The IESG and The RFC-Edito… Hallam-Baker, Phillip
- The original specs and notes on them..... Harald Alvestrand
- HTTP archaeology [Re: Complaints Against The IESG… Brian E Carpenter
- Re: HTTP archaeology [Re: Complaints Against The … Carl Malamud