Re: CVE Current States

["kseifried@redhat.com" <kseifried@redhat.com>]

On 05/26/2017 07:59 AM, Beverly Finch wrote:
> Chris,
> 
>  
> 
> I prefer the second option.  Keep RESERVED as the state and add
> STATE_DETAIL. 
> 
> I can’t think of any other possible state details but we should 
> consider
> any reporting requirements/stats that may be helpful to Mitre or CNAs 
> in
> the future.
> 
>  
> 
> You mentioned ALLOCATED when talking about UNASSIGNED state.  Is
> ALLOCATED a state or would this be same as RESERVED?
> 
>  
> 
> For REJECT, if there is not a defined list of reject reasons, I
> encourage the team to define them (for consistency in reporting).  Add
> ‘other’ as a catchall for anything missed.  Some ‘fault’ needs to be
> associated with each reason in order to be actionable in the future.

One concern there is defining behavior. E.g.:

REJECT: something went wrong, don't use this.
RESERVED: this is planned for use, you will see it at some future point
(either PUBLIC or REJECTED)
PUBLIC: this is used and here's the info.

I can't think of an "Other" situation (either we're planning to use the
CVE, using it, or explicitly not using it). My thought is if we really
truly run into a situation that isn't covered we need to define it
officially, I don't want data that is not defined and requires human
interaction ideally.



-- 

Kurt Seifried -- Red Hat -- Product Security -- Cloud
PGP A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993
Red Hat Product Security contact: secalert@redhat.com