SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


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

    RE: iSCSI: not offering a key



    Eddy,

     

    > What I was referring to is that you said:

    >

    > If for some reason the other party doesn't have the

    > same default (bugs happen), negotiation should drive

    > both parties to an agreed value ...

    >  

    Reading on I assumed you meant that we should add code to cope with that.

    > If you take that to an extreme, we would be adding “lots of code” just to cover all possible bugs.

     

    That was definitely not my intention.  If either party chooses to negotiate a value, the negotiation

    code that has to be implemented anyway will drive both parties to agreement, but notice the *if*.

    I definitely do not want this taken to an extreme that would require all keys to be negotiated in

    all cases. As a consequence, there will be situations in which mistakes occur that cause the

    two parties to have different ideas of what the default value is for a key that wasn't negotiated

    (to err is human, most code is written by humans ... ).  I am recommending an "if in doubt,

    negotiate" approach to implementation that will tend to limit such problems to relatively

    unimportant keys.  Coverage of "all possible bugs" was not my intention.

     

    > An implementation should only have to cover the other ends bugs that could cause a crash

    > or data corruption at our end. In this case, I don’t think that means we should change the

    > standard to do extra negotiations just to cover possible bugs. 

     

    I think we have a serious difference in philosophy.  The usual IETF

    dictum of being conservative in what is sent and liberal in what is

    accepted implies coverage of more than just bugs that could cause a

    crash or data corruption - see the recent example I sent to the list

    of how a notion of "implicit offers" could cause a silly breakdown

    in negotiation.  OTOH, being liberal in what is accepted does not

    equate to covering all possible bugs - it means doing one's best to

    do something reasonable in the face of the unexpected as opposed

    to regarding the least little thing going wrong as a fatal error and

    reason to immediately give up.

     

    As to the standard, I'm not proposing any change.  I'm recommending that implementers

    exercise good judgment by choosing to negotiate any parameters that are important to the behavior

    and performance of their implementation (which sounds like common sense - are you objecting to

    this?).  The negotiation algorithm has been (and should be) specified in a way that is robust to

    minor things going wrong, and hence just using it provides some robustness against minor

    things going wrong.

     

    The overall principle is somewhat akin to the exhortation not to complain about the behavior of

    the government if you didn't bother to vote.  I think we're close to violent agreement.

     

    Thanks,

    --David

    ---------------------------------------------------
    David L. Black, Senior Technologist
    EMC Corporation, 42 South St., Hopkinton, MA  01748
    +1 (508) 249-6449 *NEW*      FAX: +1 (508) 497-8500
    black_david@emc.com         Cell: +1 (978) 394-7754
    ---------------------------------------------------

     

     -----Original Message-----
    From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
    Sent: Friday, February 01, 2002 7:37 AM
    To: Black_David@emc.com; Eddy Quicksall
    Cc: ips@ece.cmu.edu
    Subject: RE: iSCSI: not offering a key

    Maybe I misunderstood your note.

     

    What I was referring to is that you said:

     

    If for some reason the other party doesn't have the

    same default (bugs happen), negotiation should drive

    both parties to an agreed value ...

     

    Reading on I assumed you meant that we should add code to cope with that. If you take that to an extreme, we would be adding “lots of code” just to cover all possible bugs.

     

    An implementation should only have to cover the other ends bugs that could cause a crash or data corruption at our end. In this case, I don’t think that means we should change the standard to do extra negotiations just to cover possible bugs.

     

    Again, maybe I misunderstood what you were trying to say.

     

    Eddy

     

    -----Original Message-----
    From: Black_David@emc.com [mailto:Black_David@emc.com]
    Sent: Tuesday, January 29, 2002 3:16 AM
    To: Eddy_Quicksall@ivivity.com
    Cc: ips@ece.cmu.edu
    Subject: RE: iSCSI: not offering a key

     

    I don't understand how this leads to "lots of code".  The

    underlying principle is to negotiate anything you care about

    and not to complain about things that you didn't negotiate.

    Saying that there are no implicit offers is fine with me.

     

    Thanks,

    --David

    -----Original Message-----
    From: Eddy Quicksall [mailto:Eddy_Quicksall@ivivity.com]
    Sent: Monday, January 28, 2002 12:42 PM
    To: julian_satran@il. ibm. com (E-mail)
    Cc: ips@ece.cmu.edu; Robert D. Russell
    Subject: RE: iSCSI: not offering a key

    I don’t think we should be in the business of adding lots of code to cope with possible bugs at the other end … there would be no end to what you would do and how you would do it.

     

    Couldn’t we just strike the sentence and say what Dr. Russell said. I would suggest something like:

     

    “There is no such thing as implicit offers. If an explicit offer is not made then a reply cannot be expected.”

     

    -- cut and past from his EMAIL --

    I believe this sentence was added to the spec because at the

    last UNH plugfest, several people were interpreting "no explicit

    offer" of a key as an "implicit" offer of the default for the key,

    and were therefore expecting a reply.  This sentence is intended

    to prevent that interpretation -- if you don't make an explict offer

    you cannot expect a reply -- there are no such things as implicit offers.

     

    Eddy

     

    -----Original Message-----
    From: Black_David@emc.com [mailto:Black_David@emc.com]
    Sent: Saturday, January 26, 2002 3:31 AM
    To: Eddy_Quicksall@ivivity.com
    Cc: ips@ece.cmu.edu
    Subject: RE: iSCSI: not offering a key

     

    > 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:

     

    (1) If for some reason the other party doesn't have the

        same default (bugs happen), negotiation should drive

        both parties to an agreed value, but in the absence of

        negotiation, the other party might do something different.

        Moral: if a key value is important, it MUST be negotiated.

        This is a little weaker than Luben's statement that

        all keys always have to be negotiated.  That strength

        was never intended.

     

    (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

     

    --David

     



Home

Last updated: Fri Feb 01 12:17:54 2002
8592 messages in chronological order