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

[Brian E Carpenter <[e-mail]>]

John,

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