Re: PS Characterization Clarified

[Olaf Kolkman <[e-mail]>]

Based on the conversation below I converged to:


   <t>
      While less mature specifications will usually be published as
      Informational or Experimental RFCs, the IETF may, in exceptional
      cases, publish a specification that still contains areas for
      improvement or certain uncertainties about whether the best
      engineering choices are made.  In those cases that fact will be
      clearly and prominently communicated in the document e.g. in the
      abstract, the introduction, or a separate section or statement.
    </t>


I will be publishing version 02 shortly.

--Olaf


[This is a top-post, nothing but context below]



On 16 sep. 2013, at 18:04, John C Klensin <[e-mail]> wrote:

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