SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Login Request error



    Parthi wrote:
    > 
    > > >  Responder should say  "Reject" in Text param negotiation.
    > > >
    > > >        ex.       Originator->  ImmediateData=Ye
    > > >                     Responder ->  ImmediateData=Reject
    > > >
    > > >  The status value would be  020b  "Invalid during login".
    > >
    > > Would 020b be the correct error for that? I would have thought 0200
    > > "Miscellaneous iSCSI initiator errors" would have been better; I thought
    > > 020b was exclusively for an attempt to do something that should only be
    > > done in FFP, before you've gotten to FFP.
    > >
    > > Take care,
    > >
    > > Bill
    > 
    > Hi :
    > 
    >   Draft says "Initiator Error(not a format error) -- This indicates request for a resource for
    > which the initiator
    > does not have permission. The request should not be tried again".
    
    The status value should be 0 (Success). Note that
    since we are talking about status codes, we imply
    that the _Target_ replies.
    
    That is, the Target should reply with (as already noted)
    ImmediateData=Reject and status of 0. This would tell the
    Initiator that login is proceeding ok, but ImmediateData
    needs renegotiation/reconsideration.
    
    Note that the Target may reply with other keys' responses,
    along with the rejected ones.
    
    Then the initiator will reconsider all rejected keys.
    
    Note that a status code of anything but 0, implies
    closing the connection.
    
    Please see this message:
    http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09771.html
    
    My reply is a bit messy, in that I should've been clearer,
    that the originator of the key being rejected by the
    responder, SHOULD, if available, offer another set of values,
    or close the connection.
    
    Currently, the draft says (pg 69, 12-90):
    
    	If a responder does support, understand or is allowed
    to use none of the offered options with a specific originator,
    it MAY use the constant "Reject" or it MAY respond with an
    admissible value. The selection of a value not offered is
    considered a negotiation failure and is handled as a protocol
    error.
    
    Which is inconsistent with itself. (I.e. self-contradictory
    to negotiation.)
    
    Proof: By the first clause:
    Assume that the responder cannot use any of the
    offered options to a key (keyword ``none'' in the
    first sentence). Then the responder 
       1) MAY Reject,
       2) MAY offer an admissible value.
    Take 2) and proceed.
    
    Then the originator receives an (admissible) value
    which was NOT in what it offered and closes the
    connection by the second clause.
    Clearly, this is a negotiation failure.
    
    If, on the other hand, we had chosen 1),
    i.e. send Reject, the originator, may reconsider
    it's options and send a different set of values,
    and should one of them be acceptable to the
    responder, we arrive at negotiation success.
    QED.
    
    This has already been communicated to Julian. Julian?
    
    Nevertheless, a Reject response is required by
    the responder to ``close the loop''.
    
    If the originator doesn't close the connection
    after that, the responder MAY choose to send
    it's own values for the same (Rejected) key.
    I.e. the responder to the Reject will now become
    the originator of the Reject-ed variable.
    
    -- 
    Luben
    


Home

Last updated: Thu May 23 04:18:32 2002
10230 messages in chronological order