Yaron Sheffer writes:
> Hi Tero,
>
> I was ready to accept your answer, until I came across the following
> sentence in -07.
>
> "Payloads are processed in the order in which they appear in an IKE
> message by invoking the appropriate processing routine according to
> the "Next Payload" field in
> -Original Message-
> From: Valery Smyslov [mailto:sva...@gmail.com]
> Sent: Friday, January 22, 2010 20:55
> To: Yaron Sheffer; Tero Kivinen
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] IKEv2-bis, comments up to 2.16
>
> Hi Yaron,
>
> > Hi Tero,
> &g
Hi Yaron,
Hi Tero,
I was ready to accept your answer, until I came across the following
sentence in -07.
"Payloads are processed in the order in which they appear in an IKE
message by invoking the appropriate processing routine according to the
"Next Payload" field in the IKE header and su
osite (that payload order doesn't matter)?
Thanks,
Yaron
> -Original Message-
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Wednesday, January 20, 2010 18:29
> To: Yaron Sheffer
> Cc: ipsec@ietf.org
> Subject: RE: [IPsec] IKEv2-bis, comments up to 2.1
At 11:08 AM +0200 1/21/10, Tero Kivinen wrote:
>Yaron Sheffer writes:
>> > 1.4.1: the last paragraph springs a surprise by defining the behavior
>> > of IKE SA deletion while discussing an unlikely "messing up" of Child
>> > SAs. IKE SA deletion deserves its own subsection.
>> >
>> > [[ Response: i
Yaron Sheffer writes:
> > 1.4.1: the last paragraph springs a surprise by defining the behavior
> > of IKE SA deletion while discussing an unlikely "messing up" of Child
> > SAs. IKE SA deletion deserves its own subsection.
> >
> > [[ Response: it is optional behavior and makes sense. If you want
Hi Paul,
Thanks for rejecting my issues so quickly :-) Please see some comments below. I
have deleted issues where I accept the rejection.
Yaron
> -Original Message-
>
> =
> 1.4.1: the last paragraph springs a surprise by defining the behavior
> of IKE SA deletion while dis
Thanks for the in-depth review; I expect we will hear more for sections after
2.16. I have incorporated all the editor comments and opened issues for many of
the technical ones. Here is my list of ones that I have rejected; it does not
include ones that Tero responded to and you agreed to drop.
Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Wednesday, January 20, 2010 18:29
> To: Yaron Sheffer
> Cc: ipsec@ietf.org
> Subject: RE: [IPsec] IKEv2-bis, comments up to 2.16
>
> Yaron Sheffer writes:
[snip]
>
> > > > 2.8.2: we should add a sentence on what happens if
Yaron Sheffer writes:
> > > 1.4: "The processing of an INFORMATIONAL exchange is determined by
> > > its component payloads." Adding "The payloads are processed in
> > > strict left-to-right order" would make it deterministic, and is
> > > probably what people do today.
> >
> > There should be no
Hi Tero, thanks for your response. Some comments below.
Yaron
> -Original Message-
> From: Tero Kivinen [mailto:kivi...@iki.fi]
> Sent: Wednesday, January 20, 2010 14:22
> To: Yaron Sheffer
> Cc: ipsec@ietf.org
> Subject: [IPsec] IKEv2-bis, comments up t
I only commented to those cases where I disagreed with you (mostly I
think we do not need to make the change). The other comments were ok
for me.
Yaron Sheffer writes:
> 1.3.2: for some reason we support negotiation of DH parameters when
> rekeying the IKE SA. So we should say that the INVALID_KE_
Abstract: "It replaces" -> "This specification replaces" (otherwise "it" could
refer to the protocol itself).
1: Remove bracketed first paragraph of the Introduction.
1: "IKE message flow" -> "An IKE message flow".
1.1.3: "IPsec- protected" - remove space.
1.2: in the table, add "IKE header (n
13 matches
Mail list logo
