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