[Servercert-wg] Document Versioning

Ryan Sleevi sleevi at google.com
Mon Aug 26 06:33:11 MST 2019

On Mon, Aug 26, 2019 at 1:30 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> Now, if CAs are going to vote against the Ballot on the basis of the
> number - and I wholly admit, this ballot "conveniently" gives them the
> excuse to suggest that they're voting against it not because of the dates,
> but because they don't like the numbers - then that's disappointing, but at
> least it's clear what their priorities are, and that's useful for the
> ecosystem. If folks feel that adopting "1.8.0" is somehow going to doom the
> Forum or the Servercert WG into a life of reprobate versioning in which up
> is down, day is night, and cats and dogs live in harmony, then as laughable
> as that is, we still have time to change. But we should really be carefully
> thinking about what the substance of the objection is, and why it's there.
> And, perhaps more importantly, what folks feel is the "right" solution for
> CAs and the ecosystem not being aware that things are meaningfully
> changing, and what once was allowed, is now no longer.
> To reverse the question, why do you consider that using the next number
> (following the existing sequence) will doom your Ballot? IMHO moving away
> from the "norm" (even when this is set by "precedent") should be justified.
> Again, I don't care if the ballot allows the Chair to change the number
> after the vote is complete but I would prefer if you used the next number
> in the sequence, otherwise we "jump" versions without a good explanation.
> Moving from 1.2.5 to 1.3.0 via ballot 146 was justified because of the
> complete document restructuring into RFC3647 format. If we take this
> example as one of the reasons for "jumping" versions, I don't think ballot
> SC22 meets that level. However, if this is your way of signalling to CAs
> and the ecosystem to be "more aware" of this change, perhaps we should
> discuss a bit further so that we establish a good procedure and the
> versions don't change major numbers for less meaningful changes.

Dimitris: I'm wanting to make sure I understand your latest objection. You
believe it is important to object to an attempt which can help CA
understanding and compliance, because the numbers are not sequential, and
because sequential numbers - which have to date harmed CA understanding and
compliance - are how we've always done it, right?

When you frame the question as not justified, you're implicitly stating
that it is more important to follow an unspecified practice, which you
acknowledge as such, then to make an earnest effort to help better improve
the state of the ecosystem. From your previous emails, you indicated that
you believe sequential numbering is important, because it does not force
CAs or relying parties to closely examine what changed and why, but as
noted, that's exactly the property being desired here. This approach may
not work out either, but given that you shared the same concerns as I had
for the objectives, it seems that it's important to make an effort to help
improve things, don't you agree?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190826/30c3c1de/attachment.html>

More information about the Servercert-wg mailing list