--On Saturday, July 7, 2018 20:10 -0800 Melinda Shore <melinda.shore@xxxxxxxxx> wrote: > Right, and I don't think the answers to those questions are > nearly as clear as your appeal suggests. The attribute's > inclusion doesn't mandate that the primes be validated but it > makes it possible that they are, and I think that if there's a > semantic change to the protocol the IESG has a point. IMO, only if there is something in the PKCS#8 specs that says to validate, or not validate, primes. However, the more important point for me is that, if the IESG has said, e.g., "because this alters the way that RFC 5208 and 5859 treat validation of Primes, we think it alters an IETF specification and must be processed in the IETF", we would be having a rather different discussion or no discussion at all (at least I wouldn't be part of it). I'm fairly indifferent whether that part of the response appeared in the text of the response or in something recorded in the evaluation record as long as it is clear that it is the IETF's opinion and not that of one AD and, in the light of the ISE's ability to consider IESG advice and then not take it, I find the question of whether that type of conclusion would, in this case, be a conflict evaluation or a technical one to be fairly uninteresting. The main objection, in the simplest possible terms, is to the IESG saying "... extends an IETF protocol in a way that requires IETF review" without identifying the protocol and why, in fairly specific terms, the IESG thinks it is being extended. I believe that exactly the things that cause you to say that things are now as clear as the appeal suggests are the ones that cause me to claim that the IESG owes the community more explanation of why it made the decision it did and that future decisions like this should not be approved without that type of explanation being present. There is also a question as to whether comments in the evaluation record are sufficient for that purpose because the community has no way to tell whether those were just comments by one ADs or information the IESG as a whole relied on when deciding to approve the "do not public" request. > After > all, it's not just some random chunk of data that's irrelevant > to handling the private key. But I really don't know what the > intent here was so I'm just not sure, and I'm hopeful that a > little more clarity about the context and intended use might > put some of those questions to rest. Agreed completely on the substance and what should be in the document. best, john
