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



    
    --- 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 06:18:50 2002
9761 messages in chronological order