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

Ryan Sleevi sleevi at google.com
Tue Sep 15 16:43:46 MST 2020


On Tue, Sep 15, 2020 at 4:18 PM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
>
> On 2020-09-15 9:34 μ.μ., Ryan Sleevi wrote:
>
>
>
> On Tue, Sep 15, 2020 at 12:25 PM Dimitris Zacharopoulos (HARICA) <
> dzacharo at harica.gr> wrote:
>
>> I think you have a point about A + B, so we should have independent
>> review periods for each ballot as we did with version 1.6.4 (we had
>> independent ballots to be reviewed and then a combined/aggregated new
>> version of the BRs).
>>
>> I also received some personal messages supporting the "aggregated"
>> practice as it seems to be much more efficient for a CA's compliance review
>> to check against one new BR rather than 2 or 3 separate ones within a very
>> short timeframe.
>>
>
> As Chair, could I ask you to encourage these to be shared on the list? I
> think it's troubling the increased amount of off-list messages used to
> justify Forum behaviour. This feels very much like the mode which the Forum
> explicitly tried to move past with our move to open lists and minuted
> calls, so that we can more accurately understand perspectives and ask
> questions. Certainly, I hope it should be uncontroversial that the Forum
> helps us understand the many different perspectives and constraints, and
> this sort of "appeal to private communication, anonymized, without data"
> actively harms the ability of the Forum to function and improve. This is
> part of why we have public discussion
>
>
> Sure, I can do that but in any case I forwarded it the argument on the
> list. I also support this argument that aggregating new versions of the
> documents saves time.
>

While you're the only one qualified to measure whether it saves time, as a
browser, this raises a host of questions for understanding how CAs are
staying abreast of changes and reviewing them. This is actually critical,
given that I've seen multiple CA incidents where CAs have reported that
they have trouble staying abreast of changes, even for ballots they voted
for! So it suggests to me that some of the current ways that CAs are
keeping up to date are flawed, or lend themselves to easy mistakes.

Naturally, if we had the specific member, we could ask them to describe
their process for staying aware of changes, and why one document makes that
easier. For example, I'd be deeply concerned if a CA was looking at an
aggregated SC28+SC35, since they might mistake a meaningful normative
change as a cleanup or clarification, or similarly, mistake or overlook an
important clarification because they're distracted by logging changes.

Indeed, I'd be quite worried if someone was specifically using the Redline
PDF for reviewing changes (in the full document), without also looking at
any supporting discussion and included redlines, to also make sure they
have an at-a-glance understanding of what's changing. Of course, I'm not a
CA, so it's much better to hear, in a CAs own words, the processes they
employee, so they can describe why one document saves more time.

Selfishly, my priority is not in saving time for CAs, if saving time risks
correctness. I'd much rather ensure CAs do the right thing, and
consistently implement it, even if it means they have to take more time to
be careful and thorough. This is no different from me wanting to make sure
my surgeon was certain my spleen needed to be removed, before scheduling
the surgery, rather than just have them open me up and see what looks
interesting or relevant.


> Once I have the review period redline ready, it usually takes between 30
>> minutes to 1 hour to create the final documents, upload them to the wiki
>> (the word versions), produce the final PDF versions and upload them to the
>> public web site.
>>
>
> Wow! I wouldn't have expected this to be more than 5 minutes, so that's a
> really surprising amount of time!  Do you know where the bulk of the time
> is, so we can prioritize? That said, it sounds like your response here
> aggregated 2-5 - is that roughly right?
>
>
> Yes, because to produce a Final Guideline and a redlined version in a
> non-GitHub version is quite painful. In the GitHub version, things are
> faster but again I need to create the redline manually, compare the two
> .docx versions produced by GitHub (before and after the merge to Main),
> check everything like track changes mode, make sure the ToC is not tracked
> and other minor details.
>

I'm not really sure I understand this process. It might be useful to have a
demonstration on an Infrastructure WG call, to best see the challenge.
Beyond helping the (presumptive, given single candidate) future chair, it
might also help figure out opportunities for improvement here :)


> Then, create a PDF without the formatting comments (otherwise the PDF
> contains formatting changes in the redline which doesn't look good). Then
> make the changes to the web sites, wiki, etc. I wish I could make that in 5
> minutes :-)
>
> This would probably require having our entire public website on GitHub and
> automate the process. That would be really something!
>

Certainly, a number of other SDOs have managed this in a variety of forms!
So it's not at all inconceivable, and that's why I'm trying to understand
the process, so we can of course make it easier and simpler; for you, and
for whomever the future Chair(s) may be. The more time we spend on process,
understandably, the less time we spend on progress, and so the more that
can be shared about the work involved, the better we can improve things.

> Would your concerns be addressed if we had a separate/distinct IPR review
>> for each ballot and once each IPR review is cleared with no essential
>> claims filed, produce an aggregate document, or you still prefer separate
>> Final documents with distinct versioning to be created? What do others
>> think?
>>
>
> The IP review necessitates the production of the Final document, so that
> sounds like more work, rather than less, and it seems to run in the same
> problem of commingling outputs.
>
>
> During my entire time as Chair of the Forum and the SCWG I have tried to
> perform my duties following the Bylaws to the best of my knowledge and
> understanding. Just in case I had misunderstood these requirements, I
> shared this process with the Vice Chairs who are native English speakers.
> We all agreed that aggregating the final Guidelines was allowed and not in
> conflict with our Bylaws.
>
> Can you point me to where you believe this practice is forbidden?
>

Can you mention where I said it was forbidden? I'm not sure how best to
answer your question, and so I think this might require disentangling what
you think I said versus what I said.


> I honestly don't mind the extra work of creating more Guidelines but it
> seems pointless to create a document that nobody will ever read because it
> will be valid for just a few seconds.
>

I described, at length, why it was meaningful, from both an IP perspective
and from a document versioning perspective. It sounded like you agreed
with, or at least understood, those challenges, so I'm not sure I
understand what you're trying to say here.


> Documents with the *same effective date* would create a lot of confusion
> to CAs and Relying Parties.
>

I'm also not really sure I understand this. It appears you're saying here
that CAs ignore the version, and focus on the date, while in the past,
you've specifically objected to changes in versioning, because you've
argued that CAs focus on the version.

Are you saying that having a BRs 1.2.0, 1.2.1, and 1.2.2, and 1.2.3 creates
a lot of confusion to CAs and Relying Parties? Because that's /four/
versions within the 3 day window of the Bylaws. (14 Oct - 16 Oct).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20200915/4dbb1591/attachment.html>


More information about the Public mailing list