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

    RE: iSCSI: not offering a key

    Excerpt of message (sent 26 January 2002) by
    > > Maybe I don't understand the sentence. I interpret it to mean that if the
    > > default value is acceptable to me then not offering it is somehow
    > different
    > > than the default ... and that confuses me (well, actually it makes me
    > wonder
    > > if the sentence is trying to say something else).
    > Here are two examples of how it's different:
    >  ...
    > (2) If the other party wants to negotiate the value and
    >     both offer the same default value, not offering the default
    >     results in an additional step before the negotiation can
    >     conclude, viz:
    >     -> Nothing        -> Key=Default
    >     <- Key=Default    <- Key=Default
    >     -> Key=Default
    But that's an artifact of a peculiar design approach for a negotiation
    algorithm.  The obvious design approach says that there are two ways
    to *encode* a key having the default value: by sending the key with
    that value, and by omitting that key.  Those two encodings should have
    the same effect on the negotiation state machine.
    That approach is far easier to understand and implement.  Given that
    approach, there cannot possibly be an extra message resulting from one
    encoding or the other, because the state machine reacts the same.
    What we see now is reasoning backwards from the design.  In other
    words: the starting position was to make the two encodings mean
    different things; the state machine was constructed in such a way that
    one results in more messages than the other; finally, that property is
    used as an argument for why the distinction has to exist.  But that's
    circular reasoning: do away with the distinction, and reduce the state
    machine to the shorter of the two cases, and the whole problem goes


Last updated: Mon Jan 28 13:17:57 2002
8517 messages in chronological order