Pete,
I generally agree with your changes and consider them important
-- the IESG should be seen in our procedural documents as
evaluating and reflecting the consensus of the IETF, not acting
independently of it.
Of the various places in the document in which "IESG" now
appears, only one of them should, IMO, even be controversial.
It is tied up with what I think is going on in your exchange
with Scott:
--On Tuesday, September 17, 2013 18:10 -0500 Pete Resnick
<presnick@xxxxxxxxxxxxxxxx> wrote:
>>> Section 2:
>...
>>> "the IESG strengthened its review"
>...
>>> The IETF as a whole, through directorate reviews, area
>>> reviews, doctor reviews, *and* IESG reviews, has evolved,
>>> strengthened, ensured, etc., its reviews.
>>>
>> I believe that change would be factually incorrect
>
> Which part of the above do you think is factually incorrect?
The issue here --about which I mostly agree with Scott but still
believe your fix is worth making-- is that the impetus for the
increased and more intense review, including imposing a number
of requirements that go well beyond those of 2026, did not
originate in the community but entirely within the IESG. It
didn't necessarily originate with explicit decisions. In many
cases, it started with an AD taking the position that, unless
certain changes were made or things explained to his (or
occasionally her) satisfaction, the document would rot in the
approval process. Later IESG moves to enable overrides and
clarify conditions for "discuss" positions can be seen as
attempts to remedy those abuses but, by then, it was too late
for Proposed Standard. And, fwiw, those changes originated
within the IESG and were not really subject to a community
consensus process either.
However, because the document will be read externally, I prefer
that it be "IETF" in all of the places you identify. If we have
to hold our noses and claim that the community authorized the
IESG actions by failing to appeal or to recall the entire IESG,
that would be true if unfortunate. I would not like to see
anything in this document that appears to authorize IESG actions
or process changes in the future that are not clearly authorized
by community consensus regardless of how we interpret what
happened in the past.
john