Network Working Group J. Klensin Internet-Draft September 14, 2018 Updates: 5742 (if approved) Intended status: Best Current Practice Expires: March 18, 2019 Clarifying and Updating the Document Conflict Review Procedure draft-klensin-iesg-rfc5742bis-00 Abstract The IESG procedures for conducting conflict reviews of Independent and IRTF Stream Submissions, described in RFC 5742, have proven excessively 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 18, 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 18, 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. Proposal Part I: Add a Missing Category to RFC 5742 . . . . . 3 2.1. Explanation . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Changes to RFC 5742 . . . . . . . . . . . . . . . . . . . 4 3. Proposal Part II: Clarify and Extend the Permanent "Do Not Publish" Recommendations . . . . . . . . . . . . . . . . . . 4 3.1. Explanation . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Changes to RFC 5742 . . . . . . . . . . . . . . . . . . . 5 4. Proposal Part III: Make Authorization for IESG Flexibility and Discretion Explicit in RFC 5742 . . . . . . . . . . . . . 6 4.1. Explanation . . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Change to RFC 5742 . . . . . . . . . . . . . . . . . . . 6 5. Further Context and Issues . . . . . . . . . . . . . . . . . 6 5.1. Definition of an "IETF Protocol" . . . . . . . . . . . . 6 5.2. Procedure for Updating a Specification Published as an RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Possible Future Work: The Variance Procedure . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Appendix A. Endnotes . . . . . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 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]. Those reviews were called for by earlier specifications that had been extensively debated in the community [RFC4846] [RFC5743]. 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 Klensin Expires March 18, 2019 [Page 2] Internet-Draft Conflict Review Update September 2018 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. For simplicity and clarity, the present document is written in terms of the Independent Stream. However, the specific changes proposed are consistent with the scope of RFC 5742, i.e., covering both Independent Stream and IRTF documents. 2. Proposal 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. Under ordinary circumstances involving the pre-publication review contemplated by RFC 4846, clarifications along Klensin Expires March 18, 2019 [Page 3] Internet-Draft Conflict Review Update September 2018 those lines will be made by the author(s), with input from the Independent Submission Editor 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. In addition, a document's being unclear about its intended role is one 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. 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. The IESG would welcome the opportunity to do a review for substantive conflicts after that problem is corrected. 3. Proposal 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 Klensin Expires March 18, 2019 [Page 4] Internet-Draft Conflict Review Update September 2018 clear) the Independent Submission Editor 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 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 paragraphs ("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 ". Klensin Expires March 18, 2019 [Page 5] Internet-Draft Conflict Review Update September 2018 4. Proposal 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. 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. 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. 5.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. Klensin Expires March 18, 2019 [Page 6] Internet-Draft Conflict Review Update September 2018 5.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 ISE 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. 6. 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 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. 7. IANA Considerations [[CREF1: RFC Editor: Please remove this section before publication.]] This memo includes no requests to or actions for IANA. Klensin Expires March 18, 2019 [Page 7] Internet-Draft Conflict Review Update September 2018 8. Security Considerations As was the case with RFC 5742, the changes in this memo have no direct bearing on the security of the Internet. 9. References 9.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, . [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, . 9.2. Informative References [IESG-ConflictReview] IESG, "Conflict review draft-mavrogiannopoulos-pkcs8- validated-parameters-04", June 2018, . [klensin-appeal] Klensin, J., "Appeal of IESG Conflict Review process and decision on draft-mavrogiannopoulos-pkcs8-validated- parameters-02", July 2018, . [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, . [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, DOI 10.17487/RFC4846, July 2007, . [RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, December 2009, . Klensin Expires March 18, 2019 [Page 8] Internet-Draft Conflict Review Update September 2018 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 6, will preempt the need for such an action, at least for the particular case of publication conflict reviews. 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 18, 2019 [Page 9]