Hi Steffen, > Hi, > > I've read the document and I support it. > > One nit: > > The document talkes about 'anti-replay protection' which sounds a bit odd. We > protect against replay, not anti-replay. > > ESP RFC 4303 talkes about 'anti-replay service' or just 'anti-replay'. > Maybe the document can be aligned with terms used in ESP.
I'm all for aligning this document with RFC 4303 (especially if currently used terms may confuse readers). But I checked RFC 4303 - it uses: - anti-replay service (8 times) - anti-replay mechanism (2 times) - anti-replay feature (2 times) - anti-replay protection (2 times) --- sic! - anti-replay (as a noun, 10 times) The question is - what term is best to use. Perhaps we should use different terms in different contexts (e.g., anti-replay service as a 'thing', that the receiver turns on/off and anti-replay feature as an ability to enable that service)? Amy suggestions? Regards, Valery. > Steffen > > On Fri, Dec 06, 2024 at 02:17:30AM +0200, Tero Kivinen wrote: > > As we talked earlied when doing g-ikev2 IETF last call, the text > > talking about renaming ESN transform type got separated to this new > > draft, and this will start one (1) week working group last call of the > > draft. > > > > I try to make this fast so it can catch up the g-ikev2 draft (which is > > in IETF LC until 2024-12-10), so unless we get objections during WGLC, > > I will request publication of ths draft almst immediately after the > > WGLC ends. > > > > Send your comments about the draft to the ipsec list before > > 2024-12-13. > > -- > > kivi...@iki.fi > > > > _______________________________________________ > > IPsec mailing list -- ipsec@ietf.org > > To unsubscribe send an email to ipsec-le...@ietf.org > > _______________________________________________ > IPsec mailing list -- ipsec@ietf.org > To unsubscribe send an email to ipsec-le...@ietf.org _______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
