[IPsec] Martin Vigoureux's No Objection on draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

[Martin Vigoureux via Datatracker <[e-mail]>]

Martin Vigoureux has entered the following ballot position for
draft-ietf-ipsecme-qr-ikev2-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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ipsecme-qr-ikev2/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

It seems to me there are places where 2119/8174 keywords would make sense.
Few examples, with suggestions:
   If the initiator is configured to use a post-quantum preshared key
   with the responder (whether or not the use of the PPK is mandatory),
   then it will include a notification USE_PPK in the IKE_SA_INIT
   request message as follows:
>>MUST include

   If the initiator needs to resend this initial message with a cookie
   (because the responder response included a COOKIE notification), then
   the resend would include the USE_PPK notification if the original
   message did.
>>MUST (or SHOULD?) include
by the way, if it is a resend of the message described in the paragraph above,
then "if the original message did" seems superfluous.

   Otherwise the responder replies with the IKE_SA_INIT message including a
   USE_PPK notification in the response:
>>MUST reply

      initiator and the responder.  The responder can use the PPK_ID to
      look up the corresponding PPK value.  Not all implementations are
      able to configure arbitrary octet strings; to improve the
      potential interoperability, it is recommended that, in the
      PPK_ID_FIXED case, both the PPK and the PPK_ID strings be limited
      to the base64 character set, namely the 64 characters 0-9, A-Z,
      a-z, + and /.
>>RECOMMENDED

   values 3-127 are reserved for IANA;
Maybe it's just because I'm not used to that wording, but why "reserved for
IANA" ?  The table seems to qualify them as unassigned.