Subject: Re: Last Call: 'IETF Process and Operations Documentss' to Experimental RFC (draft-alvestrand-ipod)

From: John C Klensin <[email-masked]>
Date: Fri, 19 May 2006 08:16:40 -0400

--On Thursday, 18 May, 2006 17:16 -0400 The IESG
<[email-masked]> 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 [email-masked] or [email-masked] 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 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.
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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 21 May 2006 21:35:25 +0200

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.

>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....

>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.

>the IESG's decisions about details are subject to appeal.
>
Yes, that's exactly my intention.

>  But
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.

>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

---

From: John C Klensin <[email-masked]>
Date: Sun, 21 May 2006 17:39:06 -0400

> 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.

>...

>> 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.

>> 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.
>> 
>...
 
     john