On Wed, Jun 25, 2008 at 01:41:35PM +1200, Brian E Carpenter wrote: > I have been selected as the General Area Review Team (Gen-ART) reviewer > for this draft (for background on Gen-ART, please see > http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). > Please resolve these comments along with any other Last Call comments > you may receive. > Document: draft-ietf-opsawg-snmp-engineid-discovery-02.txt > Reviewer: Brian Carpenter > Review Date: 2008-06-25 > IETF LC End Date: 2008-06-30 > IESG Telechat date: (if known) > > Summary: Almost ready > > Comments: > > ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226)
easy fix > 5. Security Considerations > ... > If a device configuration permits non-secure SNMPv1/v2c access to a > target system, then reading the snmpEngineID variable of the SNMP- > FRAMEWORK-MIB will also reveal a suitable contextEngineID value for > subsequent SNMPv3 usage. However, implementations should not rely on > non-secure SNMPv1/v2c access and therefore MUST implement this > specification to enable secure contextEngineID discovery. > > This is a little odd, since, as the previous paragraph indicates, > the localEngineID mechanism is not intrinsically secure. I think the > second sentence should be extended to: > > However, implementations should not rely on > non-secure SNMPv1/v2c access and therefore MUST implement this > specification to enable secure contextEngineID discovery whenever > an SNMPv3 security mechanism is in use. The paragraph in question establishes an implementation requirement. Your proposed addition "whenever an SNMPv3 security mechanisms is in use" hints to a deployment decision, which for me does not go along with an implementation requirement. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
