SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Use of Reject as a key value



    Do you propose the formulate the standard so that it can tolerate all
    initiator syntax errors? Or just we state that it should be case
    insensitive.
    The first would be a bad idea. The protocol has enough complexity in order
    to deal with transport errors. It would be a bad idea to add
    implementation errors to the list.
    If you want case insensitivity - this was discussed and rejected a long
    time ago - again because it felt unnecessary.
    
    I would also like to point out that this is not a change. This behavior was
    always assumed (and implied in the statements about negotiations
    atomicity).
    The statement was added at the request of Bob Russell as a clarification.
    
    Julo
    
    
    
    
                                                                                                                                                
                          kevin_lemay@agile                                                                                                     
                          nt.com                   To:       Julian Satran/Haifa/IBM@IBMIL, rdr@io.iol.unh.edu                                  
                                                   cc:       ips@ece.cmu.edu, pat_thaler@agilent.com                                            
                          07/25/2002 09:59         Subject:  RE: iSCSI: Use of Reject as a key value                                            
                          PM                                                                                                                    
                                                                                                                                                
                                                                                                                                                
    
    
    
    Julian,
    
    I think that this change is a bad idea.
    
    The spec says that:
    
    "If the acceptor sends "Reject" as an answer the negotiated key is left at
    its current value (or default if no value was set). If the current value is
    not acceptable to the proposer on the connection or session it is sent the
    proposer MAY choose to terminate the connec- tion or session."
    
    But what happens in the following case:
    
    i->ImmediateData=Yes
    t->ImmediateData=no (Note: wrong case used)
    
    The initiator must use the default, which is ImmediateData=Yes, and there
    is no way for the initiator to inform the target of the error because
    sending:
    i->ImmediateData=Reject would be a re-negotiation.
    
    This will not work!
    
    Kevin
    
    -----Original Message-----
    From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    Sent: Wednesday, July 24, 2002 7:52 PM
    To: Robert D. Russell
    Cc: ips@ece.cmu.edu; owner-ips@ece.cmu.edu
    Subject: Re: iSCSI: Use of Reject as a key value
    
    
    
    Bob,
    
    On the last pdf you will find a statement about what to do.
    
    Julo
    
    
    
                 "Robert D. Russell" <rdr@io.iol.unh.edu>
    Sent by: owner-ips@ece.cmu.edu
    
    
    07/25/2002 12:58 AM
    
    
    
            To:        ips@ece.cmu.edu
            cc:
            Subject:        iSCSI: Use of Reject as a key value
    
    
    
    
    
    
    
    Julian:
    
    Attached are 2 ascii text files.
    
    The first, reject_extracts.txt, contains all the pieces of
    draft 14 (the latest available txt version of the drafts)
    that say anything about the use of Reject as a key value.
    (At least all those I could find using simple search --
    unfortunately, Reject is also the name of a PDU and hence
    it is not a simple mechanical process to distinguish the two
    uses!  If I missed some, please let me know.)
    
    The second, reject_comments.txt, are my comments on these
    excerpts from the standard.
    
    It seems to me that the key thing missing in the standard is
    a general statement about "what to do next" if a key=Reject response
    is received.  Except for the OFMarkInt and IFMarkInt keys,
    I could find no other statement about how to proceed after
    receiving the key=Reject response.  In looking through the
    e-mails posted to the list for June and July, I also could find
    nothing, although many people seem to be taking the third
    of the 3 interpretations I listed in reject_comments.txt.
    
    I am requesting a clear statement somewhere in the standard that
    says "what to do next" upon receiving a key=Reject response.
    
    Thank you for your consideration.
    
    Bob Russell
    InterOperability Lab
    University of New Hampshire
    rdr@iol.unh.edu
    603-862-3774
    
    
    
    
    
    
    
    #### reject_extracts.txt has been removed from this note on July 25 2002 by
    Julian Satran
    #### reject_comments.txt has been removed from this note on July 25 2002 by
    Julian Satran
    
    
    
    
    
    
    


Home

Last updated: Tue Jul 30 10:39:09 2002
11481 messages in chronological order