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

[Panos Kampanakis (pkampana)]

Thanks Alexey. The text will now read 

  [...] both the PPK and the PPK_ID strings be limited
  to the base64 character set, namely the 64 ASCII [RFC0020]
  characters 0-9, A-Z, a-z, + and /.


-Original Message-
From: IPsec  On Behalf Of Alexey Melnikov via
Datatracker
Sent: Tuesday, January 07, 2020 1:16 PM
To: The IESG 
Cc: ipsec@ietf.org; ipsecme-cha...@ietf.org; david.walterm...@nist.gov;
draft-ietf-ipsecme-qr-ik...@ietf.org
Subject: [IPsec] Alexey Melnikov's No Objection on
draft-ietf-ipsecme-qr-ikev2-10: (with COMMENT)

Alexey Melnikov 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:
--

Thank you for this document. One small suggestion below:

5.1.  PPK_ID format

   o  PPK_ID_FIXED (2) - in this case the format of the PPK_ID and the
  PPK are fixed octet strings; the remaining bytes of the PPK_ID are
  a configured value.  We assume that there is a fixed mapping
  between PPK_ID and PPK, which is configured locally to both the
  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 /.

In order to avoid any doubt, I suggest you make it clear that you mean ASCII
encoding here. For this you should add a normative reference to RFC 20 in
the last quoted sentence.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


smime.p7s
Description: S/MIME cryptographic signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Alexey Melnikov via Datatracker]

Alexey Melnikov 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:
--

Thank you for this document. One small suggestion below:

5.1.  PPK_ID format

   o  PPK_ID_FIXED (2) - in this case the format of the PPK_ID and the
  PPK are fixed octet strings; the remaining bytes of the PPK_ID are
  a configured value.  We assume that there is a fixed mapping
  between PPK_ID and PPK, which is configured locally to both the
  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 /.

In order to avoid any doubt, I suggest you make it clear that you mean ASCII
encoding here. For this you should add a normative reference to RFC 20 in the
last quoted sentence.


___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec