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

david.black at emc.com david.black at emc.com
Wed Jan 26 07:44:19 PST 2011


* From the T10 Reflector (t10 at t10.org), posted by:
* <david.black at emc.com>
*
In addition, I would observe that the proposed use of "token" does align with
Curtis's description of usage models:
> > 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.
There's definitely a permission aspect, as initiator presentation of a token
can imply permission to access data that would otherwise be inaccessible to
that initiator - the token may reference a point-in-time version of part of a
logical unit that is not visible to the initiator that presents the token. 
That permission is not absolute, as the storage can still say "no" by
deciding not to honor the token (e.g., "no" may take the form of Check
Condition, Invalid Request, Invalid Field in Parameter Data if the storage no
longer has state for that token).
Thanks,
--David
> -----Original Message-----
> From: owner-t10 at t10.org [mailto:owner-t10 at t10.org] On Behalf Of Ralph Weber
> Sent: Tuesday, January 25, 2011 5:08 PM
> To: T10 Reflector
> Subject: Re: More than an Identifier ...but... less than a Name
> 
> * From the T10 Reflector (t10 at t10.org), posted by:
> * Ralph Weber <roweber at ieee.org>
> *
> Curtis,
> 
> Since an OS vendor originally proposed this use of "token" and
> representatives of that T10 member organization have already
> privately questioned my sanity for proposing that some other
> word be considered, I judge that the initiator side of the
> aisle has been appropriately represented in this matter.
> 
> Personally, I am a little leery of "handle" because the word
> is both a noun and a verb
> 
> In the body of T10 standards, MMC-6 has muddied the waters
> for "handle" significantly with the following definition:
> 
> "Authentication Grant ID (AGID): The Authentication Grant ID
> is a handle used for resource control associated with DRM key
> management. Individual key management threads may be identified
> through the use of AGID."
> 
> MMC-6 is mildly supportive of "token", which is described as a
> kind of packet in: "Phase: This is a token, data, or handshake
> packet."
> 
> On the plus-side for "token", the proposed usage is consistent
> with the existing SPC-3 and SPC-4 usage of "token" in the
> ACCESS CONTROL OUT command.
> 
> All the best,
> 
> .Ralph
> 
> On 1/25/2011 1:01 PM, Ballard, Curtis C (StorageWorks) wrote:
> >
> > 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 t10.org [mailto:owner-t10 at t10.org] *On Behalf Of
> > *Joe.Breher at hitachigst.com
> > *Sent:* Tuesday, January 25, 2011 11:25 AM
> > *To:* Ralph Weber
> > *Cc:* owner-t10 at t10.org; 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
> > us/contr/hgst
> > HDD FW
> > Synapse-DA
> > Longmont CO USA
> > oh yeah - and lingua data, too
> > (478) 2-Breher
> > (478) 227-3437
> >
> >
> > *Ralph Weber <roweber at IEEE.org>*
> > Sent by: owner-t10 at t10.org
> >
> > 01/21/2011 02:09 PM
> >
> >
> >
> > To
> >
> >
> >
> > T10 Reflector <t10 at t10.org>
> >
> > cc
> >
> >
> >
> > Subject
> >
> >
> >
> > Re: More than an Identifier ...but... less than a Name
> >
> >
> >
> >
> >
> >
> >
> > * From the T10 Reflector (t10 at t10.org), posted by:
> > * Ralph Weber <roweber at ieee.org>
> > *
> > Joe,
> >
> > 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,
> >
> > .Ralph
> >
> >
> > 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 'identifier'.
> > > <<...snip...>
> > *
> > * For T10 Reflector information, send a message with
> > * 'info t10' (no quotes) in the message body to majordomo at t10.org
> >
> *
> * For T10 Reflector information, send a message with
> * 'info t10' (no quotes) in the message body to majordomo at t10.org
*
* 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