RE: DefaultTime2Retain Negotiation during Discovery Session

["Paul Hughes" <phughes@xxxxxxxxxxxxxx>]

I think it's legal to terminate a login if a proposed key is not answered in the next login request/response (with exceptions for Boolean negotiations having optional responses).  I don't think RFC3720 states this explicitly, but this seems to indicate that initiators and targets should not delay answering a proposed key:

5.2.  Text Mode Negotiation

   A target or initiator SHOULD NOT use a Text or Login Response or Text
   or Login Request with no data segment (DataSegmentLength 0) unless
   explicitly required by a general or a key-specific negotiation rule.

My interpretation is that DefaultTime2Retain requires an answer and does not require an empty PDU request/response, therefore the acceptor must answer in the next login request/response.

Thanks,
Paul



-----Original Message-----
From: Ken Craig [mailto:kcraig@xxxxxxxxx]
Sent: Monday, August 20, 2007 9:11 AM
To: William Studenmund; RAM SUNEE
Cc: Ips
Subject: RE:  DefaultTime2Retain Negotiation during Discovery
Session


William,

Wouldn't it also be legal for the Target to
terminate the Login with a response code of
Initiator Error after the receipt of the first
empty PDU since the value was offered by the
Target but not returned by the Initiator?

Thanks,
Ken Craig

-----Original Message-----
From: William Studenmund [mailto:wrstuden@xxxxxxx] 
Sent: Sunday, August 19, 2007 10:12 PM
To: RAM SUNEE
Cc: Ips
Subject: Re:  DefaultTime2Retain Negotiation during Discovery
Session
Importance: High


On Aug 18, 2007, at 9:46 AM, RAM SUNEE wrote:

> 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?

The target should send back an empty PDU denying the transition to FFP.

There certainly is a question of timing out the login. :-) It is  
perfectly reasonable for a target to terminate a login that doesn't  
complete after a number of replies. Ken mentioned 100 or 1000 PDUs.  
I'd set the limit lower, say at 20. Another option is to keep the  
count low, say 10, and reset it when you get a reasonable PDU.

I also recommend that if you kill a login attempt for this reason  
(didn't complete, were outstanding Keys), log why you're doingthis and  
what keys were outstanding. This will help customers escalate the  
issue w/ the initiator vendor.

Take care,

Bill


_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips


_______________________________________________
Ips mailing list
Ips@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ips