A few additional points: First off, thank you Rob and James for calling out unacceptable list behavior. Personal attacks will not be tolerated from anyone on this list.
On Thu, Sep 27, 2018 at 10:26 AM Ryan Sleevi <r...@sleevi.com> wrote: > > On Thu, Sep 27, 2018 at 11:17 AM Jeremy Rowley <jeremy.row...@digicert.com> > wrote: > >> Oh – I totally agree with you on the Google inclusion issue. Google meets >> the requirements for inclusion in Mozilla’s root policy so there’s no >> reason to exclude them. They have an audited CPS, support a community >> broader with certs than just Google, and have operated a CA without >> problems in the past. The discussion on Mozilla’s independence is important >> IMO where a) a Mozilla competitor as a module peer and b) having that same >> person also belong to a CA. There are legit concerns. Has any other CA >> served as a module owner? If not, why? I know Tim Hollebeek would be >> interested in being a peer. If he’s not permitted to be a peer, why not? >> > > Again, I don't think there is or should be a ban on module peers being employed by a CA. > I think this again conflates peership with ownership, and it's good to > revisit what policies are actually specified by how it works. > > I disagree with you as to the independence discussion being valuable, > because that conclusion rests on a misunderstanding about module ownership > and peership. Again, > https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ > addresses these concerns. It also is conflating MoCo and MoFo, which I know > was a topic that Gerv was particularly sensitive to. > > To your second part, the selection of peers, > https://wiki.mozilla.org/Modules addresses this - "A peer is a person > whom the owner has appointed to help them." and "Owners may add and remove > peers from their modules as they wish, without reference to anyone else" > > My observation is that peers are appointed in recognition of the level of work they've done for the module. Peer appointments are announced on the Mozilla governance list, and I believe that a search of recent peer announcements [1] supports my observation. If members of this list think there is someone whose contributions should be recognized by making them a peer, please let Kathleen and me know. Employees of CAs often have the knowledge needed to make meaningful contributions here, and we welcome their contributions. [1] https://groups.google.com/forum/#!searchin/mozilla.governance/peer%7Csort:date To be fair, separating out Ryan as a Google browser representative and Ryan >> as a module peer is…hard. Perhaps, he specifically is seen as more >> influential (from my point of view) than others simply because of his dual >> role. >> > > What is difficult separating out? You're intimating at some degree of > influence that is not transparent, but that's not supported by any > evidence. You're also intimating influence over Mozilla somehow, but that > seems like the separation would be easy. > > >> As I said before, Ryan’s a good module peer so I don’t disagree with your >> conclusion or any decision to keep him in that spot. But I think openness >> should include respectful conversation on the impact of influences, >> perceived or real, on the Mozilla direction. What might help alleviate >> concerns is to describe how you (as a module owner) are going to ensure >> that if Ryan is reviewing and approving code or CA policies, they won’t be >> unfairly biased towards google or against its competitors? Maybe that’s a >> bad question, but I’m spit-balling on how we can move past speculation to >> address concerns raised. >> > > Considering that all of this happens in the open, on m.d.s.p., what are > you using to support your thinking that there's some undue influence? Do > you believe that if the title peer is removed, the relationship changes? > Between questions asked and concerns raised? You're not just spit-balling, > you're intimating that the speculation has a reasonable foundation that > requires redress, but you're not actually addressing why that speculation > is seen as reasonable. That things happen here, transparently, should > itself serve to demonstrate the speculation as unfounded. Further, the > influence or lack of influence is based on the discussions that happen > here, and that regardless of any influence that may be perceived, the > community discussion that Wayne facilitates as Module Owner provides ample > opportunity to explore or influence in any other preferable direction. > > Just want to point out that Kathleen is currently still the CA Certificate Policy Module Owner. But let's humour the specious reasoning here, and imagine there was some > undue influence on the peership > - One scenario is that such influence is exercised, and that there isn't a > public review or discussion phase to 'undo' that influence, and that's bad. > That's not a failure of peership though, that's a failure of Module > Ownership > - Another scenario is that such influence is exercised, and there is a > public review and discussion phase. If the result produced by that > influence is the same as the community expectation, then there's nothing > improper here. If the result produced by that influence is different from > the community expectation, then that can be corrected and identified during > the review and discussion phase, and such 'influence' is actually either > non-existent or equivalent to the same influence practiced by all > participating members of the community > - Another scenario is that there is no such influence, and the > participation and peership is identical to that of what the community > expects and concurs with. > > It's almost as if influence is being conflated with consistency - that is, > if I'm expressing views that the community agrees with, I'm seen as > influential, while ignoring the fact that if I express views the community > disagrees with, they are just as influential as to call that out. Do you > see the logical flaws here? > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
