Stephen Farrell has entered the following ballot position for draft-ietf-precis-framework-16: 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 http://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: http://datatracker.ietf.org/doc/draft-ietf-precis-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - 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:-) _______________________________________________ precis mailing list [email protected] https://www.ietf.org/mailman/listinfo/precis
