Do Later -- Re: draft-rfced-info-banan-00.txt (EMSD)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Do Later -- Re: draft-rfced-info-banan-00.txt (EMSD)
- To: mohsen@neda.com
- Subject: Do Later -- Re: draft-rfced-info-banan-00.txt (EMSD)
- From: Mohsen BANAN <mohsen@neda.com>
- Date: Sat, 7 Nov 1998 14:33:58 -0800 (PST)
- Content-Length: 8456
- Content-Type: text/plain; charset=US-ASCII
- In-Reply-To: <199811032035.PAA17901@spot.cs.utk.edu>
- References: <199811032035.PAA17901@spot.cs.utk.edu>
xx To : Keith Moore <moore@cs.utk.edu> xx Cc : iesg@ietf.org, Internet Architecture Board <iab@isi.edu>, records@neda.com xx Subject : Re: draft-rfced-info-banan-00.txt (EMSD) Keith, I know that you already have recognized that this message which was the first one that you sent out was at least a bit out of line and that you have already admitted that. However, because of my previous experiences with the IESG, I have already started CCing the RFC Editor and the IAB as a way of bringing in some level of accountability which I feel is called for. On this one, let's do it by the book from the beginning to the end. I really want this specification to be published as an Informational RFC in a timely manner. >>>>> On Tue, 03 Nov 1998 15:35:35 -0500, Keith Moore <moore@cs.utk.edu> said: Keith> I do not consider this document fit for publication as an RFC Keith> in its current form. Since I understand that you are an Area Direc tor, this statement is very grave and causes all kinds of problems. First, in the case of referral of a non-IETF document for publication as an Informational RFC, which does not represent an Internet recommendation of any sort, the determination for fitness for publication is with the RFC Editor not by the IESG or by you. Further, that determination by the RFC Editor is supposed to be based on the following 3 criterias. 1) Relevance to Internet activity There should be no question about draft-rfced-info-banan-00.txt's relevance to Internet. This is a super hot topic. For example, every palmtop and handheld PC is begging to become a two-way pager over wireless IP. There are no Internet Mail Protocols that address that specific domain. draft-rfced-info-banan-00.txt has an obvious clear place there. Keith has acknowledged this explicitly. If there are any concerns in this regard, the RFC Editor can let me know and I'll address it promptly. 2) Meets the editorial standard for RFCs I have been using the LaTeX templates in the rfc repository directory for many years now. So the format should be fine. If there are any concerns in this regard, the RFC Editor can let me know and I will fix them promptly. 3) Meets the technical standard for RFCs This specification is the result of 4 years of development work by a number of engineers. The specification is generally complete. All the requirements and goals that the protocol sets out to accomplish are documented. The protocol meets those goals and requirements. The ASN.1 text of the protocol has been verified using at least two compilers. Existing implementaions of both user agent and server agent run on a number of platforms, already. The spec has been reviewed by many and their relevant input has been included. I believe that draft-rfced-info-banan-00.txt easily meets the minimum technical standard requirements for publication as an Informational RFC. If there are any concerns in this regard, the RFC Editor can let me know and I will address them promptly. Beyond its fitness for publication, the RFC Editor's referral to the IESG is focussed on two areas. 1) Based on Keith's messages, I understand that the IESG has already decided that it is NOT recommending that the document be brought in the IETF. I have no problem with that. 2) Based on Keith's messages, I understand that the IESG is planning to put an IESG disclaimer in the RFC. I have no problem with that as long as I get a chance to review it and comment on it before publication. Such an IESG note is supposed to be primarily about the determination that the document conflicts with or is inimical to an established IETF effort. I know of no such IETF effort. But, I also understand that the IESG does more than that now. My main concern is that draft-rfced-info-banan-00.txt progresses towards publication in a timely manner. Keith> The protocol itself is poorly designed in a number of areas. Naturally, I don't agree. Keith> It might be more efficient than SMTP in terms of number of Keith> packets and delay, That sure is true and proven. See section "C.1.1" of draft-rfced-info-banan-00.txt for details. Keith> but on a quick review it appears to be Keith> gratuitously complex, lack important functionality, and have Keith> insufficient error reporting and diagnostic capability. Those are gross generalities with which I don't know what to do. First, a quick review of something like this is likely to be problematic. I really don't expect you to understand many of the aspects of what we have been working on over the past 4 years all that quickly. Given its requirements and goals (which are documented), the protocol is as complex as it needs to be. First hand development experience with the protocol has been quite positive and complexity has not been a problem. The functionality of the protocol meets all the requirements and goals that it needs. The protocol has adequate error reporting and diagnostic capability and if anything is missing it can easily be added. What in specific are you pointing to? Keith> Its design ignores much that has been learned about email over Keith> the past 20 or so years. This is just an opinion. Obviously, I disagree. Keith> The use of ASN.1 and ESRO are highly questionable. ONC RPC/XDR Keith> and T/TCP would appear to be far better choices. We had expected that there may be comments such as this. For that reason, Appendix C, "RATIONALE FOR KEY DESIGN DECISIONS" was added to the spec. That part of the spec explains our justifications for use of ASN.1 and ESRO. In the early stages of the design of this protocol (4 years ago), ONC RPC/XDR and T/TCP were considered and decided against. I would love to see somebody else try those and then compare notes with them ... Keith> The document also contains a number of inaccurate characterizations Keith> of Internet mail and SMTP. I would love to know about that. Please email me the details of what you consider "inaccurate characterizations". If they are reasonable, I'll be happy to incorporate them. Keith> If this is indeed widely deployed, then the community might benefit Keith> from publication of this document as an Informational RFC, Informational RFC is all that I want. Nothing more. Keith> but it Keith> should first be edited to remove these mischaracterizations and/or Let me know about the specifics of the mischaracterizations that you are refering to. Keith> have a strong disclaimer that recommends against actually using it. Okay. As long as you can technically justify it. Keith> There is a real need that the protocol attempts to address, as SMTP Keith> is not well suited to an environment where there is a high cost Keith> associated with transmission of each IP datagram (it uses more Keith> datagrams than absolutely necessary), or where there is a long Keith> round-trip delay combined with low reliability (the several round Keith> trips required to complete an SMTP session can cause considerable Keith> delay in message delivery). Absolutely! Keith> So we should probably consider doing a better design in IETF, but Keith> it should not be based on this protocol. That is fine. Let there be competition amongst protocols. And, may the better one win more in usage and deployment. Please do not suppress or censor or delay publication of this spec. as an Informational RFC because you prefer to do it differently. Can we please turn this into a positive and productive interaction? I suggest the following: - Quickly email me your specific comments which you feel I should incorporate. - If there are significant pieces that are missing and that should go in the next rev. of this spec., please email me those. I'll update Appendix D, "FURTHER DEVELOPMENT". - Give me a general feel for the nature of the IESG note that you intend to include as soon as possible so that we can discuss it and make sure that there are no mis-understandings. Regards, ...Mohsen.
- Replies
- draft-rfced-info-banan-00.txt, Keith Moore
- draft-rfced-info-banan-00.txt, Keith Moore
- Prev by Date: Re: draft-rfced-info-banan-00.txt
- Next by Date: Re: draft-rfced-info-banan-00.txt (EMSD)
- Prev by thread: Re: draft-rfced-info-banan-00.txt
- Next by thread: Re: draft-rfced-info-banan-00.txt (EMSD)
- Index(es):