[Servercert-wg] Document Versioning

Dimitris Zacharopoulos (HARICA) dzacharo at harica.gr
Tue Aug 27 00:42:02 MST 2019

On 26/8/2019 4:33 μ.μ., Ryan Sleevi wrote:
> On Mon, Aug 26, 2019 at 1:30 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto: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?

Not at all. If we want to signal a "significant change" to CAs and the 
ecosystem, all I'm saying is that we need to discuss what is the proper 
way to do that. Is it a "bump" in the version number? Is it a blog on 
our public web site? Is it both? Other ideas?

My impression (and I don't know this for a fact) is that every change in 
the Guidelines is "significant enough" for CAs to pay attention. Perhaps 
this is why the numbers were sequential. Again, I would defer to the 
previous Chairs to clarify.

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

I'm sorry for not phrasing it correctly. This is clearly not what I 
wanted to convey so let me try again. When we have an existing 
unspecified practice in place (like the fact that the Chair adds a 
version number, updates the two tables and adds a table of contents), 
which has not been objected to for years, this is not a reason to 
consider it wrong, malicious or something that produces harm. Merely the 
fact that it is unspecified in the Bylaws shouldn't be dismissive of a 
practice. Existing unspecified practices could definitely be improved if 
suggested so by any member, as we have demonstrated in the past. For 
example, we agreed in F2F meetings (and not in the Bylaws) that in order 
to get a ballot number, a ballot proposer must already have two 
endorsers and then can "reserve" a number. If an improved practice is 
presented, we have no reason not to proceed with the improved practice.

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

Of course we want to improve things which is why I wanted to open up a 
discussion to members and describe the problem we are trying to solve. 
The problem is "we want to be able to signal to the CAs and the 
ecosystem, via the version number of the Guideline, whether significant 
changes or changes that affect compliance, are introduced". Is that a 
fair description of the problem?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190827/a5cc07d6/attachment-0001.html>

More information about the Servercert-wg mailing list