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.
McAfee | An Intel Company
This is seriously devolving. Can we possibly drop the temperature a bit and discuss this civilly?