Early Review of draft-ietf-opsawg-rfc5706bis-01
review-ietf-opsawg-rfc5706bis-01-artart-early-alvestrand-2026-01-26-00

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!