Re: PS Characterization Clarified

[Barry Leiba <[e-mail]>]

>> 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