>> 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?) That's a good point; probably yes. So if the text here can say something that allows a PS spec to *say* that it's less mature, and that that's being done on purpose, my concern is satisfied. >> 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. As a specific current example, I have the sense that the documents coming out of the repute working group are specifying a protocol that's somewhat less mature than what we usually do -- more comparable to the 2026 version of PS than to this one. Yet I absolutely think they should be PS, *not* Experimental. Barry