Hello Valery,
TL;DR: Thanks for your reply and your comments. I agree with them ;-)
If you want a more detailed reply, then look for EV> below
Regards
-éric
On 29/11/2022, 18:47, "Valery Smyslov" <s...@elvis.ru> wrote:
Hi Éric,
thank you for your comments. Please see inline.
> -----Original Message-----
> From: Éric Vyncke via Datatracker [mailto:nore...@ietf.org]
> Sent: Tuesday, November 29, 2022 12:38 PM
> To: The IESG
> Cc: draft-ietf-ipsecme-ikev2-multiple...@ietf.org;
ipsecme-cha...@ietf.org; ipsec@ietf.org;
> kivi...@iki.fi; kivi...@iki.fi; charl...@computer.org; g...@apnic.net
> Subject: Éric Vyncke's No Objection on
draft-ietf-ipsecme-ikev2-multiple-ke-10: (with COMMENT)
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ipsecme-ikev2-multiple-ke-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
>
> # Éric Vyncke, INT AD, comments for
draft-ietf-ipsecme-ikev2-multiple-ke-10
> CC @evyncke
>
> Thank you for the work put into this document. Even if my IPsec knowledge
is
> now very dated, I find it relatively easy to read.
Thank you.
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education), and some nits.
>
> Special thanks to Tero Kivinen for the shepherd's write-up including the
WG
> consensus *but* the justification of the intended status is missing.
>
> Other thanks to Geoff Huston for his Last Call DNS directorate review at:
>
https://datatracker.ietf.org/doc/review-ietf-ipsecme-ikev2-multiple-ke-07-dnsdir-lc-huston-2022-10-10/
>
> Please note that Charles Perkins is the Internet directorate reviewer (at
my
> request) and you may want to consider this int-dir reviews as well when
Charles
> will complete the review (no need to wait for it though):
>
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ikev2-multiple-ke/reviewrequest/16618/
>
> I hope that this review helps to improve the document,
>
> Regards,
>
> -éric
>
> ## COMMENTS
>
> Out of all Paul Wouters's points, I support the last one about AH (I am
not
> experience enough to appreciate the other ones). It is also related to
bullet
> 3) of section 2.
I have already commented this in my response to Paul.
So, the document focuses on PQ security, but also has
another application in mind - the ability to combine
several different key exchange methods so, that the resulting
shared secret depends on all of them. This can be useful
without any PQ algorithms - e.g. in a situation
when each of the peers trust only its favorite
key exchange algorithms, so that there is no any single
one that is trusted by the both. In this case the draft
allows to use two, so that each peer will be sure
that its favorite algorithm is used.
EV> indeed, this feature escaped me
In this context AH still may be used
(well, it is not deprecated yet?).
EV> no comment about AH deprecation ;-)
> ### Missing reference RFC 8247
>
> As indicated by idnits tool, RFC 8247 is used as a reference but is not
defined
> ;-)
Ah, we managed to confuse idnits (which in fact is not too difficult) :-)
This document does not reference RFC 8247, but it contains
the text to be placed at the IANA registry page as a Note,
and this text contains a "[RFC8247]", but this reference
is in the context of IANA page :-)
EV> I should have better eyes... sorry
> ### Section 2
>
> The bullet 2) is a nice explanation about *why* there must be multiple key
> exchanges with different methods. Until reading that part, I was really
> wondering why this I-D was about the link with PQC and multiple key
exchanges.
> Should this be mentioned in the abstract already ?
I don't mind, but as far as I know, IESG wants abstract to be short :-)
If you (and other ADs) think it's a good idea, then we'll add this text.
EV> I know about short abstract, but they should also give an idea of the
content & purpose
> Should "FIPS" be prefixed by "USA" as in "USA FIPS" ?
I don't know, rely on my co-authors (actually it seems that
this is a well-known organization outside USA, but formally you are right).
EV> I live a in Federal state as well (Belgium), so while I understand that
FIPS stands for the USA one, let's be inclusive. Up to you and the authors.
> ## NITS
>
> ### Section 1.2
>
> `payloads longer than 64k` suggest to specify the units of measure.
Changed to 64 Kbytes.
Thank you!
The updated PR is available at:
https://github.com/post-quantum/ietf-pq-ikev2/pull/22
Regards,
Valery.
> ## Notes
>
> This review is in the ["IETF Comments" Markdown format][ICMF], You can
use the
> [`ietf-comments` tool][ICT] to automatically convert this review into
> individual GitHub issues.
>
> [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
> [ICT]: https://github.com/mnot/ietf-comments
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
