Re: iSCSI: negotiation failure

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

Sandeep,

The only mechanism I considered is OpParmReset (the IO is a mistake) - the
new text I suggest is:

01   OpParmReset

   Use: All
   Who can send: Initiator and Target

   OpParmReset=<yes|no>

   OpParmReset enables an Initiator or Target to request the operational
   parameters to be reset to the values they had before the negotiation.
   Either the initiator or target may choose to do so but only within an
   operational parameter negotiation exchange within login or during full
   feature phase.  The resetting should involve only parameters that where
   set during operational parameter negotiation on the connection in which
   the OpParmReset is issued.  Please note that since either initiator or
   target may request this behavior there is no need to reply.

 However please note that 7.7 has also a "negative connotation" - that
 parameters that did not get agreed upon on a successfully completed text
 exchange do not get "committed".

Comments ?

Julo


sandeepj@research.bell-labs.com (Sandeep Joshi) on 30-07-2001 21:09:47

Please respond to sandeepj@research.bell-labs.com (Sandeep Joshi)

To:   ips@ece.cmu.edu
cc:
Subject:  iSCSI: negotiation failure




Julian,

Sec 7.7 (Negotiation failure) says a text sequence during
full feature phase can be aborted but I could not find the
mechanism to do this.

Is this done using the OpParmReset key ?
The key description says it is "IO" only (not full-feature)

  > A failure in negotiation while in the full-feature phase MUST
  > terminate the entire negotiation sequence possibly consisting
  > of a series of text commands using the same Initiator Task
  > Tag.  The operational parameters of the session or the
  > connection MUST continue to be the values agreed upon during
  > an earlier successful negotiation - i.e. any partial results
  > of this unsuccessful negotiation must be undone.

-Sandeep