On 07/16/11 06:12, Mykyta Yevstifeyev wrote:
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.
I saw the messages. It is very hard to write an analysis on behalf of
someone else - to my mind, the analysis of why the IESG decided what
they did has to be based on information from the IESG; it's impossible
for any outsider, including you and me, to divine what their thought
processes on this matter were.
There's no IETF consensus to be documented here; the analysis and
decision was done by the IESG, and the IESG (as it was composed at that
time) is the body from which the information has to come. All any
outsider (like you and me) can do is to help with the editing.
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:
Now, if someone were to speak for the then-present IESG and say the same
thing, I would make the following comments:
3.4. Analysis
There were a number of reasons which forced IESG to close the IONs
experiment.
Nit: "forced IESG" -> "caused the IESG to decide". There's no forcing
function.
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.
In a protocol, I'd ask for a definition of "quickly". Days, weeks or
months? Examples of documents where "days" is the correct timescale?
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).
I disagree with this statement, obviously. If the IESG thought so, it is
correct to include it.
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.
I believe this is a red herring. However, I can fully believe that the
argument was raised, even though I don't believe it, so if the IESG
indeed thought that, I'm fine with having that documented.
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.
Nit: "it was concluded" -> "the IESG concluded".
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf