Expeditious review requested of Zone Attributes definitions rewrites

Ralph Weber Ralph.Weber at wdc.com
Tue May 19 16:42:18 PDT 2015

Formatted message: <a href="http://www.t10.org/cgi-bin/ac.pl?t=r&f=r1505196_f.htm">HTML-formatted message</a>

All 'shall' requirements for the attributes have been moved to the subclauses
that define the attributes (i.e., in these subclauses the 'have' instances
have been changed to 'shall have' ... or more particularly 'shall be set
to'). Naturally, this was accompanied by mirror-image changes in the states
In the SCSI standards with which I am familiar, some kind of entity name is
required following the object name if 'set to' is part of the action for that
entity (e.g., '<foobar> field shall be set to zero', not '<foobar> shall be
set to zero'). Since 'zone attribute' is the equivalent of 'field' in nearly
all the cited cases in both proposals, relenting on the use of 'set to'
(which has been done) means keeping the 'zone attribute' usage.
To my reading, these two notes address all the issues raised earlier today.
My apologies if a detail has been overlooked. Doubtless, it will be raised
again forthwith.
All the best,
From: owner-t10 at t10.org [owner-t10 at t10.org] on behalf of Gerry Houlder
[gerry.houlder at seagate.com]
Sent: Tuesday, May 19, 2015 11:37 AM
To: T10 Reflector
Subject: Re: Expeditious review requested of Zone Attributes definitions
Regarding topic one: I heard strong agreement for using true and false
instead of one and zero. i think most of us are used to the "set to" wording
for consistency. The terms "true value" and "false value" could have
connotation like "real value" or "liar value" that we should want to avoid.
Another topic you didn't discuss: should the zone attributes be referred to
without adding the 'zone attribute" label after them one they have been
defined? This was considered correct when referring to the write pointer,
shouldn't it also be correct for the Non-Sequential Write Resources Active
and the RWP Recommended?
Regarding topic three: There already is a rule that Non-Sequential Write
Resources Active is set to false for empty zones. i think it is fair to
presume that all zones that will be written will start as empty zones, so
that sets the starting value. There already is a statement that a
non-sequential write may set the value to true and there is no other
statement of another event that may (or should or shall) set the attribute to
true. I think this statement is redundant but otherwise have no objection.
Regarding topic four: The one sentence you didn't like in my "big comment"
was a restatement of this sentence with a shall in it instead of just a
"have". I presume you are dropping the shall because these states has a shall
in them about maintaining the attribute. I am OK with that.
On Tue, May 19, 2015 at 10:47 AM, Ralph Weber
<Ralph.Weber at wdc.com> wrote:
Topic One
During yesterday's call, I specifically asked if anybody wanted to insist
that the "set to" nomenclature be used for zone attributes.
The discussion favoring the current wording revolved around the notion that
the definitions of zoned attributes should be enough different from the way
field values are described so as to ensure that the standard was not seen as
requiring any specific implementation for zone attributes.
When the dust settled, I heard no concerted demands for the "set to"
nomenclature. Now, upwards of 90% of the markups in the transmitted PDF
amount to exactly such demands.
Did I misread the tenor of opinions on yesterday's call? Has use of the "set
to" nomenclature become the consensus position?
Topic Two
Regarding the "big comment" ...
Given the previous efforts that are reflected in Curtis' proposed text, I
have no objection to the following two changes.
The device may allocate and deallocate non-sequential write resources at any
time during or after the processing of one or more non-sequential write
commands. As a result, the host is not able to associate the value of the
Non-Sequential Write Resources Active zone attribute with any series of write
commands that start at the write pointer, as recommended by this standard,
mixed with non-sequential write commands.
If a non-sequential write operation occurs in a zone, then the device server
may cause the Non-Sequential Write Resources Active zone attribute to have a
true value.  The device server may change the Non-Sequential Resources Active
zone attribute to a false value at any time if non-sequential write resources
are no longer allocated for that zone.
Action by the host (e.g., sending a RESET WRITE POINTERS EXT command (see
5.2.8) specifying this zone) may or may not be required to cause the value of
the Non-Sequential Write Resources Active zone attribute to change from true
to false.
However, I object to the other changes in the "big comment" as described in
topic three and topic four.
Topic Three
The application client is owed some shred of consistent behavior as regards
the Non-Sequential Write Resources Active zone attribute. Therefore, the
following paragraph (or something equivalent) ought to remain in the
If the device has not processed a non-sequential write command in a zone
since the last time a RESET WRITE POINTERS EXT command (see 5.2.8) was
processed, then the Sequential Writes Affecting Performance zone attribute
shall have a false value.
Topic Four
To maintain a consistency of descriptions across all zone attribute
definitions, the following paragraph is critical to the success of the
Empty zones, read only zones, and offline zones have a false value in the
Non-Sequential Write Resources Active zone attribute (see,, and, respectively).
All the best,
From: Gerry Houlder
[gerry.houlder at seagate.com]
Sent: Tuesday, May 19, 2015 9:55 AM
To: Ralph Weber
Cc: t10 at t10.org<mailto:t10 at t10.org>
Subject: Re: Expeditious review requested of Zone Attributes definitions
My comments are included in the attachment. There is one big comment and a
handful of editorial nits.
On Tue, May 19, 2015 at 8:20 AM, Ralph Weber
<Ralph.Weber at wdc.com> wrote:
The two-page, recently posted
http://www.t10.org/cgi-bin/ac.pl?t=d&f=15-159r0.pdf contains the rewrites
that resulted from yesterday's review of 15-113r3. The goal of this separate
document that is not on any agenda is to put the new text in the hands of
interested parties ASAP.
Comments on 15-159r0 that are received by the close of business today will be
reflected in the ZAC zone state machine document posted tomorrow morning for
review by the conference call later that day.
All the best,

More information about the T10 mailing list