[cabfpub] Review Notices

Tim Hollebeek tim.hollebeek at digicert.com
Mon Feb 5 14:24:55 MST 2018


I support this, because the technology we are currently using offers the option of viewing the final document without redlining if you so choose.

 

-Tim

 

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Rich Smith via Public
Sent: Monday, February 5, 2018 2:17 PM
To: 'Ryan Sleevi' <sleevi at google.com>; 'CA/Browser Forum Public Discussion List' <public at cabforum.org>; 'Kirk Hall' <Kirk.Hall at entrustdatacard.com>
Subject: Re: [cabfpub] Review Notices

 

I think Ryan and Kirk are both right.  Ryan in that for effective review the change must be reviewed and understood as part of the whole, Kirk in that sending out the whole document without redlining the specific changes under review also makes review more difficult.  I propose that we change such that we keep the requirement to send out the full document text, but permit (encourage?) redlining of the ballot changes to which the review notice pertains.  Thoughts?

 

Regards,

Rich Smith

Sr. Compliance Manager

Comodo CA

 

From: Public [mailto:public-bounces at cabforum.org] On Behalf Of Ryan Sleevi via Public
Sent: Monday, February 5, 2018 8:41 AM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com <mailto:Kirk.Hall at entrustdatacard.com> >; CA/Browser Forum Public Discussion List <public at cabforum.org <mailto:public at cabforum.org> >
Subject: Re: [cabfpub] Review Notices

 

 

 

On Sun, Feb 4, 2018 at 9:00 PM, Kirk Hall via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

Virginia – we have been following the steps you listed below, and have been sending out “Review Notices” since Ballot 190 that included the specific Ballot language in “track changes” mode showing how our guidelines (BRs or EVGL) were amended by each Ballot – I believed that this complied with our Bylaws shown below.  

 

Unfortunately, as Ryan pointed out a few days ago, our Review Notices can’t include just the specific Ballot language showing the changes that were made by the Ballot, but must include “a complete draft of the Draft Guideline [i.e., the entire BR or EVGL document itself] that is the subject of such notice”.  Oddly enough, the IPR Agreement language doesn’t allow the “Draft Guideline” that is sent with the Review Notice to show what changes were made by the Ballot, so it’s not very helpful to Members for their IP review. 

 

Kirk,

 

If you recall our last discussions of the IP Policy, this was an intentional decision, and one we rather thoroughly discussed in the context of multiple ballots being pursued in parallel.

 

Given that the decision to add or remove language has IP connotations in its surrounding textual environment, the choice to provide a fully integrated copy (the one "true" version) was the only method that would allow for effective and meaningful review of the IP obligations. Given, for example, the failure to publish timely 'full' copies in a reliable way, this is perhaps proof positive of the potential challenges that would exist if your 'redline-only' IP policy were adopted.

 

I'm not sure how Entrust is doing its IP review, but having a full document with all of the necessary obligations is how Google does its review, and a number of members expressed similar views, and a number of SDOs follow similar approaches.

 

Regarding the proposed Ballot Range - I happened to pick Ballot 187 as the start of examples rather intentionally in my list at https://cabforum.org/pipermail/public/2018-February/012903.html

 

Ballot 183 was the bylaws

Ballot 184 did not progress

Ballot 185 failed

Ballot 186 did not progress

Ballot 187 was the first, post 180/181/182 set of changes to modify the BRs

 

182 did not progress due to the formation of the PAG

180, 181, and 182 each proposed to adopt the full documents, but as you recall, used a process that the Forum had never exercised before, even under its previous IPR Policy (namely, the review being kicked off prior to voting, and without the full text or redline provided). There was sufficient ambiguity with that process which was itself problematic.

 

https://cabforum.org/pipermail/public/2017-January/009181.html was the resultant mail that contained those documents

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20180205/dfbd3cb1/attachment-0001.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/20180205/dfbd3cb1/attachment-0001.p7s>


More information about the Public mailing list