Re: Last Call: <draft-yevstifeyev-ion-report-06.txt> (Report on the Experiment with IETF Operational Notes (IONs)) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

As Russ agreed to sponsor this document on I-D submission cut-off date, I did make only some minor changed proposed by him during AD evaluation. However I thought the document would be incomplete without analysis, so after LC I propose to add the following sub-section in the draft:

3.4. Analysis and Results

   IONs were intended to serve as a means to document issues related to
   procedures used by IETF or other parties, but to be more stable as a
   simple web page and to have a more lightweight procedures for
   approval than Best Current Practice (BCP) or other sort of RFC.  Even
   though such middle-ground approach might be quite useful, it also
   brings a number of complexities and negative effects, which are
   described below.

   First of all, IONs were mainly scoped to IETF procedural questions.
   A number of IONs were published defining procedures used by IETF
   community, such as ion-ad-sponsoring.  However, it should be noted
   that the formal procedure of IONs approval, laid out in RFC 4693
   [RFC4693] did not imply community involvement, unlike one for BCP or
   other IETF Stream RFC.  Even though RFC 4693 intended IONs to cover
   issues not sufficient for documenting in BCP, this regulation was
   often overlooked.  This might have resulted in community non-
   acceptance of such procedures, partial or full, if IONs were adopted
   on the persistent basis.

   Moreover, as IONs were lower in the hierarchy of IETF documents that
   RFCs, published RFCs may override what mentioned in a particular ION
   (whereas a published RFC may change already established procedures),
   which might result in them not being sufficiently followed, creating
   documentation conflicts.

   Several IONS were published that describe the procedures used by IESG
   or its members internally, such as ion-discuss-criteria or ion-tsv-
   alt-cc.  Such material is obviously more appropriate for publication
   as IESG Statements, which are also meant to be quite stable when
   published and are approved at IESG's discretion.

   A number of IONs were published covering different IAOC issues.  Such
   IONs included ion-execd-tasks and ion-subpoena.  However, even though
   IAOC works tightly with IETF, they have an ability to publish such
   material on their site - <http://iaoc.ietf.org/>.

   A one ION - ion-procdocs - was a reference guide to the IWTF Process
   documents.  An other ION - ion-2026-practice - provided the criticism
      and operational experience on RFC 2026 [RFC2026].  Both this
   documents are fine as web pages, since the material contained in it
   might change quickly and often.

   ion-ion-format and ion-ion-store were published for the purpose of
   the IONs series itself and were discarded upon experiment closure.
   They are not analyzed here.

   The aforementioned facts claim that IONs were less useful than the
   equivalent information published in other way, and should be
   abandoned, as proposed by Section 4 of RFC 4693 [RFC4693].

In order not to request the 2nd LC after this text is included, I'd like to seek community feedback on it during this Last Call.

Thanks,
Mykyta Yevstifeyev

12.07.2011 17:39, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Report on the Experiment with IETF Operational Notes (IONs)'
   <draft-yevstifeyev-ion-report-06.txt>  as an Informational RFC

[ . . . ]

_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]