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

[John C Klensin <john-ietf at jck.com>]

--On Monday, 12 June, 2006 12:02 +0200 Brian E Carpenter
<brc at zurich.ibm.com> wrote:

> John,
> 
> John C Klensin wrote:
>> 
>> --On Thursday, 18 May, 2006 17:16 -0400 The IESG
>> <iesg-secretary at ietf.org> 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 at ietf.org or ietf at ietf.org 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:
>>...
>> (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.

I agree, modulo a comment that has been made elsewhere: in
general, anything that requires Last Call now and formal
publication now, such as a significant change in procedures,
requires that same level of processing under this model.   In
other words, this is a way to collect documents together in a
coherent way, not a way to permit IESG to make major procedural
changes --changes it cannot make today-- on its own initiative.

Much as I like the general ideas behind this document, if the
above restriction is not clear to all concerned, I'd need to
oppose this particular proposal.

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

I would hope we could normally resolve all issues by informal
discussion rather than appeals.  History indicates that
sometimes we cannot.

     john


_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf