RE: iSCSI: Support Alias in the protocol

["Martin, Nick" <Nick.Martin@compaq.com>]

Bob,

I agree that the iSCSI Name is analogous to the VIN number on a car.
The VIN number and the iSCSI Name are supposed to be constant for the life
of the device.
In my mind the iSCSI Alias is like the license plate tag.  If someone is
looking for your car, in the mall parking lot you don't tell them the
manufacturer assigned VIN number, you tell them the tag.  (You may also
mention the make, model, and color.)  The VIN number is used for
confirmation when required.  These are administrator assigned regionally and
duplicate numbers are not much of a problem.

Initiator Target relationships are defined by the InitiatorName and
TargetName.  The protocol does not need aliases, but I believe the
administrators do.  We need to allow administrators to assign their own tags
to devices, and I believe these should be carried within the protocol so
that no external databases are required.  When reporting a problem to an
administrator, the device alias should be reported along with the device
name.  The chances for error and confusion will be greatly reduced.  The
alias or "tag" value will be easier for humans to deal with on a daily basis
than a name field or VIN number would be.

I support Alias within the iSCSI protocol.

Thanks,
Nick
-----Original Message-----
From: Robert Snively [mailto:rsnively@Brocade.COM]
Sent: Monday, August 20, 2001 4:25 PM
To: 'Mark S. Edwards'; ips@ece.cmu.edu
Subject: RE: iSCSI: Support Alias in the protocol


Folks,

I remain concerned about this called consensus.  Clearly there
will be thousands of Targets and Initiators running around
a network.  Creating a set of human useable aliases
that will distinguish all these seems to me somewhat farfetched.
We don't even do very well on kings.  George, George II, etc.

To create aliases in the context of a single management environment
makes some sense, but again, that should be outside the 
scope of iSCSI.

That we call our car Skeezix (human useable, for management
purposes within the tightly constrained context of our own
family) is non-architected information.  Whenever anyone cares 
which car it is (including during servicing and upgrades) they 
use the VIN, a registered and architected non-human-readable value.

If Marjorie and I are the only voices in the woods, we have
clearly had the consensus called against us, but this is high
on my list of things that really aren't much help to anyone
and shouldn't be in the document.

Bob

> >Let me also acknowledge as valid Marj's opinion that anything of
> >this sort belongs in a management tool rather than the protocol.
> 
> But it only works if everyone uses the same management tool, 
> or the tools agree upon the location and storage format of the 
> information 
> --  Somebody dig me up from my grave when Tivoli and 
> OpenView merge.
> 
> As a way of easily identifying virtual LUN's or LU's within a 
> Target Space of potential hundreds or thousands the alias 
> is very valuable.