RE: DefaultTime2Retain Negotiation during Discovery Session
"Sandars, Ken" <[email protected]> Sun, 19 Aug 2007 20:45:00 -0700
| Newsgroups | gmane.ietf.ips |
|---|---|
| Message-ID | <[email protected]> |
Hi Ram, So you're probably in a delightful loop where the initiator sends an empty Login request PDU which requests a transition to FFP, and the target responds with an empty Login response refusing to transit. This goes on forever, and probably quite quickly. Two valid target implementations to break out of this are: 1. Limit the number of Login responses the target will send before it gives up. Let this be a gross number - say over a hundred, a thousand, whatever you prefer. 2. Limit the duration from the start of the TCP connection to reaching FFP. If the login phase goes over your arbitrary limit, terminate the sequence. Cheers Ken -----Original Message----- From: RAM SUNEE [mailto:[email protected]] Sent: Sunday, 19 August 2007 02:46 To: Ips; William Studenmund Subject: RE: [Ips] DefaultTime2Retain Negotiation during Discovery Session Importance: High -----Original Message----- From: William Studenmund [mailto:[email protected]] Sent: Saturday, August 18, 2007 8:29 AM To: RAM SUNEE Cc: Ips Subject: Re: [Ips] DefaultTime2Retain Negotiation during Discovery Session Importance: High On Aug 18, 2007, at 8:08 AM, RAM SUNEE wrote: > Hello, > > During LoginOperational negotiation phase of Discovery Session, > Initiator didn't initiate negogiation for DefaultTime2Retain key. > Target tried to negotiate for this key a value of 0,but initiator > tried to enter full feature phase without responding to this specific > key. > In this case what target is supposed to do? What do you mean "tried to enter full feature phase without responding"? It sent back an empty PDU requesting transitioning to FFP? Did the target correctly not offer to transition to FFP (did not set the 'T' bit in the login response)? The target should not set the 'T' bit and it should wait for the initiator to answer, and eventually time out the login. From the RFC: 12.16. DefaultTime2Retain Use: LO Senders: Initiator and Target Scope: SW DefaultTime2Retain=<numerical-value-0-to-3600> Default is 20. Result function is Minimum. So it's valid to negotiate in a discovery session. RAM> Target didn't set 'T' bit when it sent Login response with DefaultTime2Retain key. What I mean here is that Intiator responded back with a Login request with an empty PDU(no keys), requesting transition to FFP. Because initiator responded back here, there is no question of timing out the login.What is the correct way the target should handle this? > Also, if the same situation happens during Normal Session,what the > target is supposed to do? Same thing. Take care, Bill _______________________________________________ Ips mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ips _______________________________________________ Ips mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ips