[Servercert-wg] Document Versioning

[Dimitris Zacharopoulos (HARICA)]

On 19/8/2019 9:42 μ.μ., Ryan Sleevi wrote:
>
>
> On Sun, Aug 18, 2019 at 4:39 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>
>
>
>     On 17/8/2019 9:21 μ.μ., Ryan Sleevi wrote:
>>
>>     On Sat, Aug 17, 2019 at 3:46 AM Dimitris Zacharopoulos (HARICA)
>>     <dzacharo at harica.gr <mailto:dzacharo at harica.gr>> wrote:
>>
>>         Until today, the Chair or Vice-Chair was assigning numbers to
>>         documents. If you want us to have a consistent numbering
>>         scheme with major and minor numbers, you could propose such a
>>         scheme in a Bylaws update. We could also add it in the topics
>>         for discussion in an upcoming governance subcommittee.
>>
>>         This is more of an administrative issue and should be
>>         disconnected from the ballot language.
>>
>>
>>     Hi Dimitris,
>>
>>     I forked this thread so as to hopefully disconnect.
>
>     +1
>
>>     As you no doubt recall, given that it's come up with numerous F2F
>>     and phone conversations, we don't really have a process in place
>>     to allow the Chair and Vice-Chair to make modifications to
>>     Ballots as they're adopted. The inclusion of informative revision
>>     history, within our documents, also means that we can't simply
>>     take the document as-is and allow the chair to ascribe a version
>>     to it.
>
>     I disagree. Looking back, this has always been the case with the
>     Final Maintenance Guidelines. The Chair assigned a version number
>     and updated the informative revision history. In some cases, the
>     Chair also updated the "relevant dates" table when the ballot
>     proposer forgot to include this. All Members accepted this
>     procedure and so far no objections have been raised.
>
>
> Would it be useful to dig up the minutes that contradict this summary?

I'm not so sure I understand what you are asking here. All I'm saying is 
that for all the versions of the BRs and EV Guidelines I have seen so 
far, it was the Chair's task to incorporate the "ballot language" into 
the latest Guifeline, update the two tables I mentioned, assign a new 
version number to the document, update the table of contents and publish 
it on the public web site. This is the precedent I am talking about. I 
don't know if this was an "approved" procedure by the Forum, but if it 
was it must have been from the very early days, before I joined the 
Forum. Perhaps Ben, Dean and Kirk (previous Chairs) can assist us here.

>>     Despite this, you can see I tried to explicitly make it clear in
>>     the Ballot what the Chair or Vice-Chair could change, in order to
>>     ensure that these changes were captured by Ballot.
>
>     I noticed that, it looks good. We could also ballot a procedure to
>     support what you wrote in SC22 so we don't have to repeat this in
>     every ballot.
>
>
> Yes, that's definitely a solution. I'd love to find something even 
> better/easier, so we can formalize the informal process in a way that 
> does not create any concerns or risks. Hopefully that should be 
> uncontroversial. However, in the absence of such formalization, I've 
> tried to work within the rules we have written down.
>
>     With that said, and although I do not object to your proposed
>     scheme (changing the BRs to 1.8 instead of 1.6.6 and the EV
>     Guidelines to 1.8 instead of 1.7.1), I disagree with this being
>     proposed in the ballot without prior discussion. It creates a
>     disconnect to the existing versioning. The CABF has been using a
>     consistent numbering scheme since version 1.4.2 in the EVG and
>     1.3.0 in the BRs. Suddenly both documents will "jump" to 1.8. What
>     if another member proposes a ballot updating the documents to
>     another arbitrary number like "100"?
>
>
> The discussion period of the Ballot is 2 weeks. I'm not sure if you're 
> suggesting there should be a pre-ballot discussion period, and perhaps 
> even a pre-pre-ballot discussion period, in addition to a Ballot 
> discussion period, and to what extent language should be expected to 
> be finalized at each step. As several members have noted on the past 
> phone calls, the best way to get feedback is to put the actual, final 
> text out there, as a Ballot, so that feedback is gathered during the 
> discussion period.

I am not suggesting we change anything in the discussion period. I am 
just saying that the ballot language should not propose a version number 
for the Final Maintenance Guideline. I have already provided arguments 
about the risk of allowing members to propose specific version numbers 
of the Guidelines. In addition, think about a case where we have ballots 
running in parallel. The Chair has been resolving these conflicts, 
making sure that ballots are incorporated in Final Maintenance 
Guidelines without versioning issues.

>>     I agree that we could potentially change our Bylaws or the
>>     process for Ballots within the respective CWGs, since it
>>     functionally ties to the Final Guideline / Final Maintenance
>>     Guidelines of the CWGs, to allow the Chair or Vice-Chair
>>     additional flexibility here. As I've stated in the past, I'm
>>     supportive of viewing those two respective sections in our
>>     documents (version history and effective dates) as informative,
>>     non-normative sections - i.e. having no binding weight on members
>>     - and thus supportive of allowing flexibility to edit. I also
>>     support that flexibility for versions.
>>
>>     However, as we don't have that flexibility now, I thought it best
>>     to play it safe.
>
>     As we are getting closer to moving the "canonical versions" on
>     GitHub (that requires change to the Bylaws), I'm sure this
>     flexibility will be covered one way or the other.
>     However, when we have an established practice for years with no
>     objections or problems, this automatically becomes kind of a norm.
>     I think it is safe to continue with the existing precedent until
>     we can discuss separately and get consensus on a versioning scheme.
>
>
> That's certainly an option! And that's why it's important to formalize 
> some of our processes. Luckily, as this is a Ballot, and not an ad-hoc 
> decision by a member to reinterpret a portion of our Bylaws, we have 
> the opportunity to discuss and vote on it.

As you already said, it's best to disconnect the discussion about a 
ballot related to shortening the lifetime of certificates and other 
administrative issues like the versioning scheme. I think it would be 
best if you replaced 1.8.0 with 1.x.x in the red-lines.

Your text "/Should this ballot be adopted, the Chair or Vice Chair shall 
be directed to correct “SCXX” to “SC22” and “XX-Xxx-2019” within both 
documents’ informative tables to the date of the completed ballot, prior 
to or following the IP Review Period, and “Xxxx XX” to the effective 
date/date of publication of the Final Maintenance Guidelines./" would 
then need to be replaced with something like:

"/Should this ballot be adopted, the Chair or Vice Chair shall be 
directed to correct "1.x.x" with the version number of the updated 
guideline, correct “SCXX” to “SC22” and “XX-Xxx-2019” within both 
documents’ informative tables to the date of the completed ballot, prior 
to or following the IP Review Period, and “Xxxx XX” to the effective 
date/date of publication of the Final Maintenance Guidelines./"

I will try to work on some language before the Fall meeting that will 
allow these changes in a formal way, following the results of the 
relevant discussion at the latest F2F 
<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>.


Thanks,
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190820/4db01816/attachment.html>