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

[Ryan Sleevi via Public]

On Tue, Sep 15, 2020 at 4:18 PM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

>
>
> On 2020-09-15 9:34 μ.μ., Ryan Sleevi wrote:
>
>
>
> On Tue, Sep 15, 2020 at 12:25 PM Dimitris Zacharopoulos (HARICA) <
> dzach...@harica.gr> wrote:
>
>> I think you have a point about A + B, so we should have independent
>> review periods for each ballot as we did with version 1.6.4 (we had
>> independent ballots to be reviewed and then a combined/aggregated new
>> version of the BRs).
>>
>> I also received some personal messages supporting the "aggregated"
>> practice as it seems to be much more efficient for a CA's compliance review
>> to check against one new BR rather than 2 or 3 separate ones within a very
>> short timeframe.
>>
>
> As Chair, could I ask you to encourage these to be shared on the list? I
> think it's troubling the increased amount of off-list messages used to
> justify Forum behaviour. This feels very much like the mode which the Forum
> explicitly tried to move past with our move to open lists and minuted
> calls, so that we can more accurately understand perspectives and ask
> questions. Certainly, I hope it should be uncontroversial that the Forum
> helps us understand the many different perspectives and constraints, and
> this sort of "appeal to private communication, anonymized, without data"
> actively harms the ability of the Forum to function and improve. This is
> part of why we have public discussion
>
>
> Sure, I can do that but in any case I forwarded it the argument on the
> list. I also support this argument that aggregating new versions of the
> documents saves time.
>

While you're the only one qualified to measure whether it saves time, as a
browser, this raises a host of questions for understanding how CAs are
staying abreast of changes and reviewing them. This is actually critical,
given that I've seen multiple CA incidents where CAs have reported that
they have trouble staying abreast of changes, even for ballots they voted
for! So it suggests to me that some of the current ways that CAs are
keeping up to date are flawed, or lend themselves to easy mistakes.

Naturally, if we had the specific member, we could ask them to describe
their process for staying aware of changes, and why one document makes that
easier. For example, I'd be deeply concerned if a CA was looking at an
aggregated SC28+SC35, since they might mistake a meaningful normative
change as a cleanup or clarification, or similarly, mistake or overlook an
important clarification because they're distracted by logging changes.

Indeed, I'd be quite worried if someone was specifically using the Redline
PDF for reviewing changes (in the full document), without also looking at
any supporting discussion and included redlines, to also make sure they
have an at-a-glance understanding of what's changing. Of course, I'm not a
CA, so it's much better to hear, in a CAs own words, the processes they
employee, so they can describe why one document saves more time.

Selfishly, my priority is not in saving time for CAs, if saving time risks
correctness. I'd much rather ensure CAs do the right thing, and
consistently implement it, even if it means they have to take more time to
be careful and thorough. This is no different from me wanting to make sure
my surgeon was certain my spleen needed to be removed, before scheduling
the surgery, rather than just have them open me up and see what looks
interesting or relevant.


> Once I have the review period redline ready, it usually takes between 30
>> minutes to 1 hour to create the final documents, upload them to the wiki
>> (the word versions), produce the final PDF versions and upload them to the
>> public web site.
>>
>
> Wow! I wouldn't have expected this to be more than 5 minutes, so that's a
> really surprising amount of time!  Do you know where the bulk of the time
> is, so we can prioritize? That said, it sounds like your response here
> aggregated 2-5 - is that roughly right?
>
>
> Yes, because to produce a Final Guideline and a redlined version in a
> non-GitHub version is quite painful. In the GitHub version, things are
> faster but again I need to create the redline manually, compare the two
> .docx versions produced by GitHub (before and after the merge to Main),
> check everything like track changes mode, make sure the ToC is not tracked
> and other minor details.
>

I'm not really sure I understand this process. It might be useful to have a
demonstration on an Infrastructure WG call, to best see the challenge.
Beyond helping the (presumptive, given single candidate) future chair, it
might also help figure out opportunities for improvement here :)


> Then, create a PDF without the formatting comments (otherwise the PDF
> contains formatting changes in the redline which doesn't look good). Then
> make the changes to the web sites, wiki, etc. I wish I could make that in 5
> minutes :-)
>
> This would probably require having our entire public website on GitHub and
> 

Re: [cabfpub] [EXTERNAL] Voting begins on Special Ballot Forum-15: Election of CA/Browser Forum Chair

[Ian McMillan via Public]

Microsoft votes “Yes”.

Thanks,
Ian McMillan

From: Public  On Behalf Of Dimitris Zacharopoulos 
(HARICA) via Public
Sent: Monday, September 14, 2020 8:11 AM
To: public@cabforum.org
Subject: [EXTERNAL] [cabfpub] Voting begins on Special Ballot Forum-15: 
Election of CA/Browser Forum Chair


Voting begins for Special Ballot Forum-15.

Dimitris.

On 2020-09-07 8:53 μ.μ., Dimitris Zacharopoulos (HARICA) wrote:



The following motion has been proposed by the CA/Browser Forum Chair Dimitris 
Zacharopoulos of HARICA.

Purpose of Ballot

This special ballot is to confirm the new Chair of the CA/Browser Forum.


--- MOTION BEGINS ---

In accordance with Bylaw 4.1(c), Dean Coclin representing Digicert is hereby 
elected Chair of the CA/Browser Forum for a term commencing on November 1, 2020 
and continuing through October 31, 2022.



--- MOTION ENDS ---





The procedure for approval of this ballot is as follows:

Special Ballot Forum-15 - Election of CA/Browser Forum Chair

Start time

End time
Discussion (7 days)
September 7, 2020 at 11:00 am Eastern Time

September 14, 2020 at 11:00 am Eastern Time
Vote for approval (7 days)

September 14, 2020 at 11:00 am Eastern Time

September 21, 2020 at 11:00 am Eastern Time


___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] [EXTERNAL] Voting begins on Special Ballot Forum-15: Election of CA/Browser Forum Chair

[Mike Reilly (SECURITY) via Public]

Microsoft votes “yes” on Ballot Forum-15.  Thanks, Mike

From: Public  On Behalf Of Dimitris Zacharopoulos 
(HARICA) via Public
Sent: Monday, September 14, 2020 8:11 AM
To: public@cabforum.org
Subject: [EXTERNAL] [cabfpub] Voting begins on Special Ballot Forum-15: 
Election of CA/Browser Forum Chair


Voting begins for Special Ballot Forum-15.

Dimitris.

On 2020-09-07 8:53 μ.μ., Dimitris Zacharopoulos (HARICA) wrote:



The following motion has been proposed by the CA/Browser Forum Chair Dimitris 
Zacharopoulos of HARICA.

Purpose of Ballot

This special ballot is to confirm the new Chair of the CA/Browser Forum.


--- MOTION BEGINS ---

In accordance with Bylaw 4.1(c), Dean Coclin representing Digicert is hereby 
elected Chair of the CA/Browser Forum for a term commencing on November 1, 2020 
and continuing through October 31, 2022.



--- MOTION ENDS ---





The procedure for approval of this ballot is as follows:

Special Ballot Forum-15 - Election of CA/Browser Forum Chair

Start time

End time
Discussion (7 days)
September 7, 2020 at 11:00 am Eastern Time

September 14, 2020 at 11:00 am Eastern Time
Vote for approval (7 days)

September 14, 2020 at 11:00 am Eastern Time

September 21, 2020 at 11:00 am Eastern Time


___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

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

[Dimitris Zacharopoulos (HARICA) via Public]

On 2020-09-15 9:34 μ.μ., Ryan Sleevi wrote:



On Tue, Sep 15, 2020 at 12:25 PM Dimitris Zacharopoulos (HARICA) 
mailto:dzach...@harica.gr>> wrote:


I think you have a point about A + B, so we should have
independent review periods for each ballot as we did with version
1.6.4 (we had independent ballots to be reviewed and then a
combined/aggregated new version of the BRs).

I also received some personal messages supporting the "aggregated"
practice as it seems to be much more efficient for a CA's
compliance review to check against one new BR rather than 2 or 3
separate ones within a very short timeframe.


As Chair, could I ask you to encourage these to be shared on the list? 
I think it's troubling the increased amount of off-list messages used 
to justify Forum behaviour. This feels very much like the mode which 
the Forum explicitly tried to move past with our move to open lists 
and minuted calls, so that we can more accurately understand 
perspectives and ask questions. Certainly, I hope it should be 
uncontroversial that the Forum helps us understand the many different 
perspectives and constraints, and this sort of "appeal to private 
communication, anonymized, without data" actively harms the ability of 
the Forum to function and improve. This is part of why we have public 
discussion




Sure, I can do that but in any case I forwarded it the argument on the 
list. I also support this argument that aggregating new versions of the 
documents saves time.


If someone wants to send me something in private to check if I agree or 
not, I don't see any harm in doing that. I am sure that direct 
communication among Members, although discouraged, is not prohibited.





More answers inline.

On 2020-09-15 5:34 μ.μ., Ryan Sleevi wrote:



On Tue, Sep 15, 2020 at 4:33 AM Dimitris Zacharopoulos (HARICA)
mailto:dzach...@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 

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

[Ryan Sleevi via Public]

On Tue, Sep 15, 2020 at 12:25 PM Dimitris Zacharopoulos (HARICA) <
dzach...@harica.gr> wrote:

> I think you have a point about A + B, so we should have independent review
> periods for each ballot as we did with version 1.6.4 (we had independent
> ballots to be reviewed and then a combined/aggregated new version of the
> BRs).
>
> I also received some personal messages supporting the "aggregated"
> practice as it seems to be much more efficient for a CA's compliance review
> to check against one new BR rather than 2 or 3 separate ones within a very
> short timeframe.
>

As Chair, could I ask you to encourage these to be shared on the list? I
think it's troubling the increased amount of off-list messages used to
justify Forum behaviour. This feels very much like the mode which the Forum
explicitly tried to move past with our move to open lists and minuted
calls, so that we can more accurately understand perspectives and ask
questions. Certainly, I hope it should be uncontroversial that the Forum
helps us understand the many different perspectives and constraints, and
this sort of "appeal to private communication, anonymized, without data"
actively harms the ability of the Forum to function and improve. This is
part of why we have public discussion



> More answers inline.
>
> On 2020-09-15 5:34 μ.μ., Ryan Sleevi wrote:
>
>
>
> On Tue, Sep 15, 2020 at 4:33 AM Dimitris Zacharopoulos (HARICA) <
> dzach...@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 

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

[Dean Coclin via Public]

I don’t want to speak for Dimitris here but perhaps he is referring to the 
totality of the tasks required of the Chair? He has done a great job in 
organizing and semi-automating many of the menial tasks that Chairs have to do. 
Nonetheless there are still many tasks that add up so I can see where he was 
trying to save some efforts in combining these two.

 

But as pointed out, there are pros and cons to this combination. Any work that 
members can do to help further automate these processes would be greatly 
appreciated.

 

 

From: Servercert-wg  On Behalf Of Dimitris 
Zacharopoulos (HARICA) via Servercert-wg
Sent: Tuesday, September 15, 2020 12:25 PM
To: Ryan Sleevi 
Cc: CA/B Forum Server Certificate WG Public Discussion List 
; CABforum1 
Subject: Re: [Servercert-wg] CANCEL Notice of Review Period – Ballot SC35

 

I think you have a point about A + B, so we should have independent review 
periods for each ballot as we did with version 1.6.4 (we had independent 
ballots to be reviewed and then a combined/aggregated new version of the BRs). 

I also received some personal messages supporting the "aggregated" practice as 
it seems to be much more efficient for a CA's compliance review to check 
against one new BR rather than 2 or 3 separate ones within a very short 
timeframe.

More answers inline.

On 2020-09-15 5:34 μ.μ., Ryan Sleevi wrote:

 

 

On Tue, Sep 15, 2020 at 4:33 AM Dimitris Zacharopoulos (HARICA) 
mailto:dzach...@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 

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

[Dimitris Zacharopoulos (HARICA) via Public]

I think you have a point about A + B, so we should have independent 
review periods for each ballot as we did with version 1.6.4 (we had 
independent ballots to be reviewed and then a combined/aggregated new 
version of the BRs).


I also received some personal messages supporting the "aggregated" 
practice as it seems to be much more efficient for a CA's compliance 
review to check against one new BR rather than 2 or 3 separate ones 
within a very short timeframe.


More answers inline.

On 2020-09-15 5:34 μ.μ., Ryan Sleevi wrote:



On Tue, Sep 15, 2020 at 4:33 AM Dimitris Zacharopoulos (HARICA) 
mailto:dzach...@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 

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

[Ryan Sleevi via Public]

On Tue, Sep 15, 2020 at 4:33 AM Dimitris Zacharopoulos (HARICA) <
dzach...@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) 

Re: [cabfpub] Voting begins on Special Ballot Forum-15: Election of CA/Browser Forum Chair

[Doug Beattie via Public]

GlobalSign votes Yes on Ballot Forum-15

 

From: Public  On Behalf Of Dimitris Zacharopoulos 
(HARICA) via Public
Sent: Monday, September 14, 2020 11:11 AM
To: public@cabforum.org
Subject: [cabfpub] Voting begins on Special Ballot Forum-15: Election of 
CA/Browser Forum Chair

 


Voting begins for Special Ballot Forum-15.

Dimitris.



On 2020-09-07 8:53 μ.μ., Dimitris Zacharopoulos (HARICA) wrote:

 


The following motion has been proposed by the CA/Browser Forum Chair Dimitris 
Zacharopoulos of HARICA.




Purpose of Ballot


This special ballot is to confirm the new Chair of the CA/Browser Forum. 

 

--- MOTION BEGINS ---


In accordance with Bylaw 4.1(c), Dean Coclin representing Digicert is hereby 
elected Chair of the CA/Browser Forum for a term commencing on November 1, 2020 
and continuing through October 31, 2022. 

 

--- MOTION ENDS ---

 

 

The procedure for approval of this ballot is as follows: 


Special Ballot Forum-15 - Election of CA/Browser Forum Chair

Start time 

End time 


Discussion (7 days) 

September 7, 2020 at 11:00 am Eastern Time

September 14, 2020 at 11:00 am Eastern Time


Vote for approval (7 days)  

September 14, 2020 at 11:00 am Eastern Time

September 21, 2020 at 11:00 am Eastern Time

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

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

[Dimitris Zacharopoulos (HARICA) via Public]

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.



Thanks,
Dimitris.



On Mon, Sep 14, 2020 at 11:46 AM Dimitris Zacharopoulos (HARICA) 
mailto:dzach...@harica.gr>> wrote:




On 2020-09-14 5:45 μ.μ., Ryan Sleevi wrote:

Dimitris: Could you explain why it's necessary to integrate?

It seems much better to have Ballot -> Distinct BR version, and
there's nothing in our IP policy I'm aware of that requires you
to send them as a combined review.



The result of the IPR review will produce a new version of the
Guidelines. Having two ballots with two IPR review periods would
probably require creating two versions of the Guidelines, which is
why we've been trying to combine reviews in the past, so we can
bump up one version of the Guideline.

Hope this helps.


On Mon, Sep 14, 2020 at 4:38 AM Dimitris Zacharopoulos (HARICA)
via Servercert-wg mailto:servercert...@cabforum.org>> wrote:


I just realized that ballot SC28 also contains changes to the
BRs so I will create a combined IPR review for ballots SC35
and SC28 later today.

Thank you,
Dimitris.


On 2020-09-14 11:02 π.μ., Dimitris Zacharopoulos (HARICA) wrote:


*NOTICE OF REVIEW PERIOD*

**

This Review Notice is sent pursuant to Section 4.1 of the
CA/Browser Forum’s Intellectual Property Rights Policy
(v1.3).This Review Period is for two Final Maintenance
Guidelines (30 day Review Period).Attached are the complete
Draft Guidelines subject of this Review Notice.


Ballots for Review: Ballot SC35



Start of Review Period: September 14, 2020 at 11:00 Eastern
Time
End of Review Period:   October 14, 2020 at 11:00 Eastern Time


Please forward a written notice to exclude Essential Claims
to the Forum and Working Group Chair by email to
dzach...@harica.gr  and a copy to
the CA/B Forum public mailing list public@cabforum.org
 before the end of the Review
Period.


See current version of CA/Browser Forum Intellectual
Property Rights Policy for details.

/(Optional form of Exclusion Notice is available at

https://cabforum.org/wp-content/uploads/Template-for-Exclusion-Notice.pdf)/

//



___
Servercert-wg mailing list
servercert...@cabforum.org 
https://lists.cabforum.org/mailman/listinfo/servercert-wg





___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Voting begins on Special Ballot Forum-15: Election of CA/Browser Forum Chair

[Josselin Allemandou via Public]

Certigna votes « Yes » on ballot Forum-15.

 

 


--

From: Public < 
public-boun...@cabforum.org> on behalf of Dimitris Zacharopoulos (HARICA)
via Public <  public@cabforum.org>
Sent: Monday, September 14, 2020 23:11
To:   public@cabforum.org <
 public@cabforum.org>
Subject: [cabfpub] Voting begins on Special Ballot Forum-15: Election of
CA/Browser Forum Chair 

 


Voting begins for Special Ballot Forum-15.

Dimitris.



On 2020-09-07 8:53 μ.μ., Dimitris Zacharopoulos (HARICA) wrote:


The following motion has been proposed by the CA/Browser Forum Chair
Dimitris Zacharopoulos of HARICA.




Purpose of Ballot


This special ballot is to confirm the new Chair of the CA/Browser Forum. 

 

---

MOTION BEGINS ---


In accordance with Bylaw 4.1(c), Dean Coclin representing Digicert is hereby
elected Chair of the CA/Browser Forum for a term commencing on November 1,
2020 and continuing through October 31, 2022. 

---

MOTION ENDS ---

 

The procedure for approval of this ballot is as follows: 


Special Ballot Forum-15 - Election of CA/Browser Forum Chair

Start time 

End time 


Discussion (7 days) 

September 7, 2020 at 11:00 am Eastern Time

September 14, 2020 at 11:00 am Eastern Time


Vote for approval (7 days)  

September 14, 2020 at 11:00 am Eastern Time

September 21, 2020 at 11:00 am Eastern Time

 

 



smime.p7s
Description: S/MIME cryptographic signature
___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public

Re: [cabfpub] Voting begins on Special Ballot Forum-15: Election of CA/Browser Forum Chair

[Dai Yeqi via Public]

SHECA votes "Yes" on ballot Forum-15.

From: Public  on behalf of Dimitris Zacharopoulos 
(HARICA) via Public 
Sent: Monday, September 14, 2020 23:11
To: public@cabforum.org 
Subject: [cabfpub] Voting begins on Special Ballot Forum-15: Election of 
CA/Browser Forum Chair


Voting begins for Special Ballot Forum-15.

Dimitris.


On 2020-09-07 8:53 μ.μ., Dimitris Zacharopoulos (HARICA) wrote:

The following motion has been proposed by the CA/Browser Forum Chair Dimitris 
Zacharopoulos of HARICA.
Purpose of Ballot

This special ballot is to confirm the new Chair of the CA/Browser Forum.


--- MOTION BEGINS ---

In accordance with Bylaw 4.1(c), Dean Coclin representing Digicert is hereby 
elected Chair of the CA/Browser Forum for a term commencing on November 1, 2020 
and continuing through October 31, 2022.


--- MOTION ENDS ---


The procedure for approval of this ballot is as follows:

Special Ballot Forum-15 - Election of CA/Browser Forum Chair

Start time

End time

Discussion (7 days)
September 7, 2020 at 11:00 am Eastern Time

September 14, 2020 at 11:00 am Eastern Time

Vote for approval (7 days)

September 14, 2020 at 11:00 am Eastern Time

September 21, 2020 at 11:00 am Eastern Time


___
Public mailing list
Public@cabforum.org
https://lists.cabforum.org/mailman/listinfo/public