From RFC 2026
" At all stages of the appeals process, the individuals or bodies
responsible for making the decisions have the discretion to define
the specific procedures they will follow in the process of making
their decision."
Suggest that before anyone suggests modifying process they consider
the fact that the reason we have an appeals process is to be able to
obtain insurance. There are good reasons to tie the IESG hands at
certain points in the process.
Endless DISCUSS is not permitted by RFC 2026: The IESG is required to
deliver a timely decision. If one IESG member was using DISCUSS as a
filibuster the process document makes clear that it is the IESG rules
that have to bend to meet the requirements of the process document.
On Thu, Mar 11, 2010 at 5:18 PM, Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com> wrote:
I agree with Sam, for cases which would otherwise result in an
endless DISCUSS - although normally I'd expect the argument
to be complex enough that a separate RFC would be needed to
explain the dissent.
Brian
On 2010-03-12 09:58, Sam Hartman wrote:
"Andrew" == Andrew Sullivan <ajs(_at_)shinkuro(_dot_)com> writes:
Andrew> On Fri, Mar 12, 2010 at 09:02:53AM +1300, Brian E Carpenter
wrote:
>> That seems to cover most angles. I can't see why the IESG could
>> be expected to add technical disclaimers to a consensus
>> document. In fact, doing so would probably be a process violation
>> in itself.
Andrew> Well, ok, and yes it probably would be a violation. But to
Andrew> defend the appelant, there might be a serious (though in my
Andrew> view totally wrong) point in the appeal.
For what it's worth, I think it is entirely reasonable for the IESG to
add text raising technical concerns to a consensus document. The IESG
note, unlike the rest of the document reflects IESG consensus, even in
cases where the document is intended to reflect IETF consensus.
Here's a case where I think it would be entirely appropriate for the
IESG to do so. The current process--both internal IESG procedure and
RFC 2026 requires some level of agreement from the IESG to publish a
document. If we had a case where it was clear that there was strong
community support for something that the IESG had serious concerns
about, I think it would be far bettor for the IESG to include its
concerns in an IESG note than to trigger a governance problem by
declining the document. Another option also open to the IESG would be
to write up its concerns in an informational document published later.
Without knowledge of specifics I cannot comment on which I'd favor.
I have not read the current appeal and doubt that adding an IESG note is
the right solution to an appeal on technical grounds about a consensus
document. I simply don't want a legitimate case where adding an IESG
note to come up years later and people dig through this discussion and
find no objections to the claim that adding such a note would be a
process violation.
--Sam
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
--
--
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf