Re: Publication of EMSD as an Informational RFC

[Brian E Carpenter <brian@hursley.ibm.com>]

Hi,

As you know, the IESG has serious doubts whether this document is
suitable for RFC publication, and the RFC Editor has chosen to
consult the IESG in this matter. There it stands for the moment.

I would also like to point out that there is *no* automatic right
to RFC publication. 

  Brian Carpenter
  IAB Chair

Mohsen BANAN wrote:
> 
> More than 7 weeks ago, on October 23, 1998 I submitted
> a protocol specification titled:
> 
>         Efficient Mail Submission and Delivery (EMSD) Protocol
> 
>    ftp://ftp.ietf.org/internet-drafts/draft-rfced-info-banan-00.txt
> 
> to the RFC-Editor for timely publication as an
> Informational RFC.
> 
> As of now, more than 7 weeks since the initial
> submission, the specification has not been published
> yet. The RFC Editor has not even responded to my request
> for providing a time frame in which we can expect to see
> the EMSD protocol published as an Informational RFC.
> 
> Such seemingly unjustified and unexplained delays by the
> RFC Editor are completely unacceptable.
> 
> It is the responsibility of the RFC Editor to determine
> the suitability of non-ietf non-standards track
> documents in a *timely* manner.
> 
> The RFC Editor has had more than adequate time to review
> the EMSD specification and convey to us any concerns
> with respect to suitability for publication. The RFC
> Editor has expressed none.  In the case of EMSD protocol
> for the reasons that I have enumerated before, the
> suitability of the specification is obvious.
> 
> Yet, as it was the case with the publication of
> RFC-2188, the RFC Editor seems to have again simply
> stopped progress towards publication and is awaiting
> instructions from the IESG.
> 
> If indeed that is again the case, then something is
> terribly wrong.
> 
> The last response we received from the RFC Editor was:
> 
> >>>>> On Tue, 24 Nov 98 12:39:40 PST, rfc-ed@ISI.EDU said:
> 
>   RFC-Editor> Thank you for your additional message.  Since it is important to obtain
>   RFC-Editor> the IESG's feedback, we have noted their deferred request.  We defer
>   RFC-Editor> making a decision until the IESG has had a chance to comment.  We would
>   RFC-Editor> be happy to chat further about this in Orlando.
> 
> As I have said before, the IESG has had more than an
> adequate chance to comment on this specification.
> 
> The initial two week timeout expired on November 17,
> 1998. Since then, the IESG has had an additional 4 weeks
> to comment.
> 
> Further as the RFC Editor must know, according to
> Sections 4.2.2 and 4.2.3 of RFC-2026, the purpose and
> scope of the IESG review is well defined and limited to
> identification of over lap and conflict between EMSD and
> the work of IETF groups. Such a determination by the
> IESG must be done within a reasonable period of time
> (Section 4.2.3).  Such a determination can be done very
> quickly.
> 
> Furthermore, some IESG members have already said that
> they want to produce protocols that compete with
> EMSD. Therefore, the IESG appears to have the incentive
> of delaying publication of EMSD as an Informational
> RFC. It has also already been publicly stated that from
> the IESG's perspective review of non IETF working group
> documents (such as EMSD) are of a low priority to IESG.
> 
> In view of the above, an independent and strong RFC
> Editor is expected to prevent the IESG from delaying
> publication of non-IETF non-standards track documents.
> However, as it was the case with the publication of
> RFC-2188, the RFC Editor appears to be simply awaiting
> orders and instructions from the IESG.
> 
> If in fact the RFC Editor is not adequately equipped
> with knowledge and experience to do what the procedures
> of RFC-2026 demands of the RFC Editor, then please let
> that be known.
> 
> If in fact the RFC Editor is only providing the
> equivalent of secretarial services to IESG/IETF and the
> real decision in publication of non-IETF non-standards
> track documents is made by the IESG, then please let
> that be known.
> 
> The key questions here are the same ones that I asked
> nearly 2 years ago with respect to the publication of
> RFC-2188.
> 
>   o What do "reasonable period of time" and "timely"
>     mean to the RFC Editor and the IESG?
> 
>   o What does the IESG and the RFC Editor think the
>     scope and purpose of IESG review of the non IETF
>     non standard track RFCs are?
> 
>   o What is the RFC Editor expected to do when the IESG
>     does not review the document in a reasonable period
>     of time?
> 
> These questions remain unanswered.
> 
> I consider anything more than 7 weeks, *not timely*.
> 
> Related to my complaint about the publication of
> RFC-2188,
> 
> >>>>> On Sun, 8 Nov 1998 10:22:21 -0800, "Marshall Rose"
>  >>>>> <mrose.netnews@lists.dbc.mtview.ca.us> said:
> 
>   Marshall> 2. ... however, the fault i assign to the "power
>   Marshall> conspiracy" in the IETF is simple: they should have told you "yes" or "no"
>   Marshall> sooner, like within 6 weeks. if they'd said "no", well, you'd have a
>   Marshall> different complaint, but it wouldn't be for lack of timeliness.
> 
>   Marshall> 3. publication of rfcs is upto the rfc editor, with the caveat that on
>   Marshall> matters that deal with ongoing on near-term IETF standardization matters,
>   Marshall> the IESG gets to advise. ...
> 
> others suggested 6 weeks as a reasonable time.
> 
> Publication of the EMSD Protocol is in the best interest
> of the Internet technical community for reasons which
> include:
> 
>   - Protocols specifically designed for submission and
>     final delivery of mail are needed in today's
>     Internet mail environment. EMSD is one such protocol
>     which can work with and also compete with other such
>     protocols. Wide publication of such a protocol is a
>     good thing.
> 
>   - Protocols which focus on "Efficiency" of Mail
>     Submission and Delivery  in the wireless
>     environment are needed.  Two-Way Paging over
>     Wireless-IP is a natural and expected evolution
>     of paging networks. EMSD can serve as a basis for
>     Two-Way Paging over Wireless-IP.
> 
>     Existing Internet protocols do not deal with
>     efficiency properly. Wide publication of an application
>     protocol which emphasizes efficiency is a
>     good thing.
> 
>   - Examples of application protocols which use
>     Efficient Short Remote Operations (ESRO) --
>     which has already been published as RFC-2188 -- are
>     of use to those interested in using ESRO. EMSD is
>     one such application of ESRO.
> 
>   - EMSD protocol specification has been verified in a
>     number of ways.  EMSD and ESRO
>     specifications under the titles of:
>         "Limited Size Messaging" (used with the CDPD Network)
>     and
>         "pACT" (used with AT&T's Narrowband PCS Network)
> 
>     have gone through a great deal of review by a large
>     number of engineers.
> 
>  - Independent implementations based on earlier releases of
>    EMSD and ESRO specifications have been made by
>    Neda (server and client), PCSI (client), Aldiscon
>    (server), Sema Group UK (server). The independent
>    implementations have interoperated successfully.
> 
>   - The rationale for design decisions of EMSD are
>     documented in Appendix C of the spec. Whether or not
>     these are "good" or "bad" design decisions are mostly
>     a matter of opinion at this time. Test of time and
>     usage will decide that. EMSD spec will server as a
>     point of record and a point of reference for that
>     purpose.
> 
> Since publication of the EMSD Protocol is in the best
> interest of the Internet technical community and since
> it is the responsibility of the RFC Editor to publish
> such information, I expect that the RFC Editor will not
> allow further delays and censorship of the EMSD
> specification.
> 
> Having waited 7 weeks since the initial submission of
> the EMSD specification, I respectfully request that the
> RFC Editor publish the EMSD Protocol as an Informational
> RFC without any further delays.
> 
> Respectfully Yours,
> 
> Mohsen Banan.