Mykyta, I think the draft is fine without this addition, which contains some statements that I disagree with. I don't think analysis is needed; this all ancient history anyway.
Regards Brian On 2011-07-13 04:50, Mykyta Yevstifeyev wrote: > 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@ietf.org > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
