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