More than an Identifier ...but... less than a Name

Ralph Weber roweber at
Fri Jan 21 13:09:00 PST 2011

* From the T10 Reflector (t10 at, posted by:
* Ralph Weber <roweber at>
Let's try looking at it this way.
In response to an EXTENDED COPY command, a copy manager assigns a
[name|token|identifier ] to a collection of bytes. At a future time,
the *same* copy manager is presented the [name|token|identifier] as a
way to address the same collection of bytes. The [name|token|identifier]
may be presented to the *same* copy manager any number of times ...
via however many paths that copy manager is addressable (FC, iSCSI, SAS,
this port, that port, etc.). It is the *same* [name|token|identifier] in
all such cases.
The [name|token|identifier] is expiration dated (how is TBD), but rest
assured, expiration dates measured in weeks or even months are considered
critical to success in some circles.
The following points are fundamental:
a) the "token" is only valid when presented to the copy manager that 
created it;
b) checking the validity of a "token" is the copy manager's problem 
(with caveat noted below); and
c) the "token" is neither short-lived nor long-lived.
[Caveat] Based on T10's general interest in making SCSI work well, I
have  every reason to believe that some details of how to validate a
"token" will creep into SPC-4 as part of the "token's" definition.
However, I cannot accept the premise that details of how the
"token" is validated affect the term to be used.
Now! Here is the rub.
I have recently become interested in giving one collection of bytes
a genuine Identifier -- in addition to a "token". The genuine
Identifier would have a lifetime that is limited to the duration of
processing for the EXTENDED COPY command which creates it. This is
a short-lived thing, and Identifier is definitely the right term.
Also the genuine Identifier is 16 bits, which is vastly different
|from the 512 byte "token".
I do *not* want the standard to pick between Identifier and "token".
A single EXTENDED COPY command might create one, or the other, or both
for a single collection of bytes. Only the application client knows
for sure which usage (or usages) are correct for a given situation.
As far as I am concerned, this usage model removes identifier as a
possible replacement term for "token". In theory, the "token" could
be called a name, but in my humble opinion that choice might very
well end up giving SCSI Names a bad name.
So, we have come full circle ... back to "token".
All the best,
On 1/20/2011 6:29 PM, Joe Breher wrote:
> My use of the term 'domain' in my initial post was meant to be taken as
domain in the general sense -- wider than the scope of our defined term of
'SCSI domain'. If a 'snapshot token' (i.e. the handle we use to refer to the
pile of point-in-time logical block copies) crosses SCSI domains, that just
makes the domain (not necessarily SCSI domain) over which names must be
unique and invariant that much larger.
> Let me ask this in an attempt to add clarity (for my benefit at least):
> This 'snapshotty' thing is assigned a [ name | token | identifier ] by some
entity within a SCSI domain. May this snapshotty thing later need to be
dereferenced in another SCSI domain, using the same [ name | token |
identifier ]?
> If so, it would seem to me that the name, token, or identifier be created
in some deterministic fashion, such that name conflicts could not occur.
> Again, should this be the case, it sounds as if what is needed is a name.
> If not however, perhaps 'snapshot identifier' would be appropriate
(substitute the term of your choosing for 'snapshot').
> Crawling further out on the limb, to me a 'token' implies something that an
object possesses only long enough to present as a credential to another
object. I don't see it as a unique characteristic of the object to be
identified. Your view may differ.
> I still don't see the necessity of a third classifier beyond 'name' and
> <<...snip...>
* 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