feat: Rewrite 'Compatibility and Migration' in RFD template

Based on conversations with Matt Power, I've amended the text
of the "Compatibility and Migration" section of the RFD template
in a couple of ways:

1. Removed explicit reference to SchemaVer as the versioning scheme
   of choice for the CVE Record Format.
2. Introduced a set of questions which must specifically be
   answered in any submitted RFD.

The key goal here is to balance the need for a high level of rigor
around compatibility and migration in CVE because it is a
systemically-important and large multi-stakeholder system with the
need to not be overly prescriptive in the RFD template in ways
which may in fact reduce rigor by over-specializing RFD requirements
on today's considerations for what the important questions are.

The questions included are specific, and intended to capture key
concerns about forward compatibility and the impact of changes
on CVE consumers particularly.

Separately, references to SchemaVer were removed because, while
it is my understanding that SchemaVer is the version scheme of
choice for the CVE Record Format, that is not currently codified
and itself likely ought to go through an RFD process to firmly
resolve. In fact, Matt Power has raised concerns that SchemaVer
may be insufficiently expressive for the versioning constraints
under which CVE operates, and I'd rather not attempt to resolve
that question in the context of this process-focused RFD.

Signed-off-by: Andrew Lilley Brinker <abrinker@mitre.org>

Author: alilleybrinker

rfds/_TEMPLATE.md

@@ -70,43 +70,46 @@ expectations to CVE stakeholders.
 ## Compatibility and Migration
 [compatibility-and-migration]: #compatibility-and-migration
 
-Describe the SchemaVer compatibility between the current development version of
-the record format and the changes proposed in the RFD.
-
-SchemaVer defines three levels of compatibility, delineated as a version triple
-of the form `MODEL-REVISION-ADDITION`:
-
-- `MODEL`: Incremented for breaking changes which present interaction with
-  _any_ historic data.
-- `REVISION`: Incremented for changes which prevent interaction with _some_
-  historic data.
-- `ADDITION`: Incremented for changes which _do not_ prevent interaction with
-  _any_ historic data.
-
-Also describe any migration paths required of CVE stakeholders, including any
-requirement to transition from a prior structure in the schema to a new
-structure, or to comply with stricter data quality constraints.
-
-Some of the following questions may be important to answer, depending on the
-scale of the changes proposed in an RFD:
-
-- How long should the proposed change be communicated to CVE stakeholders in
-  advance of being rolled out in CVE Services?
-- What types of testing are necessary before the change is rolled out into
-  production? (This testing may also be part of the Success Metrics and
-  rollback criteria.)
-
-While SchemaVer's compatibility rules only consider the impact of a change on
-the ability of users of a schema to interact with _historic_ data, any change
-to the schema which adds new capabilities places a demand on CVE stakeholders
-to adapt. For CNAs and ADPs this may mean updating their integrations with
-CVE Services to provide data in new fields, while for CVE consumers it may
-require amending their CVE record parsing to make use of new data or be able to
-parse new records.
-
-This fact, that `ADDITION`-level changes still create work for CVE stakeholders,
-should never be used as a sole reason to reject a proposed RFD, but it should
-strongly inform any roll out plan for changes.
+Describe the impacts of the proposed change on both backward and forward
+compatibility.
+
+To address backward compatibility, explain if and how your proposal would
+impact users of the schema's ability to parse existing CVE records produced
+under prior versions of the CVE Record Format.
+
+To address forward compatibility, explain if current users of the schema would
+be able to accept all, some, or none of the records produced with the schema as
+modified by your proposal.
+
+These explanations must specifically answer the following questions:
+
+1. Does your proposal modify an `enum` type to add, remove, or modify the set
+   of acceptable values?
+2. Does your proposal modify a closed set of required fields to add a new
+   required field or a new alternative set of required fields?
+3. Does your proposal involve the addition of a new format which CVE consumers
+   would need to parse? If it does include a new format...
+   1. How complex is the format to parse?
+   2. Are there parser implementations available under open source licenses,
+      and for what programming languages?
+
+You must also address considerations for planning migration of CVE stakeholders
+to support your proposed changes. This includes both the impacts to CVE
+producers, including CVE Numbering Authorities (CNAs) and Authorized Data
+Publishers (ADPs), and impacts to CVE consumers.
+
+Considerations for migration, which must be addressed in your explanation,
+include:
+
+1. How long should the proposed change be communicated to CVE stakeholders
+   before being implemented in production?
+2. What testing would be needed before the change is implemented in production?
+
+As CVE is a large and multi-stakeholder system, detail and sensitivity in this
+section of an RFD are extremely important. Particular scrutiny should be paid
+by both RFD submitters and reviewers to understand the impacts of any proposed
+change on all sides of the CVE system, including producers (CNAs, ADPs),
+consumers, the CVE Board and Working Groups, and the Secretariat.
 
 ## Success Metrics
 [success-metrics]: #success-metrics