Network Working Group J. Klensin Internet-Draft September 23, 2018 Updates: 5742 (if approved) Intended status: Best Current Practice Expires: March 27, 2019 Clarifying and Updating the Document Conflict Review Procedure draft-klensin-iesg-rfc5742bis-01 Abstract The IESG procedures for conducting conflict reviews of Independent and IRTF Stream Submissions, described in RFC 5742, have proven restrictive in ways that prevent the IESG from adequately expressing its opinions and that can interfere with an open and transparent process. This document updates RFC 5742 to mitigate that problem. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 27, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Klensin Expires March 27, 2019 [Page 1]
Internet-Draft Conflict Review Update September 2018 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Update Part I: Add a Missing Category to RFC 5742 . . . . . . 4 2.1. Explanation . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Changes to RFC 5742 . . . . . . . . . . . . . . . . . . . 5 3. Update Part II: Clarify and Extend the Permanent "Do Not Publish" Recommendations . . . . . . . . . . . . . . . . . . 5 3.1. Explanation . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Changes to RFC 5742 . . . . . . . . . . . . . . . . . . . 6 4. Update Part III: Make Authorization for IESG Flexibility and Discretion Explicit in RFC 5742 . . . . . . . . . . . . . . . 6 4.1. Explanation . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Change to RFC 5742 . . . . . . . . . . . . . . . . . . . 7 5. Update Part IV: Clarify Relationship Among Categories . . . . 7 5.1. Explanation . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Changes to RFC 5742 . . . . . . . . . . . . . . . . . . . 7 6. Further Context and Issues . . . . . . . . . . . . . . . . . 7 6.1. Definition of an "IETF Protocol" . . . . . . . . . . . . 8 6.2. Procedure for Updating a Specification Published as an RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Possible Future Work: The Variance Procedure . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Appendix A. Endnotes . . . . . . . . . . . . . . . . . . . . . . 10 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 B.1. Changes from version -00 (2019-09-14) to -01 . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Note in Draft: Entries below that consist of a left square bracket, one or more digits, and a right square bracket are references to the Endnotes in Appendix A. In 2009, the IESG proposed, approved, and published a description of the procedures it intended to use to process the conflict reviews of Independent and IRTF Stream Submissions [RFC5742]. For the Independent Stream, those reviews were called for by a specification that had been extensively debated in the community [RFC4846]. Similar provisions were later adopted for the IRTF Stream [RFC5743]. Klensin Expires March 27, 2019 [Page 2]
Internet-Draft Conflict Review Update September 2018 In addition to outlining procedures to be followed, RFC 5742 includes a set of categories into which IESG responses are expected to fall and corresponding text to be used in responses to the relevant stream managers. At least in retrospect, some members of the community believed that that those categories and textual statements specified all of the positions that the IESG could take and all of the responses they could generate. Others believed that the categories and text provided guidance for the common cases that could be anticipated but that the IESG could depart from them as needed as long as the general principle of a conflict review rather than a technical one was adhered to. The latter interpretation was seen to be consistent with a very long standing IETF principle that we prioritize good sense over rigid procedures and allow relevant bodies to make adjustments as required by circumstances even if an exception procedure is required in some more extreme cases. This difference in interpretations of RFC 5742 was highlighted in the middle of 2018, when the IESG reported on a conflict review of a draft from the Independent Stream [IESG-ConflictReview]. That response seemed to at least some members of the community to be badly matched to the document in question, leading to an appeal [klensin-appeal] that was intended to be primarily about how the IESG was interpreting and using RFC 5742 [1]. The IESG's response to the appeal [IESG-response] indicated, in its Section 5, that they believed the only response they could give to a conflict review request were those specified in the exact text of RFC 5742, that they could not make exceptions to that text on their own (i.e., that the text of RFC 5742 was "exhaustive and constraining" (Section 5 of the appeal response)) [2], and invited members of the community who believe that RFC 5742 was inappropriate or insufficient to propose revisions "through the appropriate IETF processes" (Section 4 of the appeal response). This document is a response to that suggestion and updates RFC 5742 in line with the explanation above. While this document was motivated largely by issues with the Independent Stream, RFC 5742 covers both it and the IRTF Stream. The specific changes proposed are consistent with the scope of RFC 5742, i.e., covering both Independent Stream and IRTF documents, and the term "Stream Manager" is used to refer generically to both Streams and the associated approval processes and requests for conflict reviews. Klensin Expires March 27, 2019 [Page 3]
Internet-Draft Conflict Review Update September 2018 2. Update Part I: Add a Missing Category to RFC 5742 2.1. Explanation A recurring issue with Independent Submissions (and, in principle, documents from other non-IETF Streams) is that some of the documents submitted are insufficiently clear about their role and specifically that they are not IETF standards or other normative documents. Such documents may create confusion about status for which no amount of boilerplate (which many people don't read) is an adequate remedy. Such a document might be entirely acceptable for Independent Stream publication if it were more clear on that subject but is problematic without that category. At least in principle, this problem might occur with IRTF documents as well. When a document is submitted for Conflict Review with this problem, the IESG should ordinarily combine this response with one of the others (see Section 5 below) so as to avoid the additional processing associated with a second review. However, should a document be encountered in which the IESG concludes that lack of clarity about the document's role prevents a competent conflict review, a request may be made that the document be resubmitted for a second review after the document is clarified (with the understanding that the stream is not required to honor that request). The need for this option should be very rare. Under ordinary circumstances involving the pre-publication review contemplated by RFC 4846 and RFC 5743, clarifications along those lines will be made by the author(s), with input from the Stream Manager as needed, well before the document reaches the IESG for a conflict review. However, when the IESG concludes that the document, as presented for conflict review, is insufficiently clear about its role, it should be allowed (or even encouraged) to respond with a category and in a way that makes the issue clear. While RFCs 4486 and 5743 and the unmodified RFC 5742 assume that the IESG Conflict Review is a one-shot effort, not an iterative process, were a document to be so unclear about its intended role that an actual conflict review is not possible, that situation is the one easily-identified case in which it is likely to be appropriate for the IESG to say something equivalent to "get that clarified and then we would like to do a more substantive conflict review". This new category is consistent with, and in the spirit of, the discussion in Section 5 of RFC 5742; it just provides more information for the submitting streams and the community. Klensin Expires March 27, 2019 [Page 4]
Internet-Draft Conflict Review Update September 2018 2.2. Changes to RFC 5742 In Section 3: 1. In the third paragraph, change "five" to "six" 2. Add a new numbered item, reading as follows, after numbered item 2 of the third paragraph and renumber subsequent items. 3. "The IESG has concluded that the body text of the draft is insufficiently clear about the status of the document, e.g., that it is too difficult to tell from the text alone that the draft, if published in its current form, is not an IETF standards track document." If the IESG concludes that it is unable to determine whether the document would be acceptable after the body text is clarified in that regard, it may add: "The IESG would welcome the opportunity to do the originally- requested review for substantive conflicts after that problem is corrected." 3. Update Part II: Clarify and Extend the Permanent "Do Not Publish" Recommendations 3.1. Explanation As suggested in the appeal, in RFC 4846, and in Section 5 of RFC 5742, the primary intent of having "do not publish" categories was to keep an Independent Stream publication from violating IETF procedures or interfering with active or developing IETF work, especially normative IETF work. In part because the notion of Independent Submissions to the RFC Editor (which, in one form or another, predate the IETF by many years) was to allow challenging, critiquing, or presenting alternatives to community decisions (and, later, IETF standards) that category should not be used in a way that creates the impression of attempted IESG censorship, even if (as RFC 4842 makes clear) the relevant Stream Manager is free to reject the IESG's recommendation. Seen in that light and in the light of the discussion of the previous section, the "do not publish" recommendations (numbered items 4 and 5 of Section 3 of RFC 5742) are for explicit violations of IETF procedures (e.g., an attempt to establish a new protocol parameter where the base protocol explicitly requires IETF review and IESG approval) or, primarily for more extreme cases of apparent conflicts with IETF work, circumstances for which a request for a delay while Klensin Expires March 27, 2019 [Page 5]
Internet-Draft Conflict Review Update September 2018 the IETF finishes a particular piece of work, especially work that may take a long time. Consequently, it is appropriate to modify the "do not publish" discussion and text to require that the IESG either identify the specific procedure or requirement that would be violated, the specific work with which the document would interfere, or otherwise justify the decision. A reference to IESG ballot comments, recorded in the tracker or elsewhere, is not sufficient for this purpose because it is often not clear whether such a comment is an observation by a particular AD or a statement that represents IESG consensus and for which the IESG is willing to be held accountable. 3.2. Changes to RFC 5742 1. In Section 3, at the end of the fifth full paragraph ("The last two responses...") add: For the last two responses above, the IESG is expected to include a specific reference to, or discussion of, the procedure that would be violated or the protocols that specify requirements for IETF review. It is expected to do so in sufficient detail that document authors, the relevant stream managers, and the community can evaluate the review conclusions. The last response should be applied only with extreme care because it effectively adds an additional requirement to the original specification without review or approval by the IETF and with no assurance about consistency with other documents and decisions. 2. In Section 3, last numbered item, change "an IETF protocol" to "IETF protocol(s) for <Y>". 4. Update Part III: Make Authorization for IESG Flexibility and Discretion Explicit in RFC 5742 4.1. Explanation As discussed in Section 1 above, one of the important properties of the way the IETF does things is that we put flexibility and the ability to apply good sense ahead of rigid procedures when those two approaches conflict. Apparently it is necessary to explicitly apply the principle of the priority of good sense and flexibility to RFC 5742. Klensin Expires March 27, 2019 [Page 6]
Internet-Draft Conflict Review Update September 2018 4.2. Change to RFC 5742 In Section 3, after the numbered list, add a new paragraph that reads: The above types of conclusions and responses are descriptive and not prescriptive. Should the IESG encounter unusual circumstances within the scope of a conflict review and the spirit of this document, it may modify reply text as needed. It is far preferable for the IESG to have, and exercise, discretion about the text chosen than to utilize text that does not fit the circumstances and therefore confuses the relevant stream, the community, and the historical record about the actual character of the problem the IESG has identified. 5. Update Part IV: Clarify Relationship Among Categories 5.1. Explanation As an extension to the additional flexibility called for in Section 4 above, it is perhaps worth making clear that the categories of RFC 5742 (both with and without the changes specified in this document) may not be mutually exclusive. As an example, it is easy to imagine circumstances in which the IESG would want to recommend that a document not be published at all but, even if the Stream Manager decided to reject that recommendation, would want to request a delay for the IETF to complete some specific effort before publication. 5.2. Changes to RFC 5742 In Section 3, Paragraph 3 1. Change "any one of which" to "one or more of which". 2. At the end of the paragraph, add "If the IESG chooses more than one of the responses, it is responsible for explaining how the recommendations relate to each other so that the desired action is clear. 6. Further Context and Issues While not addressed in this document, in part because the issues may be more controversial rather than closer to extended clarifications, the language of RFC 5742 appears to raise two additional issues, one or both of which might be further explored if and when the community thinks that would be appropriate. Klensin Expires March 27, 2019 [Page 7]
Internet-Draft Conflict Review Update September 2018 6.1. Definition of an "IETF Protocol" Paragraph 3 of RFC 5742 refers to an "IETF protocol". It is not clear whether that is a standards track Technical Specification; a Technical Specification, even an Informational or Experimental one, published with IETF consensus; any document published in the IETF Stream, even one that is not a Technical Specification; or, in the most extreme case, any document published or posted under rules or procedures set by the IETF. Having this be unclear, or subject to different interpretations on different occasions, is probably not wise. 6.2. Procedure for Updating a Specification Published as an RFC Bullet item 5 of Section 3 of RFC 5742 refers to an "IETF protocol" and "in a way that requires IETF review". Normally, a requirement for IETF review can be imposed only in an IANA Considerations provision or other text or in the protocol specification itself. Decisions about which extensions require IETF review and approval are normally made by IETF consensus and the only way to change those decisions requires updating the specification, an action that itself requires IETF consensus. However, paragraph 5 of Section 3 appears to allow the IESG to decide, without consulting the IETF community, that the original authors of a specification (and the IETF) erred in not requiring IETF review and to ask the Stream Manager to not publish a document because such review is, in the IESG's judgment, required after all. Independent of other issues, there is some question about whether it is appropriate for the IESG to effectively update a protocol specification, even a standards track one, to change the requirements for extensions without consulting the community in any way, much less without ascertaining IETF consensus. 7. Possible Future Work: The Variance Procedure The variance procedure described in Section 9.3 of RFC 2026 [RFC2026] is limited in scope to issues involving the approval of standards. A very narrow reading of it, and application of the principle sometimes described as "anything not explicitly permitted is forbidden", could imply that no variances are permitted for any other IETF procedure, at least without standards-track (including BCP) action. That reading appears to be excessively constraining and is inconsistent with situations in the past in which they IESG has issued statements or used very liberal interpretations of documents in order to apply common sense and make the right things happen. So, if the IESG interpretation of RFC 5742 that led to this document is likely to be Klensin Expires March 27, 2019 [Page 8]
Internet-Draft Conflict Review Update September 2018 applied more broadly, it will likely be useful to update RFC 2026 (or some other relevant process document) to extrapolate the variance procedure to other cases. 8. Acknowledgements This document has benefited from informal discussions with several people about the general context and symptoms that motivated it and possible remedies for those symptoms and from reflection on the process and discussions that produced RFC 4496. Comments from Adrian Farrel, Sue Hares, and Subramanian Moonesamy about early drafts led to considerable improvements in the underlying ideas and resulting text. 9. IANA Considerations [[CREF1: RFC Editor: Please remove this section before publication.]] This memo includes no requests to or actions for IANA. 10. Security Considerations As was the case with RFC 5742, the changes in this memo have no direct bearing on the security of the Internet. 11. References 11.1. Normative References [IESG-response] Cooper, A., "Response to appeal of IESG Conflict Review process and decision on draft-mavrogiannopoulos-pkcs8- validated-parameters-02", August 2018, <https://mailarchive.ietf.org/arch/msg/ietf/ G0J3W6j27Z_Xy5lriJwjpHmO5nQ>. [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for Handling of Independent and IRTF Stream Submissions", BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, <https://www.rfc-editor.org/info/rfc5742>. 11.2. Informative References Klensin Expires March 27, 2019 [Page 9]
Internet-Draft Conflict Review Update September 2018 [IESG-ConflictReview] IESG, "Conflict review draft-mavrogiannopoulos-pkcs8- validated-parameters-04", June 2018, <https://datatracker.ietf.org/doc/conflict-review- mavrogiannopoulos-pkcs8-validated-parameters/>. [klensin-appeal] Klensin, J., "Appeal of IESG Conflict Review process and decision on draft-mavrogiannopoulos-pkcs8-validated- parameters-02", July 2018, <https://www6.ietf.org/iesg/appeal/ klensin-2018-07-07.txt>. [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <https://www.rfc-editor.org/info/rfc2026>. [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, DOI 10.17487/RFC4846, July 2007, <https://www.rfc-editor.org/info/rfc4846>. [RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, December 2009, <https://www.rfc-editor.org/info/rfc5743>. Appendix A. Endnotes [[CREF2: Note in Draft: if this document progresses to the RFC Editor, we will, at that time, sort out how to handle and format this material.]] [1] The issues specific to the content and presentation of draft- mavrogiannopoulos-pkcs8-validated-parameters-02 are outside the scope of this document. [2] That conclusion may violate the spirit of the variance procedure described in Section 9.3 of RFC 2026 [RFC2026] and more general IETF principles. It may, consequently, be an issue for a further appeal. The present author hopes this document, including the discussion in Section 7, will preempt the need for such an action, at least for the particular case of publication conflict reviews. Klensin Expires March 27, 2019 [Page 10]
Internet-Draft Conflict Review Update September 2018 Appendix B. Change Log RFC Editor: Please remove this appendix before publication. B.1. Changes from version -00 (2019-09-14) to -01 o Clarified the "insufficiently clear about status" material (Section 2) to make it more clear about the intent and avoid imposing a requirement for the IESG to conduct two formal reviews and votes as well as bringing the text more in line with the "one review only" intent of RFC 4486. The change included adding an explicit provision (Section 5) that the IESG can make more than one finding about the same document if that is appropriate. o Adjusted terminology in several places to make the document more clear or more consistent. o Minor editorial corrections Author's Address John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA Phone: +1 617 245 1457 Email: john-ietf@jck.com Klensin Expires March 27, 2019 [Page 11]