I agree with Sam that it might be a sensible modification of the existing process.
However, it is irrelevant to the current discussion since the IESG is not at current permitted to make such a statement. The main argument against modification might well be the very fact that it would allow appeals of this type. On Thu, Mar 11, 2010 at 5:18 PM, Brian E Carpenter < brian.e.carpen...@gmail.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 <a...@shinkuro.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@ietf.org > > https://www.ietf.org/mailman/listinfo/ietf > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
