Yeah, the ballot number was a tyop (should be 14).  I’ll fix.

 

-Tim

 

From: Ryan Sleevi <[email protected]> 
Sent: Wednesday, May 20, 2020 6:20 PM
To: Tim Hollebeek <[email protected]>
Cc: CABforum1 <[email protected]>
Subject: Re: [cabfpub] Ballot FORUM-12: Creation of S/MIME Certificates Working 
Group

 

Oh, and the ballot number will need to be updated - I'm not sure how both 
collided on 'FORUM-12' (Dimitris' Bylaws ballot and this)

 

On Wed, May 20, 2020 at 6:18 PM Ryan Sleevi <[email protected] 
<mailto:[email protected]> > wrote:

 

 

On Fri, May 15, 2020 at 2:20 PM Tim Hollebeek <[email protected] 
<mailto:[email protected]> > wrote:

I’m willing to drop the scope statement based on Thursday’s discussion and the 
addition of the paragraph I suggested to the introduction, which describes much 
of the same thing in a form that seems more acceptable to most.  Clint and 
Wayne, are you ok with that?

 

On the subject of redlines, //github_redline_guide is not normative, so I 
disagree that it is not a valid Ballot.  But that’s not really important, 
because I’m more than happy to improve the ballot by fixing the link.

 

While I realize we end up frequently discussing this, I think you may have 
missed that this was a different scenario than you may have realized.

 

If your ballot had included the full text, then I agree, the redline link was 
not normative. However, your ballot just pointed to a link, and so that made 
the link itself normative. The contents of the link were not actually a 
charter, they were just a few edits. That's why it wasn't really a "Ballot".

 

This is easily fixed in the next run. You can paste the full text, as I think 
you're one of the folks who still prefers to do so, despite the risks, or you 
could provide the full link to all the edits, which will at least include a 
"full charter". Just a single commit on its own, or "as of this revision", can 
end up being ambiguous :) In the future, the infrastructure WG efforts will 
certainly make this easier, and it's not difficult to imagine an easy "create a 
ballot for me" that provides the PDF, docx, and patch file and stable link, so 
appreciate your patience :)

 

Assuming Clint and Wayne sign off, please merge the change, and I’ll update the 
ballot.

 

One more set of issues, now that scope has been finalized, that came up on 
another review cycle: https://github.com/sleevi/cabforum-docs/pull/22/files

 

 

-Tim

 

From: Ryan Sleevi <[email protected] <mailto:[email protected]> > 
Sent: Wednesday, May 13, 2020 5:44 PM
To: Tim Hollebeek <[email protected] 
<mailto:[email protected]> >; CABforum1 <[email protected] 
<mailto:[email protected]> >
Subject: Re: [cabfpub] Ballot FORUM-12: Creation of S/MIME Certificates Working 
Group

 

 

 

On Wed, May 13, 2020 at 5:18 PM Tim Hollebeek via Public <[email protected] 
<mailto:[email protected]> > wrote:

Upon approval of the CAB Forum by ballot in accordance with section 5.3 of the 
Bylaws, the S/MIME Certificates Working Group (“SMWG”) is created to perform 
the activities as specified in the Charter, with the Charter as described here 
(https://github.com/cabforum/documents/pull/167/commits/2aa376c06b45146249d0cc6b8cc5d42d08ccb177).

 

Just to be clear: This link doesn't match the link for a valid proposal, so I 
don't think this is a valid Ballot yet. 
https://wiki.cabforum.org/github_redline_guide is helpful, but any suggestions 
for improvements are welcome.

 

The immutable link is 
https://github.com/cabforum/documents/compare/6e0b8e61590164eb2d686ddcf266b189f46fc636...2aa376c06b45146249d0cc6b8cc5d42d08ccb177

 

The pull request is still https://github.com/cabforum/documents/pull/167 

 

Again, our concern is that the statement that "non-publicly trusted S/MIME 
certificates are out of scope" accomplishes nothing valuable, and causes real 
harm. That is, either it fails to keep anything out of scope due to its 
definition, OR limits the discussion to being impossible to introduce any new 
requirements due to, by definition, anything not in the existing documents is 
out of scope. Neither of these scenarios are good, and the risk of harm 
outweighs any benefits. We remain committed to trying to work with you and 
understand your goals, to find language that better captures those goals 
without the problematic ambiguity and harm of what's being proposed.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public

Reply via email to