Thanks for that quick work. If you want me to take a peek at the changes before the I-D submission window opens, I can do that. (either in github or as a diff). Otherwise, I'll wait until the window opens.
Deb On Fri, Mar 7, 2025 at 3:00 AM Valery Smyslov <s...@elvis.ru> wrote: > HI William, > > > > (as the shepherd of this document) Thank you Deb for your review. > > > > I agree with all these comments. > > > > One suggestion for this one: > > > Appendix A, last paragraph: 'PPK stuff', maybe 'PPK messages'? > > I wonder if “messages” is the correct word as it means the whole request > or response packet to me. > > Maybe ‘the PPK related payloads can be piggybacked with other payloads ’? > > > > Thank you for this proposed text, I’ll use it. > > > > Regards, > > Valery. > > > > Regards & Thanks！ > > Wei PAN (潘伟) > > > > *From:* Deb Cooley <debcool...@gmail.com> > *Sent:* Friday, March 7, 2025 4:41 AM > *To:* draft-ietf-ipsecme-ikev2-qr-alt.auth...@ietf.org > *Cc:* ipsecme-cha...@ietf.org; ipsec@ietf.org > *Subject:* [IPsec] AD comments on draft-ietf-ipsecme-ikeve-qr-alt > > > > Thanks to Valery for writing this draft, apologies for the delay. I was > hoping to beat the I-D submission cutoff, but I didn't make it. > > > > I did spend some time mapping out the differences in how the key > development works in all three versions: RFC 7296, RFC8784 and this > draft. They are related, but different in all three places. I think I see > why it is done the way it is, including a way to rekey the SA without > tearing down the whole connection. [I'm happy take comments from those > whose crypt background is less rusty than my own.] > > > > Specific comments: We might need to work on these a bit. Most are > readability comments. > > > > Abstract, para 2: Remove the word 'Besides,'. Last sentence, change to, > 'This specification defines a way to use PPKs in active IVKv2 SAs for > creating additional IPsec SAs and rekey operations. (I'm not sure how much > this helps, it is pretty awkward.) > > Introduction, para 1, sentence 2, 4, last phrase: add/change some text to > make it flow better, 'An extension...', 'post-quantum security is defined', > 'IPsec traffic that mostly needs protecting, (albeit it wouldn't provide > protection of the identity of the peers). > > Introduction, para 3, QKD sentence: 'for example via the use of Quantum > Key Distribution (QKD). > > Section 3.1.1, para 2, first sentence: I don't understand this sentence, > 'computed differently compared to use PPKs'... maybe 'computed differently > to how PPKs are used in IKE_AUTH', but I'm not sure. > > Section 3.2, para 1: 'peers MAY use this PPK' to 'peers MAY use this > fresh PPK'. > > Section 3.2, Figure 2: What is 'Nir'? Maybe a typo for 'Nr'? Or > something else. > > Appendix A, last paragraph: 'PPK stuff', maybe 'PPK messages'? > > General: There are a handful of pointers back to the g-ikev2 draft. Just > be sure that the naming that was changed late in the process has made it > into this draft. For example, GSA_AUTH - I don't remember if that was new, > old, or unchanged. > > > > Deb > > >
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
