SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: Boolean value (yes, no) negotiation


    • To: "Lakshmi Ramasubramanian" <nramas@windows.microsoft.com>, <ips@ece.cmu.edu>
    • Subject: RE: iSCSI: Boolean value (yes, no) negotiation
    • From: "Martin, Nick" <Nick.Martin@compaq.com>
    • Date: Wed, 6 Feb 2002 13:17:36 -0600
    • content-class: urn:content-classes:message
    • Content-Transfer-Encoding: 8bit
    • Content-Type: text/plain;charset="US-ASCII"
    • Sender: owner-ips@ece.cmu.edu
    • Thread-Index: AcGvL3uiAtkRBxjhSWuOqFMN2B29HQAAwdHAAADBenA=
    • Thread-Topic: iSCSI: Boolean value (yes, no) negotiation

    Lakshmi,
    
    It is my understanding, that if either initiator or target begins
    negotiation for a boolean by sending a key=value pair, the responder
    applies the specified boolean function (to the requested value and the
    current value) to obtain the result.  The result is then included in a
    reply (unless the rules say it may be omitted).  This negotiation is
    concluded.
    
    I believe it should not be permitted for the responder, desiring a
    different outcome, to later initiate negotiation for a different value
    of the same parameter.  If both initiator and target were permitted to
    do this, it can cause an endless loop.  However I do not find where this
    is documented.
    
    I have found an option for the target other than rejecting the login.
    It can reject this parameter value with key=Reject.  The initiator in
    this case can then accept the value previously in effect, negotiate for
    another value, or close the connection.  I believe sending key=Reject
    does not require that the entire login should fail.  The current value
    for key should be unchanged by a negotiation ending in key=Reject, just
    as if it never happened.
    
    It is not always clear to me whether such negotiations are intended only
    to allow selection of preferred modes of operation, or to enable
    implementations which do not support certain features to operate with
    other implementations which do not require those features.
    
    For example, it is not stated whether a target or an initiator SHOULD or
    MUST implement/accept both ImmediateData=yes and ImmediateData=no.
    
    If these are for preferences, and the initiator and target are
    configured for different preferences, what should be the result?  Either
    result may allow operation.  In fact neither may be optimal for both
    parties at the same time.  Is the result predictable?  Should we
    negotiate differently for preferences versus requirements?  For example
    should an initiator only negotiate preferences after the target has had
    a chance to negotiate requirements?  Should we expect that key=Reject
    could be the response to almost any key negotiation?
    
    The suggestion by Rahul to use key=? is not permitted.  key=? is only
    permitted in text commands, during full feature phase.  It returns the
    current value, not the list of support values.  Requesting the list of
    supported values is not a current capability.
    
    Thanks,
    Nick
    
    > -----Original Message-----
    > From: Lakshmi Ramasubramanian [mailto:nramas@windows.microsoft.com]
    > Sent: Wednesday, February 06, 2002 11:26 AM
    > To: ips@ece.cmu.edu
    > Subject: iSCSI: Boolean value (yes, no) negotiation
    > 
    > 
    > Could someone please clarify Boolean key=value usage
    > (such as "ImmediateData=yes", etc)?
    > 
    > For example, the initiator sends to target "ImmediateData=no". 
    > But the target wants ImmediateData. So, it sends back
    > "ImmediateData=yes".
    > The initiator, being able to handle it, sends back "ImmediateData=no".
    > Now, they use immediate data in the PDUs. 
    > 
    > Is this valid? Or, in the above case if the target can't handle 
    > non-immediate data it has to reject the login ?
    > 
    > thanks!
    >  -lakshmi
    > 
    


Home

Last updated: Wed Feb 06 15:17:59 2002
8687 messages in chronological order