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 procedure proposal Rephrased



    
    I am rephrasing the last note:
    
    There are two things, to do when the key=value comes in wrong...
    (That is after you respond with a Reject).
    
    1. terminate the connection
    OR
    2. continue but do not accept that key again.(If attempted, terminate the
    connection)
         a. What ever the defaults are, they stand.
         b. If there is no default, and the value is needed, terminate the
    connection.
    
    As for 1,  it is simple and not an interoperability problem -- FIX the
    Problem.
    As for 2:
    * I do not think you need to be to formal here.  Either defaults work, or
    they don't.  If they don't, then terminate and Fix the problem.
    * I do not think this brings up interoperability problems. If it doesn't
    work, terminate and fix the problem.
    
    This is good enough.  Pick 1 or 2 and lets stop polishing the error case.
    
    .
    .
    .
    John L. Hufferd
    Senior Technical Staff Member (STSM)
    IBM/SSG San Jose Ca
    Main Office (408) 256-0403, Tie: 276-0403,  eFax: (408) 904-4688
    Home Office (408) 997-6136, Cell: (408) 499-9702
    Internet address: hufferd@us.ibm.com
    
    
    Luben Tuikov <luben@splentec.com>@ns.splentec.com on 05/23/2002 05:23:14 PM
    
    Sent by:    luben@ns.splentec.com
    
    
    To:    John Hufferd/San Jose/IBM@IBMUS
    cc:    Martins Krikis <mkrikis@yahoo.com>, ips@ece.cmu.edu
    Subject:    Re: [iSCSI]: Key negotiation procedure proposal
    
    
    
    John Hufferd wrote:
    >
    > Martins said:
    > "...However, I actually object to the whole idea of cutting any slack to
    > non-conforming Originators by not Rejecting their keys and sending a
    "good
    > value" instead.  I don't think it is good. So I'm for the removal of this
    > possibility...."
    >
    > I agree with this.
    >
    > I do not know if we have to end the connection after the Reject, but if
    the
    > Originator sends it again, then shut down.  I see no value in going on
    and
    > on (like this thread).  lets move to closure here.
    
    Ok, ``simple implementation'' handles this.
    
    But, John, what else can we do after sending key=Reject
    _and_ inter-operate?!
    
    We have to have some stringent rules, in order to
    achieve inter-operability _and_ negotiation convergence.
    
    If you have a constructive suggestion (a rule, ruleset, etc.),
    please post it.
    
    --
    Luben
    
    
    
    


Home

Last updated: Thu May 23 22:18:33 2002
10285 messages in chronological order