--On Monday, September 16, 2013 10:43 -0400 Barry Leiba <barryleiba@xxxxxxxxxxxx> 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