I mostly agree with this draft, but I have a concern. Let's anchor that concern off of this bit that Jari said: > Secondly, the other obvious action we could take is to go back to the original > mode of operation, i.e., making PS RFCs truly early and somewhat untested > specifications. I am personally opposed to that on the following grounds. First, > it would not change the fact that a large part of Internet technology today runs > on PS RFCs, and Olaf's problem with getting these RFCs recognised would > continue. Second, while I think we need to keep adjusting the level of review > performed by the IESG and in IETF Last Call (we sometimes overdo it), I think > broad review is actually useful. It's certainly clear to all of us that most PS specs are far more mature than what we thought about when we wrote RFC 2026. The only concern I have is that once we do this -- declare that PS is always more mature than that -- we can't go back. Do we *really* want to say that we will never again approve a PS spec that's partially baked? This is painting us into the room where PS is mature and robust. If we like being in that room, that's fine. But it removes the "IESG can put fuzzy stuff out as PS if it thinks that's the right thing to do" option. It says that IETF PS specs are "at least as mature as final standards from other" SDOs. Mostly, that's true. But it doesn't have to be. After this, it would have to be, always, for every PS spec. Are we *sure* that's what we want? Barry