RE: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]

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

Costa,

Should the IP-SCSI spec indicate a reference to an additional standard that
describes methods of extracting information from an LDAP server, you will
see the desired uniformity in implementations.  This key information will be
related to the intrinsic network identification used also by DHCP and would
provide the normal behavior of local drives.  Such references may also
include system user identification or some other pop-up identification to
allow a virtual local drive that follows the user or application.  All of
these reference keys lay beyond any transport standards.  How this
information ultimately is derived may be a local proxy by means of menus or
shared data between LDAP servers.  These servers also include their own
authentication.  Again, as these methods evolve, it would be beneficial to
exclude everything except this standards reference.  Try to isolate
transport encapsulation from transport/SCSI configuration.

Doug

> -----Original Message-----
> From: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> csapuntz@csapuntz-u1.cisco.com
> Sent: Friday, September 22, 2000 7:01 PM
> To: IP Storage
> Subject: Re: SCSI URL scheme [WAS: Re: iSCSI: 2.2.6. Naming & mapping]
>
>
>
> Just for clarification... I was not proposing to add the extended
> URL scheme for the transport spec. It isn't necessary.
>
> In this thread, Doug makes an excellent point about LDAP being a
> superior mechanism for describing how to connect to the
> storage. Directory services such as LDAP, as Doug has pointed out,
> will be critical to managing large quantities of storage. A host can
> ask such a directory service for a list of storage devices it should
> mount and how to connect to those storage devices. The query against
> the directory server that returns this information can be based on
> machine ID, user ID, operating system ID, or even the owner's
> birthday. One of the things discovery will end up doing, no doubt, is
> defining LDAP schemas that describe how to connect to storage
> (i.e. use SCTP or TCP, what port, what target name, what LUN, what
> WWN, how to authenticate, etc.).
>
> However, there is one place where the transport protocol has to define
> a name: third party commands. There needs to be some kind of global
> name which the initiator can pass to the target. The name must be
> distillable into a string. The target must understand the name and
> be able to use the information to establish a connection to
> another target.
>
> One could say that the string that is passed is not specified by the
> standard but instead specified by some management software. I think
> this will lead to poor interoperability.
>
> The SCSI URL-type name is the current proposal for target name.
>
> Why is SCSI target name made up of a hostname + a path? Why is the
> hostname + path passed on connection setup? There are two reasons.
> I think NAT and IPv6 makes passing hostnames rather than addresses in
> protocols more desirable. Hostnames can be re-resolved as you cross
> addressing boundaries. The path is there so that the name can
> support multiple targets behind a single IP address without having
> to add entries to the DNS server. At Cisco, for example,
> I have no control over the local DNS servers and cannot
> add DNS entries for the ATAPI DVD and floppy in my computer.
>
> _Costa
>