CVE ID Syntax Change - MITRE vote

["Steven M. Christey" <coley@mitre.org>]

After discussion among the MITRE CVE team, we present the following as
the official MITRE vote. We feel it is important to note that the
following is a consensus opinion of the CVE team, arrived at after
much discussion, and should not be construed as unanimous.

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

FIRST CHOICE: Option B

REASONS (first choice): Option B does not change the syntax until it
is absolutely necessary (> 9,999 IDs), so it retains the recognition
and processing of the old format for the longest possible time.  This
means that the new ID syntax will be less likely to break products
initially, and will afford consumers of CVE more time to implement
changes.  Although transcription errors are always possible, if they
occur they are much more likely to resolve to or be recognizable as a
valid CVE ID.  Option B provides an infinite ID space, which will
"future proof" CVE IDs in this specific regard.

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

SECOND CHOICE: Option A

REASONS (second choice): Option A could be expected to immediately
break products that have not been able to implement the necessary
changes by 1 January 2014.  Option A provides for a finite (although
very large) number of IDs.  It should be noted that the team feels
that any circumstance(s) that would require the issuance of (on
average) over 2,700 CVE IDs per day (999,999 IDs per year) would
reflect a fundamental change in the meaning and usage of CVE IDs.  Put
another way, the "CVE" that requires the issuance of over 2,700 IDs
would not be the CVE of today. To be complete, we recognize that the
fixed length of Option A makes parsing simple and predictable, and the
syntax would be close enough to the original to be immediately
recognizable as a CVE.

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

THIRD CHOICE: Option C

REASONS (third choice): The MITRE team recognizes that there are many
attractive features of Option C.  It has an infinite ID space and has
a built in method to detect parsing and transcription errors.
However, some team members believe that the implementation and
utilization of the detection feature will be inconsistent and,
overall, the format makes transcription errors more likely.  They also
believe that the addition of the check digit is sufficiently different
from the current format that it will confuse many users.  It was
suggested by some that it is unnecessary to have the check digit as
part of the official ID scheme; a detection feature could be added as
additional, supplemental information later.  For these reasons, MITRE
does not favor Option C.