Re: iSCSI: SessionTypes

["Prasenjit Sarkar" <psarkar@almaden.ibm.com>]

Julian,

There are existing mechnaisms to deal with the DVD/CD/robot example you
came up with, so adding another mechanism (to a complex spec) is probably
not desirable.

The second and more important issue is how you came up with the desired
behavior on "SessionType=BootSession". From a survey of exisitng booting
protocols (SCSI and non-SCSI), I could not find anything remotely like it
because
such issues are dealt with in a different layer.

Finally, the oft-repeated reason that "if we dont introduce them now, we
will
never have them" is very specious and is contrary to the history of
protocol development.

   Prasenjit Sarkar
   Research Staff Member
   IBM Almaden Research
   San Jose



                                                                                                                                              
                    Julian                                                                                                                    
                    Satran/Haifa/I       To:     ips@ece.cmu.edu                                                                              
                    BM@IBMIL             cc:                                                                                                  
                    Sent by:             Subject:     Re: iSCSI: SessionTypes                                                                 
                    owner-ips@ece.                                                                                                            
                    cmu.edu                                                                                                                   
                                                                                                                                              
                                                                                                                                              
                    07/24/2001                                                                                                                
                    11:01 AM                                                                                                                  
                                                                                                                                              
                                                                                                                                              




Jim,

Layering between SCSI and iSCSI is a question of implementation and not
protocol.
A boot device may do filtering and authentication - but my assumption was
that i will do some
more and here are but a few examples:

   on boot it can load a specific CD/DVD if it is a changer and do not give
   you access to any other device - or not accept you at all for an
   all-purpose session
   on copy manager it may allow you access to part of a robot library but
   not another and get the credentials from the "original initiator"

Even if loosely specified now they have a "framework value" and will help
implementers craft APIs to surface
hose type to operational (SCSI) or management layers.

If we don't introduce them now there will be no such "hooks" and we stand
no chance to introduce them later as a refinement

Marjorie,

There where no new features introduced in 07 - and if it seems so to  will
have to be more specific.
The session type (in another form) was there for a long time.


Regards,
Julo

"Jim Hafner" <hafner@almaden.ibm.com> on 24-07-2001 20:07:01

Please respond to "Jim Hafner" <hafner@almaden.ibm.com>

To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: SessionTypes




Folks,

As was noted in another thread, the recent drafts (07 included) introduced
a new mechanism for avoiding the issue of login to the "default target" for
SendTargets only function.   It did this with the "SessionType" key.  I
like this idea a lot.

However, the draft proposes two additional session types besides
"Discovery" (for SendTargets only) and "Normal" (for SCSI to a real live
target).  The two additional ones are "Boot" and "CopyManager" and in both
of these additional cases, it is suggested that the target might limit what
SCSI commands are allowed.

I have very strong feelings that these are (a) both unnecessary, (b)
strongly violate layering AND (c) are incompletely specified, in any case.

It's unnecessary because in both cases, the intent seems to be to limit
what SCSI commands might be allowed within the given session, but if an
initiator voluntarily requests such limiting behavior, then it can
voluntarily limit what SCSI commands it sends.  For the initiator to ask
for a filter from the target when it can filter itself is silly.

With respect to layering, this would be the first protocol that *might*
restricts the set of SCSI commands allowed. In affect, it allows the iSCSI
layer to filter the SCSI layer by changing the set of commands supported by
a particular device type.  That could get very confusing for the SCSI layer
in the initiator (it sends a command and the iSCSI target layer rejects it,
even though the device should support the command).  It is also well beyond
what a protocol spec should do.

The proposal does not say what error conditions are reported if a command
is rejected.  By saying it's "vendor-dependent", it leaves the door open
for massive interoperability problems (one target doesn't filter, another
filters most everything).

I can possibly foresee iSCSI specific reasons for such things (e.g., to
request different authentication methods or security context, in analogy
with Discovery session type), but until those are defined in detail, I see
no reason to keep these things in.  At best they might be reintroduced in
the second generation of the standard.

Consequently, I would *strongly* suggest that these two be removed from the
draft.

Comments?
Jim Hafner