RE: CVE ID Syntax Vote - results and next steps

["Christey, Steven M." <coley@mitre.org>]

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. 

- Steve


>-----Original Message-----
>From: owner-cve-editorial-board-list@lists.mitre.org [mailto:owner-cve-
>editorial-board-list@lists.mitre.org] On Behalf Of Pascal Meunier
>Sent: Friday, April 19, 2013 12:17 AM
>To: Booth, Harold
>Cc: cve-editorial-board-list
>Subject: Re: CVE ID Syntax Vote - results and next steps
>
>That assumes that already issued CVEs would not be revised to conform to
>the
>new format.  My understanding of the proposals so far is that as soon as a
>new
>option will be adopted, all previously issued CVEs would be changed to the
>new
>format.
>
>On Thu, 18 Apr 2013 22:34:07 -0400
>"Booth, Harold" <harold.booth@nist.gov> 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
>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: owner-cve-editorial-board-list@lists.mitre.org
>> [mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of security
>> curmudgeon Sent: Thursday, April 18, 2013 6:05 PM To:
>> Kent_Landfield@McAfee.com Cc: cve-editorial-board-list@lists.mitre.org
>> 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.
>>