idnits 2.17.1 draft-klensin-iesg-rfc5742bis-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5742, updated by this document, for RFC5378 checks: 2008-07-31) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 23, 2018) is 2041 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 451 -- Looks like a reference, but probably isn't: '2' on line 455 == Outdated reference: A later version (-04) exists of draft-mavrogiannopoulos-pkcs8-validated-parameters-02 ** Downref: Normative reference to an Informational draft: draft-mavrogiannopoulos-pkcs8-validated-parameters (ref. 'IESG-response') -- Duplicate reference: draft-mavrogiannopoulos-pkcs8-validated-parameters, mentioned in 'IESG-ConflictReview', was also mentioned in 'IESG-response'. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft September 23, 2018 4 Updates: 5742 (if approved) 5 Intended status: Best Current Practice 6 Expires: March 27, 2019 8 Clarifying and Updating the Document Conflict Review Procedure 9 draft-klensin-iesg-rfc5742bis-01 11 Abstract 13 The IESG procedures for conducting conflict reviews of Independent 14 and IRTF Stream Submissions, described in RFC 5742, have proven 15 restrictive in ways that prevent the IESG from adequately expressing 16 its opinions and that can interfere with an open and transparent 17 process. This document updates RFC 5742 to mitigate that problem. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 27, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Update Part I: Add a Missing Category to RFC 5742 . . . . . . 4 55 2.1. Explanation . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2. Changes to RFC 5742 . . . . . . . . . . . . . . . . . . . 5 57 3. Update Part II: Clarify and Extend the Permanent "Do Not 58 Publish" Recommendations . . . . . . . . . . . . . . . . . . 5 59 3.1. Explanation . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2. Changes to RFC 5742 . . . . . . . . . . . . . . . . . . . 6 61 4. Update Part III: Make Authorization for IESG Flexibility and 62 Discretion Explicit in RFC 5742 . . . . . . . . . . . . . . . 6 63 4.1. Explanation . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.2. Change to RFC 5742 . . . . . . . . . . . . . . . . . . . 7 65 5. Update Part IV: Clarify Relationship Among Categories . . . . 7 66 5.1. Explanation . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.2. Changes to RFC 5742 . . . . . . . . . . . . . . . . . . . 7 68 6. Further Context and Issues . . . . . . . . . . . . . . . . . 7 69 6.1. Definition of an "IETF Protocol" . . . . . . . . . . . . 8 70 6.2. Procedure for Updating a Specification Published as an 71 RFC . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 7. Possible Future Work: The Variance Procedure . . . . . . . . 8 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 11.2. Informative References . . . . . . . . . . . . . . . . . 9 79 Appendix A. Endnotes . . . . . . . . . . . . . . . . . . . . . . 10 80 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 81 B.1. Changes from version -00 (2019-09-14) to -01 . . . . . . 11 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 84 1. Introduction 86 Note in Draft: Entries below that consist of a left square bracket, 87 one or more digits, and a right square bracket are references to the 88 Endnotes in Appendix A. 90 In 2009, the IESG proposed, approved, and published a description of 91 the procedures it intended to use to process the conflict reviews of 92 Independent and IRTF Stream Submissions [RFC5742]. For the 93 Independent Stream, those reviews were called for by a specification 94 that had been extensively debated in the community [RFC4846]. 95 Similar provisions were later adopted for the IRTF Stream [RFC5743]. 97 In addition to outlining procedures to be followed, RFC 5742 includes 98 a set of categories into which IESG responses are expected to fall 99 and corresponding text to be used in responses to the relevant stream 100 managers. At least in retrospect, some members of the community 101 believed that that those categories and textual statements specified 102 all of the positions that the IESG could take and all of the 103 responses they could generate. Others believed that the categories 104 and text provided guidance for the common cases that could be 105 anticipated but that the IESG could depart from them as needed as 106 long as the general principle of a conflict review rather than a 107 technical one was adhered to. The latter interpretation was seen to 108 be consistent with a very long standing IETF principle that we 109 prioritize good sense over rigid procedures and allow relevant bodies 110 to make adjustments as required by circumstances even if an exception 111 procedure is required in some more extreme cases. 113 This difference in interpretations of RFC 5742 was highlighted in the 114 middle of 2018, when the IESG reported on a conflict review of a 115 draft from the Independent Stream [IESG-ConflictReview]. That 116 response seemed to at least some members of the community to be badly 117 matched to the document in question, leading to an appeal 118 [klensin-appeal] that was intended to be primarily about how the IESG 119 was interpreting and using RFC 5742 [1]. 121 The IESG's response to the appeal [IESG-response] indicated, in its 122 Section 5, that they believed the only response they could give to a 123 conflict review request were those specified in the exact text of RFC 124 5742, that they could not make exceptions to that text on their own 125 (i.e., that the text of RFC 5742 was "exhaustive and constraining" 126 (Section 5 of the appeal response)) [2], and invited members of the 127 community who believe that RFC 5742 was inappropriate or insufficient 128 to propose revisions "through the appropriate IETF processes" 129 (Section 4 of the appeal response). This document is a response to 130 that suggestion and updates RFC 5742 in line with the explanation 131 above. 133 While this document was motivated largely by issues with the 134 Independent Stream, RFC 5742 covers both it and the IRTF Stream. The 135 specific changes proposed are consistent with the scope of RFC 5742, 136 i.e., covering both Independent Stream and IRTF documents, and the 137 term "Stream Manager" is used to refer generically to both Streams 138 and the associated approval processes and requests for conflict 139 reviews. 141 2. Update Part I: Add a Missing Category to RFC 5742 143 2.1. Explanation 145 A recurring issue with Independent Submissions (and, in principle, 146 documents from other non-IETF Streams) is that some of the documents 147 submitted are insufficiently clear about their role and specifically 148 that they are not IETF standards or other normative documents. Such 149 documents may create confusion about status for which no amount of 150 boilerplate (which many people don't read) is an adequate remedy. 151 Such a document might be entirely acceptable for Independent Stream 152 publication if it were more clear on that subject but is problematic 153 without that category. At least in principle, this problem might 154 occur with IRTF documents as well. 156 When a document is submitted for Conflict Review with this problem, 157 the IESG should ordinarily combine this response with one of the 158 others (see Section 5 below) so as to avoid the additional processing 159 associated with a second review. However, should a document be 160 encountered in which the IESG concludes that lack of clarity about 161 the document's role prevents a competent conflict review, a request 162 may be made that the document be resubmitted for a second review 163 after the document is clarified (with the understanding that the 164 stream is not required to honor that request). 166 The need for this option should be very rare. Under ordinary 167 circumstances involving the pre-publication review contemplated by 168 RFC 4846 and RFC 5743, clarifications along those lines will be made 169 by the author(s), with input from the Stream Manager as needed, well 170 before the document reaches the IESG for a conflict review. However, 171 when the IESG concludes that the document, as presented for conflict 172 review, is insufficiently clear about its role, it should be allowed 173 (or even encouraged) to respond with a category and in a way that 174 makes the issue clear. While RFCs 4486 and 5743 and the unmodified 175 RFC 5742 assume that the IESG Conflict Review is a one-shot effort, 176 not an iterative process, were a document to be so unclear about its 177 intended role that an actual conflict review is not possible, that 178 situation is the one easily-identified case in which it is likely to 179 be appropriate for the IESG to say something equivalent to "get that 180 clarified and then we would like to do a more substantive conflict 181 review". 183 This new category is consistent with, and in the spirit of, the 184 discussion in Section 5 of RFC 5742; it just provides more 185 information for the submitting streams and the community. 187 2.2. Changes to RFC 5742 189 In Section 3: 191 1. In the third paragraph, change "five" to "six" 193 2. Add a new numbered item, reading as follows, after numbered item 194 2 of the third paragraph and renumber subsequent items. 196 3. "The IESG has concluded that the body text of the draft is 197 insufficiently clear about the status of the document, e.g., 198 that it is too difficult to tell from the text alone that the 199 draft, if published in its current form, is not an IETF 200 standards track document." 202 If the IESG concludes that it is unable to determine whether 203 the document would be acceptable after the body text is 204 clarified in that regard, it may add: 206 "The IESG would welcome the opportunity to do the originally- 207 requested review for substantive conflicts after that problem 208 is corrected." 210 3. Update Part II: Clarify and Extend the Permanent "Do Not Publish" 211 Recommendations 213 3.1. Explanation 215 As suggested in the appeal, in RFC 4846, and in Section 5 of RFC 216 5742, the primary intent of having "do not publish" categories was to 217 keep an Independent Stream publication from violating IETF procedures 218 or interfering with active or developing IETF work, especially 219 normative IETF work. In part because the notion of Independent 220 Submissions to the RFC Editor (which, in one form or another, predate 221 the IETF by many years) was to allow challenging, critiquing, or 222 presenting alternatives to community decisions (and, later, IETF 223 standards) that category should not be used in a way that creates the 224 impression of attempted IESG censorship, even if (as RFC 4842 makes 225 clear) the relevant Stream Manager is free to reject the IESG's 226 recommendation. 228 Seen in that light and in the light of the discussion of the previous 229 section, the "do not publish" recommendations (numbered items 4 and 5 230 of Section 3 of RFC 5742) are for explicit violations of IETF 231 procedures (e.g., an attempt to establish a new protocol parameter 232 where the base protocol explicitly requires IETF review and IESG 233 approval) or, primarily for more extreme cases of apparent conflicts 234 with IETF work, circumstances for which a request for a delay while 235 the IETF finishes a particular piece of work, especially work that 236 may take a long time. 238 Consequently, it is appropriate to modify the "do not publish" 239 discussion and text to require that the IESG either identify the 240 specific procedure or requirement that would be violated, the 241 specific work with which the document would interfere, or otherwise 242 justify the decision. A reference to IESG ballot comments, recorded 243 in the tracker or elsewhere, is not sufficient for this purpose 244 because it is often not clear whether such a comment is an 245 observation by a particular AD or a statement that represents IESG 246 consensus and for which the IESG is willing to be held accountable. 248 3.2. Changes to RFC 5742 250 1. In Section 3, at the end of the fifth full paragraph ("The last 251 two responses...") add: 253 For the last two responses above, the IESG is expected to 254 include a specific reference to, or discussion of, the 255 procedure that would be violated or the protocols that specify 256 requirements for IETF review. It is expected to do so in 257 sufficient detail that document authors, the relevant stream 258 managers, and the community can evaluate the review 259 conclusions. The last response should be applied only with 260 extreme care because it effectively adds an additional 261 requirement to the original specification without review or 262 approval by the IETF and with no assurance about consistency 263 with other documents and decisions. 265 2. In Section 3, last numbered item, change "an IETF protocol" to 266 "IETF protocol(s) for ". 268 4. Update Part III: Make Authorization for IESG Flexibility and 269 Discretion Explicit in RFC 5742 271 4.1. Explanation 273 As discussed in Section 1 above, one of the important properties of 274 the way the IETF does things is that we put flexibility and the 275 ability to apply good sense ahead of rigid procedures when those two 276 approaches conflict. Apparently it is necessary to explicitly apply 277 the principle of the priority of good sense and flexibility to RFC 278 5742. 280 4.2. Change to RFC 5742 282 In Section 3, after the numbered list, add a new paragraph that 283 reads: 285 The above types of conclusions and responses are descriptive and 286 not prescriptive. Should the IESG encounter unusual circumstances 287 within the scope of a conflict review and the spirit of this 288 document, it may modify reply text as needed. It is far 289 preferable for the IESG to have, and exercise, discretion about 290 the text chosen than to utilize text that does not fit the 291 circumstances and therefore confuses the relevant stream, the 292 community, and the historical record about the actual character of 293 the problem the IESG has identified. 295 5. Update Part IV: Clarify Relationship Among Categories 297 5.1. Explanation 299 As an extension to the additional flexibility called for in Section 4 300 above, it is perhaps worth making clear that the categories of RFC 301 5742 (both with and without the changes specified in this document) 302 may not be mutually exclusive. As an example, it is easy to imagine 303 circumstances in which the IESG would want to recommend that a 304 document not be published at all but, even if the Stream Manager 305 decided to reject that recommendation, would want to request a delay 306 for the IETF to complete some specific effort before publication. 308 5.2. Changes to RFC 5742 310 In Section 3, Paragraph 3 312 1. Change "any one of which" to "one or more of which". 314 2. At the end of the paragraph, add "If the IESG chooses more than 315 one of the responses, it is responsible for explaining how the 316 recommendations relate to each other so that the desired action 317 is clear. 319 6. Further Context and Issues 321 While not addressed in this document, in part because the issues may 322 be more controversial rather than closer to extended clarifications, 323 the language of RFC 5742 appears to raise two additional issues, one 324 or both of which might be further explored if and when the community 325 thinks that would be appropriate. 327 6.1. Definition of an "IETF Protocol" 329 Paragraph 3 of RFC 5742 refers to an "IETF protocol". It is not 330 clear whether that is a standards track Technical Specification; a 331 Technical Specification, even an Informational or Experimental one, 332 published with IETF consensus; any document published in the IETF 333 Stream, even one that is not a Technical Specification; or, in the 334 most extreme case, any document published or posted under rules or 335 procedures set by the IETF. 337 Having this be unclear, or subject to different interpretations on 338 different occasions, is probably not wise. 340 6.2. Procedure for Updating a Specification Published as an RFC 342 Bullet item 5 of Section 3 of RFC 5742 refers to an "IETF protocol" 343 and "in a way that requires IETF review". Normally, a requirement 344 for IETF review can be imposed only in an IANA Considerations 345 provision or other text or in the protocol specification itself. 346 Decisions about which extensions require IETF review and approval are 347 normally made by IETF consensus and the only way to change those 348 decisions requires updating the specification, an action that itself 349 requires IETF consensus. 351 However, paragraph 5 of Section 3 appears to allow the IESG to 352 decide, without consulting the IETF community, that the original 353 authors of a specification (and the IETF) erred in not requiring IETF 354 review and to ask the Stream Manager to not publish a document 355 because such review is, in the IESG's judgment, required after all. 356 Independent of other issues, there is some question about whether it 357 is appropriate for the IESG to effectively update a protocol 358 specification, even a standards track one, to change the requirements 359 for extensions without consulting the community in any way, much less 360 without ascertaining IETF consensus. 362 7. Possible Future Work: The Variance Procedure 364 The variance procedure described in Section 9.3 of RFC 2026 [RFC2026] 365 is limited in scope to issues involving the approval of standards. A 366 very narrow reading of it, and application of the principle sometimes 367 described as "anything not explicitly permitted is forbidden", could 368 imply that no variances are permitted for any other IETF procedure, 369 at least without standards-track (including BCP) action. That 370 reading appears to be excessively constraining and is inconsistent 371 with situations in the past in which they IESG has issued statements 372 or used very liberal interpretations of documents in order to apply 373 common sense and make the right things happen. So, if the IESG 374 interpretation of RFC 5742 that led to this document is likely to be 375 applied more broadly, it will likely be useful to update RFC 2026 (or 376 some other relevant process document) to extrapolate the variance 377 procedure to other cases. 379 8. Acknowledgements 381 This document has benefited from informal discussions with several 382 people about the general context and symptoms that motivated it and 383 possible remedies for those symptoms and from reflection on the 384 process and discussions that produced RFC 4496. 386 Comments from Adrian Farrel, Sue Hares, and Subramanian Moonesamy 387 about early drafts led to considerable improvements in the underlying 388 ideas and resulting text. 390 9. IANA Considerations 392 [[CREF1: RFC Editor: Please remove this section before publication.]] 394 This memo includes no requests to or actions for IANA. 396 10. Security Considerations 398 As was the case with RFC 5742, the changes in this memo have no 399 direct bearing on the security of the Internet. 401 11. References 403 11.1. Normative References 405 [IESG-response] 406 Cooper, A., "Response to appeal of IESG Conflict Review 407 process and decision on draft-mavrogiannopoulos-pkcs8- 408 validated-parameters-02", August 2018, 409 . 412 [RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for 413 Handling of Independent and IRTF Stream Submissions", 414 BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, 415 . 417 11.2. Informative References 419 [IESG-ConflictReview] 420 IESG, "Conflict review draft-mavrogiannopoulos-pkcs8- 421 validated-parameters-04", June 2018, 422 . 425 [klensin-appeal] 426 Klensin, J., "Appeal of IESG Conflict Review process and 427 decision on draft-mavrogiannopoulos-pkcs8-validated- 428 parameters-02", July 2018, 429 . 432 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 433 3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, 434 . 436 [RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent 437 Submissions to the RFC Editor", RFC 4846, 438 DOI 10.17487/RFC4846, July 2007, 439 . 441 [RFC5743] Falk, A., "Definition of an Internet Research Task Force 442 (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, 443 December 2009, . 445 Appendix A. Endnotes 447 [[CREF2: Note in Draft: if this document progresses to the RFC 448 Editor, we will, at that time, sort out how to handle and format this 449 material.]] 451 [1] The issues specific to the content and presentation of draft- 452 mavrogiannopoulos-pkcs8-validated-parameters-02 are outside the 453 scope of this document. 455 [2] That conclusion may violate the spirit of the variance procedure 456 described in Section 9.3 of RFC 2026 [RFC2026] and more general 457 IETF principles. It may, consequently, be an issue for a 458 further appeal. The present author hopes this document, 459 including the discussion in Section 7, will preempt the need for 460 such an action, at least for the particular case of publication 461 conflict reviews. 463 Appendix B. Change Log 465 RFC Editor: Please remove this appendix before publication. 467 B.1. Changes from version -00 (2019-09-14) to -01 469 o Clarified the "insufficiently clear about status" material 470 (Section 2) to make it more clear about the intent and avoid 471 imposing a requirement for the IESG to conduct two formal reviews 472 and votes as well as bringing the text more in line with the "one 473 review only" intent of RFC 4486. The change included adding an 474 explicit provision (Section 5) that the IESG can make more than 475 one finding about the same document if that is appropriate. 477 o Adjusted terminology in several places to make the document more 478 clear or more consistent. 480 o Minor editorial corrections 482 Author's Address 484 John C Klensin 485 1770 Massachusetts Ave, Ste 322 486 Cambridge, MA 02140 487 USA 489 Phone: +1 617 245 1457 490 Email: john-ietf@jck.com