[Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

[Ryan Sleevi]

On Tue, Sep 15, 2020 at 4:33 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> On 14/9/2020 8:08 μ.μ., Ryan Sleevi wrote:
>
> Yes, I'm aware of the "what", but it's not clear the "why".
>
> The act of combining ballots is relatively new, as you can see from
> https://cabforum.org/baseline-requirements-documents/ . Producing
> multiple versions of the Guidelines, linear based on when the Ballot
> concluded, was something our GitHub flow intentionally was to make easy.
> While that page stopped listing dates of adoption around Ballot 189, you
> can see previous ballot pairs (e.g. 171+164, 125+118+134+135) that did that.
>
> It seems worth figuring out the challenges you're facing, since it was
> meant to be very easy to create a new version of the document for each
> ballot, even ballots that conclude closely, and to have IP reviews as such.
>
>
> The administrative overhead of updating public web sites, sending
> additional emails, and the fact that we would have versions of the
> Guidelines that would be valid for a few seconds (which seems unreasonable
> for a public standards document), are some of the reasons behind aggregated
> final guidelines. Version 1.6.4 aggregated 3 ballots, 1.6.7 and 1.7.1. had
> 2 and now 1.7.2.
>

> This process was discussed with Dean and Wayne back in February 2019, and
> we all considered it compliant with our Bylaws. The results of each IPR
> review period were sent to the public lists without receiving any
> objections or concerns.
>
> Although we have documented a GitHub workflow that supports the most
> common case (one ballot, one IPR review, one Final Maintenance Guideline),
> it should not prohibit aggregated ballots to minimize administrative
> overhead or the production of Guidelines that have some reasonable validity
> time.
>
> If there are strong objections to this process, we can revise it going
> forward.
>

I think we should understand the concerns, so we can make sure we have
solutions that work.

The concerns for aggregated ballots is that, from an IP perspective, it
makes multiple ballots share the same fate and can easily delay adoption.
For example, imagine there are Ballots A and B. A makes a change to one
section, B makes a change to another, and only through their combined
implementation does a Member raise an IP concern.

In the serialized approach, A then B, A can be introduced to the IP review
and not introduce any IP obligations. It can become effective. When B is
introduced and undergoes IP review, and an exclusion is filed (on the B+A),
then B is basically sent to the PAG to work through what to do, while A
remains effective.

In the combined approach, A and B, when A+B trigger the IP review and
result in the IP obligation. An exclusion is filed, and now A+B are sent to
a PAG. The act of understanding whether it is A introducing the IP
obligation or B introducing the IP obligation is left for the PAG to sort,
with neither A nor B being effective until the PAG reaches recommendations.

This was a concern debated at length throughout our governance process, and
was indeed one of the core motivations for our IPR policy update (which,
you may recall, was motivated by the removal of the "any other method"
introducing obligations on the other enumerated methods). Our IP policy was
revised to try to make it easier to distinguish whether A or B was
introducing the obligation, and allow modifications like A (and subsequent
modifications) to continue, even while B was addressed within the PAG.

Beyond that explicit reason, the distinct versioning also helps better
review changes and tie back to ballots. It treats Ballots as they are -
logical units of change - rather than aggregations of change. The Forum
first started with an aggregation-of-change approach (through submitting
amendments and errata) and quickly confounded the ability to understand the
reconciled state. The same issue applies to unified ballots. Given that we
have CAs asserting that it's difficult to find changes in Ballots they
explicitly voted for, after lengthy reviews, and with policies incorporated
in at least two root programs, I'm incredibly sensitive to wanting to make
sure CAs are set up to succeed in following the Requirements, by making
changes discrete and digestible.

So that's the context about "why" serialized was intended. I'm also totally
sympathetic to the difficulty involved in producing ballots, especially as
we haven't quite got automation up to speed, and so I can understand why
wanting to avoid that work is undesirable. What I take from your reply is
that there are several tasks that, as a consequence of our current tooling,
represent undesirable time commitments. It's unclear if that's "5 minutes
more" or "5 hours more", and so your help in breaking down how much time it
takes for the following would be greatly useful, as it will help prioritize
what is most important to resolve. I suspect these can become priorities
for the Infrastructure WG.

1) Merge a single Ballot into GitHub
2) Produce a Final Guideline and a Redlined Version
3) Draft and send the e-mail for the IP review period announcement
4) Upload the Final Guideline and Redlined Version to the website
5) Update the Website to link to these
6) Draft and send the e-mail concluding the IP review period

As a number of these tasks are very automatable, figuring out what we can
do so that it represents <30 minutes of additional work seems... a
reasonable target, right? This only comes up when we have multiple ballots
concluding within a short period of eachother, which although historically
rare, certainly was more common over the summer as stuff got batched to
accommodate Covid disruptions.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200915/ec25975d/attachment.html>