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

Ballard, Curtis C (StorageWorks) curtis.ballard at
Tue Jan 25 11:01:29 PST 2011

Formatted message: <a href="">HTML-formatted message</a>

I'm uncomfortable with the term 'token'.  There are several usage models
where the word 'token' implies permission (e.g., you have the token, you may
go ahead).  In the SCSI realm I have seen this in multi-initiator tape
environments where only one initiator can use the drive at a time but many
initiators have access and a 'token' is passed around to control who is using
the drive at any given time.  The value that is being described in this
discussion doesn't sound to me like permission as much as it does location.
I have seen a couple of terms used in discussion of the concept that I think
are possible descriptions.   I think the one I liked best was 'reference'.  A
reference is information necessary to look up something and it usually
assumes a preexisting domain knowledge before it makes any sense.  Some
references resolve directly but there are also indirect references that
require looking somewhere else to get the rest of the information and the
concept being described here sounds to me a lot like an indirect reference.
Another term used that sounded promising was 'handle'.	In common use a
handle is a lot like a name but not as permanent.
Curtis Ballard
Hewlett Packard
StorageWorks Division
Fort Collins, CO
(970) 898-3013
From: owner-t10 at [mailto:owner-t10 at] On Behalf Of
Joe.Breher at
Sent: Tuesday, January 25, 2011 11:25 AM
To: Ralph Weber
Cc: owner-t10 at; T10 Reflector
Subject: Re: More than an Identifier ...but... less than a Name
Ralph -
Thank you for the detailed description. With the expanded discussion, I
concur that what is described is not a name.
It would apear that you have essentially two forms of an identifier - one
that you propose to refer to as an Identifier, and one which you propose to
refer to as a token.
Under the circumstance -- that you need to distinguish between the two forms
-- I'm good with the term 'token'.
Joe Breher
Longmont CO USA
oh yeah - and lingua data, too
(478) 2-Breher
(478) 227-3437
Ralph Weber <roweber at>
Sent by: owner-t10 at
01/21/2011 02:09 PM
T10 Reflector <t10 at>
Re: More than an Identifier ...but... less than a Name
* 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