Hello Harald,
As you could see in one of my previous messages, I did intend to include
some analysis in the draft
(http://www.ietf.org/mail-archive/web/ietf/current/msg67491.html).
However, numerous responses which discouraged me from doing this were
received, and including that section will create problems with
consensus. However, I share your opinion that the document won't be
full, so I think the following analysis section, which is different from
the previous proposed one, can satisfy you and everybody else:
3.4. Analysis
There were a number of reasons which forced IESG to close the IONs
experiment. One of them is a complexity of their approval and
publication, compared with ones for IESG Statements and simple Web
Pages. As IONs were intended to represent operational experience,
they might have needed to be updated quickly. Even though these
documents were meant to have a very lightweight approval procedure,
it could sometimes be inappropriate for that material which was
contained therein.
Secondly, due to the nature of the scope of IONs, there was no need
to allow the access to the revision history (which is unavailable in
simple Web Pages as well).
Thirdly, IONs on procedural question could step into the conflict
with Best Current Practice (BCP) RFCs; moreover, as IONs approval
procedure did not imply any formal community review, unlike BCPs,
they could easily fall in the community non-acceptance.
Correspondingly, it was concluded that the mandate of IONs can fully
be fulfilled by RFCs, when documenting IETF procedures, IESG
Statements, when clearing up other issues for which RFC publication
process is not appropriate, and Web Pages, when dealing with other
IETF-related issues.
Please see other response in-line.
15.07.2011 18:18, Harald Alvestrand wrote:
My apologies for the lateness of this review.
I am not happy with this document.
I was unhappy with the IESG's decision to close the ION experiment,
since I believe the mechanisms that were chosen to replace it failed
to fulfil several of the requirements that were driving forces in the
design of the ION mechanism (as an example, try to find out who, if
anyone, approved http://iaoc.ietf.org/network_requirements.html, what
the previous version was, and when this version was approved).
The document does not refer back to the aims of the experiment, which
I tried to make explicit in section 5 of RFC 4693, which include:
- Easy updating
- Explicit approval
- Accessible history
It's very easy to add. I think the 2nd paragraph of the Section 2 may
be changed to:
IONs were meant to be easily updated but to have some explicit IESG
approval mechanism; IESG might also have granted the approval right
to other parties. The strict format rules for RFCs were not applied
to IONs. Moreover, the history of revisions was intended to be
easily accessed. For more background information on IONs, please see
Section 5 of RFC 4693 [RFC4693] .
The sum total of analysis in this document is two sentences:
See above.
The cited IESG statement
[ . . . ]
Harald
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf