RE: Proposal into smaller documents

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

Charles,

It is not that profound.  The address space would be exchanged upon
initialization and authorization.  I would assume, this would be done with a
selector so that should the client have access to great volumes, only those
of interest would be exposed at that point.  The SCSI address space would be
as seen via the transport.  There would not be two views with respect to the
client.  Each client may hold a different view and may hold a different
number for the same target, but that would be a function of the database and
portal and if there was a translation required to access the target.  And as
systems use names to attach LUNs, the database should contain a User:Name
list.  This would not be a function of the transport but rather where the
LUN gets mounted within the OS.  This name may also include a relative base
which may be associated with the selector.

Connection Diagram
                              (Target /bin:Foo)
                              (Target /:Foo)
                              (Target /<swap>:Foo)
                              (Target /usr:Foo)
                              (Target /home:Foo)
                                     |  \ (Third-Party Address)
        (SCSI Address Space)         |   \
(Accessible from Client Gateway) SCSI Portal 1
                                     |    \
                                     |     \
                                   (NAT)    \
                                     |       \  (IP Address Space)
                                 (GATEWAY)    \
                                     |         \
                                Client Foo      \
                                                 \
                                           SCSI Portal 2
        (SCSI Address Space)                     |
                                            (Target /opt:Foo)

<snip>

> This raises a profound issue since there's no such thing as "SCSI Address
> space". i.e.: An address space that's independent of the transport layer.
>
> If such an address space were to be defined, there'd be a number of
> corollary issues, such as:
>
> a)  How to translate from SCSI address space to transport address space.

In the case of simple encapsulation, the translation from transport and real
is rather straight forward.  Again as this translation should be required to
remain static during the permissions lease, there should never be any
conflict.

> b)  How to enforce the implicit assumption that the copy manager
> always has
> the same view of the network as the initiator.  i.e.. Ensuring
> that the copy
> manager resolves the address of the SCSI device passed in the copy command
> to the device intended by the initiator.

These translations would be handled with tools that run off of the same
database that maps these real locations and possible translated locations
for transparent bridges.  Having a definition of how things are mapped in an
accessible form allows these tools to handle such things as third-party
commands.  Allowing a third-party command target to be defined on the fly
will never scale as this would require in-line authorization and rebuilding
of permission lists which is also why these locations can not and should not
be configured by the client.

Doug

> Charles
>