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

[Harald Alvestrand <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf