Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames
RFC 8266

Note: This ballot was opened for revision 07 and is now closed.

(Ben Campbell) Yes

(Terry Manderson) Yes

(Alexey Melnikov) Yes

(Adam Roach) Yes

Comment (2017-07-05 for -08)
No email
send info
I like the clear explanation of some of the design choices in here (e.g., the rationale for using NFKC).

There are two places that I think a slight bit of additional text might be useful:

1. When talking about processing "each string" in section 2.4, it's probably worth noting that implementations should be careful not to assume that any information received from a wire protocol has necessarily had any of the rules in this document applied to it (as this might allow intentionally noncompliant clients to slip certain kinds of shenanigans past their checks); and

2. Where the final paragraph of section 4 indicates that the operations in this document are not necessarily idempotent, it is probably worth being more explicit that they should be applied repeatedly until the output string is stable; or, if the string does not stabilize after a reasonable number of iterations (is this possible?), that it should be rejected as invalid.

(Alia Atlas) No Objection

Deborah Brungard No Objection

(Benoît Claise) No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

(Suresh Krishnan) No Objection

Warren Kumari No Objection

Comment (2017-07-04 for -08)
No email
send info
This is wildly outside my area of expertise -- about the only thing I know about PRECIS, Unicode, internationalization and similar is that it is tricky and subtle. 
I'm balloting No Objection with the belief that the author and AD understand this stuff :-)

I would like to point out the OpsDir review from Nevil: (which, I see, you have already responded to).

(Mirja Kühlewind) No Objection

(Kathleen Moriarty) No Objection

(Eric Rescorla) No Objection

Alvaro Retana No Objection