iscsi: technical comments to iSCSI 05:

[Matt Wakeley <matt_wakeley@agilent.com>]

technical comments to iSCSI 05:


Global: (especially in section 6) timeouts are not defined.  We went
    through a lot of work defining time-out values for FCP-2.  I think
    that time-out values need to be specified for interoperability.


1.2, page 10:
    "The iSCSI protocol is a mapping of the SCSI remote procedure
     invocation model on top of the TCP protocol."
    is iSCSI limited to TCP? Seems like it could be implemented over
    other transports, such as SCTP with no modification...

    
1.2.3, page 14:
    After the sentance "Otherwise, it sends a response with
    a "login reject" ..."
    add that the connection is terminated.


1.2.5, page 16 (middle) and 6.7.1, page 84:
    The initiator should not be required ("MUST") to honor R2Ts.
    Conditions may have occurred that might prevent the initiator
    from processing the R2T, in which case appropriate error recovery
    should be performed.  I suggest "SHOULD if at all possible...".


1.2.5, page 16 (bottom):
    "Unsolicited data MUST be sent on every connection in the same order
    in which commands were sent." - must the data be sent immediately after
    the command, or can other commands be sent before the data?


1.2.7, page 19, middle of page
    must "iSCSI://..." be caps?  is "iscsi://..." allowed?


2.2.3, page 28:
    Are "what's next" fields included in the header digest?  It's not
    stated that they are.
 

2.7.2, page 45:
    Why must a LUN be associated with a Target Transfer Tag?


2.7.4, page 45:
    It is not clear if the DataSN restarts from zero for each R2T.


2.7.6, page 46:
    It is not stated, but seems implied that a bi-di commands must
    send status in a separate response PDU.  If this is so, please
    state it.


2.10.9, page 52:
    What is the default maximum length for login parameters?


2.15, page 63:
    What is the initiator supposed to do when it receives a code of
    "cleanup failed"?  It seems like it's the target's problem and
    should not be reported to the initiator.


2.17, page 66:
    *if* as you state in 2.7.2 a LUN must be sent when a target transfer
    tag is specified, shouldn't the LUN be also specified in the R2T?


2.20, page 71:
    remove "reserved fields not 0".  This makes it sound like
    reserved fields must be checked, which they should not must
    be checked.


2.20, page 71:
    add "data digest error" to the list of reject reasons.


3.1.2 and 3.1.3, page 72:
    I don't care what SCSI has defined for it's mode pages, for iSCSI,
    these fields should be byte values, not multiples of 512.


4.3, page 78:
    It may not be clear to everyone that a target can send a text or
    login response to a login or text command.  That is, a target could
    respond to a text command with a login response.  This should be
    made more clear.


6.2, page 81, last paragraph:
    Can a "restart" also be issued in this case?


Appendix A: 01, page 94:
    I don't think that crc-64 "MUST" be implemented.
    I also don't agree with the phrase "Cyclic codes are particularly
    well suited for hardware implementations."  This is not true if
    iSCSI PDUs span TCP segments and arrive out of order.


Appendix A: 01, page 94:
    "Implementations MAY also negotiate digests with security
     significance for data authentication and integrity as detailed
     in the following table:" needs a lot more description.


Appendix C: page 104:
    change: "will leave at least" to "should leave at least".


Appendix C: 06, page 105:
    change: "When reduced to iSCSI terms markers MUST point to..."
    to: "When reduced to iSCSI terms markers MUST indicate the offset to..."


Appendix C: 07, page 105:
    "The marker-less interval is not less than 4 kbytes and the
     default is 4 kbytes." It should be whatever the the receiver
     needs it to be (not min 4K).


Appendix C: 17,18 page 109:
     The sender should send markers at whatever interval the reciever
     requires them.  Not the "larger" of the sender and receiver.
     Otherwise, the sender could say 0xffffffff and it would be of no
     use to the receiver.  Also, the default should be "none", not 2050.


Appendix C: 22 page 111:
     Indicate what "no,no" and "yes,no" means.


Appendix C: 23 page 111:
     This parameter should be in bytes, not multiples of 512,
     especially since framing mechanisms may require that a PDU not be
     larger than MSS. (perhaps -1 can be used to indicate MSS)


Appendix C: 26 page 112:
     This should be deleted, since CmdSN is now mandatory.


Appendix C: 27 page 112:
     PingMaxReplyLength is both a target and initiator negotiated value.
     Therefore, text saying "the target MUST..." should be change to
     indicate both target and initiator.