All, after several private discussions, I'd like to communicate long-standing substantial concerns and conclusions related to the current version of the "IESG Procedures for Independent Submission and IRTF Stream" I-D, <draft-housley-iesg-rfc3932bis-10>. Preamble: "A strong democracy needs a strong opposition" (nearly proverbial; found frequently quoted in The Economist, or refer to http://www.faqs.org/abstracts/Business-international/ Italys-weak-right-hand-a-strong-democracy-needs-a-strong-opposition.html) The IETF (Process and) Stream needs a strong Independent Submission Stream as well. One of the aims of the Headers and Boilerplates effort was to get rid of the necessity for IESG Notes in 'normal' cases. The current draft does mention that in a single sentence in Section 3, below the list of 5 kinds of conclusions possible: The RFC headers and boilerplate is intended to describe the relationship of the document to the IETF standards process [N3]. In | exceptional cases, when the relationship of the document to the IETF | standards process might be unclear, the IESG may provide an IESG note to clarify the relationship of the document to the IETF standards process, such a note is likely to include pointers to related IETF RFCs. [...] Subsequently, the draft now has grown to elaborate on this exceptional case on almost two pages, but it fails to reciprocally establish any means to protect the two streams independent of the IETF stream from many kinds of, say, "strange behavior", observed in the past. (Dave Crocker and John Klensin have recalled such observations at an abstract level in their recent postings to this list.) That resulting dis-balance is rather incommensurate. In order to restore some degree of balance, in the spirit of RFC 4648, I suggest to consider the following additions that should help to limit the opportunities for abuse and DoS against these streams: (1) After the clause quoted above, insert: || To ensure the truly exceptional nature of IESG notes, the IESG || sets priorities and rate limits the requests to add IESG notes || to at most 10% (on average) of the drafts submitted to it under || the procedures defined in this document. [[ Notes: a) You might propose another figure than 10% -- arguably this conservative proposal is already beyond what usually would be regarded as 'exceptional'. b) This clause is stated in the form of a self-committment from the IESG; it purposely avoids the installation of additional procedures for supervision. Feedback to the NomCom should suffice in the long term to give the community an opportunity to evaluate and ensure the 'performance' of the IESG w.r.t. this goal. ]] (2) In the 4th-to-last paragraph of Section 3, The IESG will normally complete review within four weeks after notification by the RFC Editor or IRTF. [...] ... insert after the quoted sentence: || If the IESG does not respond within ten weeks, the ISE or the || IRTF, respectively, can firmly assume that conclusion #1 holds. [[ Note: Despite handwaving arguments presented, it should be worth using precise terms to avoid confusion, and denote the 'gatekeeping' entities of the streams with the names now assigned to them. So please replace "RFC Editor" by the more precise "Independent Submission Editor (ISE)" wherever that RFC Editor 'function' is intended to be denoted -- it most likely will be an independent person or team soon. In this draft, almost all instances of "RFC Editor" do not refer to the (abstract) umbrella institution still assigned that name, nor to the RSE (which in practice most likely will colloquially still be called "the RFC Editor" in the future), but to the ISE. ]] (3) The intent of conclusion #3 was, and is, to give the IETF 'protected' time to bring a starting or ongoing effort to success. Failure of the IETF (not too rarely not only on the WG level!) to achieve that success within a reasonable time span should not be able to block a document forever. As any other measures of suspension codified in the IETF process, this decision should have a 'built-in' time limit, and it should not last indefinitely by default. Here's my proposal to correct that: After the paragraph in Section 3 starting with The last two responses are included respectively, [...] insert a new paragraph establishing a timout rule prohibiting indefinite stalling of documents by conclusion #3; for instance: || In the case of the third conclusion, lack of progress in the IETF || should not be able to block a document forever. If the IETF does || not arrive at bringing the work denoted as potentially disrupted || to a state where publication is granted or extremely likely, || within a period of two years from the time of the conclusion || suspending the Independent Submisison or IRTF stream document, || the ISE or IRTF, respectively, may decide to forward the document || for publication anyway. This timeout can be extended once by || another year if the IESG can provide evidence that the IETF effort || regarded as colliding with the document has been held off by || substantive reasons, but will most likely come to success within || this time frame. If IETF work is not able to make significant || progress within such time span, this most likely will be due to || personal and or technical disputes that will not disappear in || the longer term, making it likely that publication of the original || proposal(s) serves to either reconcile the discussion or giving || the networking community a clear indication that the IETF effort || is probably bound to failure. Colophon: It has been complained frequently that people do not read RFC front matter and boilerplate text (including IESG notes) on RFCs. According to my observation, what intuitively counts much more for such people when judging the relevance of an RFC for their work is the RFC number: Higher number is newer; higher number supersedes predecessor -- that's a very human built-in pattern of thought! Many RFC search engines also return hits in ascending RFC number order, irrespective of the status of the memo, potentially adding to the misconception. Therefore it is fatal that, with extreme likelihood, the documents held off by IESG recommendation will ironically be published later than the IETF output, with higher RFC numbers, making them appear more relevant than the IETF output. It might be worth reconsidering the RFC number assignment and publication schedule strategies to avoid such potential for misconception. One way to do so would be to publish the held-off document(s) in a coordinated manner with the primary IETF output, but with lower RFC number(s), and with bidirectional Obsoletes and Obsoleted-by entries in the RFC metadata, from the very beginning of the lifecycle of these RFCs in the archives. If proposal (3) above is accepted, it might even be possible to set aside RFC numbers for held-off documents, as soon as that happens, because their publication with that number within 3 to 4 years would be assured (notwithstanding rare exceptional events). Kind regards, Alfred Hönes. -- +------------------------+--------------------------------------------+ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: ah@xxxxxxxxx | +------------------------+--------------------------------------------+ _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf