On Tue, Aug 1, 2017 at 5:58 PM, Wayne Thayer via Public <public@cabforum.org> wrote: > The original concern I raised was with the ballot 190 requirement that CAs > begin to log the BR version number associated with the validation method used > on each request. My concerns are: > 1. The BR version doesn’t clearly indicate when a validation method has > changed. As has been stated, the BR version number will surely increment for > many reasons unrelated to validation methods. BR version 1.8.3 is likely to > have the same meaning as version 2.1.6 in terms of validation methods.
Right, but surely every CA is reviewing their entire practices (and the implications of each ballot) with every subsequent update, right/ > 2. CAs will review changes to the validation methods and come to different > conclusions as to what changes require the BR version number to be > incremented in their logs. Is a wording change material, even though I’m not > updating the code? The ballot author should decide this. I'm not sure I fully understand this concern. Could you elaborate, perhaps with a past example of ambiguity? If your goal is to ensure that CAs have an unambiguous interpretation, then, as we've seen, that's an issue that's orthogonal to recording what version number exists - it's an issue regardless, and which rests on CAs having the necessary technical understanding to interpret things. It rests on a CA's ability to determine whether or not what they do complies - and that's independent of materiality, and simply an assessment of "Is what we are doing consistent with Method X of Version Y of the BRs". Moving that to a per-method version number doesn't change the need to make that assessment, and thus, materiality is always up to the CA evaluating their process and procedures. > 3. CAs generally need to implement changes to methods prior to a BR version > number even being assigned. I closely review ballots, but I don’t track BR > version numbers. Could you explain this further? After multiple concerns raised by CAs in the past, we've fairly consistently adopted a process of effective dates. Isn't this issue entirely irrelevant in the face of effective dates? Further, given that CAs don't have clarity on the IPR until a version number has been assigned (completing both the Ballot and the Review Period), aren't CAs undergoing risk to adopt changes prior to the publication? I can totally understand this perspective, for what it's worth, but I'm highlighting that it seems inconsistent with the other complaints CAs have made, and the current proposal attempts to best balance those complaints against the need. > > This led me to propose a version number embedded in section 3.2.2.4 of the > BRs that covers either all validation methods or one for each method – it > doesn’t matter to me. This approach: > 1. Provides clear guidance that the CA must update the version number they’re > logging as part of implementing a particular change I'm not sure it provides that necessary clarity, since each CA must still review their individual policies and practices to assess compliance. > 2. 2. Allows CAs to make changes based on approved ballots rather than being > dependent on BR version numbers Bypasses the IP policy. > 3. Doesn’t require a separate section of the BRs to be updated and kept in > synch I'm not sure I understand this objection, unless it's an objection to Kirk's proposal, to which I would agree. Otherwise, we're already keeping a change log to the BRs (with effective dates), which would seem sufficient for your needs here. > 4. Can easily be added to ballot 190 while we’re waiting for ballot 202 _______________________________________________ Public mailing list Public@cabforum.org https://cabforum.org/mailman/listinfo/public