[Barry added explicitly to the CC as this speaks to 'his' issue] On 13 sep. 2013, at 20:57, John C Klensin <klensin@xxxxxxx> wrote: [… skip …] >> * Added the Further Consideration section based on >> discussion on the mailinglist. > > Unfortunately, IMO, it is misleading to the extent that you are > capture existing practice rather than taking us off in new > directions. Yeah it is a thin line. But the language was introduced to keep a current practice possible (as argued by Barry I believe). > You wrote: > >> While commonly less mature specifications will be published as >> Informational or Experimental RFCs, the IETF may, in >> exceptional cases, publish a specification that does not match >> the characterizations above as a Proposed Standard. In those >> cases that fact will be clearly communicated on the front page >> of the RFC e.g. means of an IESG statement. > > On the one hand, I can't remember when the IESG has published > something as a Proposed Standard with community consensus and > with an attached IESG statement that says that they and the > community had to hold our collective noses, but decided to > approve as PS anyway. Because, at least in theory, a PS > represents community consensus, not just IESG consensus (see > below), I would expect (or at least hope for) an immediate > appeal of an approval containing such as statement unless it > (the statement itself, not just the opinion) matched community > consensus developed during Last Call. > > Conversely, the existing rules clearly allow a document to be > considered as a Proposed Standard that contains a paragraph > describing loose ends and points of fragility, that expresses > the hope that the cases won't arise very often and that a future > version will clarify how the issues should be handled based on > experience. That is "no known technical omissions" since the > issues are identified and therefore known and not omissions. In > the current climate, I'd expect such a document to have a very > hard time on Last Call as people argued for Experimental or even > keeping it as an I-D until all of the loose ends were tied up. > But, if there were rough consensus for approving it, I'd expect > it to be approved without any prefatory, in-document, IESG notes > (snarky or otherwise). > > The above may or may not be tied up with the "generally stable" > terminology. I could see a spec with explicit "this is still > uncertain and, if we are wrong, might change" language in it on > the same basis as the loose end description above. Such > language would be consistent with "generally stable" but, since > it suggests a known point of potential instability, it is not > consistent with "stable". > I see where you are going. <draft Proposed rewrite> While commonly less mature specifications will 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 communicated in the document prefereably on the front page of the RFC e.g. in the introduction or a separate statement. </draft> I hope that removing the example of the IESG statement makes clear that this is normally part of the development process. > Additional observations based on mostly-unrelated recent > discussions: > > If you are really trying to clean 2026 up and turn the present > document into something that can be circulated to other groups > without 2026 itself, then the "change control" requirement/ > assumption of RFC 2026 Section 7.1.3 needs to be incorporated > into your new Section 3. It is not only about internal debates, > it is our rule against why we can't just "endorse" a standard > developed elsewhere as an IETF standards track specification. > > Along the same lines but more broadly, both the sections of 2026 > you are replacing and your new text, if read in isolation, > strongly imply that these are several decisions, including those > to approve standardization, that the IESG makes on its own > judgment and discretion. I think it is fairly clear from the > rest of 2026 (and 2028 and friends and IETF oral tradition) that > the IESG is a collector and interpreter of community consensus, > not a body that is someone delegated to use its own judgment. I > believe that, if an IESG were ever to say something that > amounted to "the community consensus is X, but they are wrong, > so we are selecting or approving not-X", we would either see a > revolution of the same character that brought us to 2026 or the > end of the IETF's effectiveness as a broadly-based standards > body. > > More important --and related to some of my comments that you > deferred to a different discussion-- the "IESG as final > _technical_ review and interpreter of consensus" model is very > different from that in some other SDOs in which the final > approval step is strictly a procedural and/or legal review that > is a consensus review only in the sense of verifying that the > process in earlier stages followed the consensus rules and is > not technical review at all. I don't think you need to spend > time on that, but you need to avoid things that would make your > document misleading to people who start with that model of how > standards are made as an initial assumption. So noted. As actionable for this draft I take that I explicitly mention that Section 4.1 2026 is exclusively updated. --Olaf
Attachment:
signature.asc
Description: Message signed with OpenPGP using GPGMail