2. IESG's scaling problems are a direct result of low-quality output from working groups, and we can't do much to address that problem by changing how IESG works.
I agree and disagree. We have rather a history of ADs sitting on documents and of ADs micromanaging working groups (not every AD and not every case, but enough of both that it has been something the IESG has actively had to address) that chairs feel un-empowered. This is in part what the "shepherding" thing is intended to address - widen the review, close loops, keep things out of cracks, etc. So changing the way the IESG works is in fact part of making the WG responsible for its output.
IESG appears to rule by edict because WGs demand that IESG provide them with very concrete feedback. Simply saying "you failed to provide security" or "you failed to address the concerns of this other group that you'll harm their interoperability" doesn't work - either the WG will balk or they'll sit on the document for months not being willing to fix the problems.
As stated, this sounds adversarial. While there have been adversarial relations with some WGs, I don't think that generalizes. In many cases where I have delayed updating a draft, it was because it wasn't clear to me what was being asked for, or there was no tickler that told me that the comments had been posted. "You failed to provide security" is, if you think about it, a pretty content-free statement. A better statement would be "I believe that this is open to a man-in-the-middle attack of this type" or "I don't see your threat analysis in the document".
Frankly, apart from a special cases, I think ADs sound like they are ruling by edict because they get a little frustrated saying the same thing a zillion times. The classic, which you noted earlier, is security. We have been trying to convince people to think about it for about 15 years now, and it is really only now that people are seriously considering taking other people to court for an egregious lack of thought on the topic that it is becoming an issue protocol developers think about. My issue with "security considerations" has always been that I personally am not a security expert, and dunning me for being open to this attack or that without informing me that the attack exists mostly feels to me like an attack.
You may remember an older version of the id-nits document in which I pulled a digest of common attacks (pulled from someone's doctoral thesis that I found on the net) and asked bluntly "have you asked yourself whether your protocol is vulnerable to ..."? I put that up because, frankly, several of those attacks were news to me. I notice that the current id-nits removes that set of questions; I think the net result is that people will not ask themselves about obscure forms of attack. But I think that approach is better than saying "you didn't do an adequate threat analysis"; tell people how to do a good one and what questions they are likely to need to answer.
ADs like nothing better than to be presented with well-written, focused documents from groups that have obviously done their background work and given it appropriate consideration in their designs.
Absolutely true.
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf