SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    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
    
    


Home

Last updated: Tue Sep 04 01:04:13 2001
6315 messages in chronological order