Expeditious review requested of Zone Attributes definitions rewrites

[Gerry Houlder]

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

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 proposal.
>
> 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
> proposal.
>
> Empty zones, read only zones, and offline zones have a false value in the
> Non-Sequential Write Resources Active zone attribute (see 4.5.2.4.2,
> 4.5.2.4.7, and 4.5.2.4.8, respectively).
>
> All the best,
>
> .Ralph
>  ------------------------------
> *From:* Gerry Houlder [gerry.houlder at seagate.com]
> *Sent:* Tuesday, May 19, 2015 9:55 AM
> *To:* Ralph Weber
> *Cc:* t10 at t10.org
> *Subject:* Re: Expeditious review requested of Zone Attributes
> definitions rewrites
>
>   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,
>>
>> .Ralph
>>
>
>