Appeal of IESG Conflict Review process and decision on draft-mavrogiannopoulos-pkcs8-validated-parameters-02 (John Klensin; 2018-07-07) - 2018-07-07
Response - 2018-08-16

From: IETF Chair <chair@ietf.org>
Subject: Response to appeal of IESG Conflict Review process and decision
on draft-mavrogiannopoulos-pkcs8-validated-parameters-02
Date: August 16, 2018 at 10:46:45 AM EDT
To: ietf <ietf@ietf.org>
Cc: John C Klensin <john-ietf@jck.com>, IESG <iesg@ietf.org>

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