Proposal into smaller documents

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

All,

As a means to prevent new name servers being required together will
real-time authentication, third-party commands should be restricted to SCSI
address space.  A SCSI address may be transparently bridged across IP space,
but such bridging information will not be included within the SCSI
transport.  This IP configuration is within the domain of the provider and
real-time configuration would be prohibitive.  If dynamic routes must be
used, these routes will be created in table form at time of authentication
with an authentication database.

Tunneling is beyond the scope of SCSI transport and, in the case of
third-party commands, is completely hidden from the transport.  By keeping a
SCSI address from including IP, the port identifier (S_ID or D_ID) may be
mapped through a transparent bridge which may include traversing IP.  These
locations in most cases would be addressed through fixed tables.

Should one service provider wish to allow third-party commands to yet
another storage service provider on behalf of a client, such as the transfer
of stock data, then arrangements would need to done prior to setting up the
tables. Perhaps these providers proxy the authentication to relieve the
client from seeing the entire content on their network.  With that said,
this could be the break-down with these restrictions on the scope of SCSI
transport.

Suggested proposals:
1) DHCP recommendations for client communications
2) LDAP recommendations for client communications
3) LDAP recommendations for server communications
4) SCSI Encapsulation specifications.  (One could be raw FCP, another iSCSI
as example)
5) Flow Control (Either as a prefix or separate control blocks)
6) Cookie exchanges compatible with both TCP and SCTP. (Assuming
Authentication is done via LDAP)
7) Management Services (unrelated to IP networking and separate from
encapsulation)
8) Permission lists (Target:Lun range)
9) SCSI address space and transparent bridging concepts.
10) Routing automation at portals and devices.

Excluded features:
1)  multiple connections (already standards for bundling connections.)
2)  tunneling provisions (already provisions for tunneling.)
3)  real-time authentication beyond connection (good way to keep a server
from scaling)
4)  real-time routing (would then include real-time authentication.)