Pete, you are quite correct that:
(1) The current IESG statement is, at best, somewhat incoherent.
(2) IESG authority for doing this seems to be lacking.
I nevertheless support progressing 2821bis with the note. Why? Two reasons.
First and foremost, I want this sucker published. 2821 is a vital document and
this is an important revision.
Second - and this may seem a bit perverse - I actually welcome the opportunity
to document for posterity what I see as a hamfisted blunder by the IESG.
I have long been skeptical of the true efficacy of several aspects of our
various processes. In particular, I have often wondered to what extent we allow
the best to be the enemy of the good. I have seen many cases where the amount
of effort involved in addressing issues raised by the IESG - especially these
sorts of late surprises - is clearly grossly disprportionate to the criticality
of the issue itself. And while the present case is an extreme example, I think
as the complexity of specifications increases and the abillity of generalists
to assess them diminishes this is becoming more and more of a problem.
Getting real metrics on any of this is difficult, mostly because of our own
adaptability. Many times I've seen a specification changed solely because it
was easier to do that in order to make some silly DISCUSS comment go away than
to argue about it. And in a lot of those cases changes were done to WG
documents by private agreement between the document authors, WG chairs, and the
IESG. (This last is pretty clearly an accident waiting to happen.)
But what if the IESG were required to document their assessment of a document
in such notes? If they did after a few years I'm pretty sure we'd look back in
amazement at how often we focused on the irrelevant (and no doubt how we also
managed to miss the really relevant).
Of course this isn't going to happen. But if in this one case we have such a
note to look back on maybe, just maybe, it will knock some tiny bit of sense
into our collected damnfool heads a few years from now.
Ned