PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols
draft-ietf-precis-framework-23
Yes
(Barry Leiba)
(Pete Resnick)
No Objection
(Adrian Farrel)
(Alia Atlas)
(Alissa Cooper)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Richard Barnes)
(Ted Lemon)
Note: This ballot was opened for revision 22 and is now closed.
Barry Leiba Former IESG member
Yes
Yes
(for -22)
Unknown
Pete Resnick Former IESG member
Yes
Yes
(for -22)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(for -22)
Unknown
Alia Atlas Former IESG member
No Objection
No Objection
(for -22)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -22)
Unknown
Brian Haberman Former IESG member
No Objection
No Objection
(for -22)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -22)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(for -22)
Unknown
Kathleen Moriarty Former IESG member
No Objection
No Objection
(2015-02-18 for -22)
Unknown
Thanks for your work on this draft, it reads very well! Thanks for addressing the prior SecDir review comments: https://www.ietf.org/mail-archive/web/secdir/current/msg04732.html
Richard Barnes Former IESG member
No Objection
No Objection
(for -22)
Unknown
Spencer Dawkins Former IESG member
No Objection
No Objection
(2015-02-17 for -22)
Unknown
A nit: b. Comparing two output strings to determine if they equivalent, ^are typically through octet-for-octet matching to test for "bit- string identity" (e.g., to make an access decision for purposes of authentication or authorization as further described in [RFC6943]).
Stephen Farrell Former IESG member
No Objection
No Objection
(2015-02-19 for -22)
Unknown
Last time this came around I had the comments below. While Barry no longer has a DISCUSS, I'd still be interested in chatting a bit about these. (Apologies that I've not had time to re-read the draft though, so feel free to just tell me these comments are OBE if that's the case.) " - I agree with Bary's discuss - it seems weird to not have the initial registries in hand when the RFC is being issued. People will, I guess, implement from Appendix A here anyway, so why not either delete this and get the registry in place, or else make Appendix A be the initial registry content. 7.7: This uses the empty set, which is puzzling. I think you mean that this set is to be populated by the DE in the IANA registries but if so, saying so would be good. 10.5: This says that a) its all too hard but also b) "Nevertheless, specifications for application protocols that use this framework MUST describe how confusable characters can be abused to compromise the security of systems that use the protocol in question, along with any protocol-specific suggestions for overcoming those threats." That seems like a 6919 MUST (but we know you won't) to me. Is that a good plan? 10.6: Prompted by the secdir review, it might be worth a few words on password hashing, which is very common. E.g. say that the canonical form is input to hashing and therefore just can't be mucked about with. (But say that nicely:-) "
Ted Lemon Former IESG member
No Objection
No Objection
(for -22)
Unknown