Re: PS Characterization Clarified

[John C Klensin <[e-mail]>]

--On Monday, September 16, 2013 10:43 -0400 Barry Leiba
<[e-mail]> wrote:

>...
> I agree that we're normally requiring much more of PS
> documents than we used to, and that it's good that we document
> that and let external organizations know.  At the same time,
> we are sometimes proposing things that we know not to be fully
> baked (some of these came out of the sieve, imapext, and morg
> working groups, for example), but we *do* want to propose them
> as standards, not make them Experimental.  I want to be sure
> we have a way to continue to do that.  The text Olaf proposes
> is, I think, acceptable for that.

In case it wasn't clear, I have no problems with that at all.  I
was objecting to three things that Olaf's newer text has fixed:

(1) It is a very strong assertion to say that the above is
"exceptional".  In particular, "exceptional" would normally
imply a different or supplemental approval process to make the
exception.  If all that is intended is to say that we don't do
it very often, then "commonly" (Olaf's term), "usually", or
perhaps even "normally" are better terms.

(2) While it actually may be the common practice, I have
difficulty with anything that reinforces the notion that the
IESG makes standardization decisions separate from IETF
consensus.  While it isn't current practice either, I believe
that, were the IESG to actually do that in an area of
significance, it would call for appeals and/or recalls.   Olaf's
older text implied that the decision to publish a
not-fully-mature or incomplete specification was entirely an
IESG one.   While the text in 2026, especially taken out of
context, is no better (and Olaf just copied the relevant bits),
I have a problem with any action that appears to reinforce that
view or to grant the IESG authority to act independently of the
community.

(3) As a matter of policy and RFCs of editorially high quality,
I think it is better to have explanations of loose ends and
not-fully-baked characteristics of standards integrated into the
document rather than using IESG Statements.  I don't think
Olaf's new "front page" requirement is correct (although I can
live with it) -- I'd rather just say "clearly and prominently
communicated in the document" and leave the "is it clear and
prominent enough" question for Last Call -- but don't want to
see it _forced_ into an IESG statement.

I do note that "front page" and "Introduction" are typically
inconsistent requirements (header + abstract + status and
copyright boilerplate + TOC usually force the Introduction to
the second or third page).  More important, if a real
explanation of half-baked features (and why they aren't fully
baked) may require a section, or more than one, on it own.  One
would normally like a cross reference to those sections in the
Introduction and possibly even mention in the Abstract, but
forcing the text into the Introduction (even with "preferably"
given experience with how easily that turns into a nearly-firm
requirement) is just a bad idea in a procedures document.  We
should say "clearly", "prominently", or both and then leave
specifics about what that means to conversations between the
authors, the IESG and community, and the RFC Editor.

    best,
    john