As a follow up to #1 :

3. Defining the productId
   The productId should ideally be globally unique to ensure consistency and avoid confusion across different documents or systems. The assignment of productIds can be managed by a central authority, similar to the supplierID, or follow a standardized naming convention established by the industry. By ensuring a globally unique productId, it becomes easier to track and manage EOL and EOS information for products across various sources and platforms. Getting consensus of this central authority will be one of the most challenging parts of all this. However, we can start the conversation with other industry leaders, CISA, and other participants.

Originally posted by @santosomar in #1 (comment)

Creating this issue to track this.

I think we should have either a repo, or a subdirectory of a repo, for people to submit use cases.

I will use the term use cases in the general English usage of the words (ie a case where something is used) but the software development purists might claim these are scenarios not formal use cases (note I didn't use word formal in what I proposed).

IMHO people shouldn't refute other people's use cases (just because sFractal doesn't do something doesn't mean someone else doesn't do it). Conversely, people can't submit other people's use cases (eg I at sFractal can't say 'at Redhat they do .... or as happens more often 'I think someone might ...'). Ie just speak for yourself.

If this gets contentious (it usually does as we tend to talk past each other assuming other people use our context not theirs), I found it useful to have a subdir for 'agreed to general usecases' and a subdir for 'contributor use cases'. We start with everyone submitting their own use cases into their own subdir of the contributor use cases (eg I'd put them in usecases/contrbutor/sFractal). If everyone agrees a particular sfractal use case is 'general enough', then it gets copied (maybe edited first) into usecases/general. Usually we don't need the general use cases and just develop the spec from the pile of contributor use cases. But having documented use cases does allow all of us to see the different perspectives.

This tends to be most useful in contrasting situations. One is the commercial closed source vendor vs the MIT license open source github library (and I realize there are many other variants than these two). Another is between hard-to-update-IoT devices vs classic server app vs cloud whatever-as-a-service. Delineating the use cases helps us recognize when person A was talking one situation applicable to their environment and person B was talking about a different situation applicable to their environment.

The other advantage of the 'everybody in their own subdir for use cases' and 'don't bother about the general use casses' is you don't spend months arguing about them.

We are going to be creating specifications/standards for interoperation. Terminology will be important and we will probably spend too much time arguing what certain words mean. I believe one important distinction we will need to make for each term is whether the spec contains a 'definition' or a 'description'. It seems nickpicky but doing this correctly may make lawyers happier and may make the process go faster.

A definition is 'the exact meaning of a word' and a description is less exact and can change person to person.

One example where this was important was STIX use of the label 'terrorist'. We did NOT "define" terrorist (political hot potato as well as context sensitive - Ethan Allan was a patriot in the American Revolution but he was a terrorist from the British viewpoint). STIX 'describes' terrorist. It's a label that an analyst (human or virtual) can use and convey that label in a STIX message. In STIX we don't define what a terrorist is. That's up to analyst in the context of their environment. We do include a description and are careful to use the word description not definition (and it's not in the definitions section).

We will need to decide on terms like "end of support' whether we 'define it' (we get everyone to agree on one definition that will apply to everyone in all situations or 'describe it' - ie we include words but they are nonbinding and it is between the sender and the receiver to agree on a definition for their interopration, but a different pair may use a different definition. Note the JSON won't care either way - it will contain the same content.

Note we can even change our minds. E.g. when we run into a terminology roadblock trying to define a label, we make it a description and get this version of the spec approved. If at a future time, we manage to get agreement on a definition, we update the spec. it would even be a non-breaking change as the interface wouldn't change - just the words in the spec on the use of that particular label.

usually when a product or component is reaching end-of-life, there already exists a successor product.
It would be helpful to learn about this product. Especially, when the successor is not obvious.

E.g. Red Hat Enterprise Linux 8.4 is EOL. https://access.redhat.com/support/policy/updates/errata

"In Red Hat Enterprise Linux 8, EUS is available for: 8.4 (ended May 31, 2023)"

The obvious successor was RHEL 8.5, but you also might want to update to the latest 8.X.

Thus, the field for the EOL-notification could look like this successor: "RHEL 8.5 or later"

In other cases, a release might be the last of its kind.

E.g. open source ISC-DHCP server has reached EOL by end of 2021. https://www.isc.org/blogs/isc-dhcp-eol/

The product is discontinued, but the ISC is replacing it with a new implementation: https://www.isc.org/kea/

Thus, the field for the EOL-notification could look like this successor: "Kea DHCP, https://kea.isc.org/"

In other cases, one discontinued component may have several competing successors.

When you come across an EOL notification it can become cumbersome to hunt down the supplier contact information to learn more about the EOL or the products lifecycle.

The two new fields supplierURL and supplierEmail could solve this issue.

supplierURL would obviously be a URL. The creator would have to be instructed that the field SHALL be a "permanent" and "long-living" URL to product information. (In contrast to e.g. a press release.)

supplierEmail would obviously be an email address to get in touch with the supplier. This email-address SHALL be a functional account, not a personal account to avoid tight coupling to an individual. (e.g. [email protected] instead of [email protected])

Our Code of Conduct is missing the contact address... ([INSERT CONTACT METHOD]).

Add a CODE_OF_CONDUCT.md file to set the ground rules for collaboration and communication within the project. This file should outline expected behaviors and provide guidelines for reporting violations.

Create a basic CONTRIBUTING.md file to instruct users on how to contribute and collaborate.

This is especially helpful, when you have multiple such statements with different content (to figure out which one is the latest).

Hi @santosomar,
thank you for getting us started on that important topic.

I feel there are a few things that need to clarified:

1. Who assigns / How is the supplierID assgined?
2. When you say supplier: Do you think of the source where you got that from or the developer(s) (project)? (E.g. I might get an open source software A from a service provider B that guarantees software updates / vulnerability fixes for 5 years. Who do I put into supplier? A or B?
3. When you define a productId: Is that a globally valid productId or is it document-local? Who assigns that?

Just having a single "end" date doesn't seem sufficient to me.

We'd need different lifecycle phases. One example is here: https://access.redhat.com/support/policy/updates/openshift#ocp4_phases

To match and check the schema automatically, we should add a $schema as property and make it mandatory.

Creating a Security Policy for a GitHub repository is an important step to ensure that the code and its users are protected.

This is a minor cosmetic change to change the name of the schema from eol-eos-schema-0.2.0.json to just schema-0.2.0.json

We've been looking at a similar concept but for container images. The scenarios for container images are a bit different than for a software (or they have more nuances). This document describes the concepts: https://docs.google.com/document/d/10lwVJBYoYkhfAjUfy4pq89GnmhTn0ecn/edit?usp=sharing&ouid=101139698331273179431&rtpof=true&sd=true

Would be interesting to know if OpenEoX will provide support for those scenarios.

Perhaps add a README.md to in the new /schema folder.

As a follow up to #1 :

SupplierID assignment: The supplierID can be assigned by a central authority or registry responsible for maintaining a unique identifier for each supplier in the industry. Alternatively, it can be generated using a specific algorithm or process that ensures uniqueness and avoids conflicts. However, this is something that we will need to discuss in the industry, once we take the next steps and work with other industry peers soon.

Creating this issue to track this.

https://endoflife.date/contribute has taken the lead for a while in helping publish and consolidate end of sale information.
The also have public source in https://github.com/endoflife-date

Please ensure coordination between OpenEoX and endoflife.date so that everyone can learn from one another, and benefit from commonalities.

The schema should have an $id property to be able to refer to it.