Subject: Newly updated draft-ietf-atommib-atm2-19.txt

From: "Faye Ly" <[email-masked]>
Date: Wed, 14 May 2003 06:38:46 -0700

Hi,

Please see attached. This version of the draft fixes the following
comments from Kaj.  The changes are all editorial. -faye

> >thank you for putting up with the delay; 
> >technically the draft-19 looks fine but i stumbled over a few nits: 
> >- some figures still have page breaks in them 
> >- i dont know whether the dates on the document has to be in 
> lock-step 
> >with 
> > the LAST-UPDATED/REVISION timestamps, but if you make 
> changes then 
> > do that one as well 
> >- the Full Copyright notice in the back has the wrong year 
> >- i think you forgot to paste in the text for the security section 
> > (it looks like the common boilerplate). attached is the text i 
> >thought of. 
> > 
> >thats it, otherwise ready to move. faye, i take it you make these 
> >changes? 
> > 
> >kaj 
> > 
> >------------------------------------------------------------- 
> >8. Security Considerations 
> > 
> >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 (all tables have a MAX-ACCESS clause of 
> >read-write and/or read-create unless otherwise noted): 
> > 
> >Table Sensitivity/vulnerability 
> >1. atmSvcVpCrossConnectTable Deletion of VP cross-connects 
> >2. atmSvcVcCrossConnectTable Deletion of VC cross-connects 
> >3. atmSigStatTable Signaling read-only statistics 
> >4. atmSigSupportTable Signaling configuration params 
> >5. atmSigDescrParamTable Signaling configuration params 
> >6. atmIfRegisteredAddrTable Interface address table 
> >7. atmVclAddrTable VCL/Address mapping table 
> >8. atmAddrVclTable Reverse VCL/Address mapping table 
> > (read-only) 
> >9. atmVplStatTable VPL statistics (read-only) 
> >10. atmVplLogicalPortTable VPL logical port configuration 
> >11. atmVclStatTable VCL statistics (read-only) 
> >12. atmAal5VclStatTable AAL5 statistics (read-only) 
> >13. atmVclGenTable Signaling configuration 
> >14. atmInterfaceExtTable Interface configuration params 
> >15. atmIlmiSrvcRegTable ILMI config params 
> >16. atmIlmiNetworkPrefixTable ILMI config params 
> >17. atmSwitchAddressTable Switch address info 
> >18. atmVpCrossConnectXTable VP cross-connect params 
> >19. atmVcCrossConnectXTable VC cross-connect params 
> >20. atmCurrentlyFailingPVplTable PVPL status info (read-only) 
> >21. atmCurrentlyFailingPVclTable PVCL status info (read-only) 
> > 
> >Some of the readable objects in this MIB module (i.e., objects with a

> >MAX-ACCESS other than not-accessible; see list above) 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. 
> > 
> >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. 
> >

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 14 May 2003 18:08:24 +0200 (CEST)

Does this mean the draft is ready for IETF last call?
(You presumably need to send it to internet-drafts as well.)

  Erik