|
|
|||
|
|
|
|||
|
Agreed.
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.
Harold wrote:
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.
Thoughts?
Kent Landfield
McAfee | An Intel Company Direct: +1.972.963.7096 Mobile: +1.817.637.8026 Web: www.mcafee.com
From:
Alfred Huger <
ahuger@sourcefire.com
>
Date: Thursday, April 18, 2013 4:20 PM To: security curmudgeon < jericho@attrition.org > Cc: Kent Landfield < Kent_Landfield@McAfee.com >, cve-editorial-board-list < cve-editorial-board-list@lists.mitre.org > Subject: Re: CVE ID Syntax Vote - results and next steps
|
