.ll 72
.po 0
.nr sf 1
.nr tf 1
.m1 0
.m2 0
.m3 0
.m4 0
.nr fm 0
.de $0
.(x t
\\$2 \\$1
.)x
..
.nh
.na
.lp
.nf
-- If not already present for other reasons, then add in the overview
-- or introduction section:
.fi
.lp
.in 3
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in BCP 14,
RFC 2119 [RFC2119].

.sh 1 "Security Considerations"
.lp
.nf
-- if you have any read-write and/or read-create objects, please
-- describe their specific sensitivity or vulnerability.
-- RFC 2669 has a very good example.
.fi
.lp
.in 3
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create.  Such
objects may be considered sensitive or vulnerable in some network
environments.  The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations.  These are the tables and objects and their
sensitivity/vulnerability:
.lp
.in 4
<list the tables and objects and state why they are sensitive>
.lp
-- else if there are no read-write objects in your MIB module
.lp
.in 3
There are no management objects defined in this MIB module that have
a MAX-ACCESS clause of read-write and/or read-create.  So, if this
MIB module is implemented correctly, then there is no risk that an
intruder can alter or create any management objects of this MIB
module via direct SNMP SET operations.
.lp
.nf
-- for all MIB modules you must evaluate whether any readable objects 
-- are sensitive or vulnerable (for instance, if they might reveal
-- customer information or violate personal privacy laws such as
-- those of the European Union if exposed to unathorized parties)
.fi
.lp
.in 3
Some of the readable objects in this MIB module (i.e., objects
with a MAX-ACCESS other than not-accessible) may be considered
sensitive or vulnerable in some network environments.  It is thus
important to control even GET and/or NOTIFY access to these objects
and possibly to even encrypt the values of these objects when
sending them over the network via SNMP.  These are the tables and
objects and their sensitivity/vulnerability:
.lp
.in 4
<list the tables and objects and state why they are sensitive>
.lp
.in 3
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPsec),
even then, there is no control as to who on the secure network
is allowed to access and GET/SET (read/change/create/delete) the
objects in this MIB module.
.lp
.in 3
It is RECOMMENDED that implementers consider the security features
as provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms
(for authentication and privacy).
.lp
.in 3
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security.  It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to
an instance of this MIB module is properly configured to give
access to the objects only to those principals (users) that have
legitimate rights to indeed GET or SET (change/create/delete) them.

.sh 1 "Normative References"
.ip [RFC2119] 12
Bradner, S., \*(lqKey words for use in RFCs to Indicate
Requirement Levels\*(rq`, BCP 14, RFC 2119, March 1997.

.sh 1 "Informative References"
.ip [RFC3410] 12
Case, J., Mundy, R., Partain, D. and B. Stewart, \*(lqIntroduction
and Applicability Statements for Internet-Standard Management
Framework\*(rq, RFC 3410, December 2002.