Re: Publication of EMSD as an Informational RFC

[Robert Moskowitz <rgm@htt-consult.com>]

At 01:10 PM 12/18/98 +0000, Brian E Carpenter wrote:

Did you catch this guy's rant on IETF that the IETF needs to take control
of the RFC process becuase anyone can 'no longer' publish?

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