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

[Dimitris Zacharopoulos (HARICA)]

On 2020-09-16 2:43 π.μ., Ryan Sleevi wrote:
>
>
> On Tue, Sep 15, 2020 at 4:18 PM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>
>
>     On 2020-09-15 9:34 μ.μ., Ryan Sleevi wrote:
>>
>
>     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.
>

I hope you realize that this is not related with Forum's activities. The 
Forum produces standards/Guidelines. Whether CAs, Relying Parties adhere 
to those standards/Guidelines and update their processes/products is a 
different issue.

> 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.

I don't think that's necessary. It seems very reasonable to me that 
reviewing one redline document that introduces changes from two or three 
ballots, is more convenient and simpler than having to review two or 
three redline documents to reach the same result.

If there are questions about a new requirement or an introduced change, 
the discussion of the specific ballot that introduced the change is 
there for anyone to review and get a better understanding on the 
rationale and get clarifications. In some cases, even that is not 
enough, and we encourage people to submit questions to the 
questions at cabforum.org, or if these questions come from Members, they 
can post questions directly to the WG public mailing list.

>
> 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.

My priority here is to serve the SCWG and the Forum in a compliant and 
productive manner. If the SCWG Members have no objection to the current 
practice of aggregating Final Guidelines when we have timelines that 
permit this aggregation, I will continue with this practice.

>>         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 :)

We did try to capture the steps in 
https://docs.google.com/spreadsheets/d/1gTHJfPoGgv-1oXCtGxqxg887iSyCnPF0bSYfrc4JD30/edit#gid=0 
but this probably needs to be updated with more details regarding the 
preparation of redlines and final guidelines.

Even going through this page every time to make sure nothing is missed, 
takes time :-) I'd be happy to discuss this process further at an 
Infrastructure Subcommittee call.

>     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.

I am aware of some and although it's not inconceivable, it's certainly 
very difficult to accomplish considering that we have repeatedly 
discussed doing a review of our existing public web site, remove 
obsolete information and update what needs to be updated. I hope the 
next chair(s) will have the energy to drive this process and update the 
public web site.

>>         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.

Perhaps I misunderstood this particular statement:

  * "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."

I'm glad we are in agreement that this practice is not forbidden and, of 
course, not required.

>     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.

What I'm trying to say is that creating a document with version 1.2.2 
and 5 minutes later another with version 1.2.3, makes 1.2.2 valid for 
just 5 minutes because everyone will just download and read 1.2.3 that 
incorporates the changes introduced in 1.2.2. It seems meaningless (from 
a practical standpoint) to create 1.2.2 since it will not be of use by 
almost anyone.


>     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).
But if the review periods end Oct 14 - 16, I will prefer to spend one 
day working with the final guidelines and post the results. I probably 
don't want to spend one day producing 1.2.1, publish the resulting 
document to the mailing lists, update the web site, then do the same the 
next day for 1.2.2. This means that all these Guidelines will be sent 
(and thus become effective) on -say- 16 Oct.

 From a compliance perspective, all 4 documents (with 4 distinct 
versions) would be effective on 16 Oct which might create challenges and 
confusion. I would like to avoid that an either aggregate or ensure we 
have different effective dates so that at every single day there is one 
and only one normative version of the Guideline in effect. Hope this 
makes more sense then the previous attempt.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20200916/14b85f87/attachment-0003.html>