>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.e.carpenter@xxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf