Internet DRAFT - draft-klensin-iesg-rfc5742bis
draft-klensin-iesg-rfc5742bis
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]
