RE: CVE numbering

["Huger, Alfred" <Alfred_Huger@nai.com>]

> - 'Reserving' arbitrary blocks of numbers for backfill or middlefill.
> - Difficult to insert CVE indexes in the event that some information
> source
> is unearthed in the future.
> - Adds little or no value as to the relative time of discovery, as in the
> example where one knowledge base reports the discovery date as several
> months different from another site.
> - May require reindexing at a future date, thereby requiring version
> control
> and violating the integrity of the index numbers (CVE-1 may not always be
> CVE-1).
> - May delay entry of information pending authoritative determination of
> discovery date.
> 
> 
> 
	I would have to agree with Andre, given this is a post-event effort
it makes more sense to apply the numbers in the current format with the
given disclaimers Andre mentioned. The value (at least where Scanner
customers are concerned) is not to chronologically arrange the
vulnerabilities but to properly categorize them to help people get a better
handle on what a given product checks for. 

	This IMO will help alleviate the 'check magic' or creative math that
vendors are applying to their vulnerability counts in their Scanner or ID
products. Note, I am not pointing fingers, it is my opinion that we *all* do
it to some degree or another.

	-Al Huger