[Servercert-wg] Document Versioning
Dimitris Zacharopoulos (HARICA)
dzacharo at harica.gr
Sun Aug 25 22:30:25 MST 2019
Actually, I thought we were making progress but thanks for summarizing.
On 21/8/2019 8:17 μ.μ., Ryan Sleevi wrote:
> To be clear, we're going back and forth on the substance of your
> objections, and that's continuing to make it difficult to meaningfully
> As I see it, from this thread, there's been two objections raised:
> 1) Objections over Process
> 2) Objections over Numbering
> - This is objecting to the notion that Ballots can assign version
> numbers *at all*, and a view that Ballots should not be assigning
> versions at all (except for placeholders to be filled by the Chair)
> - Forms of this include:
> - "This is how we've always done it"
> - "What if we have multiple ballots?"
> - "The Chair should be able to change the version number / tables at
> - This is an objection over the specific numbers chosen
> - Forms of this include:
> - "This wouldn't be an issue if the versions were sequential"
> - "What if someone chose a version 100"
> - "People will be confused by why there are gaps"
> I have no regard for the Process objections, precisely because it's a
> Ballot following our Bylaws, and it's right within the text of the
> thing we're voting on. It's functionally part of the document itself,
> at present, and if we want to change that, we need to change our
> Bylaws (and, likely, our Charter) so that the Chair of the CWG can
> exercise version control of the documents. While the exact color we
> paint that bikeshed can be deferred until later, objecting to using a
> Ballot to change the text in a Final Maintenance Guideline rings
> hollow, so let's just ignore those objections, because I don't think
> we'll find consensus on the substance of objections.
Point taken. What you seem to also object to is the existing process
that has been a practice for years so I still don't know if you imply
that all the previous Guidelines are invalid because the Chair assigned
the number and updated some text in the tables of the Final Maintenance
Guidelines. If you want to suggest that your solution is more in-line
with the Bylaws, I get that and we could update our current practice to
follow your suggestion. We just need to ensure this is followed in every
ballot going forward.
It would also help me understand your point of view on similar
established procedures (I call them precedents) if you could tell me
your thoughts about the following:
"In my understanding, the Bylaws is one thing ("the voted law") and the
existing practices is another thing ("customary law"). I am not a lawyer
but I try to follow both "laws". Of course, if there is a conflict
between the Bylaws and existing practices, the Bylaws prevail and the
existing practices must change. If a member challenges an existing
practice, which doesn't seem to be explicitly allowed or which is
explicitly not allowed, then I would bring for discussion as a separate
> With respect to Numbering, the choice was not random. Browser Root
> Programs are seeing, routinely, CAs fail to annually update their
> CP/CPS, or, when they do, failing to detect that there are meaningful
> changes. Our numbering here has attempted to adopt a semantic
> versioning style (Major, Minor, Patch) approach, as used in Software
> and some other standards documents, but never actually defined those
> semantics. What ended up being practiced is a "Count to 10, then wrap
> around" - for no real reason, other than perhaps that's what the Chair
I would also add the "no-one objected" part, which made it acceptable
for years. There was no need to differentiate Major, Minor, Patch levels
before, since it is critical that the Guidelines are followed, even if
there are subtle changes between versions.
As you stated, since there is no meaningful way to distinguish when the
"Major, Minor, Patch" level in the Final Maintenance Guidelines is
applicable, perhaps we could ask the proposer of each ballot to include
a short sentence about his/her classification (Major, Minor, Patch) and
a brief explanation of "why". If members disagree, the classification
could be different.
> Previously, the Forum had discussed (with Ballot 146) using a
> meaningful version - which is why it jumped from 1.2.5 to 1.3.0, to
> signal "Oh, hey, there's big changes". The discussion then was to look
> at a "2.0.0" if/when the Net Sec, EVGs, and BRs were folded into a
> unified CP/CPS, but that never materialized.
Right, that was in April 2015. Ballot 146
included a document version into the motion. No other ballot included a
> If we want to talk about _why_ the numbers were chosen, and _why_
> they're strictly better than the monotonically increasing number being
> used here, the rationale chosen was "This is removing something
> previously permitted" - i.e. a breaking change - and that's exactly
> the kind of thing you'd want to signal with a version number. When we
> add things; say, adding an LEI identifier (as proposed by Tim
> recently), that doesn't require CAs to go and change any existing
> processes. On the other hand, changing the maximum age for the
> certificates and validity does affect existing deployments: the kind
> of thing that's extremely useful to signal with a major version bump.
I believe this is very useful feedback. If members want to explore this
route using Major, Minor, Patch classification for Guideline updates,
some documented rationale would assist in this classification. We could
further discuss here or at the next F2F so that more members can share
> My hope, in forcing this gap, was to be a very clear signal that "Yes,
> things have changed, pay attention". The downside (of CAs wondering
> why there's a gap) is an *upside*, in the hope that it addresses some
> of the real issues we as Root Programs are seeing with CAs following
> things. It also helps make it clearer, when looking at Audit Criteria,
> "just how recent" things are.
> Do we need to use a (Major, Minor, Patch) numbering scheme? Of course
> not. We could have said "The BRs as adopted on 2019-09-09", for
> example, using a date-based scheme that perhaps achieves the above
> objective even better. The numbers don't really matter, we've never
> defined a purpose or structure, but what we do know is that things
> aren't going as well as they could, and there's a real need and
> opportunity to improve things.
Numbers don't matter as in "it is not *required* nor *necessary*" but
they help put a unique reference that is easier to remember. We don't
need to re-invent the wheel. Most international standards use version
numbers and not dates, for easier reference.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Servercert-wg