SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    Re: [iSCSI]: Key negotiation procedure proposal




    Discovering capabilities is best left to discovery (SLP, iSNS etc.).
    Reject, Irrelevant etc., should be marginal and IMHO are here to handle gracefully exceptions.
    I would not complicate negotiation beyond a one time handshake - except perhaps for deep negotiation trees
    if they can be proven useful. And even then I would leave them for iSCSI-2  :-)

    Julo


    Luben Tuikov <luben@splentec.com>
    Sent by: luben@ns.splentec.com

    05/23/2002 04:35 PM
    Please respond to Luben Tuikov

           
            To:        iSCSI <ips@ece.cmu.edu>, Julian Satran/Haifa/IBM@IBMIL
            cc:        
            Subject:        [iSCSI]: Key negotiation procedure proposal

           


    I'm proposing the following key negotiation procedure. It
    preserves the no-renegotiation of keys rule and all the
    rules of login request and response currently used in the
    draft (12-91). It applies to any kind of value (list,
    boolean, integer, etc.).

    Simple implementations:

    Simple implementations SHOULD close the connection right
    after Reject has been communicated. This ensures that the
    reason for closing has been communicated to the peer.

    Regular implementations:

    Core rule: A negotiation of a key=value pair is
    complete/finished when both the Originator and Responder
    have sent their values (non-reserved keywords).

    The core rule implies the the following:

    If a Responder replies with Reject, then the Originator
    SHOULD NOT renegotiate the rejected key.

    If a Responder replies with Reject, it SHOULD sent its value
    of that key on the next reply to the Originator.

    If an Originator finds the response to an offered key=value
    pair to be unacceptable, it SHOULD send Reject and close the
    connection.

    Please note that the core rule above ensures that both the
    Originator and Responder _know_ each other's values if the
    connection is closed due to Reject. This will give the user
    of each node more information to find out what went wrong.
    That is, this kind of negotiation is exhaustive.

    Let O: denote Originator and R: the Responder.

    Example 1:
    ----------
    O: v = x  -->
            <--   R: v = Reject

    O: ""     -->
            <--   R: v = y

    O: 1) v = y is OK, continue as normal,
      2) v = y is unacceptable,
     
      v = Reject -->
      close the connection (reason just given).


    Example 2:
    ----------
    O: v = x  -->
            <--   R: v = y

    O: 1) v = y is OK, continue, as normal,

      2) v = y is unacceptable,
     
      v = Reject -->

      close the connection (reason just given).

    --
    Luben




Home

Last updated: Tue May 28 16:18:42 2002
10353 messages in chronological order