[lamps] Spencer Dawkins' No Objection on draft-ietf-lamps-rfc5280-i18n-update-03: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-lamps-rfc5280-i18n-update-03: 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-lamps-rfc5280-i18n-update/



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

You folks would know best what's actually clear to your intended audience, but
the use of  "provide clarity on the handling of" in the Abstract,

   These updates to RFC 5280 provide clarity on the handling of
   Internationalized Domain Names (IDNs) and Internationalized Email
   Addresses in X.509 Certificates.

and in the first paragraph of the Introduction,

   This document updates RFC 5280 [RFC5280].  The Introduction in
   Section 1, the Name Constraints certificate extension discussion in
   Section 4.2.1.10, and the Processing Rules for Internationalized
   Names in Section 7 are updated to provide clarity on the handling of
   Internationalized Domain Names (IDNs) and Internationalized Email
   Addresses in X.509 Certificates.

wasn't particularly helpful to me.  Are there a few words that would describe
(at a high level) what the problem with RFC 5280 was, that required this
document (I'm suggesting saying "so if you implemented RFC 5280, you can expect
problems A and B, so you probably want to implement this specification as
well", but in different words)?