<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 5, 2017 at 1:13 PM, Gervase Markham <span dir="ltr"><<a href="mailto:gerv@mozilla.org" target="_blank">gerv@mozilla.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Ryan,<br>
<span class="gmail-"><br>
On 05/06/17 15:14, Ryan Sleevi wrote:<br>
> That seems a sort of broadly worded expiration, and one that would be<br>
> hard to measure.<br>
<br>
</span>Which half is hard to measure? The deliverables are fairly concrete, and<br>
after they come up with a couple of proposals which don't reach<br>
consensus, it should end up being fairly clear to all whether or not<br>
there's no obvious way forward. (Although I suspect this scenario to be<br>
unlikely.)<br></blockquote><div><br></div><div>Respectfully, it's left an incredible amount up to interpretation that doesn't seem necessary?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> For example, if a single ratification fails, is the WG expired?<br>
<br>
</span>Not unless there are no other plausible candidates for a proposal.<br></blockquote><div><br></div><div>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)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">If that happens (and they also can't agree that a proposal is<br>
impossible), we might ask them what on earth they are doing :-)<br></blockquote><div><br></div><div>Why not avoid that mess entirely with simple and clear criteria?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> If the WG makes<br>
> a single proposal - while others are still being worked on - does the WG<br>
> expire?<br>
<br>
</span>I wouldn't expect the WG to make a proposal if others are being<br>
prepared; they are being asked for one report. </blockquote><div> </div><div>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.</div><div><br></div><div>A simple and clear date-based criteria avoid this.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> Looking at the bylaws, Section 5.3 makes it clear that there's a<br>
> "Working Group expiration _date_" (emphasis added). From the past<br>
> discussions regarding the scope and nature of WGs - including the F2F<br>
> discussion in Raleigh - and borrowing from other SDOs, perhaps it would<br>
> be more fruitful and worthwhile to set an explicit date, one year out.<br>
<br>
</span>I've been involved in IETF groups such as DBOUND; they seemed to shut<br>
themselves down when it was clear that no progress was going to be made,<br>
rather than on a date basis. I agree the Bylaws say "expiration date",<br>
but do any of our existing WGs have an expiration date? That's not<br>
necessarily a reason not to have one, but it shows the sky doesn't<br>
necessarily fall if we have expiration conditions rather than a date.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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?</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Given the short time available and the value of having the WG<br>
constituted by the F2F, I propose this: we'll talk about WG rules at the<br>
F2F and if there is support for expiration dates rather than conditions,<br>
I'll put forward a ballot adding dates to all existing WGs. If there is<br>
instead support for conditions, I'll put forward a ballot amending the<br>
Bylaws to match practice.<br></blockquote><div><br></div><div>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)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">
> Are there any limitations to the WG? For example, will the WG only<br>
> consider updates to the Network Security Controls? Is it considering<br>
> updates to all documents?<br>
<br>
</span>I think the statement is pretty clear that the group's charter is to<br>
consider the future of the NSGs, not any other document.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>If your concern is about trying to find appropriate wording, consider the suggested edits. Using the --()-- language for removal, and __ __ for addition.</div><div><br></div><div>1) Remove the subjective nature of "extensive" report - one person's extensive report is another person's brief summary.<br></div><div>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)</div><div>3) Explicit expiration date, with an option for earlier. If more time is needed, a rechartering ballot can be done.</div><div><br></div><div><div>-- MOTION BEGINS --</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>Scope</div><div><br></div><div>1. Consider options for revising, replacing or scrapping the Network Security Guidelines.</div><div><br></div><div>Deliverables</div><div><br></div><div>1. A--(n extensive)-- report with one or more proposals for the future of the Network Security Guidelines.</div><div><br></div><div>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.</div><div><br></div><div>3. For proposals involving revision, details of the revisions that are deemed necessary and how the document will be kept current in the future.</div><div><br></div><div>4. For proposals involving scrapping, an explanation of why this is preferable to either of the other two options.</div><div><br></div><div>5. If there are multiple proposals, optionally a recommendation as to which one to pursue and an associated timeline.</div><div><br></div><div>6. A form of ballot or ballots to implement any recommendations.</div><div><br></div><div>Expiry</div><div><br></div><div>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.</div><div><br></div><div>-- MOTION ENDS --</div></div></div></div></div>