RE: iSCSI Naming and Discovery

["Douglas Otis" <dotis@sanlight.net>]

John,

> Douglas Otis,
> You said " ... You should consider the OS requirements for mounting.  The
> database which defines the target:LUN:WWN should also include a name for
> mounting...".
>
> I know of no such "Requirement".  So lets get back to the real
> problems and
> requirements.  I think the key point that we need to work on is the Naming
> and Discovery of iSCSI Devices (Storage Controllers) in the Greater IP
> network environment.

In a normal drive environment, mounting information is rather static as is
the interconnect to storage.  Providing such an extensible SAN, one should
consider mounting dynamic drives.  In real life use, it would be extremely
short sighted to ignore this *required* mounting information.  Rather than
have the client store this information, the bootstrapping database can
greatly assist the client by storing mounting information to assist in
creating a suitable environment for running various applications.
Eventually, tools should allow the user to redefine these values.

LUN may be used at a higher level than the device.  As SCSI allows for this
resolution, the naming scheme for mounting should also include this
resolution.  Regardless in how a LUN is seen by the device, until such
addressing is totally removed from SCSI, and I doubt it will be, providing
needed structures for mounting based on user requirements should be
considered within the bootstrapping database at the LUN level.  A symbolic
means of organizing these drives is appropriate at this level of
configuration even if the LUN may always have the value 0.

Rather than burden transports with these details, acceptance of an external
authentication scheme removes much of the burden this transport must bear.
In the end, you will be developing an LDAP server within the transport
protocol from the direction of this present scheme, otherwise.  DNS does not
provide the needed selectors found with LDAP.

Doug