<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 3, 2019 at 11:36 AM Dimitris Zacharopoulos (HARICA) via Public <<a href="mailto:public@cabforum.org">public@cabforum.org</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>
    Dear Members,<br>
    <br>
    Following up on recent discussions,<br>
    <ul>
      <li>At the <a href="https://cabforum.org/2019/08/16/minutes-for-ca-browser-forum-f2f-meeting-47-thessaloniki-12-13-june-2019/#Instructions-for-creating-ballots-and-challenges-for-moving-canonical-versions-of-all-Guidelines-to-GitHub" target="_blank">last
          F2F in Thessaloniki</a></li>
      <li>On the <a href="https://cabforum.org/pipermail/servercert-wg/2019-August/000896.html" target="_blank">server
          certificate WG list</a></li>
    </ul>
    <p>and since the current Bylaws (version 2.2) do not address how the
      Chair or Vice-Chair could make any changes whatsoever to the Final
      Guidelines or Final Maintenance Guidelines, I would like to
      prepare a ballot with some administrative language that would
      allow the Forum or WG Chair (or Vice-Chair) to make some changes
      to Final Guidelines and Final Maintenance Guidelines. Please note
      that these practices are already in place and have been followed
      for years without any "official" approval from the Forum or a WG
      and without having received any objections by the Membership.</p>
    <p>Since this is language that would normally be in the Bylaws, and
      while we have <a href="https://docs.google.com/document/d/1EtrIy3F5cPge0_M-C8J6fe72KcVI8H5Q_2S6S31ynU0" target="_blank">other
        issues pending to discuss</a>, I would like to propose to ballot
      these issues separately and once we collect a few, we could update
      the Bylaws including language for all these separate issues. I
      understand that we don't want to make too frequent changes to our
      Bylaws because it involves legal reviews that take additional
      time, etc. <br></p></div></blockquote><div>I don't believe this can be solely done by a change to the Bylaws; I believe it would have to be the Bylaws and the SCWG Charter, since the SCWG would need to designate what part of the Final Guidelines / Final Maintenance Guidelines it adopts are informative and may be edited as such. Does that match your understanding?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><p>
    </p>
    <p>I would like to start with what seems to be an uncontroversial
      issue. There seems to be consensus to allow the Chair or
      Vice-Chair to update informative (non-normative) sections of the
      Guidelines. Here is a list of changes that the Chair or Vice-Chair
      should be allowed to do on a Final Guideline or Final Maintenance
      Guideline before it is published on our public web site and
      without requiring a ballot procedure: <br>
    </p>
    <ol>
      <li>The cover page, <br></li></ol></div></blockquote><div>This is only for the version number, right? </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><ol><li>
      </li>
      <li>The Table of Contents</li>
      <li>Headers/Footers with version numbers and page numbers<br>
      </li>
      <li>The table with document revisions or Document History<br>
      </li>
      <li>The table with Relevant Dates, unless the ballot explicitly
        updates this table</li>
    </ol>
    <p>I would also recommend removing the first paragraph of the EV
      Guidelines which reads:</p>
    <p>"This version 1.7.0 represents the Extended Validation
      Guidelines, as adopted by the CA/Browser Forum as of Ballot SC17,
      passed by the Forum on 21 May 2019 and effective as of 21 June
      2019." I believe it's redundant because this information is
      included in the revision history table and the public web site.</p></div></blockquote><div>Note that the current "effective as of" refers to the document's adoption per our IP review period completing, while the Document History table refers to the effective date of various provisions. You can see this in some of the dates within the existing history table; for example, it wasn't until Ballot 198 (Version 1.6.3) that the Effective Date began aligning with the completion of the IP Review Period, except it then diverged by Ballot 217 (version 1.6.8)</div><div><br></div><div>I highlight this, because there's two elements / two updates:</div><div>1) The version circulated for IP review, which presumably will only be missing the "Effective" date</div><div>2) The version posted to the Website, which would then be updated following the adoption</div><div><br></div><div>Does that match your understanding?</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
    <p>Are there any comments or additional changes that members would
      like to see before I start drafting some language? I plan on
      having something ready by the end of next week.</p></div></blockquote><div>From past discussion, but not specified here, it would seem that implicit in this is a desire to allow the Chair or Vice-Chair to determine the versioning, and prohibiting it via Ballot. Is that correct? That is, only #5 on your list is reserved as "unless the ballot explicitly updates this table", so it's unclear if it's meant that the first four can override a ballot.</div></div></div>