Hi Scott.
On Sep 3, 2010, at 10:43 PM, Scott C Moonen wrote:
> Looks good. I have one technical question:
>
> - What is the purpose of sending an empty response to the unprotected
> N(INVALID[_IKE]_SPI)&N(QCD_TOKEN)+ message? I'm not sure it provides any real
> value and would really prefer no
On Fri, 3 Sep 2010, Pekka Riikonen wrote:
: something like next_message_id += window_size / 2, and be happy. Though,
: implementation must ensure it never sends more than the increment (that's why
: window size of 1 doesn't work to begin with). Why was the window size defined
: by default to 1 an
Hi Pekka,
Thanks for the comments on draft.
Please find my comments inline.
Regards,
Kalyani
-Original Message-
From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf
Of Pekka Riikonen
Sent: Friday, September 03, 2010 2:48 PM
To: y...@checkpoint.com
Cc: ipsec@i
Hi Pekka,
What is the message Id that can be used to send the informational
exchange while sending RESET_WINDOW notify? I find that your approach is
similar to this draft as
1. Initiator(failover) and responder(peer) agree upon the new range of
message Id's and ignore the lost message Id's.
Bot
On Sat, 4 Sep 2010, Kalyani Garigipati (kagarigi) wrote:
: 1. If window size is say some five and range expected is 4-8, and if
: peer has got all four requests with values 5,6,7,8 and 4 is lost, then
: there would be no message id that can be used to send the notify
: reset_window.
: The initiato
On Sep 4, 2010, at 3:01 PM, Kalyani Garigipati (kagarigi) wrote:
>
> 1. If window size is say some five and range expected is 4-8, and if
> peer has got all four requests with values 5,6,7,8 and 4 is lost, then
> there would be no message id that can be used to send the notify
> reset_window.
>
