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



    
    Martins,
    I am sorry I do not see it like you do.  We have been having a shot-gun
    approach, to every thing at the same time.  Please focus on one thing at a
    time and drive that to closure.
    
    That way we can discard the personal preferences without getting it tied up
    with worthwhile things.
    
    If you want to work with three topics, lets have three threads, etc.  But
    we need to drive to closure with focus.
    
    I can not blame Julian, this thread has become a stew for everything.   And
    I do not think it is fair for you to attack him.  We have over 270 pages of
    stuff, and you are focused on a narrow point, which is fine, but if there
    is not clarity, agreement, or closure, therefore he can not add it to the
    document.  The problem is not Julian!!!
    
    
    
    .
    .
    .
    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
    
    
    Martins Krikis <mkrikis@yahoo.com> on 05/24/2002 04:59:02 PM
    
    To:    John Hufferd/San Jose/IBM@IBMUS, ips@ece.cmu.edu,
           wrstuden@wasabisystems.com
    cc:
    Subject:    Re: [iSCSI]: Key negotiation procedure proposal
    
    
    
    John L. Hufferd wrote:
    
    > I do not see the new draft as broken,  it is a bit clearer.
    
    Yes, getting clearer little by little, because some people
    fight for clarity. Once it gets crystal clear in the area
    of negotiation, I'll say "thanks" and leave it alone.
    
    Please note that some of the very clear and right things
    that you have been saying, even things that you have said
    should be put in the draft, are NOT there!
    
    > And it has
    > worked in the plugfests.
    
    That does not constitute a proof that it is not broken.
    
    > We only have had about 3-4 folks that have been
    > having a problem here,
    
    Yes, I was having a problem here. Because this mailing list
    erroneously convinced me that renegotiating Reject-ed keys
    is allowed. I actually believed this and recoded a previously
    perfectly good implementation. After raising text clarity issues
    I was then being assured about completely the opposite, in fact
    we got some text in the draft proving the opposite.
    
    Now I have to undo the changes to my implementation. Do you think
    I'm having fun with this here? Do you think I'd like to move
    to other areas of iSCSI only to implement those too the wrong way?
    I'm pretty mad about the (now ex-) renegotiation issue actually!
    
    >    most of the rest are busy doing meaning work.
    
    I'd rather have my manager decide whether I'm doing meaning work or not.
    Saving a company from doing a wrong implementation seems like a
    fairly worthwhile cause to me.
    
    > But these 3 folks have been chatting a lot.
    
    Yes, that's very unfortunate. But it could have all been
    prevented simply by having a clearer draft to work with.
    
    > What I see is some folks dealing with is preference not brokenness.
    
    On some issues yes. Some of us prefer simplicity, others prefer
    feature completeness, others prefer not doing anything "this late".
    This could have all been avoided by having the specification
    be more deterministic, or just less ambiguous.
    
    > There might be some words that you want to clear up.
    > Please suggest them,
    
    Done already.
    
    > but lets not get into preferences on how one would like it to
    > work I think we are past that, lets just clear up the miss understanding.
    
    That's what we're trying to do. Unfortunately the misunderstandings
    often reveal deaper deficiencies. And Julian asked to submit
    proposals, which is what I just did regarding pairs broken across PDUs.
    
    
    
      Martins Krikis, Intel Corp.
    
    Disclaimer: these are my own opinions and not necessarily my employer's.
    
    
    
    


Home

Last updated: Fri May 24 21:18:31 2002
10321 messages in chronological order