[Servercert-wg] Document Versioning

[Dimitris Zacharopoulos (HARICA)]

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 
> resolve.
>
> As I see it, from this thread, there's been two objections raised:
>
> 1) Objections over Process
> 2) Objections over Numbering
>
> Process:
> - 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 
> will"
>
> Numbering:
> - 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 
issue."


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

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 
<https://cabforum.org/2015/04/16/ballot-146-convert-baseline-requirements-to-rfc-3647-framework/> 
included a document version into the motion. No other ballot included a 
version number.

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

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


Thanks,
Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190826/3701c5a9/attachment-0001.html>