John,
John C Klensin wrote:
--On Thursday, 18 May, 2006 17:16 -0400 The IESG
<iesg-secretary@xxxxxxxx> wrote:
The IESG has received a request from an individual submitter
to consider the following document:
- 'IETF Process and Operations Documentss '
<draft-alvestrand-ipod-01.txt> as an Experimental RFC
This is a proposed process experiment under RFC 3933.
The IESG plans to make a decision in the next few weeks, and
solicits final comments on this action. Please send any
comments to the iesg@xxxxxxxx or ietf@xxxxxxxx mailing lists
by 2006-06-15.
Hi.
I think this idea is generally a good one. It seems to me to
be quite desirable to bring all IETF procedural materials and
notes into a single series and to decouple the publication of
those materials from the RFC Editing process: the documents are
not archival and should not delay, or be delayed by, technical
specifications.
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).
(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.
(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. 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's clear to me that this experiment will only succeed
if it is run in a lightweight manner. By that I mean using
procedures like a formal last call, and an approval process other
than "silence means consent", only when things are contentious.
I don't see the IESG responsibility being any different from
what happens today when, for example, 1id-guidelines gets
updated, or when an IESG Statement is issued.
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.
Recently the IESG has chosen to interpret the right of appeal
broadly, even though the text in RFC 2026 is unclear about scope.
I don't see how we could refuse to consider an appeal about an
ION, although I'd hope that we could normally resolve issues
without the need for it.
Brian
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.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf