[sv-ac] Email ballot result (Due 11 April)

Below are the results of the email ballot:

3295

Ashok Bhatt

Yes Laurence Bisht

Yes Eduard Cerny

Dana Fisman

Yes Tapan Kapoor

Yes Jacob Katz

No Scott Little

Yes Manisha Kulshrestha

Yes Anupam Prabhakar

No Erik Seligman

Yes Samik Sengupta

Yes Tom Thatcher

The issue failed.

Comments and friendly amendments:

Scott:
I agree with Erik that the descriptions need some more work to improve clarity.

In the sentence "The system task $assertcontrol" , $assertcontrol needs to have a font change.

In the description for Lock: "Once a $assertcontrol" should read "Once an $assertcontrol"

It think it is easier to follow if the description of the control_types uses the same ordering as the table.

I would favor a high-level English description of most items before the more precise description. For instance, the description of lock has two nearly identical sentences. The first could be changed to something like, "Lock: The Lock control_type prevents the status change of all specified assertions until they have first been unlocked. Once an $assertcontrol call with Lock (control_type value of 1) is applied to an assertion, it becomes locked and no $assert_control shall affect it until the locked state is removed by a subsequent unlock ($assertcontrol call with a control_type value of 2).

I believe that many of the descriptions would benefit from a change along this line.

Erik:
The concepts are great, but I think some editorial changes are needed to make this section clearer:
- At the start of 20.11 we mention $assertcontrol and then dive right into the details of the control_type arg. I think we should start with a high-level description of the purpose of assertcontrol, and a bulleted list with a high-level description of each arg & its type. Then the details of control_type can start in the 2nd paragraph.
- P.3, near start of 20.11-- I think 'expect' needs to be in courier in the text.
- Uses of 'i.e.'/'e.g.' at the start of a sentence or without any semicolon/comma before don't sound right; I think those sentences need rephrasing.
- Where we refer to raw numbers in the text, I think we should have a parenthesized reference to their symbolic meaning. (Except at the start of a bullet point where we have just given the meaning.) Otherwise it requires frequent manual back-referencing to tables. For example:
o Current: "Lock: A value of 1 for this argument shall maintain the same status of all specified assertions until a subsequent $assertcontrol with a control_type value of 2."
o Suggested: "Lock: A value of 1 for this argument shall maintain the same status of all specified assertions until a subsequent $assertcontrol with a control_type value of 2 (Unlock)."
- The extended code example is nice-but I think we should use full words in the symbol names (CONCURRENT, SIMPLE_IMMEDIATE, etc.) rather than truncated words (CONCUR, S_IMMED), to make the example more readable.
- Also in the example, when a comment extends >1 line, it might be nice for each line to have a // to improve readability.

Laurence:
With the following comment: Table 20-5 has 11 values, maybe we should consider a re-org.
The main actions are ON / OFF / KILL.
Pass can get a value ON or OFF or KILL. Same as FAIL.
My point here is to consider adding a new category "Action" which will contain ON / OFF / KILL, and a control category with LOCK/PASS/FAIL/VACUOUS/NONVACUOUS.

Jacob:
Some of the comments in the code on page 5 cross lines...

Tom:
I did find one error in the example
                CONR should be CONCUR

---------------------------------------------------------------------
Intel Israel (74) Limited

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.