Good to see some debate on this!
As author, I should try to indicate where I come from in my thinking....
but it's up to the IESG to judge whether this could be an useful
experiment to run, and up to those who run the experiment to determine
the details as they go along. That's by design.
John C Klensin wrote:
I have three concerns:
(1) The various documents that will (or might - see (3) below)
be included in this series have wildly different status, from
firm and requirements to casual advice. It seems to me that an
important property of the document series is that the status of
any given document be made very clear. Since these documents
seem much closer to "living" than the archival RFCs, probably
that information should be in-line. But the I-D doesn't
specify that information or its inclusion (again, see (3) below).
Yep - my thinking was that it was impossible to specify before the
experiment started what the possible useful classes of status would be,
so I left it open. And since I can't even name them, I thought that
putting in instructions on how to classify status was rather hard.
I think that if we have 20 active IONs at the end of the experiment, we
can think about a set of classes then. If we have none, the experiment
is a failure, so we don't need any....
(2) It seems to me that the versioning and threading of these
documents should be clear, with earlier versions obtainable from
some source (not necessarily maintained in the same way as the
current versions) and clear ways to identify which versions were
in effect at which times, when new versions go into effect, etc.
The text of the I-D clearly allows for this, but does so in a
way that would permit interpretations that would not preserve
these properties. See below.
Versioning is clear, I think - threading is not, because I think we've
proved in the RFC series that we don't know how to make threading with
general branch/merge permitted work. (quick - trace the descendant tree
of RFC 1766....)
The intent of the text is that all the "current" versions of IONs are in
effect at the time they're approved, and remain in effect until
superseded, but that some of them will be documents that say "This
document has no active content" (an end-of-life marker for a name). If
that can be better stated, please send text.
(3) The document is written on a model that I would describe as
"here are the principles, the IESG should sort out the details".
Personally, I think that is the right model, at least as long as
the IESG's decisions about details are subject to appeal.
Yes, that's exactly my intention.
But
some of the members of previous IESGs have expressed concerns
that making similar decisions would add to their workload or
that documents were not acceptable unless they contained much
more specific detail.
To permit the community to evaluate this Last Call, it seems to
be to be critical to know whether the IESG is willing to take on
that responsibility. It would also be helpful to know whether
the IESG will consider these documents, especially the ones that
define the parameters of the series, to be subject to the usual
appeal procedures when they are adopted and published.
The document says:
A decision by any other body than the IESG to publish an ION can be
appealed to the IESG, in which case the IESG can nullify the
approval. A decision of the IESG can be appealed using the common
IETF appeals procedure, except that an IESG decision to nullify an
IAB decision to publish an ION cannot be appealed to the IAB.
Of course, the IESG hasn't approved that yet.
Without those assurances, I would have many comments on details
that should be specified in the I-D before it is used to
initiate an experiment (and assume some others might too). With
them, I am happy to see this go forward on an experimental basis.
I'd be happy to hear our esteemed IESG members speak, too; Brian says he
likes it, but I haven't heard much from others.
Harald
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf