--On Monday, 12 June, 2006 12:02 +0200 Brian E Carpenter
<brc@xxxxxxxxxxxxxx> wrote:
> John,
>
> John C Klensin wrote:
>>
>> --On Thursday, 18 May, 2006 17:16 -0400 The IESG
>> <iesg-secretary@xxxxxxxx> 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@xxxxxxxx or ietf@xxxxxxxx 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf