SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI 05.txt is out



    
    
    After reading Matt's answer I realized that this probly did not get out to
    the list.
    So here it is again.
    
    Julo
    ---------------------- Forwarded by Julian Satran/Haifa/IBM on 11/03/2001
    12:21 ---------------------------
    
    Julian Satran
    06/03/2001 06:02
    
    To:   "Venkat Rangan" <venkat@rhapsodynetworks.com>
    cc:
    From: Julian Satran/Haifa/IBM@IBMIL
    Subject:  RE: iSCSI 05.txt is out  (Document link: Julian Satran - Mail)
    
    Answers in text - +++
    
    Thanks for the careful reading,
    Julo
    
    "Venkat Rangan" <venkat@rhapsodynetworks.com> on 06/03/2001 00:40:18
    
    Please respond to "Venkat Rangan" <venkat@rhapsodynetworks.com>
    
    To:   Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu
    cc:
    Subject:  RE: iSCSI  05.txt is out
    
    
    
    
    Julian,
    
    Here are a few technical and editorial comments on the latest draft.
    
    Technical:
    
    Page 12:
    
    - CmdSN - the current Command Sequence Number advanced by 1 on each command
    shipped
    
    Add: skipping zero, which is reserved for immediate delivery.
    +++ will fix +++
    Page 12:
    Remove the sentence:
    "A large difference between StatSN and ExpStatSN may indicate a failed
    connection."
    
    This may have made sense when StatSN and ExpStatSN are session-wide. Now
    that it is per-connection, this may not be valid. As was pointed out in the
    "Holes in StatSN" thread, ExpStatSN may be "stuck" at a low value when a
    single PDU encountered a Digest Error, followed by several well-formed
    PDUs.
    +++ if it cant't be recovered with a SACK it is stll a sign of error+++
    Page 24 - Section 2.1
    Add: The length of the PDU SHALL include any padding bytes added.
    +++ No the length does not include padding - padding is implicit +++
    This raises a question as to whether it may be useful to include a two-bit
    "Fill Bytes" field in the header (BHS and AHS) which indicates the number
    of
    bytes that were added. Without this, it may be harder for the receiver to
    know how many bytes are part of the data. Fibre Channel has the Fill Byte
    specifier in its F_CTL part of the header.
    +++ No need - length does not include padding +++
    Page 25:
    This may be covered in another thread.
    
    What does the first Next-Qualifier (at byte 0) describe? Is it the BHS or
    the header following the BHS? If a PDU has a single BHS and a single AHS,
    is
    the sequence WN-BHS-AHS or is it WN-BHS-WN-AHS?
    +++ in your example the second answer is correct and the second WN descibes
    the data payload +++
    Page 25 and 26:
    The text next to the bit description and the headers in the text for
    sections 2.2.2.1 to 2.2.2.3 appear to be inconsistent.  An example is
    "read-data transfer" vs. "Read Data" "Long Data" vs. "Long Data Transfer"
    
    Also, 2.2.2.3 appears to have text about Long Data Header that probably
    belongs in section 2.2.2.2 (or I am confused about how WN is supposed to
    work.)
    +++ will make consistent +++
    Page 43
    Section 2.7
    The PDU diagrams should not show "Digests if any..." etc. It should be
    covered by NQ and corresponding AHS.
    +++ correct by tastes vary - and many people prefer a complete picture - I
    have a hard time now trying to find a way to reconcile all +++
    
    Page 44
    Section 2.7.2
    The requirement of having to specify a valid LUN as part of WRITE Data (and
    NOP-Out) may pose unnecessary overhead for Target processing. The fact that
    Targets are now REQUIRED to reject errant initiators who may place a LUN
    inconsistent with the one sent in the CommandPdu means that targets should
    save the LUN against each context entry for the task. This was discussed
    earlier, and I think we said that unless the folks who originally wanted it
    spoke up, we will remove it. Note that Fibre Channel does not have this
    feature, and its original purpose can be accomplished by using Target
    Transfer Tag.
    
    If we still want it, targets should be given the option of negotiating this
    so that it can operate in a mode where a LUN specified as part of WRITE
    data
    will be ignored (as opposed to rejected).
    +++ Several people on this list reuested the freedom to build the tags at
    the device-server (part of the LU according to SAM) without regard to what
    other LUs the target has
    The simplest way to accomodate them is to have the initiator direct the dat
    through a LUN
    We can make checking that optional although I don't understand what is all
    the fuss about it+++
    Section 2.17
    The following text:
    "Within a connection, outstanding R2Ts MUST be fulfilled by the initiator
    in
    the order in which they were received."
    
    implies that R2Ts for the same WRITE command may be sent by the target on
    multiple connections? Since this is not possible, all R2Ts for a command
    are
    always on a single connection, so I am not sure how the above sentence
    should be interpreted.
    
    +++ even when received in order the initiator may decide to fulfill them
    out of order - this statement prevents it+++
    
    Page 75:
    Add: "i.e., from Most Preferred to Least Preferred" to "reverse order of
    preference."
    +++ why? is there something ambiguous in the statement? ++
    ------------
    Editorial - typos and such
    
    1. Page 11:
    
    Not covered are he means
    
    Change "he" to "the"
    
    +++ will fix ++
    2. Page 20:
    
    Change "later" to "latter" in "the later can be used in subsequent
    commands."
    +++ will fix ++
    3. Page 23:
    
    Change "isa"  to "is a"
    +++ will fix ++
    Page 42:
    Section 2.6.1
    Change to: Initiator Task Tag of the task that was not found; used in
    conjuction with Response value 1. It MUST be set to zero in other cases.
    
    +++ will fix +++
    Page 51:
    Change "CID does not change and this command is performs first" to
    
    "CID does not change and this command first performs"
    +++ will fix +++
    Page 55:
    There is nothing that indicates the status codes in the table are sent as
    part of Status-Detail.
    +++ it says above the table +++
    Page 66:
    Change "iSSCSI Data-out PDU" to "iSCSI Data (WRITE) PDU"
    
    The Data-out PDU is a new concept not introduced anywhere.
    +++ will fix +++
    Page 75:
    The term "Security Context Complete" is referred to prior to its
    definition.
    
    Page 81:
    Change "later" to "latter"
    ++ will fix +++
    ------------
    
    Venkat Rangan
    Rhapsody Networks Inc.
    http://www.rhapsodynetworks.com
    
    
    
    
    
    
    


Home

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