Paul Hoffman writes:
> Section 1.3.1 says "When an IKE SA is not created, the error message
> return SHOULD NOT be encrypted because the other party will not be
> able to authenticate that message." First, this seems out of place,
> since this section talks about CREATE_CHILD_SA for Child SAs.
> S
Paul Hoffman writes:
> At 10:55 AM +0900 12/14/09, Toshihiko Tamura wrote:
> >Hi, I want to check one point.
> >At the last paragraph in Section 2.5, there is a mention of refering
> >the figures in Section 2.
> >Does it mean we should refer all fighres in Section 2?
> >Or does it mistake section 2
Hello all,
A minor technical note about Issue #22. Section 2.25, last paragraph reads:
A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a
request to rekey a Child SA that does not exist. A peer that receives a
CHILD_SA_NOT_FOUND notification SHOULD silently delete the Child
Hi Alper,
2009/12/12 Alper Yegin :
> Hi Hui,
>
>> Hi Alper,
>>
>> It seems that your argument goes to 3GPP only not this new work item,
>> then I would suggest that you propose your solution to 3GPP HNB.
>
> We are having this discussion in IETF right now. So, there is no point in
> telling us to
At 2:49 PM +0200 12/14/09, Tero Kivinen wrote:
>BTW, I think that change is one of the significant changes we should
>list in the RFC4306, i.e. following the payload order of the figures
>in section 2 is no longer MUST, it is now SHOULD (and applies to
>figures in section 1 too).
Quite right. I re
At 2:26 PM +0100 12/14/09, Matthew Cini Sarreo wrote:
>Hello all,
>
>A minor technical note about Issue #22. Section 2.25, last paragraph reads:
>
>A CHILD_SA_NOT_FOUND notification SHOULD be sent when a peer receives a
>request to rekey a Child SA that does not exist. A peer that receives a
>CH
