Re: CVE ID Syntax Change - Second Round Voting Ballot (Deadline Wednesday, May 22, 2013, 11:59 PM EDT)

["Andy Balinsky (balinsky)" <balinsky@cisco.com>]

=====================================================
VOTING BALLOT
=====================================================

Enter your votes as specified in the preceding "Instructions" and
"Filling out the ballot" sections.

*****************************************************

FIRST CHOICE: OPTION A

REASONS (first choice):

It is superior to Option B, in that the length is well-defined, and you know whether you have a complete CVE-ID or not. You can be sure it hasn't been truncated in email or otherwise. We feel that 8 digits is probably overkill, but certainly should be enough to handle any foreseeable massive expansion in CVE reporting. 1/4 Million CVE's per day is unimaginable.

From a user search perspective, if option A is selected, we would encourage tools to make the leading zeros optional during a search. In other words, if a user searches for CVE-2014-7, that the search results should include CVE-2014-00000007 (as well as, optionally, CVE-2014-0000007X, CVE-2014-000007XX, etc. where X represents any digit from 0-9). But users who search for a lot of vulnerabilities are going to get tired of typing and counting leading zeros, which is why we favor being allowed to omit them for a search. 

*****************************************************

SECOND CHOICE: OPTION B

REASONS (second choice):

We feel that the completely open-ended nature of option B opens up too much room for errors.  It is just too hard to tell whether you have an incorrectly-typed CVE-ID using option B. And, as we don't feel that the need for cataloguing > 99,999,999 vulnerabilities in a single year is at all likely, option B has no real advantages to speak of.