Do Later -- Re: draft-rfced-info-banan-00.txt (EMSD)

[Mohsen BANAN <mohsen@neda.com>]

  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.