I've recently been through several chartering efforts and was quite surprised by the amount of effort ADs now put into getting the charters sorted out, and correct. It is very much appreciated but I do suspect one consequence of this is that we're producing extremely high-quality charters but the working group process and product is actually not much improved. That is to say, IESG time and attention are scarce and extremely valuable and I suspect that putting this much effort into charters is not an optimal allocation of these scarce resources, in the sense that it's consuming more calories but doesn't appear to be leading to better outcomes. I'm very interested in what Lars is doing in the IRTF (letting efforts go forward but waiting a year to charter, to see if the group is successful in identifying a problem and appears to be capable of addressing that problem) but given that it depends on the ability to say "no" to work already underway it seems unlikely to be successful in an IETF where underperforming working group chairs aren't fired and where it's nearly impossible to shut down even a working group that's bound and determined to fail. So, that doesn't seem to be an approach that's likely to translate well to the broader IETF. It also seems to me that the proliferation of the problem statement/architecture/requirements/gap analysis pattern is a problem. You wouldn't think that now that we're producing tightly-focused, high-quality working group charters and that in some cases it's taking several years to charter a new working group we'd need problem statement documents, but we're getting them anyway. It's not that we never need a problem statement document, or an architecture, or a separate requirements draft, or a gap analysis, but we certainly don't need them nearly as often as we're getting them, and I think they represent a significant part of the problem with getting work done in a timely way. I think we'd be well-served by a little more caution about committing to those sorts of documents. To be honest I think the core problem is that we've seen a massive influx of participants whose job is to produce standards - that's what they do. So they're being incentivized to write lots and lots and lots and lots and lots of internet drafts and to push very hard on chartering new working groups. And as has been noted quite often before, the increased IESG workload has tended to limit the candidate pool for AD positions to those who can work full-time on standards, which is a very, very bad thing, both because it's going to tend to exclude very qualified people whose main job is not standards but also because it means that the people who are selected are going to tend to be have a more positive attitude (or at least be less unhappy with) the IETF's gradual transformation into a more conventional standards body. The IETF structure and processes are largely based on how they were during a time when the focus was on producing useful things. I do think we need to adapt to the new reality, although I don't know what that means in practice. Personally, I'd like to see working group efforts tied more closely to implementation even though that won't solve the bigger problems around participant incentives (although wouldn't it be *great* to have more implementers involved?) and the proliferation of unhelpful and occasionally windbaggy documents. But, as John Chambers likes to say, we need to live in the world as it is, not as we'd like it to be. Melinda