There are no management objects defined in this these MIB module modules 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.

   Some of the readable objects in this these MIB module modules (i.e., objects with
   a MAX-ACCESS other than not-accessible) may be considered sensitive
   or vulnerable in some network environments.  This includes INDEX
   objects with a MAX-ACCESS of not-accessible, and any indices from
   other modules exposed via AUGMENTS.  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:

    <list

   o  the l2L3VpnMcastPmsiTunnelAttributeTable collectively shows the
      P-tunnel network topology and its performance characteristics.
      For instance, l2L3VpnMcastPmsiTunnelAttributeId in this table will
      contain the identifier that uniquely identifies a P-tunnel.  This
      identifier may be composed of source and multicast group IP
      addresses.  l2L3VpnMcastPmsiTunnelPointer and
      l2L3VpnMcastPmsiTunnelIf will point to the corresponding entries
      in other tables containing configuration and/or performance
      information of a P-tunnel and its interface.  If an Administrator
      does not want to reveal this information, then these objects and state why they are sensitive>
      should be considered sensitive/vulnerable.

   SNMP versions prior to SNMPv3 did not include adequate security.
   Even if the network itself is secure (for example by using IPsec),
   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.

   Implementations SHOULD provide the security features described by the
   SNMPv3 framework (see [RFC3410]), and implementations claiming
   compliance to the SNMPv3 standard MUST include full support for
   authentication and privacy via the User-based Security Model (USM)
   [RFC3414] with the AES cipher algorithm [RFC3826].  Implementations
   MAY also provide support for the Transport Security Model (TSM)
   [RFC5591] in combination with a secure transport such as SSH
   [RFC5592] or TLS/DTLS [RFC6353].

   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.