Issue 2: replacement text for secure management protocol boilerplate

Hi,

The IETF has been in the process of changing from a managenent
strategy that basically said "write a MIB" (and presumably use SNMP to
access it) to a strategy that says "consider the nature of the
management functionality required, and select an appropriate protocol
to address the requirements. I think the existing boilerplate should
be modified to reflect this change.

OLD:
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.

   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).

   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.

NEW:
Any protocol used to manage a device should support authentication,
encryption, integrity checking, and control of access to the
management information. It is RECOMMENDED that operators deploy an
IETF standard protocol for secure management, such as Netconf over SSH
[RFC4742] or SNMPv3 [RFC3410] or syslog over TLS [RFC5425].  Operators
SHOULD enable cryptographic security and ensure that the server/agent
giving access to management information is properly configured to give
access only to those principals (users) that have legitimate rights to
read/create/change/delete the information. 

David Harrington
[email protected]
[email protected]
[email protected]