Ballot Details: Resolve VIRTIO-167: Confusing "non-Transitional" conformance statement (CLOSED)

Ballot Question Should the TC accept changes listed in the description to resolve issue VIRTIO-167, for inclusion in specification version(s) "virtio 1.1 cs01", and future versions of the specification?
Ballot Description Please vote Yes if you agree with all of the following.
If you disagree, please vote No.
If you don't have an opinion, please vote Abstain.

I move that:
The TC agrees to resolve the following specification issue:
VIRTIO-167: Confusing "non-Transitional" conformance statement
--------------------------------------
We read in 7.4:

"A non-transitional implementation conforms to this specification if it satisfies all of the MUST or REQUIRED level requirements defined above. "

Is that true? ALL the "MUST" in all previous sections? Probably not. Or maybe it is "below" and not "above". (always explicitly refer to requirements sets by using a sub-section number & name)

I suggest to make "transitional" just a variable (i.e. a parameter) in previous top-level conf clauses. (see TAB conformance guideline [http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html, section 5.5) |http://docs.oasis-open.org/templates/TCHandbook/ConformanceGuidelines.html)]E.g. someone claiming conformance as "PCI driver" should always clarify: "transitional PCI driver" or "non-transitional PCI driver"
--------------------------------------

The TC accepts the following proposed changes to the specification:
--------------------------------------
https://lists.oasis-open.org/archives/virtio/201903/msg00063.html
--------------------------------------

The TC agrees to include the above change(s) in specification version(s) "virtio 1.1 cs01", and future versions of the
specification.

--------------------------------------

Reminder: A Voting Member must be active in a TC to maintain voting rights. As
the Virtio TC has adopted a standing rule to conduct business only by
electronic ballot, without Meetings, a Voting Member who fails to cast a ballot
in two consecutive Work Product Ballots loses his or her voting rights at the
close of the second ballot missed.

--------------------------------------
Ballot Options
VOTING CLOSED: Thursday, 21 March 2019 @ 5:30 pm EDT
Yes 5 100
No 0 0
Abstain 1
Open Date Thursday, 14 March 2019 @ 5:30 pm EDT
Close Date Thursday, 21 March 2019 @ 5:30 pm EDT
Ballot Type Official, as defined by organization policies and procedures

Voting Statistics

Number of votes cast (excluding abstentions) 5
Eligible members who have voted 6 of 6 100%
Eligible members who have not voted 0 of 6 0%

Voting Summary by Option

Options with highest number of votes are bold
Option # Votes % of Total
Yes 5 100%
No 0 0%
Abstain 1

Voting Details

Voter Name Company Vote * Time (UTC) Comments
* Carabas, Mihai Oracle Yes 2019-03-15 07:37:00
* Hajnoczi, Stefan Red Hat Yes 2019-03-20 16:57:00
* Huck, Cornelia Red Hat Yes 2019-03-14 22:17:00
* Kiszka, Jan Siemens AG Yes 2019-03-15 06:40:00
* Tsirkin, Michael S. Red Hat Yes 2019-03-14 21:47:00
* Pasic, Halil IBM Abstain 2019-03-15 13:44:00 1

Voter Comments

Submitter Vote Comment
Pasic, Halil
IBM
Abstain I believe this change is an improvement. I also believe it does not address all issues raised in the description of VIRTIO-167.

The list of requirements in section "7.4 Legacy Interface: Transitional Device and Transitional Driver Conformance", which is its main content, has nothing to do with conformance, and is not linked to any conformance statements. Furthermore normative language usage in 7.4 (MUST, etc) and especially the sentence "A conformant implementation MUST be either transitional or non-transitional, see 1.3.1." which looks like a normative statement but ain't tied to any conformance target.

I agree with including this change in virtio 1.1 cs01 but I don't think it resolves VIRTIO-167.