Thank you Derrel. Getting to this a little late.
All your comments will be addressed in the next iteration. We will add some clarification text to clear up your points about rfc6023. About rfc6030 we will make clear that this out of scope of this doc or IKE, but it will just be an informative reference. Panos -----Original Message----- From: IPsec [mailto:[email protected]] On Behalf Of Derrell Piper Sent: Friday, August 18, 2017 4:56 PM To: [email protected] WG <[email protected]> Subject: Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue Notes on draft-fluhrer-qr-ikev2-04, mostly nits: pp. 1 "...pose a serious challenge to cryptography algorithms [deployed?] widely today." pp. 2 "when might one be implemented" -> "when one might be implemented" pp. 3 The Changes section wording confuses me. Does that mean, relative to the last draft? Or does it mean those were the change in -03? pp. 4 "...then it must check if has a..." -> "...if it has a..." pp. 8 "Algorithm=urn:ietf:params:xml:ns:keyprov:pskc:pin" RE: rfc6030, any chance we can not refer to an RFC with XML in it? I strongly object to XML. Does IKEv2 reference any XML? (sticks fingers in ears...) pp. 9 RE: rfc6023 text I would prefer text here that suggests exactly how to achieve post-quantum ID confidentiality. This is vague and that means people will implement it all over the map. I also don't think Child SAs should ever have been made mandatory, so refering to rfc6023 is fine. Overall, I think this document should advance. This is nice and simple, more or less. Derrell _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
