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