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 - Unrecognized value?




    you are correct. Julo


    pat_thaler@agilent.com

    21-02-02 02:50

           
            To:        pat_thaler@agilent.com, kevin_lemay@agilent.com, luben@splentec.com, marjorie_krueger@hp.com
            cc:        ips@ece.cmu.edu, Julian Satran/Haifa/IBM@IBMIL
            Subject:        RE: iSCSI: key negotiation - Unrecognized value?

           


    Thinking about this response further, "protocol error" should be replaced by
    "negotiation failure." 2.2.4 says that selection of an inadmissible value
    must be considered a protocol error and handled accordingly, but 7.8
    Protocol Errors doesn't seem to say anything relevant to this type of error.
    Also during login one cannot send a reject PDU with a reason code of
    Protocol Error.

    7.8 Negotiation Failures does contain relevant actions and should replace
    protocol error in 2.2.4.

    Pat

    -----Original Message-----
    From: THALER,PAT (A-Roseville,ex1) [mailto:pat_thaler@agilent.com]
    Sent: Wednesday, February 20, 2002 3:34 PM
    To: LEMAY,KEVIN (A-Roseville,ex1); 'Luben Tuikov'; KRUEGER,MARJORIE
    (HP-Roseville,ex1)
    Cc: Ips Reflector (E-mail); Julian Satran
    Subject: RE: iSCSI: key negotiation - Unrecognized value?


    2.2.4 says: "The constants "None", "Reject", "Irrelevant", and
    "NotUnderstood" are reserved and must only be used as described here."

    NotUnderstood is for a key not understood by the responder. The draft
    doesn't say it is used for a value that is not understood.

    It currently describes Reject only in the context of list negotiation where
    it is used when none of the values in the offered list are acceptable. For
    the example Luben gives of a numerical negotiation (MaxConnections), Reject
    would never be a valid response. If the originator offers a higher valid
    value than the responder is willing to accept, the responder would respond
    with the lower number that it is willing to accept. So a valid negotiation
    for the case where the originator asks for a valid assignable value than the
    responder is willing to support would be something like:

    Originator-> MaxConnections=65535
    Responder->  MaxConnections=3

    In the example Luben gave, 4294967296 is not a valid value for
    MaxConnections because it is outside the range <number-from-1-to-65535>. The
    draft doesn't say what to do about out of range values and other invalid
    values.

    The draft does say that "selection of a value not admissible under the
    selection rules rules is considered a protocol error and is handled
    accordingly." The context for that statement appears to be the selection of
    a value offered by the responder, but that action would also make sense for
    responding to a value that is invalid for the key (wrong type of value or
    out of range). An implementation offering an invalid value is broken which
    makes proceeding with the negotiation a problem.

    Sending a "Reject" also would be a reasonable response to an invalid value
    but it  seems that offering an invalid value is just as severe an error as
    the ones that currently are responded to with protocol errors.

    Regards,
    Pat



    -----Original Message-----
    From: LEMAY,KEVIN (A-Roseville,ex1) [mailto:kevin_lemay@agilent.com]
    Sent: Wednesday, February 20, 2002 12:33 PM
    To: 'Luben Tuikov'; KRUEGER,MARJORIE (HP-Roseville,ex1)
    Cc: Ips Reflector (E-mail); Julian Satran
    Subject: RE: iSCSI: key negotiation - Unrecognized value?


    My impression was that "notUnderstood" was used if the key name itself could
    not be decoded.

    I believe that the correct behavior in the specific case should be:


    Originator-> MaxConnections=yes
    Responder->  MaxConnections=reject (with a login response of "Initiator
    error")

    The reason being, is that this key is clearly defined as a numeric field
    with specific ranges of values. To send a non-numeric value for this key
    would be an initiator error and should be treated as such.

    Although processing as "notunderstood" may allow the login to continue, it
    will also "cover up" the error allowing bad code to continue live on. Do we
    really want to make it easy for people to not even follow the spec?

    Kevin Lemay

    -----Original Message-----
    From: Luben Tuikov [mailto:luben@splentec.com]
    Sent: Wednesday, February 20, 2002 12:17 PM
    To: KRUEGER,MARJORIE (HP-Roseville,ex1)
    Cc: Ips Reflector (E-mail); Julian Satran
    Subject: Re: iSCSI: key negotiation - Unrecognized value?


    Marjorie, Julian, all,

    When a value doesn't belong to the valid set of
    assignable values to a key, but is offered,
    as Marjorie's example, shouldn't the following
    take place:

    Originator-> MaxConnections=yes
    Responder->  MaxConnections=NotUnderstood

    Also, isn't ``Reject'' used for a valid, assignable
    value, but for which the responder has no resources:

    Originator-> MaxConnections=4294967296
    Responder->  MaxConnections=Reject

    I.e. the responder cannot allow 2^32 connections,
    since the OS will not allow it in the first place...
    (If your OS allows it, replace the number with 1e3000
    above ;-)

    ?

    P.S. The ``NotUnderstood'' reply above would also
    be semantically correct.

    --
    Luben Tuikov, Senior Software Engineer, Splentec Ltd.
    Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974.




Home

Last updated: Fri Feb 22 10:18:08 2002
8845 messages in chronological order