Re: DefaultTime2Retain Negotiation during Discovery Session

Given the default ErrorRecoveryLevel=0 and
MaxConnections=1 for the Discovery session, the only
thing an initiator would get by a non-zero
DefaultTime2Retain is session continuation (jump
straight from FAILED to LOGGED_IN) when the only
connection in the session fails.  Typical motivation
for a session continuation then is avoiding SCSI side
effects related to I_T nexus loss, and there wouldn't
be any obviously for a Discovery session anyway.

Given all that, it's unlikely that an initiator would
attempt a session continuation for a Discovery session
at all.  On its part OTOH, it's not an undue burden
for a target to support it if a continuation were
attempted - minimal state, primarily around TSIH &
Initiator Port, I'd imagine.

None of this justifies what appears a negotiation
protocol violation identified on this thread.

Mallikarjun






--- William Studenmund <[email protected]> wrote:

> On Aug 20, 2007, at 12:38 PM, Ken Craig wrote:
> 
> > William,
> >
> > To me the fact that the Initiator attempted to
> > transition to FFP without answering the key is
> > reason enough to terminate the login with an
> > error.
> 
> True. I agree.
> 
> It depends on why we want to kill the login attempt.
> :-)
> 
> I think that an empty PDU alone isn't enough,
> especially given Paul  
> Konig's comment about interoperation.
> 
> Trying to skip answering a key, however is. Good
> call.
> 
> Take care,
> 
> Bill
> 
> 
> _______________________________________________
> Ips mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/ips
> 



       
____________________________________________________________________________________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. 
http://mobile.yahoo.com/go?refer=1GNXIC


_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips