lifecycle schema proposal

[p-rog]

Below is a lifecycle schema proposal.
It's very flexible and the general conception is similar to the CSAF schema, where items defined in the product tree are mapped to the list if lifecycle phases. The main purpose of this is to allow vendors to define different phases of the End Of Support and End of Life lifecycle depending on their needs and product support model. Additionally one product can be supported in multiple streams, hence flexible mapping will allow define that one product stream is still supported when another one is already in the End Of Support phase.

First we need a lifecycle definitions (types) as a reference.
Similar to https://github.com/oasis-tcs/openeox/pull/13/files

Schema definitions:

lifecycle types:
- EndOfSupport
- ExtendedSupport
- StartOfSupport

The lifecycle schema could be like it's explained below:

The OpenEoX file for the product like RHEL:

**document:**
- document metadata
  - id
  - notes
  - publisher
- tracking
- revision_history

**products:**
- RHEL 9.2
  - ID: PID-1
  - based_on: 9.1
  - product_identification_helper
    - product_stream: rhel_9.2
- RHEL 9.3
  - ID: PID-2
  - based_on: 9.2
  - product_identification_helper
    - product_stream: rhel_9.3

**lifecycle phases:**
- ID:1
  - type: EndOfSupport
  - desc: "we stop shipping patches"
  - ref: <url>
  - scope: [private, public, whatever]
- ID:2
  - type: ExtendedSupport
  - desc: "we are shipping Critical + Important"
  - scope: public
- ID:3
  - type: ExtendedSupport
  - desc: "we are shipping Critical only"
  - scope: public
- ID:4
  - type: ExtendedSupport
  - desc: "CustomerX-specific phase"
  - scope: private

**mapping:**
- RHEL 9.2
  - active_phases[]:
    - ID:2
      - Jan 1 -> Jan 20 
    - ID:4
      - some dates
  - inactive_phases[]:
    - ID:X
      - some past dates
- RHEL 9.3
  - active_phases[]:
    - phase: ID:3
      - dates: Jan 1 -> Jan 30

In this proposal the EoL and EoS can be easily defined, including special attributes like visibility, and also different types of support model can be easily assigned to the product streams.

Thoughts?

[santosomar]

Can we also include the definitions to those elements in #13 ? This way we can also start defining all these fields in a central place and then start incorporating the use cases in the schema.

[santosomar]

ExtendedSupport and StartOfSupport should be optional fields, since not all products will have extended support or an entity will know the original date of "General availability" which is another term for StartOfSupport.

[shridarc]

Can we add "AdditionalInformation" field in schema and keep it optional. This will give flexibility so publisher put text or URL where user can pull information beyond basic[ID, EndofSupport, publisher].

[p-rog]

@santosomar the ExtendedSupport, StartOfSupport or General availability are just different support definitions, not fields. You specify the support definition in the type field.
Do you want me to add these lifecycle types to the taxonomy definitions?

@shridarc the ref: field in the lifecycle phases: section gives you an option to set a link to additional, external information. Do you think that additional, optional, "text" field is necessary?

[santosomar]

@p-rog Thank you so much for the explanation and contribution! Yes please add ExtendedSupport, StartOfSupport or General availability to the taxonomy document. Thanks again!

[kvandecr]

While I do agree with all that the taxonomy is important, for the End User of this data, the concern is not "how does Vendor X call this particular milestone?" . Customers are concerned about:

• When do I need to take action?
• Which action should I (ideally) be taking?
• What are the implications of not taking any action?

Having vendor-specific taxonomy labels does not provide much concern, whether it's called End of Life or Last Day of Vulnerability Support, but the concerns here are what these labels mean. Ideally, to address these, the standard includes with each step in the lifecycle:

• Date of the status change
• Recommended action from the vendor (url?)
• Risk assessment of using a particular version after each subsequent lifecycle milestone

These are mostly addressed in @p-rog's example above, I would like to make sure we focus on what is end-user relevant vs vendor culture concerns

[shridarc]

What I mentioned in meeting:

• Request to provide example so members understand.
• Add Product Type
• LifeCycle Phase - request to add "Withdrawn"

[p-rog]

@shridarc I will share example later this week.
I agree with you that having the product_type object in the products definitions would be beneficial.

Can you please explain what "Withdrawn" lifecycle phase would mean to the end user?
Do you have any real example where it could be used?

[thschaffr]

@p-rog and team; I have two questions/ideas.

1. Could we add two sections which indicate whether a product is still "supported" or as @shridarc described it "withdrawn". --> This would help us with keeping the model and especially the sections clean for machine consumption later on. E.g. a company might want to run a retrospective report on "withdrawn" versions and add those to a scanner etc.
2. Is there a reason that ref: is only mentioned under the EndOfSupport section? I think once we agreed on the various definitions, we can also add it as an optional field to the other sections.

Thank you in advance.

[shridarc]

Withdrawn - The term is used when Product ID is removed from Support immediately or earlier compared to standard Support timeline mentioned in End of Support Policy. You can find example if you search with keyword :Withdraw, Software

[kvandecr]

Cisco has this as well, we call it 'deferred'