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

[Valery Smyslov <[e-mail]>]

Hi Adam,

> Adam Roach 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:
> ----------------------------------------------------------------------
> 
> 
> Thanks for the work done on this protocol extension. I only have two
> relatively minor comments.
> 
> ---------------------------------------------------------------------------
> 
> §5.1:
> 
> >  It is anticipated
> >  that later standards will extend this technique to allow dynamically
> >  changing PPK values.
> 
> It's likely that future specifications will extend the technique even before
> becoming standards. Consider changing "standards" to "specifications."

OK, makes sense.

> ---------------------------------------------------------------------------
> 
> §5.1:
> 
> >     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 /.
> 
> This is a little confusing, since the base64 character set has 65 characters
> in it (the 64 cited, plus '='). If the omission of '=' is intentional,
> please add a short statement indicating so -- otherwise, implementors may
> assume that its omission is unintentional and include it in their IDs. To
> the extent that the problem describes arises in the field, this has the
> potential to cause cause similar issues.

The omission was unintentional, we'll add '=' to the list of characters.

Thank you,
Valery.