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

--On Sunday, 21 May, 2006 21:35 +0200 Harald Alvestrand
<harald@alvestrand.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@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf