Subject: Re: [iSCSI]: Key negotiation procedure proposal

From: "John Hufferd" <[email-masked]>
Date: Fri, 24 May 2002 14:39:37 -0700

I do not see the new draft as broken,  it is a bit clearer.  And it has
worked in the plugfests.  We only have had about 3-4 folks that have been
having a problem here, most of the rest are busy doing meaning work.  But
these 3 folks have been chatting a lot.

What I see is some folks dealing with is preference not brokenness.  There
might be some words that you want to clear up.  Please suggest them, 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.

.
.
.
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: [email-masked]

Bill Studenmund <[email-masked]>@ece.cmu.edu on 05/24/2002
12:53:57 PM

Sent by:    [email-masked]

To:    Julian Satran/Haifa/IBM@IBMIL
cc:    Martins Krikis <[email-masked]>, <[email-masked]>,
       <[email-masked]>
Subject:    Re: [iSCSI]: Key negotiation procedure proposal

On Fri, 24 May 2002, Julian Satran wrote:

> All this thread is based on the assumption that discovery of what other
> side capabilities are is a good thing to have in the protocol.

We must be reading different threads. While I've seen discovery mentioned
and discussed, it's not been a base assumption of what I understood the
thread was about.

> Except for one item the group has decided a long time ago against it.
> The messages consume an inordinate amount of time from all of us - and we
> are looking for things to fix (big or small).

The thread was about the fact people think that login negotiation needs
fixing. It could be the negotiation methods need changing (as in Lubin's
suggestion), or the text needs changing to something more like what John
wrote.

The point though is that the current negotiation description is broken in
the minds of a number of implementors. It sounds like it is not broken in
the minds of a number of the WG members who have been involved for a
while. So from that I conclude the spec hasn't been capturing what is in
the WG's thoughts; the spec needs work.

> If you think that negotiations have to be done some other way that is
> essentially better - please discuss this between yourselves and  submit
an
> ID.

I think that would be a reasonable suggestion if we were talking about
making it spiffier & better. But we're complaining that we think it's
broken. Telling us to go off and come back with an ID does not strike me
as a suggestion which will help us converge to an answer.

Take care,

Bill

---

From: Martins Krikis <[email-masked]>
Date: Fri, 24 May 2002 18:59:02 -0500

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.

---

From: [email-masked]
Date: Fri, 24 May 2002 17:44:44 -0600

I agree. The only reason for a rejected key is that the orignator 
offered something that shouldn't have ever been offered or provided
a list with no acceptable options to the responder. There isn't any 
point in continuing the negotiation.

Pat 

-----Original Message-----
From: Paul Koning [mailto:[email-masked]]
Sent: Thursday, May 23, 2002 9:55 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [iSCSI]: Key negotiation procedure proposal

Excerpt of message (sent 23 May 2002) by Luben Tuikov:
> But Julian, I'm _not_ talking here about discovering capabilities.
> 
> This is just rules for Login/Text Operational Key Negotiation.
> ...
> Furthermore I don't think that this complicates negotiation,
> If anything ,it makes it simpler. There is a rule for simple
> implementations (Martins, your opinion?) and a rule
> for fully developed implementations.
> 
> It's just login/text negotiation rules.
> 
> People, take a look at the rules and examples
> and let me hear your opinion? (those of you
> involved in login/text neg. discussions)

I think it's unnecessarily complex.  The "simple implementation" alone
is plenty.

   paul

---

From: [email-masked]
Date: Fri, 24 May 2002 18:09:39 -0600

I think it also makes sense to close the connection. Why try to 
interoperate when something is broken and for the existing parameters,
there is no reason for a Reject when an appropriate type value was offerred?
But if one really wants to give it a try there is a reasonable value to
use. All parameters that have a default can use that as the commit value if
an attempt to negotiate at login experiences a Reject. During full feature
they can use the old value.

Regards,
Pat

-----Original Message-----
From: Luben Tuikov [mailto:[email-masked]]
Sent: Thursday, May 23, 2002 5:23 PM
To: John Hufferd
Cc: Martins Krikis; [email-masked]
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

---

From: "John Hufferd" <[email-masked]>
Date: Fri, 24 May 2002 17:42:16 -0700

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

Martins Krikis <[email-masked]> on 05/24/2002 04:59:02 PM

To:    John Hufferd/San Jose/IBM@IBMUS, [email-masked],
       [email-masked]
cc:
Subject:    Re: [iSCSI]: Key negotiation procedure proposal

Done already.