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