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




    Reject is a legitimate negotiation option (is is not a reject pdu).  The rest is left to the implementor and any of your options is valid.
    Nothing will prevent the login/negotiation to conclude successfully althugh I assume that a responder that sees too many rejects will take some drastic action to stop being bothered.


    Julo


    Martins Krikis <mkrikis@yahoo.com>
    Sent by: owner-ips@ece.cmu.edu

    04/24/2002 04:29 AM
    Please respond to Martins Krikis

           
            To:        ips@ece.cmu.edu
            cc:        
            Subject:        Re: iSCSI: Questions regarding text parameter 'Reject' and 'Irrelevant'  usage

           



    --- Julian Satran <Julian_Satran@il.ibm.com> wrote:
    > Luben,
    >
    > I hope I cleared this.
    > The may reject is only for the responder - the
    > originator expects a good
    > selection (according to the rules) or reject and
    > will end the negotiation
    > otherwise.

    So let's suppose originator sent a key with a
    list of values and received a Reject in response.

    May the originator now send the same key again?

    May the responder now offer the same key again?

    Should the originator now send the same key again?

    Should the responder now offer the same key again?

    If they may/should and end up with another Reject
    for the same key, may/should they do it again?

    Assuming the key still hasn't been answered
    with a non-reserved value, should it prevent
    either  party from setting the T/F bits and thus
    signaling readiness to end the negotiation sequence?

    None of this is clear to me.

    > That is the exact meaning of the text.  I did look
    > it again over and I may
    > add words but it seems that the text is clear as it
    > is.

    Here are a couple of things that I personally would
    change:

     "All negotiations are stateless and explicit"

    We all know they are far from stateless.

    Explicit? Well, I would not allow boolean
    responses to be omitted under certain conditions.
    It just complicates the logic necessary to figure
    out whether I can signal readiness to complete the
    sequence or whether I'm missing some boolean response.

     "If a responder does not support, does not
     understand or is not allowed to use all of the
     offered options with a specific originator..."

    This could be interpreted to say that one value
    which cannot be used is enough to fail the whole
    list. However, simply replacing "all" with "any"
    won't make things clearer either. It would be
    best to rewrite this part and to not mention the
    previously undefined "options" either...

     "it MAY use the constant "Reject""

    The MAY part is not helpful, as many have pointed
    out. The less choices there are, the clearer things
    will become and the less room for unexpected
    surprises.

     "The selection of a value not admissible under
     selection rules is considered a negotiation
     failure and is handled accordingly"

    In list negotiations the selection rule seems to
    be "pick the first value that you support". If so,
    then should responding with Reject, Irrelevant
    or NotUnderstood be considered as "value admissible"
    or "value not admissible"? I.e., by interpreting
    the reserved words as not admissible, we could
    already treat them as failure, yet we shouldn't...

    "Handled accordingly" could provide a reference
    to a better explanation of how the handling should
    be done.

     "The rules for selecting the value with which to
     respond are expressed as Boolean functions of the
     value received and the value that the responding
     party would select in the absence of knowledge of

      the received value"

    Let's take InitialR2T: function OR, default Yes.
    Suppose the responder desires to turn this to No.
    Suppose the offering party sends a No. Now, in the
    absence of the knowledge of this offer of No, the
    responder would be forced to stick with the default
    Yes, right? So according to the quotation above,
    the value to respond with is OR(No, Yes) = Yes.
    This way we can't ever turn it to No, even if both
    sides want it.

     "An offer of a value not admissible MAY..."

    This is after boolean negotiations. Was it meant for
    boolean or for anything? And what is "not admissible"?
    Illegal value according to iSCSI standard or simply
    unwelcome value by the receiver?

     "However the negotiation is not considered as failed
     if the response is Irrelevant"

    Does it mean that it is considered as failed if the
    response is Reject?

    All the questions I asked above about Reject apply
    again here... i.e., may/should each of the parties
    offer this key again and should the current state
    of this key allow signalling readiness to complete
    the sequence?

    Why not disallow Irrelevant to simplify things?
    Make the response be mandatory. Let each side deside
    for themselves whether it is of any use, but
    negotiation should be completed for it.
    We aren't considering any operational parameters
    dependent on each other anymore, are we? So why
    the Irrelevant---for being extra nice during security
    negotiation?

    Thanks for considering these concerns,

      Martins Krikis, Intel Corp.
     
    Disclaimer: These opinions are mine and
               may not reflect those of my employer.


    __________________________________________________
    Do You Yahoo!?
    Yahoo! Games - play chess, backgammon, pool and more
    http://games.yahoo.com/




Home

Last updated: Wed Apr 24 17:18:25 2002
9772 messages in chronological order