<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<br>
<br>
<div class="moz-cite-prefix">On 2020-09-16 2:43 π.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvbGV05wyEPA=q0Yaj5qTaB8KQ27vKxqkETetVs23owVfw@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Sep 15, 2020 at 4:18
PM Dimitris Zacharopoulos (HARICA) <<a
href="mailto:dzacharo@harica.gr" moz-do-not-send="true">dzacharo@harica.gr</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> <br>
<br>
<div>On 2020-09-15 9:34 μ.μ., Ryan Sleevi wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr"><br>
</div>
</blockquote>
<br>
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.<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvbGV05wyEPA=q0Yaj5qTaB8KQ27vKxqkETetVs23owVfw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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
<a class="moz-txt-link-abbreviated" href="mailto:questions@cabforum.org">questions@cabforum.org</a>, or if these questions come from Members,
they can post questions directly to the WG public mailing list.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvbGV05wyEPA=q0Yaj5qTaB8KQ27vKxqkETetVs23owVfw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvbGV05wyEPA=q0Yaj5qTaB8KQ27vKxqkETetVs23owVfw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>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.<br>
</div>
</blockquote>
<div><br>
</div>
<div>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?<br>
</div>
</div>
</div>
</blockquote>
<br>
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. </div>
</blockquote>
<div><br>
</div>
<div>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 :)</div>
</div>
</div>
</blockquote>
<br>
We did try to capture the steps in
<a class="moz-txt-link-freetext" href="https://docs.google.com/spreadsheets/d/1gTHJfPoGgv-1oXCtGxqxg887iSyCnPF0bSYfrc4JD30/edit#gid=0">https://docs.google.com/spreadsheets/d/1gTHJfPoGgv-1oXCtGxqxg887iSyCnPF0bSYfrc4JD30/edit#gid=0</a>
but this probably needs to be updated with more details regarding
the preparation of redlines and final guidelines.<br>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvbGV05wyEPA=q0Yaj5qTaB8KQ27vKxqkETetVs23owVfw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>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 :-)<br>
<br>
This would probably require having our entire public
website on GitHub and automate the process. That would be
really something!<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvbGV05wyEPA=q0Yaj5qTaB8KQ27vKxqkETetVs23owVfw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> 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?<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
Can you point me to where you believe this practice is
forbidden?</div>
</blockquote>
<div><br>
</div>
<div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
<br>
Perhaps I misunderstood this particular statement:<br>
<ul>
<li>"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."</li>
</ul>
<p>I'm glad we are in agreement that this practice is not forbidden
and, of course, not required.<br>
</p>
<blockquote type="cite"
cite="mid:CACvaWvbGV05wyEPA=q0Yaj5qTaB8KQ27vKxqkETetVs23owVfw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>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.</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvbGV05wyEPA=q0Yaj5qTaB8KQ27vKxqkETetVs23owVfw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div> Documents with the <b>same effective date</b> would
create a lot of confusion to CAs and Relying Parties.<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>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). </div>
</div>
</div>
</blockquote>
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.<br>
<br>
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.<br>
<br>
<br>
</body>
</html>