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

[braden@ISI.EDU]

Vern,

I wrote:

  *> 
  *> > 	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.
  *> 

and you wrote:

  *> Your last paragraph puzzles me.  The usual argument has been to explicitly
  *> include vendor names in these sorts of Informational RFCs, precisely to
  *> deflect "the appearance of IETF concurrence".  That is, rather than the
  *> title being "Protocol for Web Caching" we've used "Big Conglomerate's Protocol
  *> for Web Caching".  This way it's clear from the title that this is something
  *> from Big Conglomerate and not *the* IETF protocol for Web caching.  Are you
  *> saying you think the current approach is backwards from how it should be?
  *> That the title of his Informational should just be "Efficient Mail Submission
  *> and Delivery (EMSD) Protocol Specification Version 1.3"?
  *> 

Well, yes, that was what I was saying, and what I believe.  However, I
was not previously aware of the IESG position on this matter, and my
opinion appears to be in the minority on this issue.  In any case it
seems clear that the IESG position should rule here, so disregard
my earlier paragraph.

  *> > 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.
  *> 
  *> So if a document that is technically weak and poorly documented is submitted
  *> for publication as Informational, what is the policy mechanism for weeding
  *> it out?  Or will those considerations not be directly included in the
  *> decision to publish?
  *> 

"Technically weak and poorly documented" are relative terms.  I have
seen a number of standards track RFCs that I long to tear into with an
text editor.

While I may agree with some of Keith's judgments (though perhaps not
quite so fiercely), Mr. Banan obviously does not.  If leaving the RFC
Editor some discretion on publication of Informational RFCs is to have
any meaning, it is presumably to allow publication of less-than-ideal
stuff that still has some redeeming technical value.

The policy that is in place is for the RFC Editor to make a judgment on
whether a document is frivolous or not, and whether it is so clearly
brain-dead that it does not deserve publication.  In making this
judgment, we consult with the IESG and perhaps with other experts
in the field.  In this case, we have done both.

Then comes a judgment call.  It appears to us that the EMSD document is
neither frivolous nor brain-dead.  After a great deal of time and
angst, we are trying to do the right thing.

The current policy mechanism can remain in place only as long as the
IESG and the Internet community have sufficient faith in the judgers.
I can only remark that it would be an terrible historical irony if Mr.
Banan managed, single-handedly, with "X.400-meets-ASN.1", to make Jon's
RFC process come finally and completely unglued.

Bob

  *> 		Vern
  *>