--On Sunday, 21 May, 2006 21:35 +0200 Harald Alvestrand
<harald(_at_)alvestrand(_dot_)no> wrote:
Good to see some debate on this!
I'm not sure this qualifies as "debate". As I hope was clear
from my earlier note, I think we should move ahead with this.
My concern was only that we be clear about how some aspects of
the work were to be carried out and by whom. And the document
is, in effect, somewhat different if the IESG is willing to take
on some of the decision-making that both of us desire or if
they are not.
...
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....
Yes. I think that a statement would be useful that indicated
that part of the experiment is to note that categories will
probably be needed and to figure out, late in the process, what
categories ought to be created. But I don't consider its
absence to be a showstopper.
(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.
I think that is fine. I also think that my concern about clear
identification of version could be served by making ION
NNN-YYYYMMDD as the identifier, rather than ION NNN alone.
These are, again, not big deals but someone --either the
document or the IESG-- need to be responsible for making sure
that something reasonable happens.
(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.
...
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf