Re: IG clarifications: Login Response & Reject reason codes

[Julian Satran <Julian_Satran@xxxxxxxxxx>]

"Mallikarjun C." <cb_mallikarjun@xxxxxxxxx>
wrote on 11/12/2006 20:15:23:

> All:
> 
> I received some offline feedback on the implementers' guide draft
> from  a few reviewers who preferred to be anonymous.  Please
review & comment.
> 
> 1) RFC 3720 does not explicitly call out that there cannot be more
> than one outstanding Login-Response PDU on one iSCSI connection at
> any given time (although the C-bit text indirectly implies it).
> 
>

This is intentional. At the time we where playing
with the idea of pipelining the login.
However it is common practice to have a single outstanding
Login Request.
I think that the only thing that becomes problematic
is the phase change request (there you can have only one outstanding).
There is already text that says that all changes to
key values become final only at the end (when consistency can be reasonably
checked).

> Section 10.10 on Text Request PDU (which should cover Login Request
> PDU semantics as well) says: "An initiator MUST have at most
one 
> outstanding Text Request on a connection at any given time."
 
> Essentially, an analog for Login/Text Response is missing (or so it
seems).
> 
> 2) RFC 3720 does not specify the use case for Reject reason code 
> "Task in progress" (0x07).
> 
> I vaguely recall we put in this reason code for task reassignment
> attempts while a task is in progress, but then we subsequently added
> a TMF response reason code for that case (Julian?).  So I'm not
sure
> if reason code 0x07 is used by implementations any longer.  
> 

The reject can used when the initiator attempts to
start a new task but a task with the same ITT is still active for those
cases when the target can't be sure this is a protocol error (e.g., a race
between a logout and a reissued SCSI command).

> The other non-obvious case is that of a "negotiation reset"
Reject 
> reason code.  What is this used for by implementations, if at
all?  
> If I don't hear any objections, I will deprecate these two reason
codes.
> 

The negotiating can't be continued by one of the parties
but the partial results (e.g., previous stage) are OK and no renegotiation
is deemed necessary. I have no clue if somebody uses it but I felt at the
time that the purists will object if I'd suggest restarting the login :-)

> Mallikarjun
> 
> 
>  
> ____________________________________________________________________________________
> Do you Yahoo!?
> Everyone is raving about the all-new Yahoo! Mail beta.
> http://new.mail.yahoo.com
> 
> _______________________________________________
> Ips mailing list
> Ips@xxxxxxxx
> https://www1.ietf.org/mailman/listinfo/ips
_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips