Re: The RFC Editor's current position on Mohsen Banan's EMSD

[braden@ISI.EDU]

----- Begin Included Message -----

>From VM Mon Jan 11 11:05:15 1999
Date: Mon, 11 Jan 1999 10:59:14 -0800
From: braden@ISI.EDU
To: braden@ISI.EDU, moore@cs.utk.edu
Subject: Re: The RFC Editor's current position on Mohsen Banan's EMSD
Cc: iesg@ISI.EDU, jkrey@ISI.EDU, rfc-ed@ISI.EDU
Content-Length: 7671
X-Lines: 165
Status:   


  *> 
  *> > Mohsen Banan has asked that his EMSD (Efficient Mail Submission and
  *> > Delivery) protocol be published as an Informational RFC.  After
  *> > conversations with the Area Director as well as two independent experts
  *> > (*) in the wireless industry, we have concluded that the RFC Editor
  *> > should publish this document.  We believe this is what Jon would
  *> > have done.
  *> > 
  *> > There are some legitimate concerns about EMSD from the IETF/Internet
  *> > viewpoint.  Here are the ones we have considered.
  *> > 
  *> > 	1. Is this an end-run around our standards process?
  *> > 
  *> > 		Basically, no.  
  *> 
  *> I understand that publication might be useful but it is also obvious
  *> that Mr. Banan wants IETF RFC imprimatur to add legitimacy to his
  *> protocol.  However, EMSD is not (IMHO) of sufficient quality that 
  *> we would normally publish it.  If memory serves we have requested
  *> that other protocols not be published because they did not adquately
  *> address congestion control.
  *> 

Keith,

We (the RFC Editor office) *really* does not want to get into a tussle
with you over this issue.  Questioning Joyce, I have not found any
support for the idea that Jon would have refused to publish this
document.  (Life would have been much easier had that been the case!).

The congestion control issue, one to which I am very sensitive (!), is
dealt with in the following.  BTW, I personally think the RFC Editor
(and IESG) was too lenient on publishing ESRO, which seems to me to
pose a much greater potential threat to the Internet than does EMSD.
Somehow the IESG did not pin point the real issue (lack of even
rudimentary congestion control) with ESRO, and it may come back to
haunt us.

  *> > 	2. Do these protocols pose a danger to the Internet?
  *> > 
  *> > 		Not in their intended application -- two-way pagers and
  *> > 		similar terminals operating in a bandwidth-poor
  *> > 		environment at the edge of the Internet.
  *> 
  *> Mr. Banan is on record as recommending that EMSD be adopted in the
  *> Internet at large, and it will be easier for him to do so once he 
  *> has it published as an RFC.  This is part of the problem.

I just do not think this is a realistic danger, although I agree that
the IESG should be aware of the issue.  I have seen the Internet
survive much more credible threats from X.25, X.400, and OSI.

You might consider that putting this document in the public domain
will hold it up, with all its faults, for all to see.  The wireless
community is not dumb.

The wireless problem will be increasingly important for the Internet,
and I think publishing this as an RFC might in fact increase highly
useful interaction between the two communities.

  *> 
  *> > 	3. Keith Moore has raised the question that there may be
  *> > 		problems gatewaying mail between SMTP and EMSD.
  *> > 
  *> > 		If true and if EMSD became widely used, this could be a
  *> > 		serious issue.  Perhaps Banan could be persuaded to
  *> > 		prepare a document specifying the mapping between the
  *> > 		two mail systems.
  *> 
  *> Mr. Banan does not appear to have the competence to do this job.
  *> If he did, he would have designed the message format differently.
  *> 
  *> This isn't a big problem for two-way pagers, which already have
  *> severely limited functionality.  But it is a huge problem for 
  *> general internet email usage.
  *>  

If I thought this were a threat, I would completely agree.

  *> > 	4. Is Banan trying to exploit the appearance of IETF concurrence
  *> > 		on EMSD?
  *> > 
  *> > 		I actually don't think so, but it would be appropriate
  *> > 		for the IESG to ask him to make every effort to avoid
  *> > 		any such appearance.
  *> > 
  *> > 		In particular, the title of the document was presented
  *> > 		to us as: "Neda's ...".  We believe that having a
  *> > 		company name in the title in this way is completely
  *> > 		inappropriate.  We will ask Banan to remove "Neda's" from
  *> > 		the title before publication.
  *> 
  *> Having the company name in the RFC title, for nonstandard vendor-proprietary
  *> protocols, has become well-established practice in the past few years.
  *> In recent times IESG has consistently recommended this change to help 
  *> avoid the appearance that the RFC is a standard, and the RFC Editor
  *> has consistently granted these requests.  I strongly recommend that we 
  *> not make an exception in this case and that "Neda's" remain in the title.
  *> 

As I replied to Vern, we must accept this, although I personally think
it is the wrong policy, because of exactly this issue.

  *> > Based on these comments, the IESG might want to prepare a paragraph
  *> > that addresses points 1, 2, and 4.  Thus, it would say that this
  *> > protocol is intended for a specific environment, low-bandwidth wireless
  *> > links, not for general Internet use.  It would also say the usual thing
  *> > about not being a standard, etc.
  *> 
  *> This is what I would have recommended anyway.
  *>  
  *> > Note that these considerations do not ask how good the EMSD/ESRO
  *> > protocol is, or how clearly and precisely it is documented.
  *> > We have formed some (negative) opinions on these issues, but
  *> > these judgments ought not to directly affect the decision on
  *> > whether to publish.  
  *> 
  *> In general, I strongly disagree.  I believe it is important for
  *> the RFC Editor to maintain the quality of the RFC document series,
  *> and that protocol quality, document clarity, and precision are
  *> all important components of this.  The RFC Editor might 
  *> judge that these are adequate in the case of the current document, 
  *> or that other considerations weigh in favor of publication.
  *> However, I don't believe that the RFC Editor should establish a 
  *> policy of ignoring protocol quality, clarity, or precision in making 
  *> decisions about whether to publish.

We absolutely agree!  The comment we made was incomplete; we should
have said something more like, "since this document appears to meet
the minimum standards of seriousness and quality, we believe that
a desire for further improvement should not directly affect...".
We are trying our best to carry on the policies that Jon followed
(but never had to articulate!) for more than 25 years.

  *> 
  *> Keith
  *> 
  *> p.s. I am also disappointed that the RFC Editor has chosen to 
  *> notify the author of the decision to publish, before hearing
  *> a formal recommendation from the IESG.  This makes it appear 
  *> that the RFC Editor is not considering the IESG's recommendation.
  *> Although we did discuss this matter in Orlando, I thought I made
  *> it clear that I had not yet had the time to do a complete review.
  *> If, when doing the review, I found a better reason not to publish
  *> this document, I'd like to think that the RFC Editor would consider 
  *> those recommendations. 
  *> 

We are very sensitive to this issue.  Yet, there is also the issue of
independence, and ultimately I have to feel there is some issue of
timeliness.  We also think that openness is wise.  An author whose
work has caused so much turmoil ought to be aware of the discussions
pro and con.

If the IESG had convincing arguments that EMSD was a clear threat to
the Internet, for example, OF COURSE the RFC Editor would not publish
it.  We are all trying to reach the same goals.  In this case, after
several months of discussions in person and by email, it seemed
unlikely that this would happen.

Indeed, I hope that the IESG will NOT waste much more time on this
issue; it simply is not worth it!

Bob


----- End Included Message -----