On 2019-09-03 6:50 μ.μ., Ryan Sleevi wrote:
On Tue, Sep 3, 2019 at 11:36 AM Dimitris Zacharopoulos (HARICA) via
Public <[email protected] <mailto:[email protected]>> wrote:
Dear Members,
Following up on recent discussions,
* At the last F2F in Thessaloniki
<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>
* On the server certificate WG list
<https://cabforum.org/pipermail/servercert-wg/2019-August/000896.html>
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.
Since this is language that would normally be in the Bylaws, and
while we have other issues pending to discuss
<https://docs.google.com/document/d/1EtrIy3F5cPge0_M-C8J6fe72KcVI8H5Q_2S6S31ynU0>,
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.
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?
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:
1. The cover page,
This is only for the version number, right?
Version and effective date, and probably the year in the "Copyright" footer.
1.
2. The Table of Contents
3. Headers/Footers with version numbers and page numbers
4. The table with document revisions or Document History
5. The table with Relevant Dates, unless the ballot explicitly
updates this table
I would also recommend removing the first paragraph of the EV
Guidelines which reads:
"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.
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)
I highlight this, because there's two elements / two updates:
1) The version circulated for IP review, which presumably will only be
missing the "Effective" date
2) The version posted to the Website, which would then be updated
following the adoption
Does that match your understanding?
The correct "effective date" is when the IP review is complete and no
essential claims are filed. This is the only date that should be in the
"Effective" column of table 1.2.1. The "Adopted" column should be the
date of the initial voting when the ballot passed. If you check version
1.6.4, you can see that we had 3 ballots, 3 different "Adopted" dates
but one "Effective" date when the IP review was completed. We usually
first send the results to the public list so documents are published on
the web site a bit later. However, the date of publication on the web
site is not related to the effective date of the document. Does this
answer the question?
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.
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.
I deliberately left this out because I would like to discuss the
document version issue on a separate ballot because I am not sure how
controversial or not it would be. At this point, I would not like the
first four to be overridden by the ballot. Is that ok, for now?
Thanks,
Dimitris.
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
