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

[Mohsen BANAN <mohsen@neda.com>]

>>>>> On Tue, 03 Nov 1998 19:48:46 -0500, Keith Moore <moore@cs.utk.edu> said:

  Keith> I apologize for the tone of my earlier message.   It was written
  Keith> hastily and without proper respect.  I should have waited a while
  Keith> before responding so as to better frame my argument.

Okay.

  Keith> I do have real concerns about the impact of this protocol on the Internet 
  Keith> email system, should it be widely deployed.  

I understand.

I suspect that would be true of ANY protocol coming
from outside of the IETF which was to do the
same thing that EMSD does.

This is a new area in Internet Mail protocols. There
are different approaches with different trade-offs
... Nothing is known to work unless we try it.

However, it would be a disaster if you were to try
to delay or stop publication of this as an
Informational RFC -- which does not represent an
Internet recommendation of any sort.


  Keith> I understand the utility in publishing EMSD as a "point-of-record"
  Keith> if it is widely deployed - so people can build tools that interoperate
  Keith> with deployed devices. 

The benefits of an Informational (or Experimental)
RFC publication of EMSD are a lot more than just
that.

Engineers all around the world can review it and
provide comments about a new protocol in a critical
new area of Internet Email.

Those wishing to build similar or competing
protocols can look at it as a base line.

Those wishing in participating in experimentation
and improvements to the protocol can use it as a
base line.

...


  Keith> So if you can convince us that widely deployed
  Keith> devices are already using this protocol, that would weigh heavily 
  Keith> in IESG's decision to recommend (or not) that your document be published.  

I should not have to do this to get a
spec. published as an Informational RFC.

This is not part of the BCP-9 procedures.

Since when is it the responsibility of the IESG to assess 
the scale of deployment of a new protocol which is to
be published as an Informational RFC?

Are you saying that if this RFC was from a large
software company or a large ISP (with a large
installed base) the IESG would recommend that it be
published? 

Are you saying that if this RFC was from a small
company (with a small installed base) the IESG would
recommend that it be NOT published? 

I don't follow your logic.
 
At this time, I should not have to tell you:

  - How many EMSD mail accounts our servers support.
  - How many other entities use EMSD servers.
  - How many device are using EMSD.
  - How many device platforms are supported.
  - How many entities have licensed the EMSD device software.
  - How many entities have licensed the EMSD server software.
  - ...

All that I need to say is that the answer to all of 
the above is greater than 1. That in and of itself 
is justification for publication as an Informational RFC 
which is a point-of-record.

However, I will tell you that there is a lot of
public information that you can access in this
regard.  Not all of it is complete yet. But you can
get a lot of information from:

http://www.emsd.org/
http://www.neda.com/
http://www.subscribers.neda.com/
...

  Keith> Even so, I feel certain that IESG would want to add a note to the
  Keith> document describing limitations of the approach and perhaps even 
  Keith> recommending against implementing it in new devices.

That is fine.

The IESG can put whatever note in there as long as I
get a chance to review it before publication and as
long as the IESG can justify the note.

I am not worried about the IESG note but I want the
specification published in a timely manner.

  Keith> Frankly, without 
  Keith> such justification, I'd rather not take the time to do the thorough review 
  Keith> that it would take to write up such a note, because that time would be 
  Keith> better spent designing a new protocol.  

Nobody is asking you for the "favor" of reviewing
that document.  


You have a RESPONSIBILITY with respect to a referral
made to you by the RFC Editor regarding publication
of draft-rfced-info-banan-00.txt as an Informational
RFC. The purpose and scope of your review is defined
in BCP-9. 

Just do your job.

That is all that I am asking for.

There are no conditions attached to this.

  Keith> Such a protocol needs to give very careful consideration to not only 
  Keith> packet/bandwidth efficiency, but also to implementation complexity 
  Keith> (which has a profound effect on code quality and therefore operational
  Keith> reliability).  

I have already responded to this in my previous note.

  Keith> Also, experience over many years indicates that mail 
  Keith> gateways are a primary source of operational failures, and that such 
  Keith> failures are notoriously difficult to diagnose and fix due to the lack 
  Keith> of proper trace information.  If there's going to be a new Internet 
  Keith> mail submission/relay/delivery protocol, the relationship between 
  Keith> the new protocol and Internet Mail also needs to be carefully defined 
  Keith> as part of the protocol design.  This will ensure that such gateways 
  Keith> work as well as possible, minimizing the operational difficulties.

  Keith> I believe that such design work would best be done in an IETF working
  Keith> group, where we have a large community with substantial expertise in 
  Keith> Internet email.    These people also have a significant interest in
  Keith> making sure that the gateway issues are sorted out, since they will
  Keith> be the ones who have to implement and operate the gateways that talk 
  Keith> between MIME/SMTP and the new protocol.

Wonderful. Why don't you go ahead and do that inside
of the IETF? That is a good thing. The more people
work in this area, the more we learn.

If you do a good job and if any of the problems that
you are talking about with EMSD are real, then it is
very likely that EMSD will not be widely
deployed. Then, that would address your concern.


I have already chosen to submit EMSD as an
Information RFC to the RFC Editor outside of the
IETF. My view of how this protocol should be
designed is different from yours. In someways that
means that we are competing in producing brand new
protocols in a brand new area of Internet Email.
Let there be competition. That is good.


What is scary is that you seem to think because you
are part of the IETF/IESG you have all the right
experience and all the right ideas. And I don't.

You have the advantage of being in the Inner Circles.
Don't abuse your authority. 

I am demanding a fair access to the RFC publication service.

Don't delay the publication of EMSD as an Informational RFC.


...Mohsen.