On Thu, Jun 29, 2023 at 4:02 AM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
On 6/28/23 17:52, Michael Thomas wrote:
Adam’s ballot goes on to note that, "I see that there is nevertheless "strong consensus" to publish the document”. This gets to the heart of the matter: it’s not in the IESG’s remit to substitute their preferences for IETF consensus, which is what I take Adam to be ruefully acknowledging. For similar reasons, to your earlier,
Strong consensus shouldn't be a reason to relent. I mean, why have the IESG review it at all if a discuss can be overridden by "strong consensus". When I brought this up in the wg way back then (ie, ~2013), it sort of reminded me of an echo chamber which happens to some wg's from time to time -- it wasn't just the main author raining fire on me. I've always thought of the IESG as sort of a backstop for when that happens along with its function of tightening things up. I guess it also begs the question of why it was allowed into their charter in the first place.It absolutely is the IESG's job to push back on documents of poor technical quality even when there is "strong consensus". Or to put it differently, the criteria for Proposed Standard are not merely "rough consensus" but also "no known technical omissions". To qualify for Proposed Standard status, both criteria need to be met.
I agree that the IESG's job is to Push_Back the ready_AD_adopted_Draft even if there is consensus power,
but IMO the problem mostly is the IETF's procedure not IESG_job_execution, because part of IESG which is one AD is adopting that draft), so it can make it more difficult to Push_Back than to accept by other ADs. However, that procedure makes it quick to process work (less process_delay), which should be used for some proposed_drafts not all/BCP.
Any decision making body/individual within IETF (especially IESG) needs to have complete balance in power for accepting or denying but IMO IESG's procedure is not helping that balance in decision quality.
AB
