Re: iSCSI: Questions regarding text parameter 'Reject' and 'Irrelevant' usage

["Julian Satran" <Julian_Satran@il.ibm.com>]

Luben,

I hope I cleared this.
The may reject is only for the responder - the originator expects a good selection (according to the rules) or reject and will end the negotiation otherwise.
That is the exact meaning of the text.  I did look it again over and I may add words but it seems that the text is clear as it is.

Julo

Luben Tuikov <luben@splentec.com> Sent by: luben@ns.splentec.com 04/23/2002 01:42 AM Please respond to iSCSI; Please respond to Luben Tuikov

To:        "THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>         cc:        Julian Satran/Haifa/IBM@IBMIL, ips@ece.cmu.edu, nickb@attheoffice.org, "Mallikarjun C." <cbm@rose.hp.com>         Subject:        Re: iSCSI: Questions regarding text parameter 'Reject' and 'Irrelevant'  usage

Hello,

I agree with Pat.

But along the lines of the choices of "MAY" there
seems to be another issue: (inlined)

> "THALER,PAT (A-Roseville,ex1)" wrote:
> 
> Initiator offers value x
> Target responds with value y  (which it thinks is admissible)
> Initiator finds value y to be inadmissible and offers the parameter again
> (either with x or a new value z).

The initiator should close the connection. (Reasons below.)
 
> The target wouldn't intentionally respond with an inadmissible value so some sort of error must
> have occurred. For instance, the target is using the wrong rule to pick its value, the value it
> received from the initiator was corrupted or the value it picked got corrupted.

The more reason the initiator should close the connection.

A problem arises for a "MAY" rule: that is, it opens a split (choices)
in the decision tree which may lead to a cyclical decision tree,
which would mean that the logic was faulty somewhere.

Consider this: A variable negotiation state is esablished only when
a variable offer and result have been exchanged where
no reserved keywords have been the value of the variable (i.e.
Reject, Irrelevant, etc.). This also includes
an implicit result for the OR and AND functions.
(This version of the renegotiation rule is equivalent
to: A node cannot offer a variable more than once if
it received (even implicit) a result for the variable
which is not a reserved keyword.)

Then:
I: v = x   -->
                 T: 1) either x is unnaceptable (Reject)
                    2) or rule choses y.
           <--   1) v = Reject  \
                                 > Because of MAY 
                 2) v = y       /

I: 1) ok, will renegotiate it.
 OR
   2) y is unnacceptable -- cannot break
      the renegotiation rule, close the
      connection (hopeless target).

There may be a problem for 1): the node may offer its faulty
value forever and the peer node will reject it forever --thus
we get into an inf. cycle, which is also undesirable.

To avoid this problem one needs to either keep state for
offers, or limit the number of variable negotiation exchanges.

Currently, as per the draft, offers are stateless, and a complete
negotiation is stateful (as per the renegotiation rule).

Try_1: We can get rid of the need to introduce stateful offers,
by stipulating that: A node cannot make another offer upon
a receipt of a reserved keyword for a value of the variable
which it offered.

Thus, as per the above example, once the target
goes into to 1) scenario, then the initiator
cannot make another offer.

In which case the target will make an offer later on.

BUT this would also lead to a cycle if the initiator
finds the offer unnacceptable and replies with a
reserved keyword...

So then, should we elimiate the Reject keyword?
(which would eliminate the cyclical nature)

It seems to me that to avoid all this,
stipulating that offers (not only
negotiations) are stateful is
inevitable.

If offers are stateful and we assume Try_1, then
there cannot be a cycle iff Renegotiation rule
is applied.

-- 
Luben

P.S. A better and more complete negotiation
decision tree is possible.