Document: draft-ietf-opsawg-rfc5706bis Title: Guidelines for Considering Operations and Management in IETF Specifications Reviewer: Harald Alvestrand Review result: Ready with Issues
Summary: Ready with issues To the degree of this reviewer's competence, this document seems adequate. A few issues that should be addressed before completion, and a few nits. Issues: “Monitoring the service” (5.7.4) could be better - in particular, monitoring a service should be monitoring that the service is actually useful for users - we’ve seen examples of failures that haven’t been detected because the monitoring of the service failed to monitor that the users could actually get work done. This part may be out of scope to delve further into in this document, but worth mentioning as an “also remember that…” Section 9 says “The security implications of password-based authentication should be taken into account” sounds much too weak. Better would be something like “The authentication mechanisms recommended for new protocols or extensions should provide adequate security; for instance, pure password-based authentication is rarely an adequate level of security.” Appendix A A Checklist - the relationship between this and [CHECKLIST] doesn’t seem to be carefully explained. Seems like appendix A is a snapshot of the github checklist? If so, this info should go into section 1, where [CHECKLIST] is first mentioned. Nits: 4.3 seems to use "incrementally deployable" to refer to deploying only some features of a protocol. This seems like an unusual usage of that term - normally, this refers to the state of "some users do, some users don't". When considering transition, might want to mention that transitioning between security mechanisms can be hard, but leaving stuff in an open or less-protected state during the transition is not a desirable approach. The example of SMTP is bad, since reverse DNS lookup is not a protocol requirement, it is a type of spamfilter input - it should be described as "when Berkeley installed a spamfilter using a reverse DNS lookup, the following bad thing happened". BCP166 isn't really the right reference for internationalization - it's a terminology source. Note that translation of message formats requires that the language of the end consumer is known - this can be hard. NETCONF is mentioned in section 5 without an RFC reference. Define on first use. RFC 3535 reference to "IAB workshop" fails to mention what IAB workshop - should be "IAB Network Management Workshop". That should be enough.... go for it! _______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
