IESG, 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. Summary: 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 doesn't. (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 https://datatracker.ietf.org/doc/conflict-review-mavrogiannopoulos-pkcs8-validated-parameters/history/ 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, john
