RE: Review: IESG Agenda and Package for January 22, 2004 Telechat

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

Actually, even better:

OLD: 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: 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 
   instances of these MIB modules 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.

Regards,

Dan



> -----Original Message-----
> From: owner-mreview@ops.ietf.org 
> [mailto:owner-mreview@ops.ietf.org]On Behalf Of Romascanu, Dan (Dan)
> Sent: 21 January, 2004 3:15 PM
> To: Wijnen, Bert (Bert); Mreview (E-mail)
> Subject: RE: Review: IESG Agenda and Package for January 22, 
> 2004 Telechat
> 
> 
> A couple of nits wrt. draft-ietf-rohc-mib-rtp-09.txt. As the 
> document deals with three MIB modules, the Security 
> Considerations boilerplate needs to be amended to reflect 
> this i.e. plural 'these MIB modules' instead of 'this MIB module'.
> 
> So, in Security Considerations:
> 
> 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.
> 
> NEW: 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 these MIB modules.
> 
> as well as:
> 
> OLD: 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: 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 these MIB modules 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.
> 
> Regards,
> 
> Dan
> 
> 
>  
> 
>