[cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter

Tim Hollebeek tim.hollebeek at digicert.com
Wed Feb 6 13:19:57 MST 2019


My experience is the reverse.  IETF and groups with tight charters get bogged down in constant discussions about charter revisions.  CABF has recently fallen into the same trap and I don’t think it is a change for the better.  There are other SDOs I participate in where groups have operated for 10+ years with the same charter, with no downsides other than the fact that they spend their time discussing and working on the relevant issues instead of re-chartering every time a new topic comes up.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Wednesday, February 6, 2019 12:57 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>; Dean Coclin <dean.coclin at digicert.com>
Subject: Re: [cabfpub] [EXTERNAL]Re: Draft SMIME Working Group Charter

 

 

 

On Wed, Feb 6, 2019 at 12:41 PM Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

There are many SDOs that I participate in that are able to manage their priorities effectively without hardcoding them into a charter.  In fact, it’s more common than not.  In my experience, SDOs that require a re-charter every time they want to discuss a new topic is indeed very disruptive and high overhead.

 

I've tried to provide very detailed answers to support the position I'm advocating. Could you discuss more what parts you believe are disruptive and high overhead? Is it because there's disagreement on embracing the topic and/or disagreement on the appropriateness of the timing? 

 

While there are many SDOs, I will highlight that the SDOs that have been most successful for our line of work - that is, groups such as IETF and W3C - have fairly consistency and explicitly required 'tight' charters with explicit deliverables, as a way of measuring and ensuring progress. Groups that have tended to have very broad charters - which include ETSI and OASIS - tend to get extremely mired down in debates, much like the one we're having now, rather than focusing on the concrete deliverables.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20190206/6b0b9560/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20190206/6b0b9560/attachment.p7s>


More information about the Public mailing list