[cabfpub] Ballot 203: Formation of Network Security Working Group

[Ryan Sleevi]

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.html>