[cabfpub] [Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

Ryan Sleevi sleevi at google.com
Wed Sep 16 18:44:58 UTC 2020


On Wed, Sep 16, 2020 at 2:17 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 2020-09-16 8:52 μ.μ., Ryan Sleevi wrote:
> > I realize you've provided further context, but my hope is that by
> > laying out the fundamentally wrong assumptions above, which your
> > further replies build on, we can make progress here in understanding
> > why "Everyone already reviewed the Ballot, what's the harm" is a
> > deeply flawed assumption that permeates the subsequent decision making.
>
> Early in this thread, when you presented the example ballot A and B
> should not produce an IPR review of A + B because failure of either A or
> B would block the other, I agreed that the IPR reviews should be
> distinct. This solves the possible legal issue you described.
>
> The second issue is the creation of an aggregated or separate final
> guidelines which exploded the thread.
>

The two are coupled. You cannot separate these; the IP review is what
produces a Final Guideline. If you separate out for IP review, by
necessity, it separates out the publication of a Final Guideline.


> The logical assumption I make is that CAs, especially the ones outside
> the Forum, assuming they don't check the ballots, IPR Review and such,
> they should at least directly check and monitor when a new Final
> Maintenance Guideline is published. These CAs will either see three
> distinct Final Guidelines becoming effective on the same day [versions
> 1.2.1, 1.2.2 (including changes from 1.2.1) and 1.2.3 (including changes
> from 1.2.1 and 1.2.2)], or one aggregated version 1.2.1 that will
> include changes from all ballots that cleared IPR review.
>
> In my understanding these CAs are better served by bringing the
> aggregated final Guideline to their compliance/engineering department,
> rather than versions 1.2.1, 1.2.2 and 1.2.3. It doesn't make sense for
> me to create 1.2.1 and 1.2.2 since all the introduced changes will be in
> 1.2.3.
>

Put differently, it appears that you're stating the "expected" process if
CAs (whether member or not), should be individually checking each Ballot
and IP review, rather than the Final Guideline, in order to understand what
changes.

I'm saying that's an unreasonable (as practiced) and unfair (in what it
expects) assumption. If you recognize the benefit of understanding what was
in SC30 vs SC31, then it's not clear to me how you cannot recognize the
benefit of seeing that reflected in the Final Guideline.

The very point of creating 1.2.1 is to show what changed from 1.2.0, to
then create a 1.2.2 that showed what changed from 1.2.1. Your approach, of
creating an aggregate 1.2.3, does indeed show *everything* that changed
from 1.2.0, but that's the very problem in the first place! By showing a
series of aggregate Ballots, it destroys the very context that separate
Ballots are trying to preserve, of logically grouping related changes, to
make them easier to process and understand the systemic set of changes.

It appears you recognize that value, but you think it should only exist at
the Ballot level. Yet I'm trying to tell you that we have clear evidence
that it's not working.
It appears you recognize the value of distinction, from the IP review
process, so continuing that to the Final Guideline level produces no new
work; you reuse the exact same document you used for the IP review (by
design, of the IP review process)


> I realize that we are spending a disproportional amount of time debating
> on this, but I honestly can't see -yet- the "disastrous consequences"
> that this can create, and I am very curious to see why I can't see that.
>

Because you've specifically asked me to stop providing references to CA
compliance incidents. In particular, I've got a pattern of CAs, both
Members and non-Members of the Forum, having trouble adapting to changes,
for a variety of reasons. I am fundamentally opposed to anything that makes
it harder to understand the context and relevance of the changes.

You seemingly acknowledge the issue with the IP review, and I would say the
necessity of formation of a PAG would absolutely be disastrous for any
productivity, especially under aggregated changes.

I totally get that the crux of your argument is "Isn't it better for CAs to
be able to see everything that changed at once?", as if it makes it easier
to carefully review and implement changes. However, what we're consistently
seeing is CAs say "Oh, a bunch of stuff changed at once, so we overlooked
things" - and making it clearer, more digestible, to work through each
logical change is one of things to address that. I understand that there's
a "If you have to review each change, it makes it harder to see the big
picture", but that's not the ostensible argument for why you started this
(as I understand it), it was time-savings. And I understand you're saying
"CAs can (and implicitly, should) look at individual Ballots to understand
each of those contextual changes", and in an ideal world, that would be
nice, but that's not the world we live in.

While comparing Apples to Oranges, we definitely see that there are
different approaches used by different vendors, and by the CA/B Forum
itself. And we clearly see variable degrees of compliance, including to
Ballots CAs voted on to specific changes that they were emailed about,
directed to review, and sign and acknowledge that they read and reviewed
such changes, and we're still seeing failures. I want to believe these
failures are addressible by process improvements, because the alternative
suggests that the failure is entirely the fault of each CA that has such an
issue, and that's a far less friendly thought to countenance.

So when you provided anonymous feedback for someone saying they appreciated
the aggregate approach, I hope you can see precisely why the questions I
asked about their process are relevant. And why discussing in the abstract,
of "I could see why this might be nice", still requires unpacking and
answering those questions regarding change management processes. If the
aggregated approach is better for some CAs, rather than the individual
versions, then having them share precisely the path they take to ensure
compliance, and ensure nothing is missed, presumably provides answers for
"How SHOULD it be done?", since we're apparently not to discuss the CAs
whose processes or incidents have shown "How should it NOT be done", to
avoid embarrassing or targeting them (by assuming postmortems are blameful,
rather than blameless).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20200916/1c19c112/attachment-0003.html>


More information about the Public mailing list