Hi Peny,
Thank you for reviewing this draft. Please see my comments below.
Regards,
Yaron
> -Original Message-
> From: ipsec-boun...@ietf.org [mailto:ipsec-boun...@ietf.org] On Behalf Of
> Peny Yang
> Sent: Wednesday, September 02, 2009 17:18
> To: i...@ietf.org
> Cc: IPsecme WG
In a recent append Tero said:
>Then the responder is already going against the RFC4306 which says
>"Certificate revocation checking must be considered during the
>chaining process used to select a certificate. " meaning the responder
>cannot send certifiate which itself considers revoced. Only ca
Sorry, I should cc IPsec mail list. Comments are sent again.
Hi, floks:
I have two comments on the draft of IKEv2 Session Resumption:
1) Sorry, I have to talk about my concern on the new
IKE_SESSION_RESUME. In WG last call, actually I made this comment.
However, no feedback was given, maybe beca
Yoav Nir writes:
> > Yes, altought I think most of the implementations do not bother
> > sending INFORMATIONAL requests when IKE_AUTH response has errors. I
> > think most implementations will then simply remove the IKE SA as
> > failed without any further communications to the other end
>
> But w
naoyoshi ueda writes:
> According to ikev2bis-04 section 2.1:
> > A retransmission from the initiator
> > MUST be bitwise identical to the original request. That is,
> > everything starting from the IKE Header (the IKE SA Initiator's SPI
> > onwards) must be bitwise identical; items before
