Risk Based Security Vote: CVE ID Syntax Change

[Carsten Eiram <che@riskbasedsecurity.com>]

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

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

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

FIRST CHOICE:

Option B


REASONS (first choice):

I've been preferring option A since the beginning, but with the changes made to the original proposal, this has to me become a decision between the lesser of two evils, which I consider option B to be. 

It is unlikely that CVE exceeds 4-5 digits unless major policy or architectural changes occur. Therefore, this option will closely resemble the existing format and should be easily digestible both when processing it in an automated as well as manual fashion due to the limited number of digits.

I still dislike the inconsistent format (mixing a fixed size to a certain number of digits, and then changing to a variable size) and the inability to easily spot truncation errors (or too many digits), which a purely fixed format provides.

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

SECOND CHOICE:

Option A


REASONS (second choice):

5 digits would likely be sufficient, 6 digits I considered appropriate, 7 digits would be playing it very safe, but the executive decision to go with 8 digits is pure overkill. The large number of digits devalues this option for me. 

While a plethora of digits may be inconsequential for parties purely processing CVE IDs in an automated fashion, the large number of digits can make manual processing and discussions painful and potentially lead to an increase in CVE ID typos due to too few/many leading zeroes.

The advantage of a fixed scheme, which I do like, does not outweigh the hassle of having to deal with 8 digits that likely may never provide any real value.