|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: ips : Negotiation Reset.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.] 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 ##################################
Home Last updated: Sat Oct 13 07:17:37 2001 7228 messages in chronological order |