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