Re: Informational RFC-to-bes

[Mohsen BANAN <mohsen@neda.com>]

>>>>> On Fri, 20 Nov 98 10:36:48 PST, rfc-ed@ISI.EDU said:

  rfc-ed> Mohsen,

  rfc-ed> The RFC Editor has received a request from the IESG for extensions on
  rfc-ed> the following documents, which include <draft-rfced-info-banan-00.txt>
  rfc-ed> (see message below).

I don't have too much problem giving IESG some extra
time (say 2 to 4 weeks, but not much more than that)
to prepare an IESG note for inclusion in 
<draft-rfced-info-banan-00.txt>, provided that the
following are recognized and confirmed now:

 1) The procedures and policies that are being
    followed for <draft-rfced-info-banan-00.txt>,
    a Non-IETF, Non Standards Track, Informational
    RFC (to be) are those of RFC-2026 (BCP-9).

 2) The RFC Editor is an independent entity which is
    not sub-ordinate to the IESG, adequately equipped
    with knowledge and experience to determine
    fitness for publication of Non-IETF, Non
    Standards Track documents.

 3) It is the responsibility of the RFC Editor (Not
    the IESG's) to determine suitability for
    publication of <draft-rfced-info-banan-00.txt>
    and publish it in a timely manner.

    [Of course, The RFC Editor can select any other
     additional reviewers. But waiting to be advised
     by the IESG of the suitability is not part of BCP-9.]

 4) The purpose and scope of referral of 
    <draft-rfced-info-banan-00.txt> to IESG 
    is well defined and limited to addressing
    possible conflicts and relationships with work in
    progress in the IETF Working Groups (Section 4.2.3
    RFC-2026).

 5) The EMSD specification was submitted to the RFC
    Editor on 10/23/98, more than a month ago.
    Determination by the RFC Editor for suitability for
    publication of <draft-rfced-info-banan-00.txt>
    according to RFC-2026 is very obvious in my opinion
    because:

     - It is extremely relevant to today's Internet
       activity. 

     - Meets the technical standard for RFCs,
       because in addition to having gone through 
       extensive verification steps, it has already
       been used to produce independent
       interoperable implementations.

     - Meets the editorial standard for RFCs.


   If the RFC Editor for any reason is considering not
   to publish EMSD as an Informational RFC, I request
   that the RFC Editor let me know immediately so that
   I can either correct the problems or persuade the
   RFC Editor of its fitness.


There has already been adequate time to determine
the suitability of publication of this spec.

Since, the RFC Editor has not determined otherwise, 
my understanding is that the purpose of IESG's 
request for an extension is limited to preparation
of the IESG note.

I do have a serious problem with having to wait
months and then be told by the IESG 
(which has already expressed the intent in producing a
competing protocol) that the EMSD protocol should
not be published. That simply amounts to censorship of 
competing ideas.

That would be completely wrong. 


...Mohsen.


  SteveCoya> ----- Begin Included Message -----

  SteveCoya> Date: Fri, 20 Nov 1998 12:18:24 -0500 (Eastern Standard Time)
  SteveCoya> From: Steve Coya <scoya@ietf.org>
  SteveCoya> To: RFC Editor <rfc-ed@ISI.EDU>
  SteveCoya> cc: iesg@ietf.org
  SteveCoya> Subject: Re: Informational RFC-to-bes


  SteveCoya> Joyce and Alegre,

  SteveCoya> The IESG requests extensions on the following documents:

  SteveCoya> o Neda's Efficient Mail Submission and Delivery (EMSD)
  SteveCoya> Protocol Specification Version 1.3 [INFORMATIONAL]
  SteveCoya> <Draft-rfced-info-banan-00.txt>
  SteveCoya> o NFS Version 2 and Version 3 Security Issues and the NFS
  SteveCoya> Protocol's Use of RPCSEC_GSS and Kerberos V5 [INFOPRMATIONAL]
  SteveCoya> <draft-eisler-nfssec-02.txt>
  SteveCoya> o Building Directories from DNS: Experiences from
  SteveCoya> WWWSeeker [INFORMATIONAL]
  SteveCoya> <draft-rfced-info-moats-02.txt>
  SteveCoya> o Hyper Text Caching Protocol (HTCP/0.0)[EXPERIMENTAL]
  SteveCoya> <draft-vixie-htcp-proto-03.txt>
  SteveCoya> o A Method for Transmitting PPP Over Ethernet
  SteveCoya> (PPPOE) [INFORMATIONAL
  SteveCoya> <draft-carrel-info-pppoe-03.txt>
  SteveCoya> o MIME Types for Use with the ISO ILL Protocol [INFORMATIONAL]
  SteveCoya> <draft-needleman-mime-ill-02.txt>


  SteveCoya> The IESG agenda for yesterdays teleconference was too full for any
  SteveCoya> dicussions on the above list of documents. 

  SteveCoya> There is one more IESG teleconference scheduled in December, but as the
  SteveCoya> agenda will probably be overburdened (as is the case after all IETF
  SteveCoya> meetings), we request the extension be through January, 1999.

  SteveCoya> Of course, if the IESG does get the chance to review and discuss these
  SteveCoya> documents, it will. Just trying to be realistic.


  SteveCoya> Steve

  SteveCoya> ----- End Included Message -----