Skip to main content

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

From: John C Klensin <>
Subject: Appeal of IESG Conflict Review process and decision on draft-mavrogiannopoulos-pkcs8-validated-parameters-02
Date: July 7, 2018 at 12:40:43 PM PDT


After a discussion with the IETF Chair as required by RFC 2026
and concluding that discussion could not satisfy my concerns,
this note constitutes an appeal of the conflict review decision
on draft-mavrogiannopoulos-pkcs8-validated-parameters-02 posted
last month. Because IESG conflict review decision are not
binding on the Independent Submission Editor, this appeal is not
a request that the IESG take a different position on that
document but about the mechanisms, reasoning, and process that
appear to have been followed in this case (including what appear
to be some substantive errors in that process).

In the interest of transparency and because some people might
perceive an overlap between this appeal and some of the issues
being discussed in the context of the RFCplusplus BOF, I am
copying this message to the IETF list.


The provisions for IESG conflict review specified in RFC 4846
and the IESG's explanation of its own procedures for such
reviews in RFC 5742 assume a careful review that is
well-grounded in specifics and that gives the Independent
Submission Edition information to aid in evaluating a document.
In particular, if the IESG is going to ask that something not be
published because it conflicts with IETF work or requires IETF
review, those documents (especially 4846) assume it is obligated
to identify the relevant work, WG, or requirement. Nothing in
4846 assumes the possibility of the IESG saying something that,
in this context, amounts to "the IETF touched this once,
therefore a document should not be published without IETF review
and IESG approval". Neither those documents nor any other
IETF procedure allow the IESG to request a document not be
published (or other action taken) simply on the basis of the
IESG's preferences. The IESG's statement, including the lack of
specific documentation and comments that actually relates to the
underlying documents, suggests that is what occurred here.

The fact that the IESG's conflict review report is only
advisory to the Independent Submission Editor does not change
the above or the nature of this appeal — it is important for
the Internet community that any action taken by the IESG be
carefully considered and follow the spirit of working
cooperatively to make the Internet better, rather than being (or
even appearing to be) expressions of IESG power.

Note that this appeal is about the IESG action, is intended to
avoid similar actions in the future, and is unaffected by any
decisions the ISE might make about next steps with this
particular document.

This appeal requests that the conflict review posted on
2018-06-21 be withdrawn or otherwise reversed and requests
additional actions to prevent the problems represented by that
review in the future.

Actions requested:
(1) The IESG should withdraw the decision announced on
2018-06-21 and explain to the community why it occurred. If the
IESG thinks it is wise to submit a new evaluation to the ISE,
that should be done in a timely fashion and in line with the
suggestions below.
The IESG should recognize that any request to block publication
on the basis that a document conflicts with IETF work or
requires processing in the IETF must identify the
standards-track work, existing standard, or WG involved and that
work must be specifically described in the review (or
readily-available supporting materials that represent IESG
consensus such as ballots or evaluation history). In
particular, "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" is a statement about an IESG conclusion (a very weak
one given three "yes" ballots and eight "no objections") and not
the "appropriate justification" required by Section 5 paragraph
7 of RFC 4846.
(2) The IESG should also note that, if they prefer that the
document be considered for processing in the IETF Stream, rather
than the Independent Submission Stream, it will normally be more
appropriate for them to request a delay while the document is
considered in those contexts rather than requesting that
publication be blocked (note that RFC 4846 explicitly provides
for such a delay request). A document proposing or documenting
new work that has been considered but rejected for IETF
processing is almost by definition not in conflict with (or an
end run around) IETF work. The exception would be a "path not
followed" document, but this would explicitly state that it was
different from the IETF consensus. If there is no
specifically-relevant active IETF work, relevant standards do
not explicitly require IETF review of their applications, and
authors can make a persuasive case that the Internet community
would benefit from publication of the document for the
community's information, the document is an appropriate
candidate for Independent Submission processing.

In particular, if the IESG believes that a document should be
considered for adoption (or recommendation for processing as an
AD sponsored individual submission) by a particular WG or other
process, it should make the needed inquiries and report the
results to the ISE and author(s), not say, as the IESG
Evaluation Record does, "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." RFC 4846 was intended to be
very specific that the conflict review process was not to be an
iterative negotiation between the IESG and the ISE as to whether
a document conflicts with IETF work: it either does or it

(3) The IESG should recognize that the primary use case for a
"do not publish" finding when there is no current or immediately
anticipated work on the subject matter in the IETF occurs when a
document appears to modify (including updating, revising,
interpreting, etc.) a standards track specification.

(4) The IESG should consider whether adding another response
category to the list in RFC 5742 would be helpful. That
category would be something like "After review, the IESG has
concluded that this document is insufficiently clear that it is
not an IETF standard but is, instead, an alternative to one, a
critique, or otherwise does not fit within the standards
process. The IESG believes it should not be published without
considerable revisions to make the relationship clear in the
body of the document, not just boilerplate". That
recommendation should identify particular sections or areas of
interest and should, ideally, suggest specific changes.

(5) The IESG should remind itself (and update RFC 5742 if
needed) that the category paragraphs are there for the IESG's
own convenience and do not limit what can be said, e.g., if
special circumstances arise, the scope of review should reflect
them as long as those circumstances fall within the requirements
of RFC 4846 (i.e., that this is a conflict review and not a
technical one).
Specific comments on this particular document and situation to
support the appeal.
(a) Despite the claim in comments in the IESG evaluation record,
RFC 5208 (see the evaluation history at
and the one specific comment associated with the three "yes"
ballots) was an AD sponsored Informational draft that was never
developed by the IETF as standards track work or otherwise.
PKCS#8 was an externally-developed corporate standard for which
change control was handed off to the IETF, with at least an
implicit agreement that the IETF would not take actions which
impeded the further development or practice of that
specification or its existing uses (see the IESG note about
backward compatibility in 5208).

(b) PKCS#8, whether in the form described in RFC 5208 or in the
newer description in 5958, is, as the name implies, a syntax or
data structure, not a comprehensive standard in which all values
are defined. Both the current I-D and such earlier examples as
RFC 8351 supply specific sets of values for use with that syntax
and descriptions of how they are applied and interpreted. As
such, they do not extend or alter the basic specifications in
any way, much less conflict with them or with present or future
work that might be done based on those specifications if such
work actually existed.

(c) The current I-D does not modify or conflict with 5958 or
any other set of identifying values for PKCS#8 any more than
registering a new media type conflicts with or modifies RFC 2045
or 6838 or adding a new URN namespace conflicts with or modifies
RFC 8141. In each case, there may be questions as to whether
the new arrangements and their descriptions are clear and
consistent with the base framework or syntax description. Those
are technical issues that were excluded from conflict reviews by
RFC 4846 and 5958 but, if the IESG considers it appropriate, RFC
4946 encourages informal communications between ADs and the ISE
about such issues.

(d) The present Internet-Draft appears to depend on an OID
allocated consistent with PKCS#8 and RFC 5208. The use of
mechanisms rooted in an OID structure, reinforced in this case
by the IANA Considerations of RFC 5958, indicates that there is
no conflict with IETF work or requirement for IETF review to
register or use the technique described in the specification,
nor is there any reasonable basis for blocking publication on
the basis of such conflicts. I suppose one could argue the
community does not benefit from publication of this
specification for its information, but that argument lies
outside the scope of IESG conflict reviews. Additionally, the
OID in the case of this document is in a vendor specific branch
and therefore the draft in its current state does not have wide
applicability outside of that vendors usage. This seemed to
have been overlooked in the IESG evaluation.

(e) This I-D was introduced to the SAAG mailing list in August
2017. The I-D received one positive response and one question
but no other activity. This should be taken as an additional
indication that there is no actual conflict with any ongoing
IETF work. Presumably SAAG would have suggested that some other
WG examine it if that were thought to be appropriate at that
time. In addition, as the SECDISPATCH experiment was
introduced on the SAAG mailing list immediately following the
I-D being posted, that introduction presented an excellent
opportunity for the Security ADs to recommend use of SECDISPATH
for the document if appropriate. The intent of the review
called for by RFC 4846 and its predecessors was to facilitate a
formal check but to do so in the context of a cooperative
relationship between the ISE (and predecessor roles) and the
IESG, not to encourage (or even allow) a last-stage surprise in
situations in which relevant Area Directors had ample warning
about the specification. RFC 5742 appears to this reader to be
consistent with that approach.

thank you for your consideration and best regards,