Long identifiers, aliases, etc (00-425r3)

Jim Hafner hafner at almaden.ibm.com
Tue May 15 14:27:26 PDT 2001


* From the T10 Reflector (t10 at t10.org), posted by:
* "Jim Hafner" <hafner at almaden.ibm.com>
*
Folks,

The latest draft of the subject proposal is now on the web site at
ftp://ftp.t10.org/t10/document.00/00-425r3.pdf.  This is the proposal that
defines the CHANGE ALIASES and REPORT ALIASES commands, and patches some
holes in third party commands (XOR and EXTENDED COPY) to use these aliases.

This draft contains all the comments and suggestions that came out of the
last meeting.

The rest of this note describes the changes and the few remaining issues in
brief.  The details are in the document.   I would like to get approval for
this proposal at the next meeting in July and would be more than happy to
rev this document as needed.  So, I welcome any and all comments about the
draft (technical and editorial).

MAJOR TECHNICAL CHANGES (summary):

1) removal of the "atomicity" requirement for access to the alias list;
change to an error condition if CHANGE ALIASES is processed while another
enabled task is using the alias list (this was the major technical change
that came out of the previous meeting).

2) change (from the previous rev) to the reservation conflict rules.
CHANGE ALIASES (usually) "conflicts" and REPORT ALIASES is always
"allowed".

3) addition of a place for "protocol independent" formats, and definition
of the Null Designation as protocol independent (this designation is used
to remove an alias entry)

4) more detailed proposals for FCP and iSCSI designation formats.  The FCP
ones would probably go in an annex to SPC-3 until FCP-3 comes along.  The
iSCSI ones would have to be approved by IETF as that org owns the iSCSI
protocol standard.  These are included in this proposal only as
informative.  [The SRP designations are being handled by the SRP working
group.]


OPEN ISSUES:
1) What ASC/ASCQ should be returned if a CHANGE ALIASES is processed while
another enabled task is using the alias list?

2) There are a few paragraphs that describe "content" and "validity"
language for alias designations.  Is the language proposed acceptable and
if not, what alternatives can we use to meet the author's (my) intent?

3) Are any other protocol independent designations needed besides the Null
Designation used to remove entries from the alias list?

Regards,
Jim Hafner
IBM Research

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




More information about the T10 mailing list