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 ✉︎ [email protected] On Jun 5, 2017, at 1:07 PM, [email protected] wrote: Send Public mailing list submissions to [email protected] 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 [email protected] You can reach the person managing the list at [email protected] 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 <[email protected]> To: Gervase Markham <[email protected]> Cc: "CA/Browser Forum Public Discussion List" <[email protected]> Subject: Re: [cabfpub] Ballot 203: Formation of Network Security Working Group Message-ID: <cacvawvamdqupe4ofz6snfk8opm7bezu27kfhyj541qcazmx...@mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Mon, Jun 5, 2017 at 1:13 PM, Gervase Markham <[email protected]> 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 <[email protected]> To: Ryan Sleevi <[email protected]> Cc: CA/Browser Forum Public Discussion List <[email protected]> Subject: Re: [cabfpub] Ballot 203: Formation of Network Security Working Group Message-ID: <[email protected]> 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 <[email protected]> To: CABFPub <[email protected]> Subject: [cabfpub] Ballot 203: Formation of Network Security Working Group (v2) Message-ID: <[email protected]> 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 [email protected] 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 ************************************** _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
