[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: CVE ID Syntax Vote - results and next steps
I would also add that with an Option B with no leading zeros, including less than four digits, a transition of sorts is available for the first year (or more) if CVE identifiers started at 1000. Until the 9000'th CVE tools would successfully chug along giving everyone a bit more transition time. This could allow even more time depending on the eventual number of CVEs created. Whereas with an Option A with padding there is no such transition, and whatever number of digits are agreed to are included in every CVE from the beginning (in 2014?). Regards, -Harold -----Original Message----- From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of security curmudgeon Sent: Thursday, April 18, 2013 6:05 PM To: Kent_Landfield@McAfee.com Cc: email@example.com Subject: Re: CVE ID Syntax Vote - results and next steps Importance: High On Thu, 18 Apr 2013, Kent_Landfield@McAfee.com wrote: : 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. As mentioned, this is fine with me. I was not voting for the # of digits in A. I was voting for the standard method it used in displaying it. Optionally, if Option B was redone to remove ALL trailing zeros, that too would be fine with me, as it would then bear a standard display format (of sorts). : 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 If both were changed as mentioned above, where A was 7 digits intead of 6, and B had no leading zeros at all. I am really curious how people would vote. : 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? Overall I like it. We're addressing the problems with the proposed solutions, and building on them, rather than coming up with additional. It would be great if every member would weigh in on the above, not as an official vote, but just to see if either has more benefit, or to add other options and ideas.