On Tue, 12 Mar 2019, Tommy Pauly wrote:
Thanks for writing this up! Glad to get rid of IKEv1 =)
We just need PPK and Labeled IPsec as RFC and then we are go :)
I do have a question regarding whether the deprecations for the IKEv2 registry
are appropriate for this document. RFC 8247
I am now setting up the agenda for IETF 104, so if you have any
presentation etc you want to present there (and I have not yet sent
email to you about it), send requests to us chairs
as soon as possible (i.e., before the end of
THIS week i.e., before 2019-03-15).
--
kivi...@iki.fi
This document has been stable for some time, and I think it is ready
to go forward. Because of that I will start one week long WG
adoptation call for this draft which will expire end of next week
(2019-03-22).
If you have any reasons why this should not be adopted as WG document,
send email to
The IPSECME WG has placed draft-smyslov-ipsecme-ikev2-aux in state
Call For Adoption By WG Issued (entered by Tero Kivinen)
The document is available at
https://datatracker.ietf.org/doc/draft-smyslov-ipsecme-ikev2-aux/
___
IPsec mailing list
Thanks for writing this up! Glad to get rid of IKEv1 =)
I do have a question regarding whether the deprecations for the IKEv2 registry
are appropriate for this document. RFC 8247 contains the recommendations for
the which algorithms and DH groups are going away (SHOULD NOT, MUST NOT, etc),
and
> On Mar 12, 2019, at 10:39, Valery Smyslov wrote:
>
> Hi Chris,
>
>> There are other ways to skin this cat though. :)
>>
>> One option is that instead of sending a new CC info report on the interval
>> timer expiry if we haven't received a
>> response "ack" yet, we simply update the data
> On Mar 12, 2019, at 10:34, Valery Smyslov wrote:
>
> Hi Chris,
>
>> Sure, I'm definitely open to changes, and in particular with the congestion
>> info report. This is just the first
>> draft. :)
>>
>> So my reading of IKEv2 indicated that one way notifications were supported,
>> not
Hi Chris,
> There are other ways to skin this cat though. :)
>
> One option is that instead of sending a new CC info report on the interval
> timer expiry if we haven't received a
> response "ack" yet, we simply update the data (last seq num seen, drop count
> and timestamp) we sent
>
Hi Chris,
> Sure, I'm definitely open to changes, and in particular with the congestion
> info report. This is just the first
> draft. :)
>
> So my reading of IKEv2 indicated that one way notifications were supported,
> not that they were *only* to be
> used for unprotected error notification
