再保险(CD): CD建议:投票(投票需求)

安德烈·弗雷希说:> > 5)如果投投票成员审议表决,然后编辑> >可能延迟一个临时或最终决定至少2周后> >是投票。> >好,只要有一个审核及时投票选项>显示每个人的问题是由投票>成员,但不应该推迟approvai过程。投票网站包含这个选项。同时,“nodelay”复习的可以指出作为评论。> > 7)如果选票上候选人投票成员中发现的安全问题> >产品属于一个组织竞争,那么> >成员的投票不能计入法定人数,除非> >竞争组织已经公开承认这个问题。>这是否包括推断投票,发生在一个竞争>组织给修改投票?我想说它,因为修改被视为一个“接受与小修改。”>Also, how is a competing organization defined? Is it compartmentalized >by vendors, academic, and government, or perhaps IDS, VA, and other >security products? Good question. I originally thought that it should be separated by the type of product. So a vendor who doesn't make a vulnerability assessment tool could vote on an IDS problem. But the two vendors could have competing IDSes... So I'm not sure. Perhaps it should be left up to the Board member to define who their competitors are. >On a similar issue, would a MODIFY followed by a reference citation >into a voting member's database constitute a public acknowledgement of >the problem? I think I know the answer to this question, but I would >like to see it articulated for the record. If you're asking: "if my competitor acknowledges the problem, but that information isn't included in the candidate, and the competitor hasn't voted, can I still vote for it?" I'd say yes, if some public record can reliably indicate that the competitor has acknowledged the problem. I'm not fully sure I understood the question... >> 3) A voting member should vote on candidates according to approved >> content decisions, instead of their own personal preferences. >Would it be appropriate to add a "no supporting documentation" clause >to this list? > >It's not good form to prevent a voting member from casting a REJECT >just because CVE claims that an issue exists without external support. Lack of supporting documentation gets a little fuzzy in the area of certain configuration problems, but I'd say that if a stated problem has no supporting documentation, it could be REJECTed. This could also apply if the Board member doesn't trust the documentation. There are some older candidates, as you've observed, that have no supporting documentation. I have slated them for rejection because of this. There's a little bit of a slippery slope here. Some people have voted to REJECT a problem that is confirmed to exist, but has no details whatsoever. For example, some vendors release advisories without any details, and just say "there's a problem in this piece of software, apply these patches." An as-yet-unnamed content decision will eventually be proposed to handle these cases in which there is vendor acknowledgement but little "supporting documentation" per se. >> 4) A voting member should not vote for a candidate that is related to >> a security problem in a competitor's product, unless the competitor >> has acknowledged that the problem exists. > >Again, would a MODIFY followed by a reference citation suffice as >acknowledgement? I'll try an alternate take on your question in the hopes that I'll eventually hit the right one. If a Board member votes to ACCEPT or MODIFY a candidate related to their own product, then that's vendor acknowledgement. - Steve