RE: iSCSI: Questions regarding text parameter 'Reject' and 'Irrel evant' usage

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

Pat,

Reject is for a parameter that is not acceptable. In your example the value y of the responder must be within what is admissible or reject (i.e., it cannot be an unexpected value as the responder may only select from offerings or reject. Now in this case the initiator may try again without violating the rule that says "no double negotiation".  This later rule was introduced late (and I am not convinced it is strictly needed because dependencies may make one party want to renegotiate a value - but we have none now) to solve a concern related to endless negotiations.

Julo

pat_thaler@agilent.com 04/20/2002 01:19 AM Please respond to pat_thaler

To:        Julian Satran/Haifa/IBM@IBMIL, nickb@attheoffice.org         cc:        ips@ece.cmu.edu, owner-ips@ece.cmu.edu         Subject:        RE: iSCSI: Questions regarding text parameter 'Reject' and 'Irrel        evant' usage

Julian,

There seems to be some contradictory text with regard to whether an
inadmissible value can be responded to by offering an admissible value
rather than a reject.

4.2 is compatible with this saying: All negotiations are stateless and
explicit (i.e., the result MUST be based only on newly exchanged values). 

but 4.3 says: Neither the initiator nor the target should attempt to
negotiate a parameter more than once during login If detected by the target
this
MUST result in a Login reject (initiator error). The initiator MUST
drop the connection.
4.4 has similar text with adjustments for post login negotiation behavior.

If renegotiation of a parameter MUST cause negotiation failure, then
negotiation is not stateless.

If the following sequence of events happens:
Initiator offers value x
Target responds with value y 
Initiator finds value y to be inadmissible and offers the parameter again
(either with x or a new value z).

Doesn't that look to the target like the initiator is trying to negotiate
the parameter more than once and cause the Target to do a Login reject (or
negotiation reset)? How does a device differentiate between continued
negotiation of a parameter because it's answer wasn't accepted and new
negotiation?

Why not just allow the negotiation to be stateless as 4.2 says?

Pat

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]

some comments in text - Julo 

Nick Bellinger <nickb@attheoffice.org> 

Greetings,

                I have a few questions regarding the wording as per
iSCSI-v12 4.2  Text
Mode Negotiation:

                "An offer of a value not admissible MAY be answered with the
constant
"Reject". The selection of a value not admissible under
                the selection rules is considered a negotiation failure and
is 
                handled accordingly."

1. Is a responder allowed to return an admissable value (its default
value for the key) instead of using the 'Reject' constant? 

+++ the text clearly allows this +++