[cabfpub] [EXTERNAL]Re: Ballot 190 - Recording BR Version Number

[Ryan Sleevi]

On Tue, Aug 1, 2017 at 5:58 PM, Wayne Thayer via Public
<public at 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