<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">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">
<div dir="ltr"><br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Sep 15, 2020 at
12:25 PM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr" target="_blank">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> 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). <br>
<br>
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.<br>
</div>
</blockquote>
<div><br>
</div>
<div>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</div>
<div><br>
</div>
</div>
</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>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><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 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 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><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><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 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>