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