SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iscsi: comments to iSCSI rev 6



    reply from Julian...
    
    -------- Original Message --------
    From: julian_satran@il.ibm.com
    Subject: Re: iscsi: comments to iSCSI rev 6
    To: Matt Wakeley <matt_wakeley@agilent.com>
    
    
    
    Comments in text.
    
    Thanks,
    Julo
    
    "Matt Wakeley" <matt_wakeley@agilent.com> on 01-05-2001 03:53:24
    
    Please respond to Matt Wakeley <matt_wakeley@agilent.com>
    
    To:   IPS Reflector <ips@ece.cmu.edu>
    cc:
    Subject:  iscsi: comments to iSCSI rev 6
    
    
    
    
    Section 2.2.3:
    
    The AHSLength field where it is requires RISC type processors to shift the
    length left by 8 bytes.
    
    +++ good point - I will make length the first field.  +++
    
    Section 2.3.5, 3rd paragraph: contradicts itself.  First it states that a
    AHS
    header "MUST" be present, then goes on to define what the bi-di read length
    is
    if the header is not present.  If it's not present, it's a protocol error.
    
    +++ will fix - it MUST be present +++
    
    Section 2.4.1, last sentance: "b0-b3 MUST be 0" s/b "b1-b4 MUST be 0".
    
    +++ will fix +++
    
    Section 2.7.7: why have residual bits/fields in a data PDU?  If there is
    residual, then send a status PDU indicating the residual value.
    
    +++ residual counts are not necessarily errors. Interpretation is by target
    and many commands for undefined length transfer end having a residual
    count. The space is available in the header so I see no point in not
    sending the counts.
    SAM2 is somewhat ambivalent about overflow though.  +++
    
    Section 2.8.3: Keys not understood by the target should be expicitely
    indicated as not being understood.  Silence is not a good way to indicate
    that
    one does not understand something.  Also, something more ascii friendly
    such
    as a semi-colon (;) should be used to separate key-value pairs instead of a
    null (0x00) character.  This would allow generic text manipulation
    libraries
    to be used.
    +++ generic text manipulation libraries use 0 as an end of string - our
    eyes don't :-)
    as for keys not understood the intent is to have new or vendor specific
    keys not interfering with the old or standrd only implementations
     +++
    
    Section 2.9.3: why "MUST" key-value pairs be returned in the same order
    they
    were issued?  Seems like a rather strong requirement for no apparent
    reason.
    
    +++ I've changed it into lower-case should +++
    
    Section 2.12.3: indicate that the LUN is copied from the NOP-IN.  This is
    much
    more clear than "the correct value for the task".
    
    +++ and open it up to strange thing like LU5 asking a nop-out to LU7 ? +++
    
    Section 2.14: Why is there no CmdSN for the logout command?  Also, 2 ways
    of
    performing the same operation (cleaning up) are stated in the 3rd
    paragraph.
    In the interest of reducing "options", I suggest that one be picked as the
    only method.
    +++ silly mistake - i've fixed it +++
    Section 2.17.4: "The target assigns" should be "The target may assign".
    +++ ??? it always put something there +++
    Section 6.3 & 6.7.2: why "MUST" a target reissue missing responses?  What
    if
    it is not able to?  There should be the option to reject the SNACK.
    +++ I am counting - you are number 2 +++
    Appendix: "Initial Marker-less Interval" - I say again, there should not be
    a
    "minimum markerless interval".  This should be whatever is negotiated.
    +++ The negotiation itself can't proceed if there are markers that nobody
    knows how to take out +++
    
    -Matt Wakeley
    Agilent Technologies
    
    
    


Home

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