Subject: iSCSI: No-renegotiation rule inadequately described

From: Martins Krikis <[email-masked]>
Date: Wed, 22 May 2002 13:51:16 -0700 (PDT)

Before I start, a philosophical question:

What is the point of allowing Reject-ed keys
to be renegotiated?

Now the problem. 
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg09733.html
claims that that it is OK to renegotiate keys that
have been answered with the reserved value "Reject".
I don't see where this would be mentioned in the
draft. What I see is this (page 73, very top):

  Neither the initiator nor the target should
  attempt to negotiate a parameter more than
  once during login.

Similar sentence on page 79, very bottom.

If we now imagine the following scenario:

  I -> T: ImmediateData=junk1
  T -> I: ImmediateData=Reject
  I -> T: ImmediateData=junk2

Doesn't it look like Initiator is _attempting_
to negotiate this parameter again? Thus, the
spec the way I read it disallows this (and I
like it), however the above link claims otherwise.
So, which way is it?

If it is allowed, then the draft should say so,
and it should also say whether keys answered
with Irrelevant may be renegotiated. I presume
keys answered with NotUnderstood may too, although
I'm not planning to even notice such an event.

Thanks,

  Martins Krikis, Intel Corp.

Disclaimer: these opinions are mine and may not
            be those of my employer

__________________________________________________
Do You Yahoo!?
LAUNCH - Your Yahoo! Music Experience
http://launch.yahoo.com

---

From: Martins Krikis <[email-masked]>
Date: Wed, 22 May 2002 17:23:54 -0700 (PDT)

--- [email-masked] wrote:

> The problem is there are two ways of
> interpreting the state of the negotiation 
> after ImmediateData=Reject. 
> 
> A) The offered value was rejected so the
> negotiation isn't done yet. In this view
> the second offer is a continuation of the
> first negotiation rather than a new 
> negotation.

Good point. But I don't think this view quite
fits together with, e.g., page 69:

  Reject or Irrelevant are legitimate
  negotiation options...

In my opinion (and implementation) it also
complicates the decision about whether this
value is precluding me from announcing readiness
to commit or it isn't. It's harder to view it
negotiated for commit purposes and non-negotiated
for repeated reception purposes than it is to
just view it the same way...

> B) A negotiation is always one offer and one
> response regardless of whether the response
> indicates successful negotiation or not.
> 
> Text should be added to the draft to indicate
> which is intended. 
> 
> I agree that it should state which is intended.
> My preference would be that it take the simpler
> view in B. 

I'm very much for it.

> For Booleans and numerical values,
> if the first offer caused a reject,
> there is something broken. For lists the originator
> can include all acceptable responses in the initial 
> offer. In either case, there isn't much point in 
> offering again.

This is exactly what I was planning to say once
somebody gave me a reason about the necessity
to renegotiate.

> If the response was NotUnderstood
> then there isn't any point in offering the key again
> (though I also think it is unreasonable to expect
> the
> responder to keep a list of NotUnderstood keys so
> that
> it can detect attempts to renegotiate).

Exactly.

> Irrelevant indicates that a problem such as key 
> negotiation being done in the wrong order (e.g. 
> attempting to negotiation IFMarkInt before
> IFMarker).
> There is no reason this should happen so we don't 
> need to allow the negotiation to continue in this
> case either.

First, there are no dependencies (even for markers,
keys can be viewed as independent), so in my opinion
this cannot happen. But even if it could happen, the
earlier-negotiated key that caused the 
later-negotiated key to be answered with Irrelevant,
is not going away, so there is no point repeating
the later key---it will still be answered with
Irrelevant! There is also no point to negotiate
it from the other side, as that would then be the
side who first called it Irrelevant. Once irrelevant
is always (through the life of negotiation sequence)
irrelevant, so no need to renegotiate it.

> I suggest adding to 4.2 after "Reject or Irrelevant
> are legitimate...." 
> "A negotiation is considered complete when the
> responder has sent the key value pair even if the
> value 
> is "Reject", "Irrelevant", or "NotUnderstood".
> Sending 
> the key again would be a re-negotiation."

This would be truly beatiful. Can it please happen?

Thanks,

---

From: "John Hufferd" <[email-masked]>
Date: Wed, 22 May 2002 17:37:24 -0700

OK, this has been going around and around.  But I hope the attached last
note tied it up.

Julian, can we use the conclusion in this attached note?

> the key again would be a re-negotiation."

.
.
.
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]

Martins Krikis <[email-masked]>@ece.cmu.edu on 05/22/2002 05:23:54 PM

Sent by:    [email-masked]

To:    [email-masked]
cc:
Subject:    RE: iSCSI: No-renegotiation rule inadequately described

I'm very much for it.

Exactly.

Thanks,

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 23 May 2002 06:16:12 +0300

John,

The intend of the "legitimate" statement was to say that those are not to 
be confused with not admissible and force termination.
I will add wording to make this clear. 

Julo

John Hufferd/San Jose/IBM@IBMUS
Sent by: [email-masked]
05/23/2002 03:37 AM
Please respond to John Hufferd

        To:     Martins Krikis <[email-masked]>
        cc:     [email-masked]
        Subject:        RE: iSCSI: No-renegotiation rule inadequately described

.
.
.
John L. Hufferd

To:    [email-masked]
cc:

I'm very much for it.

Exactly.

Thanks,