I could see changing my vote to A if the number of digits were extended. I responded that I believed Harold was on target with his idea to reevaluate Option A.
I agree that a revote using the same options would probably result in more or less the same result. But after reviewing the reasoning for voting, those that voted for Option B were mostly concerned with avoiding the need to change again ("future proofing") while those who voted for Option A seemed to be mostly concerned with the variable length nature of Option B. I share both sets of concerns and I would presume that there is a point where a fixed length identifier would be of an acceptable length that those who voted for Option B could be comfortable with and would address their "future proofing" concerns and those who voted for Option A would not believe would be too long. I would also like to suggest that choosing whether to use leading zeroes or not be separate choice.
Using his logic, we could make it 10+ digits and not pad it with leading zeros. Then it would be capped at a static length but we would only have to use what we need. It could grow as needed and we would have the future proofing that is a major reason stated by those who voted for Options B. The end user would see a CVE ID that is reasonable from a readability perspective, software would have a static length that we can grow into. An approach like this could potentially go a long way to getting to a consensus majority.
From: Alfred Huger <firstname.lastname@example.org>
Date: Thursday, April 18, 2013 4:20 PM
To: security curmudgeon <email@example.com>
Cc: Kent Landfield <Kent_Landfield@McAfee.com>, cve-editorial-board-list <firstname.lastname@example.org>
Subject: Re: CVE ID Syntax Vote - results and next steps