Comments on 00-359r6; extra unit attentions are permitted

Edward A. Gardner eag at
Wed Oct 3 17:51:43 PDT 2001

* From the T10 Reflector (t10 at, posted by:
* "Edward A. Gardner" <eag at>
A minor nit, Ralph's email and document incorrectly referred to 00-356r6.
The proper reference is to 00-359r6.

Ralph Weber recently posted 01-299r0, comments on 00-359r6, Interlocked UA.
Ralph's document contains three major comments, each presented as a separate
table.  This responds to the first and third comments.  I will respond
separately to the second.

I am posting this to the T10 reflector to elicit discussion.  I do not plan
to make it a formal T10 document unless someone requests that I do so.

The short answer to Ralph's first and third comments are that his proposed
changes would not affect whether a particular device or implementation did
or did not conform to SAM-2.  Therefore we should omit the proposed changes
as that results in simpler wording.

I hope that grabs enough attention to motivate reading further :-).

SAM-2 contains a catch all statement that a logical unit shall generate a
unit attention condition whenever any event occurs that the logical unit
thinks requires the attention of the initiator (beginning of subclause 5.8.5
and list item h).  In other words, a logical unit is free to generate a unit
attention condition whenever it feels like it, for any reason whatever.
SAM-2 and other standards specify certain events that shall generate a unit
attention condition, but any logical unit is free to generate unit attention
conditions for as many additional events as it wishes.  This "feature" is
not new, the relevant words were in SCSI-2.

A consequence of this is that it is meaningless to try to limit how many or
how often unit attention conditions are reported.  Any such limit is at best
guidance to an implementer on what constitutes a good implementation.  If a
logical unit wishes to generate extra unit attention condition report, it is
free to generate a "new" unit attention condition indistinguishable from the
old one at any time.  The "new" unit attention condition is generated in
response to the "I think it's time to report this again" event.  Such a
logical unit is in full compliance with the SAM-2 and SCSI-2 discussion of
unit attention conditions.

The important words in SAM-2 are those that specify when a unit attention
condition shall not be cleared -- those are the words that specify a future
report will be generated, because the unit attention condition hasn't been
adequately reported yet.

Less important are words that specify when a unit attention condition shall
/ should / may be cleared, as those are only advisory regardless of which
verb (shall / should / may) we use.

Arguably this implies that we should change all occurrences of "unit
attention condition shall be cleared" to "unit attention condition should be
cleared" to reflect the inherently advisory nature of such statements.  I
think that would be a worthwhile improvement to SAM-2.  However, it is
totally unrelated to the subject of 00-359.  The current wording of 00-359
reflects the previous words in SAM-2 as modified by working group review of
00-359.  If there is obvious consensus on the T10 reflector at least two
weeks prior to the next meeting, I will revise 00-359 to reflect that
consensus.  However I will categorically refuse to update 00-359 due to
working group discussion on this issue, since it is totally unrelated to the
subject of 00-359.  If anyone wishes significant working group discussion on
this topic, they should write their own #$*% proposal and request their own
agenda time.

The remainder of this message addresses some additional minor details of
Ralph's first and third comments.  Since the gist of the above argument is
that those comments should be ignored or rejected in their entirety, feel
free to stop reading here (except for Ralph and George).

First comment:

sam2r20, sub-clause, Asynchronous Event Reporting, top of page 68,
pdf page 91, third paragraph on that page as amended by 00-359r6.

Ralph's proposed change is to add the sentence:

If an asynchronous event report is chosen to report a unit attention
condition, the unit attention condition shall be reported to a specific
initiator only once per event causing it.


Per the above argument, it is meaningless to try to require that a unit
attention condition be reported only once per event, since the logical unit
is free to manufacture additional events at will.  Such a sentence might be
useful as implementation guidance, but the sentence above is flawed.
Interlocking unit attentions requires that a unit attention condition might
be reported once with an asynchronous event report, then many times as
autosense (for commands that may have been in flight when the asynchronous
event report was sent).  If we are to say anything at all, I propose the
following alternate text to be added as a separate paragraph:

A unit attention condition should not be reported to a specific initiator
using an asynchronous event report if that unit attention condition has
already been reported (using any method) to the same initiator.

We could append "subsequent to the most recent occurrence of an event
causing that unit attention condition" to the above sentence, but I think
that makes it sufficiently complicated to confuse people without significant
benefit.  We would need to append those phrases if we used "shall" instead
of "should".

I would prefer to leave the text of 00-359r6 unaltered, and will do so if I
get no further response.

Third comment, part 1:

First sentence of the last paragraph of the rewritten 5.8.5.  This sentence
discusses current behavior when a unit attention condition is reported with
an asynchronous event report or with autosense.  The text in 00-359r6 says
"the logical unit may clear the unit attention", the current text is sam2r20
says "the logical unit shall clear the unit attention".

Per the above argument, I think the phrase "shall clear" is meaningless.

The history of this is that 00-359r3 specified "shall clear", unchanged from
SAM-2.  At the July 2001 CAP meeting I was instructed to change this to "may
clear".  The CAP minutes do not speak to this.  My own notes merely indicate
that I was instructed to change the word.  My vague memory is that George
Penokie and/or Gerry Houlder told me to make the change, but the memory is
vague enough that I don't trust it to be reliable.  I don't recall the
reason for the change.

Fundamentally I don't care which verb is used (shall / should / may), as
this is unrelated to the substance of 00-359.  Procedurally I was instructed
to make the change, so I did so.  If there is an obvious consensus to change
this on the T10 reflector in advance of the November CAP meeting, I will be
happy to change it back.  I am unwilling change it again from discussion at
the November CAP meeting -- if there is this much controversy it can and
should be a separate proposal, not bundled into this unrelated topic.

Third comment, part 2:

This comment addresses editorial changes to the text being added to SPC-3's
discussion of the control mode page.  If I've understood Ralph's comment
correctly, he proposes to replace (text proposed in 00-359r6):

A uaintlck bit of zero specifies that the logical unit may clear any unit
attention condition reported with autosense or asynchronous event reporting.


A uaintlck bit of zero specifies that the logical unit clears any unit
attention condition reported with autosense or asynchronous event reporting.

As far as I'm concerned this is an editorial nit, and Ralph is welcome to
rephrase it this or many other ways when he incorporates the proposal into
SPC-3 (or any other time for that matter).  I'm happy to make the change to
00-359 if Ralph so wishes, but only if George agrees that he's happy with
Ralph's wording.

This is one of the few issues that I am willing to update based on
discussion at November's CAP meeting, since (despite being an editorial nit)
it is directly related to the substance of 00-359.  However it would be much
more efficient use of time if we agreed in advance.

Edward A. Gardner               eag at
Ophidian Designs                719 593-8866 voice
1262 Hofstead Terrace           719 593-8989 fax
Colorado Springs, CO  80907     719 210-7200 cell

* For T10 Reflector information, send a message with
* 'info t10' (no quotes) in the message body to majordomo at

More information about the T10 mailing list