RE: iSCSI: SessionTypes

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

I agree completely with Jim's comments, and would add that any "vendor
specific" behavior should stay in the vendor specific arena, and not be
specified in any manner in the protocol spec.  It seems to me that a
copymanager implementation could have different authentication methods on a
target (based on initiator name) without any special treatment in the iSCSI
protocol.

In addition,  I am seriously dismayed to see more "new features" creeping
into the protocol via draft 07 that haven't been discussed on the IPS list,
and seem in no way to represent any group concensis.  At this rate the draft
will *never* reach RFC status.

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: marjorie_krueger@hp.com 

> -----Original Message-----
> From: Jim Hafner [mailto:hafner@almaden.ibm.com]
> Sent: Tuesday, July 24, 2001 10:07 AM
> To: ips@ece.cmu.edu
> 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
>