adoption of the draft as well (there is a newer -08
version).
Regards,
Vukašin Karadžić
уто, 22. авг 2023. у 21:01 је написао/ла:
> Message: 1
> Date: Mon, 21 Aug 2023 21:25:08 +
> From: Rebecca Guthrie
> To: Valery Smyslov , IPsecME WG
> Cc: "ipsec-cha...@ietf.org&q
I support adoption as well.
Regards,
Vukašin
Date: Mon, 27 Nov 2023 14:20:42 -0500 (EST)
> From: Paul Wouters
> To: Tero Kivinen
> Cc: ipsec@ietf.org
> Subject: Re: [IPsec] WG Adoption call for
> draft-smyslov-ipsecme-ikev2-qr-alt
> Message-ID: <83fa6733-93fc-b282-d64e-cac6aaf8c...@noha
Hi Valery,
While updating the code logic to the latest version of the draft some
questions came up to me:
1. Assume the initiator and responder both already support RFC 8784.
If the initiator sends USE_PPK_ALT notify, and does not support
IKE_INTERMEDIATE exchange, will the initiator and responde
Hi Valery,
уто, 25. јун 2024. у 10:45 Valery Smyslov је
написао/ла:
> Hi Vukašin,
>
>
>
> Hi Valery,
>
>
>
> While updating the code logic to the latest version of the draft some
> questions came up to me:
>
>
>
> 1. Assume the initiator and responder both already support RFC 8784.
>
> If the in
As someone who implemented both RFC8784 and the new alternative approach, I
want to say I agree with Valery in the point below:
1. The code logic is simpler, and easier to follow and verify, with having
this separate notification type (the PPK code logic is already quite
complicated).
2. My intuit
