[Servercert-wg] Document Versioning

[Dimitris Zacharopoulos (HARICA)]

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.

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

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

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

>
> Perhaps you'd like to write down what the Chair or Vice-Chair should 
> be able to change, and we can see about formulating a Ballot to permit 
> that?

Sure, I can draft something up. For now, I added these two issues in 
https://docs.google.com/document/d/1EtrIy3F5cPge0_M-C8J6fe72KcVI8H5Q_2S6S31ynU0.


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