[cabfpub] Conflicting sections updated by two or more ballots at the same time

[Dimitris Zacharopoulos (HARICA)]

On 24/1/2024 8:40 μ.μ., Tim Hollebeek wrote:
>
> I would recommend reviewing the previous discussions from many years 
> ago, where we came to the IMO correct conclusion that providing this 
> information is useful in cases where it is helpful, but requiring it 
> in all cases is neither necessary nor desirable.  It would be a 
> significant burden on ballot proposers, and it adds an additional 
> mandated synchronization and update every time one or the other ballot 
> gets updated.  This would be required even when the changes are 
> trivial and do not overlap or interfere with each other, because 
> that’s how compliance
>

I think adding those provisions is trivial enough, but I agree it is an 
additional burden, yet not significant IMO. The proposer would just need 
to add the language of the section taking into account the existing 
ballot being passed or not.

> mandates work: they enforce a cost even when that cost is not 
> necessary.  That’s why the solution to a problem isn’t always a new 
> compliance rule (though that fact may come as a shock to some 
> compliance people I know …).
>
> Discretion is good.  People should use it responsibly.  Provide 
> guidance where necessary, but don’t require it.
>

Can't argue with that :) However, it might make sense to invoke some 
discussion on the lists about whether the conflict is at a level that 
requires explicit provisions in the second ballot or not. I'm thinking 
about the conflict between ballot SC-65 (conversion of EVG into RFC 
3647) and the ballot to fix some of the existing EVG language. How 
should we handle such a case? Is the outcome of both ballots clear 
enough that we don't need any provisions in the second ballot?

Any other opinions?


Thanks,
Dimitris.

> -Tim
>
> *From:*Public <public-bounces at cabforum.org> *On Behalf Of *Dimitris 
> Zacharopoulos (HARICA) via Public
> *Sent:* Wednesday, January 24, 2024 4:10 AM
> *To:* CABforum1 <public at cabforum.org>
> *Subject:* [cabfpub] Conflicting sections updated by two or more 
> ballots at the same time
>
> Dear Members,
>
> Following-up on an issue that came up during the discussion 
> <https://lists.cabforum.org/pipermail/servercert-wg/2024-January/004133.html> 
> of a ballot in the server certificate WG, I created 
> https://github.com/cabforum/forum/issues/42 and hope to discuss at the 
> next F2F, but we could start earlier using the mailing list.
>
> IMO every code management system MUST have a process to address 
> "conflicts" that may be caused when two independent processes try to 
> update the same part of a document. The current language in the Bylaws 
> do not *require *the proposer to describe what the outcome of the 
> ballot should be if a previous ballot passes or fails. It leaves this 
> at the discretion of the proposer of the subsequent ballot.
>
> Do others see this as a risk that needs to be addressed firmly in the 
> Bylaws, changing the "may" into a "shall"?
>
> In practice, the proposer of a subsequent ballot would need to include 
> two versions of the language of the conflicting section:
>
>  1.  the language of the section if both ballots A+B pass
>  2. the language of the section of ballot A fails and ballot B passes
>
> It doesn't seem too much of a burden to me and the benefits are 
> obvious (removal of the risk of creating an unstable end state of the 
> conflicting section).
>
> Happy to hear other opinions.
>
> Dimitris.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20240128/31507c4f/attachment.html>