[cabfpub] Please hit pause - Changes to Bylaws for WGs

Mon Jun 5 20:43:48 UTC 2017

Hello all,

As you know, the Governance WG is (and has been for the last few months) working on creating an amendment to the Bylaws for the creation of new working groups.  One thing that will be required, assuming the amendment passes, is a fixed end date that can be extended if work is not complete by that date.

Before suggesting or proposing any ballots that change the rules pertaining to formation of WGs, please talk to the Governance WG.  We’ve spent quite a bit of time talking about these issues, and working on solutions.  Thanks very much.

Best regards,

Virginia Fournier
Senior Standards Counsel
 Apple Inc.
☏ 669-227-9595
✉︎ vmf at apple.com

On Jun 5, 2017, at 1:07 PM, public-request at cabforum.org wrote:

Send Public mailing list submissions to
	public at cabforum.org

To subscribe or unsubscribe via the World Wide Web, visit
	https://ving.apple.com:443/proxy?url=jJJ7asktevSwtfPIKzsEBUB6DHsYqKFThHEA7wV7pz2T9vdYcMvUD2JC7CCMcH7neM1UYCshCKFF9lX9D%2FFql7lmsXBTkPkLvJwfNxAQFJs%3D&rewritten=true&o=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic
or, via email, send a message with subject or body 'help' to
	public-request at cabforum.org

You can reach the person managing the list at
	public-owner at cabforum.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Public digest..."

Today's Topics:

  1. Re: Ballot 203: Formation of Network Security Working Group
     (Ryan Sleevi)
  2. Re: Ballot 203: Formation of Network Security Working Group
     (Gervase Markham)
  3. Ballot 203: Formation of Network Security Working Group (v2)
     (Gervase
Markham)

----------------------------------------------------------------------

Message: 1
Date: Mon, 5 Jun 2017 13:29:41 -0400
From: Ryan Sleevi <sleevi at google.com>
To: Gervase Markham <gerv at mozilla.org>
Cc: "CA/Browser Forum Public Discussion List" <public at cabforum.org>
Subject: Re: [cabfpub] Ballot 203: Formation of Network Security
	Working Group
Message-ID:
	<CACvaWvamdQupe4OFz6snfK8Opm7BEzu27kfhYJ541QCaZmXn_w at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Mon, Jun 5, 2017 at 1:13 PM, Gervase Markham <gerv at mozilla.org> wrote:

> Hi Ryan,
> 
> On 05/06/17 15:14, Ryan Sleevi wrote:
>> That seems a sort of broadly worded expiration, and one that would be
>> hard to measure.
> 
> Which half is hard to measure? The deliverables are fairly concrete, and
> after they come up with a couple of proposals which don't reach
> consensus, it should end up being fairly clear to all whether or not
> there's no obvious way forward. (Although I suspect
this scenario to be
> unlikely.)
> 

Respectfully, it's left an incredible amount up to interpretation that
doesn't seem necessary?

>> For example, if a single ratification fails, is the WG expired?
> 
> Not unless there are no other plausible candidates for a proposal.
> 

I hope you can understand why "plausible candidates" is problematic - both
for those who would want to shut down the WG (but run the risk of a
candidate being called plausible, even if it's not) and those who want to
keep a WG going (feeling their proposal is plausible, although others may
not)

> If that happens (and they also can't agree that a proposal is
> impossible), we might ask them what on earth they are doing :-)
> 

Why not avoid that mess entirely with simple and clear criteria?

>> If the WG makes
>> a single proposal - while others are still being worked on - does the WG
>> expire?
> 
> I wouldn't expect the WG to make a proposal if others are being
> prepared; they
are being asked for one report.

But you've set yourself up for a process upon which production of report
may take forever, due to stalling tactics and a desire to 'explore other
proposals' before finalizing the report.

A simple and clear date-based criteria avoid this.

> 
>> Looking at the bylaws, Section 5.3 makes it clear that there's a
>> "Working Group expiration _date_" (emphasis added). From the past
>> discussions regarding the scope and nature of WGs - including the F2F
>> discussion in Raleigh - and borrowing from other SDOs, perhaps it would
>> be more fruitful and worthwhile to set an explicit date, one year out.
> 
> I've been involved in IETF groups such as DBOUND; they seemed to shut
> themselves down when it was clear that no progress was going to be made,
> rather than on a date basis. I agree the Bylaws say "expiration date",
> but do any of our existing WGs have an expiration date? That's not
> necessarily a reason not to have one, but it
shows the sky doesn't
> necessarily fall if we have expiration conditions rather than a date.
> 

In general, we try to follow our bylaws. We've seen what happens when WGs
are chartered not consistent to our bylaws - the Code Signing WG is a prime
example of this, where an ad-hoc determination to start a WG with both IP
and scope encumbrances.

I thought we had universal agreement on the simple date-based approach, so
I'm quite curious why you're pushing back. It would seem that this is being
done because it was realized that the time for a ballot to be ratified (two
weeks) would otherwise prevent discussion about it during the F2F. It seems
all the more reason just to ballot it at one year and save ourselves that
debate?

> Given the short time available and the value of having the WG
> constituted by the F2F, I propose this: we'll talk about WG rules at the
> F2F and if there is support for expiration dates rather than conditions,
> I'll put forward a ballot
adding dates to all existing WGs. If there is
> instead support for conditions, I'll put forward a ballot amending the
> Bylaws to match practice.
> 

I think this would be a rather unfortunate proposal, and regrettably,
rather the opposite of how we should be moving forward. While I realize
such a commitment was made in good faith, we've seen this attempted several
times. It has a number of problems, the most obvious of which being that
there's no reason to believe such a proposal would move timely (after all,
the debate about different WGs is a broader question of scope) or reach
consensus (the more moving parts = the harder to achieve consensus)

>> Are there any limitations to the WG? For example, will the WG only
>> consider updates to the Network Security Controls? Is it considering
>> updates to all documents?
> 
> I think the statement is pretty clear that the group's charter is to
> consider the future of the NSGs, not any other document.
> 

I don't,
especially given the multiple discussions at the past several
meetings and calls about whether or not the NSGs should be incorporated
into the BRs or not. Perhaps you mean this in the context of 'scrapping',
but this is an element that is not at all obvious, and one we know there's
been spirited debate on.

Considering the proposal was broached on a Friday and put forward on a
Monday, this seems like an entirely avoidable set of discussions. I'm not
so much looking to mire this in endless debate, but rather point out the
issues with the consistency to the bylaws, and the wording, in the hopes
that you might consider 'quick' fixes to these matters - or consider not
rushing this forward.

As it stands, because of the questions about bylaws, I don't believe we
could support this - even though we are entirely supportive of these
efforts, which are long-overdue. This may seem like putting 'process over
people', but quite simply, the risks to not adhering to our bylaws in
a
consistent fashion will continue to yield such objections.

If your concern is about trying to find appropriate wording, consider the
suggested edits. Using the --()-- language for removal, and __ __ for
addition.

1) Remove the subjective nature of "extensive" report - one person's
extensive report is another person's brief summary.
2) Remove the explicit remark about existing framework or standard, unless
you explicitly intend to limit it to those two things (and what constitutes
a 'framework' or a 'standard' - for example, a standard Google vendor
security guideline may not be a 'standard' in the sense you mean)
3) Explicit expiration date, with an option for earlier. If more time is
needed, a rechartering ballot can be done.

-- MOTION BEGINS --

In accordance with Section 5.3 of the CA/B Forum Bylaws, the chartering of
a new Working Group requires a ballot. This ballot charters the Network
Security Working Group.

The CAB Forum's Network Security
Guidelines were adopted in August 2012 but
have not been updated since. Significant doubts have been raised as to
their fitness for purpose in 2017. Therefore, the Working Group?s charter
will be as follows:

Scope

1. Consider options for revising, replacing or scrapping the Network
Security Guidelines.

Deliverables

1. A--(n extensive)-- report with one or more proposals for the future of
the Network Security Guidelines.

2. For proposals involving replacement --(with an existing framework or
standard)--, details of the availability and applicability of the proposed
alternative, and what modifications if any would be needed to it in order
to make it suitable for use.

3. For proposals involving revision, details of the revisions that are
deemed necessary and how the document will be kept current in the future.

4. For proposals involving scrapping, an explanation of why this is
preferable to either of the other two options.

5. If there are multiple
proposals, optionally a recommendation as to which
one to pursue and an associated timeline.

6. A form of ballot or ballots to implement any recommendations.

Expiry

The Working Group shall expire once the deliverables have been completed,
or --(if the group agrees that it cannot achieve the 2/3rds endorsement
required by the bylaws for any proposal)-- on 2018-06-05, whichever happens
first.

-- MOTION ENDS --
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170605/1fd06198/attachment-0001.html>

------------------------------

Message: 2
Date: Mon, 5 Jun 2017 21:02:06 +0100
From: Gervase Markham <gerv at mozilla.org>
To: Ryan Sleevi <sleevi at google.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [cabfpub] Ballot 203: Formation of Network Security
	Working Group
Message-ID: <077bb595-0a34-497c-99bd-25e5b61f0168 at mozilla.org>
Content-Type:
text/plain; charset=utf-8

On 05/06/17 18:29, Ryan Sleevi wrote:
> But you've set yourself up for a process upon which production of report
> may take forever, due to stalling tactics and a desire to 'explore other
> proposals' before finalizing the report.

And if you have a date-based criteria, a group which for some reason
doesn't want the WG to produce a report simply has to delay until the
expiry date. And if you argue "well, it'll get rechartered", then it's
exactly the same as the version without a date-based end.

A date-based end does not solve this problem.

> In general, we try to follow our bylaws. We've seen what happens when
> WGs are chartered not consistent to our bylaws - the Code Signing WG is
> a prime example of this, where an ad-hoc determination to start a WG
> with both IP and scope encumbrances.

Respectfully, this is not that.

> Considering the proposal was broached on a Friday and put forward on a
> Monday, 

Well, no, we've been
meaning to charter this working group since the
last face to face. To my mind, it's a fairly simple procedural step that
we need to go through in order to actually have the discussions about
what to do.

<sigh>

I've revised the ballot to add an expiry date, but with a postponement
clause. This meets the letter of the bylaws and should reduce administrivia.

Gerv

------------------------------

Message: 3
Date: Mon, 5 Jun 2017 21:07:13 +0100
From: Gervase Markham <gerv at mozilla.org>
To: CABFPub <public at cabforum.org>
Subject: [cabfpub] Ballot 203: Formation of Network Security Working
	Group (v2)
Message-ID: <a9ac52ac-fed3-5ee6-c49e-b86c4ad89133 at mozilla.org>
Content-Type: text/plain; charset="utf-8"

/[This replaces the earlier ballot text of the same title; timeline
dates are unchanged.]/

*Ballot 203: Formation of Network Security Working Group (v2)
*

Purpose of Ballot: To form a Network Security Working Group to
re-evaluate the CAB Forum's Network
Security Guidelines.

The following motion has been proposed by Gervase Markham of Mozilla and
endorsed by Jeremy Rowley of DigiCert and Moudrick Dadashov of SSC:

*-- MOTION BEGINS --*

In accordance with Section 5.3 of the CA/B Forum Bylaws, the chartering
of a new Working Group requires a ballot. This ballot charters the
Network Security Working Group.

The CAB Forum's Network Security Guidelines were adopted in August 2012
but have not been updated since. Significant doubts have been raised as
to their fitness for purpose in 2017. Therefore, the Working Group?s
charter will be as follows:

*Scope*

1. Consider options for revising, replacing or scrapping the Network
Security Guidelines.

*Deliverables*

1. A report with one or more proposals for the future of the Network
Security Guidelines.

2. For proposals involving replacement, details of the availability and
applicability of the proposed alternative, and what modifications if any
would be needed to
it in order to make it suitable for use.

3. For proposals involving revision, details of the revisions that are
deemed necessary and how the document will be kept current in the future.

4. For proposals involving scrapping, an explanation of why this is
preferable to either of the other two options.

5. If there are multiple proposals, optionally a recommendation as to
which one to pursue and an associated timeline.

6. A form of ballot or ballots to implement any recommendations.

*Expiry*

The Working Group shall expire once the deliverables have been
completed, or on 2018-06-19, whichever happens first.

The expiry date given above shall be automatically postponed by 1 year
on 2018-05-19 ("postponement date") and each anniversary of the
postponement date thereafter unless three or more members separately or
jointly request on the Public Mail List, within one month prior to a
particular postponement date, that expiry of this Working Group not be
postponed in
that instance.

*-- MOTION ENDS --*

The procedure for approval of this ballot is as follows:

BALLOT 203

Start time (22:00 UTC)

End time (22:00 UTC)

Discussion (7 to 14 days)

	5th June

12th June

Vote for approval (7 days)

12th June   

19th June

Votes must be cast by posting an on-list reply to this thread on the
Public list. A vote in favor of the motion must indicate a clear 'yes'
in the response. A vote against must indicate a clear 'no' in the
response. A vote to abstain must indicate a clear 'abstain' in the
response. Unclear responses will not be counted. The latest vote
received from any representative of a voting member before the close of
the voting period will be counted. Voting members are listed here:
https://cabforum.org/members/

In order for the motion to be adopted, two thirds or more of the votes
cast by members in the CA category and greater than 50% of the votes
cast by members in the
browser category must be in favor. Quorum is
shown on CA/Browser Forum wiki. Under Bylaw 2.2(g), at least the
required quorum number must participate in the ballot for the ballot to
be valid, either by voting in favor, voting against, or abstaining.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170605/c465ed69/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
Public mailing list
Public at cabforum.org
https://ving.apple.com:443/proxy?url=L8iTxsl04M8Ahi3o68Cc51nHZlSENuI%2F%2F93hDdfGrRTkU%2FgoxXcmFcpYk%2FyJCm68aHPnQIyRISyMfZ7rYAUC6JhThrAs7F5iXbiFKnrVmmY%3D&rewritten=true&o=https%3A%2F%2Fcabforum.org%2Fmailman%2Flistinfo%2Fpublic

------------------------------

End of Public Digest, Vol 62, Issue 20
**************************************