Barry, Question, in-line. On Sep 3, 2013, at 10:40 PM, Barry Leiba <barryleiba@xxxxxxxxxxxx> wrote: > 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. > Wouldn't such spec come with an applicability statement of sorts? (today, in practice?) > 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? This draft is mostly targeted to document what we do, not what we want. Although I can see how you want to keep the door open. --Olaf.