[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 5742) 00 01

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


   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

   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

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

   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"

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

   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

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

      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

              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,

11.2.  Informative References

Klensin                  Expires March 27, 2019                 [Page 9]

Internet-Draft           Conflict Review Update           September 2018

              IESG, "Conflict review draft-mavrogiannopoulos-pkcs8-
              validated-parameters-04", June 2018,

              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, <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

   [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

   Phone: +1 617 245 1457
   Email: john-ietf@jck.com

Klensin                  Expires March 27, 2019                [Page 11]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/