communication plan for "<=" version information

[ElectricNroff]

This issue is about whether QWG considers itself responsible for drafting a communication plan about whether:

"version_affected": "<=",

in JSON 4 can or can't directly be represented in JSON 5. For example, CVEProject/cve-schema#100 may have widespread support, for good reasons. Immediately after CVE Services 2.0 launches, there can be a CNA that submits JSON 4 content to the CVE Program, and another organization that wants to consume the JSON 5 document that best represents that content. Suppose that the JSON 4 content has the following, which may follow the pattern that the CNA has used for all submissions before the CVE Services 2.0 launch:

"version_affected": "<=",
"version_value": "1.2.9",

The automatically derived JSON 5 document could include:

versions: [
     {
        version: 0.0.0, limit: *, range: semver,
        status: affected,
        changes: [{at: 1.2.10, status: unknown}]
     }
]

or maybe even:

versions: [
     {
        version: 0.0.0, limit: *, range: semver,
        status: affected,
        changes: [{at: 1.2.10, status: unaffected}]
     }
]

(Note the ambiguity about what <= means. A reasonable person might want to intentionally deprecate <= usage.)

However, there is no way for the automatically generated JSON 5 content to include the number 1.2.9 anywhere, for two reasons:

• a version range may only be a half-open interval [V, L)

• no event occurred at 1.2.9 on the timeline (e.g., the status of 1.2.9 is the same as the status of 1.2.8)

The assigning CNA might be unhappy to see the number 1.2.10 in the automatically generated JSON 5 document, e.g., because they never plan to release a version with that number. (This does not necessarily mean that it is reasonable for them to be unhappy.) If they are unhappy:

• they CAN revise their processes for generating JSON 4 so that "version_affected": "<" is always used instead of "version_affected": "<="

• they CAN revise their processes for generating JSON 4 to list each specific affected version, in which case the automatically generated JSON 5 will specify an array of simple objects, such as "affected" objects for 1.0.0, 1.0.1, ... 1.2.0, 1.2.1, ... 1.2.9

• they CAN submit in JSON 5 instead of JSON 4

• they CANNOT require the CVE Program to customize the automatic generation process on a per-CNA basis (e.g., a custom algorithm in which the number after 1.2.9 is 1.3.0)

If the CNA does nothing between now and November, then:

• on the day that CVE Services 2.0 launches, a JSON 5 document published by the CVE Program will contain the number 1.2.10 (both in response to new content in the JSON 4, CSV, or Flat File format that the CNA submits on that day; and retroactively for all content previously submitted by that CNA)

• the CNA might experience adverse customer impact, e.g., support calls asking how to obtain the imaginary 1.2.10 version

• the transition period in which JSON 4 is supported by the CVE Program (e.g., 6 months or more) doesn't directly address this aspect of the CNA experience

Thus, a communication plan (written either by QWG or by others) may want to address these points:

• a CNA may want to start TODAY on assessing whether the presence of 1.2.10 in a JSON 5 document has potential customer impact (for example, maybe they know that they have major customers who will be very early adopters of JSON 5)

• a CNA may want to start TODAY on deprecating any of its own internal process that produce "version_affected": "<="

• there is a rationale for why "version_affected": "<=" is not precisely represented in JSON 5

• automatic production of 1.2.10 in JSON 5 documents will start no earlier than 1 November 2021

• a draft statement of the algorithm that the CVE Program plans to use (i.e., a generalization of the statement that <= 1.2.9 is automatically converted to < 1.2.10)

• the working relationship between the Secretariat and the CNAs is:

  • the content of a CVE Record's CNA container is the responsibility of the CNA
  • this means that the Secretariat staff are not going to manually edit CVE Records of other CNAs
  • the Secretariat is entitled to use reasonable algorithms that result in version numbers in JSON 5 documents being non-identical to version numbers submitted by any CNA who doesn't use JSON 5 themselves
  • the Secretariat is entitled to revise these algorithms from time to time

[chandanbn]

!< may have the same problem - others with (?) below:

We will need to see the extent of this problem - how many records have this encoding?

Determining a+1 automatically can be tricky too.
Data loss in up or down converting is expected - we need to figure out what is acceptable.

versionAffected	version	start	status
>	a	a+1	affected
>=	a	a	affected
=	a	a, (not a range)	affected
<=	a	a+1	unaffected(?)
<	a	a	unaffected(?)
!>	a	a+1	unaffected
!>=	a	a	unaffected
!=	a	a, (not a range)	unaffected
!<	a	a+1	affected(?)
!<=	a	a	affected(?)