Re: ips : Negotiation Reset.

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

Comments in text. Julo


                                                                                              
                    Santosh Rao                                                               
                    <santoshr@cup.       To:     IPS Reflector <ips@ece.cmu.edu>              
                    hp.com>              cc:                                                  
                    Sent by:             Subject:     Re: ips : Negotiation Reset.            
                    owner-ips@ece.                                                            
                    cmu.edu                                                                   
                                                                                              
                                                                                              
                    11-10-01 01:27                                                            
                    Please respond                                                            
                    to Santosh Rao                                                            
                                                                                              
                                                                                              



Julian,

Further comments below.

Thanks,
Santosh


Julian Satran wrote:

> Comments in text. Julo

> Why is the reject reason code "Negotiation Reset" required ? Per
> Section
> 8.7, any failure of a text cmd/rsp while in FFP causes a "negotiation
> reset" (i.e. operational parameters are reset to thee values agreed
> upon
> during an earlier successful negotiation).
>
> +++ Today we reset with a task abort (task managemenT). The proposed
> change to mandate TTT
> might unify this space ++++

The parameters are reset on any of the following events (as called out
in 8.7) :

a) target rejects any one of the text cmds in the exchange.

b) initiator timeout of any one text cmd in the text exchange. [this can
cause the initiator to issue an abort task to abort the text exchange,
or tear down the cxn as recovery.]

Now, my question is about the *specific* reason why a reject with reason
code "Negotiation Reset" is required. I presume this can only be used in
case (a) contexts to reset parameters, since in case (b), the abort task
completion or cxn teardown leads to parameter reset.

Now, in case (a), is'nt it assumed that *ANY* reject will lead to a
parameter reset ? Given this, why do we need an explicit reason code
"Negotiation Reset" ?

The above issue is independent of the "mandatory TTT in text" proposal,
right (?).

[Please help me understand by giving an example where "negotiation
reset" would be returned by a tgt.]
+++ the initiator has a clear way to reset/reject a parameter set or
negotiation.
For target Reject is the "universal" method +++

On a seperate note, the following case described in 8.7 :
- None of the choices or the stated value is acceptable to one
negotiating side.

should not cause a reset of all the parameters ? It should only reset
that specific parameter to its previous value.



> So, why do you need an explicit reason called "negotiation reset" (?)
> Any failure of a text cmd at the target end would be conveyed through
> either a "data digest error" or "protocol error". The operational
> parameters are understood to be reset on any failure of the text
> sequence.
>
> Also, I suggest that the reject reason codes 0x09 & 0x0a (Bookmark
> Reject) be removed and replaced by a reason called "Invalid Target
> Transfer Tag".  (now that bookmarks are gone.)
>
> +++ WE could  if TTT becomes generalized for sequences - today t is
> not +++

Again, the reason codes for "Bookmark Reject" are defined today for the
long text scenario, and I suggest that they be removed and replaced with
an "Invalid Target Transfer Tag". Both the former and latter are
[currently] meant for long text cmds and so the change should be ok. (?)

Lastly, the term "reset operational parameters" is used in several
places. I suggest the specific operation associated with it be called
out in places where the term 'reset' is being used.
Ex : Section 3.10.3, 3.11.3, 6.



--
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################