Response to appeal of IESG Conflict Review process and decision on draft-mavrogiannopoulos-pkcs8-validated-parameters-02

IETF Chair <chair@ietf.org> Thu, 16 August 2018 14:46 UTC

Return-Path: <chair@ietf.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E5A130E50; Thu, 16 Aug 2018 07:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T2vh77xBj9R4; Thu, 16 Aug 2018 07:46:48 -0700 (PDT)
Received: from rtp-alcoop-nitro2.cisco.com (unknown [173.38.117.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 36F74130E8B; Thu, 16 Aug 2018 07:46:47 -0700 (PDT)
From: IETF Chair <chair@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BE722007-84EC-4DFD-91B5-3E4C23E8F7D5"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Response to appeal of IESG Conflict Review process and decision on draft-mavrogiannopoulos-pkcs8-validated-parameters-02
Message-Id: <C0A864ED-72DF-46D4-AA90-EAA943A7A478@ietf.org>
Date: Thu, 16 Aug 2018 10:46:45 -0400
Cc: John C Klensin <john-ietf@jck.com>, IESG <iesg@ietf.org>
To: ietf <ietf@ietf.org>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/G0J3W6j27Z_Xy5lriJwjpHmO5nQ>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2018 14:46:51 -0000

On July 7, 2018 John Klensin asked the IESG to review their actions regarding the independent stream conflict review for draft-mavrogiannopoulos-pkcs8-validated-parameters-02 <https://www6.ietf.org/iesg/appeal/klensin-2018-07-07.txt>. Consistent with the IESG Statement On Appeals of IESG and Area Director Actions and Decisions  <https://www.ietf.org/blog/appeals-iesg-and-area-director-actions-and-decisions/ <https://www.ietf.org/blog/appeals-iesg-and-area-director-actions-and-decisions/>>, the IESG has reviewed that action and reached the following conclusions:

We understand the request to include the following points:

1) Mr. Klensin requests that the IESG withdraw its independent stream conflict review results for draft-mavrogiannopoulos-pkcs8-validated-parameters-02, posted June 25, 2018. Mr. Klensin indicates that he recognizes the conflict review results are advisory in nature, but states that his request is not contingent upon the Independent Stream Editor's (ISE) actions regarding the draft.

The IESG conflict review results were as follows:

"The IESG has concluded that this document extends an IETF protocol in a way that requires IETF review and should therefore not be published without IETF review and IESG approval."

Additionally, Eric Rescorla, who performed the review on behalf of the IESG, stated the following in his ballot comments:

"Because it extends a document (RFC 5208) that was published via the IETF process, the appropriate way to proceed is for this to go through the IETF process as well, specifically SECDISPATCH. If the IETF decides it does not want to take it on, then we can revisit this question."

SECDISPATCH discussed the draft at IETF102, and recommended that it not be progressed in the IETF stream. The IESG has no further objections to the publication of the draft in the independent stream.

The IESG, on review of the original recommendation and the events since, believes that the recommendation was appropriate based on the information available at the time. Since the conflict review results are advisory in nature, the IESG sees no reason to withdraw that recommendation. We understand that the ISE reviews ballot comments related to conflict reviews, and is aware of Mr. Rescorla's comments. The IESG trusts that the ISE will make the appropriate decisions based on all the information that is available.

2) Mr. Klensin asks that the IESG note that, in cases where the IESG believes that work should instead progress in the IETF, that it should request a delay in publication on the independent stream while the IETF discusses that work. Mr. Klensin asserts that such a delay is warranted under the procedures in RFC 4846.

The IESG understands the delay allowed by RFC 4846 applies to situations where similar work is already in progress in or being considered by the IETF. That was not the case with this draft. The IESG further understands that the expectation for a timely review in RFC 5742 argues against such a delay.

3) Mr. Klensin asks that the IESG recognize that the primary reason for a "do not publish" recommendation when there is no conflicting work currently in progress or anticipated in the IETF is when an independent stream draft modifies an IETF standards track specification.

The IESG does not understand the chosen conflict review response, as defined in RFC 5742, to be constrained to standards track specifications.

4) Mr. Klensin asks the IESG to consider whether it would be helpful to add a new conflict review response type to RFC 5742.

If the members of the community believe new response categories would be helpful, interested parties are welcome to propose such additions through the appropriate IETF processes. The IESG cannot make unilateral changes to RFC 5742.

5) Mr. Klensin asks the IESG to recognize that the category paragraphs defined in RFC 5742 are for the IESG's convenience, and do not constrain the types of recommendations the IESG can make in a conflict review.

The IESG interprets the list of conflict review response types defined in RFC 5742 Section 3 to be exhaustive and constraining. However, IESG members can offer more nuanced comments separately, or as part of ballot comments during the conflict review process. The latter occurred with the draft in question.

Mr. Klensin makes further supporting comments to argue whether the draft in question should be considered an extension of an IETF protocol, or conflicted with IETF work at the time it was first discussed. The IESG considers these arguments to be moot in light of the SECDISPATCH discussion. After a long discussion, the IESG decided not to re-ballot on the conflict review and understands that the ISE will take the action he deems appropriate based on the totality of the circumstances.


Alissa Cooper
on behalf of the IESG