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

["THALER,PAT (A-Roseville,ex1)" <pat_thaler@agilent.com>]

Julian,

 

I think you have misunderstood the scenario that I was trying to describe.

 

The original question from Nick Bellinger was whether the reaction to receiving an inadmissible value during a negotiation could be responded to by offering an admissible value (because the text says one MAY respond with a REJECT which leaves the possiblity that one may also respond other ways). Your response suggested that it would be acceptable to respond by offering a value. I think that in most cases the rule against renegotiating means that the end result of doing so woud be just drawing out the negotiation failure unless the rule about renegotiating is changed.

 

Since the situation is what to do when one has received an inadmissible value, the question assumes that the rules have been broken - otherwise one would not ever receive an inadmissible value. To recap:

 

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 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 target thought it responded with a valid value so the target thinks that negotiation for that parameter is complete.

 

When the initiator responds by sending a value for the parameter, doesn't it look to the target like the initiator is renegotiating?

 

If we want to leave the rule that renegotiation MUST cause a negotiation failure, then the text saying negotiation is stateless (which isn't entirely true anyway as Mallikarjun pointed out) should be removed. Actually, with or without that rule, an implementation needs to maintain the latest negotiated value for a parameter plus whether the parameter has been negotiated yet.

 

If we leave that rule, then there isn't any point to trying to continue the negotiation following receipt of an inadmissible value. I think leaving the rule is acceptable because I don't see much point in continuing to negotiate when getting inadmissible values. I think that the rule to not negotiate a parameter more than once is a reasonable rule. I'm not convinced that the requirement to detect that one's partner is renegotiating a parameter more than once and cause a negotiation failure is necessary.

 

Regards,

Pat

 

 

-----Original Message-----
From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
Sent: Friday, April 19, 2002 11:43 PM
To: pat_thaler@agilent.com
Cc: ips@ece.cmu.edu; nickb@attheoffice.org; owner-ips@ece.cmu.edu
Subject: RE: iSCSI: Questions regarding text parameter 'Reject' and 'Irrel evant' usage

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 +++