Re: draft-rfced-info-banan-00.txt

[Mohsen BANAN <mohsen@neda.com>]

No. 

You guys are reading this completely wrong.  I had hoped that the
"NOTE TO IESG AND RFC-EDITOR" would be clear enough.

For the publication of this revision as an Informational RFC, 
I am not the least bit interested in IESG's opinions or blessings.


I demand that this spec. be published as an Informational RFC in a
timely manner according to the procedures of BCP 9, RFC 2026, Sections
4.2.2 and 4.2.3.

The scope of the IESG review according to section 4.2.3 is quite
limited. Keith Moore's opinions clearly goes beyond that scope.

Note that based on paragraph 3 of section 4.2.3 of RFC 2026, I am
insisting that this specification be published. The IESG is free to
insert whatever note it wishes in that Information RFC. I want to see
the IESG note and have a chance to comment on it before
publication. Make sure that the "Note To IESG and RFC-Editor" section
is not altered in anyway.


Keith Moore's comments are a clear case of "Not Invented Here"
syndrome. I'll provide a more detailed response to his comments soon.


Also, as I have repeatedly requested in the past, please CC me on all
communications related to this Informational RFC.


If you are not following the procedures of RFC 2026, Sections 4.2.2
and 4.2.3, please let me know what procedures are being followed.


Respectfully Yours,

--
        Mohsen Banan
        President
        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/



>>>>> On Tue, 03 Nov 1998 12:58:24 -0800, Fred Baker <fred@cisco.com> said:

  Fred> Steve: Please advise the RFC Editor as such.
  Fred> Keith: You have copied the author on this, which I think is a Good Thing.
  Fred> Would you be willing to work with the author to make the document and the
  Fred> protocol something worthwhile? It looks like his company wants to make it
  Fred> into a business case, so they may be willing to pay for consulting services
  Fred> on protocol design.

  Fred> Fred

  Fred> At 03:35 PM 11/3/98 -0500, Keith Moore wrote:
  >> I do not consider this document fit for publication as an RFC
  >> in its current form.
  >> 
  >> The protocol itself is poorly designed in a number of areas.
  >> It might be more efficient than SMTP in terms of number of
  >> packets and delay, but on a quick review it appears to be
  >> gratuitously complex, lack important functionality, and have
  >> insufficient error reporting and diagnostic capability.
  >> Its design ignores much that has been learned about email over
  >> the past 20 or so years.
  >> 
  >> The use of ASN.1 and ESRO are highly questionable.  ONC RPC/XDR 
  >> and T/TCP would appear to be far better choices.  
  >> 
  >> The document also contains a number of inaccurate characterizations 
  >> of Internet mail and SMTP.
  >> 
  >> If this is indeed widely deployed, then the community might benefit
  >> from publication of this document as an Informational RFC, but it
  >> should first be edited to remove these mischaracterizations and/or
  >> have a strong disclaimer that recommends against actually using it.
  >> 
  >> There is a real need that the protocol attempts to address, as SMTP 
  >> is not well suited to an environment where there is a high cost 
  >> associated with transmission of each IP datagram (it uses more 
  >> datagrams than absolutely necessary), or where there is a long 
  >> round-trip delay combined with low reliability (the several round
  >> trips required to complete an SMTP session can cause considerable 
  >> delay in message delivery).
  >> 
  >> So we should probably consider doing a better design in IETF, but
  >> it should not be based on this protocol.
  >> 
  >> Keith
  >>