SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: iSCSI: Questions regarding text parameter 'Reject' and 'Irrelevant' usage



    Pat and Julian,
    
    Let me make a suggestion here.
    
    Negotiation sequences always *begin* as stateless, but a 
    negotiation is inherently stateful.  The negotiation for a given key
    within a negotiation sequence also starts out as stateless, but
    becomes stateful once the negotiation for the key is complete
    until the negotiation sequence is concluded.
    
    The draft needs to clearly make the above distinction.
    
    Consider the case of a multi-exchange text negotiation - there
    is the "state" of that negotiation at any point in time that represents
    the negotiated but uncommitted part of the negotiation sequence.
    That's what the term "partial results" was used to mean in section
    6.8 (negotiation failures).
    
    Regards.
    --
    Mallikarjun
    
    Mallikarjun Chadalapaka
    Networked Storage Architecture
    Network Storage Solutions Organization
    Hewlett-Packard MS 5668 
    Roseville CA 95747
    cbm@rose.hp.com
    
    ----- Original Message ----- 
    From: <pat_thaler@agilent.com>
    To: <Julian_Satran@il.ibm.com>; <nickb@attheoffice.org>
    Cc: <ips@ece.cmu.edu>; <owner-ips@ece.cmu.edu>
    Sent: Friday, April 19, 2002 3:19 PM
    Subject: RE: iSCSI: Questions regarding text parameter 'Reject' and 'Irrelevant' usage
    
    
    > Julian,
    > 
    > There seems to be some contradictory text with regard to whether an
    > inadmissible value can be responded to by offering an admissible value
    > rather than a reject.
    > 
    > 4.2 is compatible with this saying: All negotiations are stateless and
    > explicit (i.e., the result MUST be based only on newly exchanged values). 
    > 
    > but 4.3 says: Neither the initiator nor the target should attempt to
    > negotiate a parameter more than once during login If detected by the target
    > this
    > MUST result in a Login reject (initiator error). The initiator MUST
    > drop the connection.
    > 4.4 has similar text with adjustments for post login negotiation behavior.
    > 
    > If renegotiation of a parameter MUST cause negotiation failure, then
    > negotiation is not stateless.
    > 
    > If the following sequence of events happens:
    > Initiator offers value x
    > Target responds with value y 
    > Initiator finds value y to be inadmissible and offers the parameter again
    > (either with x or a new value z).
    > 
    > Doesn't that look to the target like the initiator is trying to negotiate
    > the parameter more than once and cause the Target to do a Login reject (or
    > negotiation reset)? How does a device differentiate between continued
    > negotiation of a parameter because it's answer wasn't accepted and new
    > negotiation?
    > 
    > Why not just allow the negotiation to be stateless as 4.2 says?
    > 
    > Pat
    > 
    > -----Original Message-----
    > From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
    > 
    > some comments in text - Julo 
    > 
    > Nick Bellinger <nickb@attheoffice.org> 
    > 
    > Greetings,
    > 
    >                 I have a few questions regarding the wording as per
    > iSCSI-v12 4.2  Text
    > Mode Negotiation:
    > 
    >                 "An offer of a value not admissible MAY be answered with the
    > constant
    > "Reject". The selection of a value not admissible under
    >                 the selection rules is considered a negotiation failure and
    > is 
    >                 handled accordingly."
    > 
    > 1. Is a responder allowed to return an admissable value (its default
    > value for the key) instead of using the 'Reject' constant? 
    > 
    > +++ the text clearly allows this +++ 
    > 
    
    


Home

Last updated: Wed Apr 24 02:18:22 2002
9760 messages in chronological order