--On Monday, September 16, 2013 15:58 +0200 Olaf Kolkman <olaf@xxxxxxxxxxxx> wrote: > [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). Understood. Barry and I are on the same page wrt not wanting to accidentally restrict established existing practices. >> You wrote: >> >>> While commonly less mature specifications will be published >>> as Informational or Experimental RFCs, the IETF may, in >... > 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. Yes. Editorial nits: * "While commonly less mature specifications will be published..." has "commonly" qualifying "less mature". It is amusing to think about what that might mean, but it isn't what you intended. Try "While less mature specifications will usually be published...". Replace "usually" with "commonly" or "normally" if you like, but I think "usually" is closest to what you are getting at. * "prefereably" -> "preferably" >> 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/ >... >> 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 >... >> 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 >... > So noted. > > As actionable for this draft I take that I explicitly mention > that Section 4.1 2026 is exclusively updated. While I understand your desire to keep this short, the pragmatic reality is that your non-IETF audience is likely to read this document (especially after you hand it to them) and conclude that it is the whole story. Since the natural question that immediately follows "why should we accept your standards at all" is "why can't you hand them off to, e.g., ISO, the way that many national bodies and organizations like IEEE do with many of their documents". Suggestion in the interest of brevity: in addition to mentioning the above, mention explicitly that there are requirements in other sections of 2026 that affect what is standardized and how. By the way, while I understand all of the reasons why we don't want to actually replace 2026 (and agree with most of them), things are getting to the point that it takes far too much energy to actually figure out what the rules are. Perhaps it is time for someone to create an unofficial redlined version of 2026 that incorporates all of the changes and put it up on the web somewhere. I think we would want a clear introduction and disclaimer that it might be be exactly correct and that only the RFCs are normative, but the accumulation of changes may otherwise be taking us too far into the obscure. If we need a place to put it, it might be a good appendix to the Tao. And constructing it might be a good job for a relative newcomer who is trying to understand the ins and outs of our formal procedures. best, john