RE: CVE ID Syntax Vote - results and next steps
Pascal, regardless of the new option, we did not plan to renumber any of the old IDs - that would be too disruptive. So the expectation is that will be a "syntax version 1.0" (for 2013 and earlier) and a "syntax 2.0" (for 2014 and later). This topic was not covered too deeply, however, as we had planned to cover transition strategies in more detail AFTER selection of an option.
>From: firstname.lastname@example.org [mailto:owner-cve-
>email@example.com] On Behalf Of Pascal Meunier
>Sent: Friday, April 19, 2013 12:17 AM
>To: Booth, Harold
>Subject: Re: CVE ID Syntax Vote - results and next steps
>That assumes that already issued CVEs would not be revised to conform to
>new format. My understanding of the proposals so far is that as soon as a
>option will be adopted, all previously issued CVEs would be changed to the
>On Thu, 18 Apr 2013 22:34:07 -0400
>"Booth, Harold" <firstname.lastname@example.org> wrote:
>> 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
>> 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?).
>> -----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
>> : 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
>> : 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.