IETF conflict review for draft-mavrogiannopoulos-pkcs8-validated-parameters
conflict-review-mavrogiannopoulos-pkcs8-validated-parameters-01

The following approval message was sent
From: The IESG
To: draft-mavrogiannopoulos-pkcs8-validated-parameters@ietf.org,
    Adrian Farrel ,
    Adrian Farrel ,
    rfc-ise@rfc-editor.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-mavrogiannopoulos-pkcs8-validated-parameters-02

The IESG has completed a review of
draft-mavrogiannopoulos-pkcs8-validated-parameters-02 consistent with RFC5742.

The IESG recommends that 'Storing validation parameters in PKCS#8'
NOT be published
as an Informational RFC.

  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.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine whether or
not they merit incorporation into the document. Comments may exist in both
the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-mavrogiannopoulos-pkcs8-validated-parameters/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-mavrogiannopoulos-pkcs8-validated-parameters/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
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.

[Ballot comment]
I have reviewed this document. Because it extends a document
(RFC 5208) that was published via the IETF process, I believe
that 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.

For that reason, I believe that the appropriate response
is the one I have listed.

[Ballot comment]
I do not object to the conclusion per se, but I note that Adrian argues (in the shepherd writeup) that this is an implementation option that does not need to update RFC 5208 or RFC 5958.

I am agnostic about the correctness of either position.