Hi Tero, thank you for the found typos and leftovers. We'll fix them in the next version (there are also a couple clarifications that we want to add to the document).
Regards, Valery. > While approving the IANA expert request for this document I noticed > some things that might require some fixes to the draft: > > -- > > In section 1.1 (which will be removed) there is typo in PPK_SUUPORT. > > -- > > In section 3 it would be better to use the same format than what is > used in the RFC7296 when using notify payloads with data in it, i.e. > replace > > N(PPK_IDENTITY)(PPK_ID) > > with > > N(PPK_IDENTITY, PPK_ID) > > (see example use in RFC7296 section 2.8.1 or RFC5685). > > -- > > In section 4 there is text saying: > > If the responder has not been upgraded and properly configured, > they will both realize it, and in that case, the link will be > quantum secure. > > I think there is something wrong with that. If the responder is not > upgraded, then link will not be quantum safe. Same if it is not > properly configured. I think it is trying to say that "If the > responder has been upgraded and ..." > > -- > > In appendix A there is text saying: > > By limiting our changes to notifications, and translating the > nonces, it is hoped that this would be implementable, even on > systems that perform much of the IKEv2 processing is in hardware. > > I think the text "translating the nonces" is leftover from old design > and should be changed to reflect the fact that this now changes the > SK_d, SK_pi and SK_pr. > > -- > [email protected] > > _______________________________________________ > IPsec mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
