[Servercert-wg] Discussion Period Begins on Ballot SC43 Version 2: Clarify Acceptable Status Codes

[Ryan Sleevi]

Apologies for not having double-checked that the endorsement in principle
carried over to the draft ballot. I think historically, ballot authors have
sent direct messages to confirm endorsers were on-board as proposed and
have double-checked everything.

Although I was listed as endorser, this wasn't something I'd had a chance
to review / was not even aware changes had been made since we reviewed and
endorsed, and it's something we plan to vote NO on, for two reasons:

1) The way this ballot updates the effect dates implies a normative
requirement, but this is explicitly something we've called out as
non-normative (because the Chair is allowed to update)
2) By placing this requirement here, this also in our bylaws *prevents* the
Chair from assigning a new version or making edits, meaning this would be a
"second" 1.7.3. That would not be good.

I realize this approach to effective date was added late (compared to the
original text), which is what lead to both of these problems. It's entirely
understandable how, so I hope it doesn't seem like I'm trying to point
fingers, but trying to capture the context.

To answer Aaron's questions directly, below

1) For ballot authors, where are standards/requirements like this
> documented? As someone relatively new to this community, the structure of
> this ballot seemed reasonable to me: there are not currently any other
> ballots in the pipeline which will be effective prior to the chosen date of
> July 1, so simply noting "this document has changed, and that change will
> go into effect on July 1" seems sufficient. How do we clearly document
> ballot best practices and style guides?


Normally this is captured during the drafting and discussion period. I
think the fact that we've had a number of ballots in the discussion period,
some being kept alive even though their authors have made clear they do not
expect to make progress, and others because they've been holding back, have
made it harder to follow the active discussions on these. As time goes on,
some of the context slips, and bugs like this crack in.

While we've talked about a style guide for presentation, the style guide
for normative requirements here might be premature, judging by the
challenges we've faced in the past. However, historically, we've explicitly
added the effective date stated where the requirement is, and then cleaned
up that language as part of the spring/fall cleanup ballots once that date
has passed. For example, 4.9.10, 7.1.4.1, 7.1.6.4, and 7.2.2 of the BRs
1.7.3 all show examples of the approach for expressing such requirements,
and then usually that specific sentence is subsequently removed.

2) For the community, why was this issue not raised during the discussion
> period? The discussion period should not simply be a week-long waiting
> period, with folks only reading the actual redline once voting begins. How
> do we incentivize active review and discussion at the appropriate point in
> the process?
>

Welcome to the CA/B Forum, where this has _always_ been a problem :)

Ideally, folks would participate and discuss prior to the discussion
period. However, as we've seen for years, these discussions can go on
indefinitely without resolution, as folks continue to bring up the same
points and they're addressed the same way, but then forgotten before the
next F2F. This is, for example, why CAA took so long - we just kept going
in circles on the same talking points.

It would, ideally, be caught during the discussion period, but folks'
priorities for reviews change, or they may not be aware that there are
subtle differences from what was discussed vs what is actually proposed in
the discussion period. Sometimes, in the rush to get a ballot out, minor
tweaks are made that folks don't fully appreciate the implications of (e.g.
as in this case), and aren't caught until voting. The same can be said for
root program updates, since sometimes, a root program update spans months,
has many fragmented discussions going on in parallel, and can be hard to
find all the relevant changes being proposed and their interactions.

That said, having a ballot fail for reasons like this is not a big deal,
and has happened in the past, and just delays things by two weeks (one week
to finish voting, one week to start a new discussion period), while often
leading to improvements.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20210401/f94171b0/attachment.html>