A cooperative's monitoring platform needs to poll interface statistics from POP routers but should never be able to push configuration changes through SNMP. How should the SNMP community be configured?

Setting a Junos SNMP community's authorization explicitly to read-only restricts that community strictly to retrieval operations, with no ability to perform set operations that would alter device configuration or state. This is exactly the safeguard needed for a monitoring platform that should observe interface statistics without ever being able to push changes. Junos does treat an SNMP community as read-only when the authorization keyword is left off, but relying on that implicit default is poor practice for a security-relevant setting: the intent is invisible in the configuration, and a default can shift across releases or be misread by the next engineer who edits the stanza. Setting authorization read-only explicitly makes the access level a documented, deliberate fact rather than an assumption. A community name carries no permission semantics of its own — a well-known string like "public" is not magically read-only by Junos; permission comes entirely from the authorization keyword, and assuming otherwise is a common and dangerous misconception. Configuring read-write authorization and trusting the monitoring software to behave is not access control at all; if the community string were ever discovered or reused elsewhere, a read-write community offers no technical barrier to a write. SNMP communities have nothing to do with authentication-order, which governs administrative login authentication methods such as radius and password, an entirely separate configuration hierarchy from SNMP's own access model. A sound operational practice is to also restrict which source addresses can use the community, in addition to setting it read-only, further narrowing who can query the device at all.