Ballot for draft-ietf-lamps-rfc5280-i18n-update
Yes
No Objection
Note: This ballot was opened for revision 03 and is now closed.
I had the same question as Spencer -- I'd be interested to know what lack of clarity was (so that people who were unclear, and read this will know what they might have guessed at!). I'm really not knowledgable in this field, so feel free to ignore if this would have been obvious to anyone reading 5280...
Thanks for addressing my DISCUSS.
-1.1: Please consider using the boilerplate from 8174. There's at least at least one use of a lower-case "should" (in 7.5.1, last paragraph).
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)?