for the Simple Network Management Protocol (SNMPv2)", STD
62, RFC3416, December 2002.
[RFC3417] Presuhn, R., Ed., "Transport Mappings for Version 2 of
the Simple Network Management Protocol (SNMPv2)", STD 62,
RFC3417, December 2002.
[RFC3418] Presuhn, R., Ed., "Management Information Base (MIB) for
Version 2 of the Simple Network Management Protocol
(SNMP)", STD 62, RFC3418, December 2002.
[ASN1] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).
9.2. Informative References
[RFC1908] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework", RFC
1908, January 1996.
[RFC2089] Levi, D. and B. Wijnen, "Mapping SNMPv2 onto SNMPv1
within a bilingual SNMP agent", RFC2089, January 1997.
[RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen,
"Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework",
RFC2576, March 2000.
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC3410, December 2002.
Appendix A. Change Log
A.1. Changes From RFC2576
Section numbers below refer to the old section numbers from RFC2576.
Some section numbers have changed since RFC2576.
- Added text to abstract about conversion of MIBs from SMIv1 to
SMIv2.
- Added note at end of section 1.3 that all discussion of SNMPv2 PDU
types and protocol operations applies to both SNMPv2c and SNMPv3.
- Added text at end of section 1.4 to clarify that there is no such
thing as 'SNMPv3 access to MIB data', as SNMPv3 just uses SNMPv2
PDU types and protocol operations.
- Moved section 1.4 to the beginning of section 4.
- Changed "MUST" to "SHOULD" in item (3) of the first list in
Section 2.1.1 to since unconstrained INTEGER is not actually
illegal in SMIv2.
- Changed "SHOULD" to "MUST" in item (13) of the first list in
Section 2.1.1 to clarify that collecting related objects into
groups is required when translating a MIB module from SMIv1 to
SMIv2.
- Re-organized bullets in section 2.1.1 to improve clarity.
- Changed "SHOULD" to "MUST" in items (1) and (2) of Section 2.3
since those updates are indeed required when translating a
capabilities statement from the language defined by RFC1303 into
SMIv2.
- In the second bullet of the last part of Section 3 listing the
SNMPv2 notification parameters, clarified that the snmpTrapOID
parameter refers to the value portion (not the name portion) of
the second variable-binding, and changed the wording in the text
under bullet (1) of Section 3.2 from "the snmpTrapOID" to "the
snmpTrapOID value" to emphasize this point.
- In bullet (6) of Section 3.2 emphasized that the SNMPv2 variable-
bindings do not include sysUpTime.0 an snmpTrapOID.0.
- In Section 4.2 clarified that the 'Upstream Version' refers to the
version used between the command generator or notification
receiver and the proxy, and the 'Downstream Version' refers to the
version used between the proxy and the command responder or
notification originator. RFC2576 neglected to mention the
notification receiver and notification originator.
- In Section 4.1.2 added text noting that SNMPv1 access to MIB data
SHOULD NOT be used when processing SNMPv2c or SNMPv3 messages and
re-worded final paragraph to note that the sub-sections that
follow are concerned solely with command responders that use
SNMPv2 access to MIB data while processing an SNMPv1 request.
- Re-worded first bullet, section 4.2.1, to make it more readable.
- In Section 4.2.1 clarified that the error-index field must be set
to zero in a translated GetResponse-PDU with an error-status of
'tooBig' and made explicit the rationale for retrying a
GetBulkRequest-PDU only once.
- Added text to the Deployment Hint in Section 4.2.2 to clarify that
different principals should be used for SNMPv1 requests and
SNMPv2/v3c requests if for SNMPv1 requests a principal for which
Counter64 objects are not-in-view is used.
- In Section 5.2.1 clarified that the securityName value and the
scopedPDU's contextSnmpEngineID and contextName values come from
the selected entry in the snmpCommunityTable. Also clarified how
maxSizeResponseScopedPDU is determined and that
securityStateReference must contain the community string of the
original request.
- Added Section 5.2.4 on Proxy Forwarding Of Requests.
- In Section 5.3 clarified that snmpTargetAddrTMask is to be ignored
whenever its use is not explicitly called for.
- Updated the LAST-UPDATED, CONTACT-INFO, and REVISION clauses and
added a copyright notice to the DESCRIPTION clause of the MIB
module's MODULE-IDENTITY invocation.
- Added text to DESCRIPTION of snmpCommunityName and
snmpTrapCommunity to clarify why the object has no size
restriction.
- Updated the description of snmpCommunityTransportTag to make it
consistent with the rest of the document.
- Updated the description of 'snmpTargetAddrMMS' to clarify that a
value of 0 means that the maximum message size is unknown.
- Changed the name of 'snmpCommunityGroup' to
'snmpCommunityTableGroup' in order to resolve a name conflict with
the SNMPv2-MIB.
- Added compliance statement to SNMP-COMMUNITY-MIB for full read-
create compliance.
- Divided references into Normative References and Informative
Reference and updated them to point to current documents.
- Inserted current year into all copyright notices.
- Corrected various typographical and grammatical errors.
A.2. Changes Between RFC1908 and RFC2576
- Editorial changes to comply with current RFCrequirements.
- Added/updated copyright statements.
- Added Intellectual Property section.
- Replaced old introduction with complete new introduction/overview.
- Added content for the Security Considerations Section.
- Updated References to current documents.
- Updated text to use current SNMP terminology.
- Added coexistence for/with SNMPv3.
- Added description for SNMPv1 and SNMPv2c Message Processing Models
and SNMPv1 and SNMPv2c Community-based Security Models.
- Added snmpCommunityMIB so that SNMPv1 and SNMPv2 community strings
can be mapped into the SNMP Version Independent parameters which
can then be used for access control using the standard SNMPv3
View-based Access Control Model and the snmpVacmMIB.
- Added two MIB objects such that when an SNMPv1 notification (trap)
must be converted into an SNMPv2 notification we add those two
objects in order to preserve information about the address and
community of the originating SNMPv1 agent.
- Included (and extended) from RFC2089 the SNMPv2 to SNMPv1 mapping
within a multi-lingual SNMP Engine.
- Use keywords from RFC2119 to describe requirements for
compliance.
- Changed/added some rules for converting a MIB module from SMIv1 to
SMIv2.
- Extended and improved the description of Proxy Forwarder behaviour
when multiple SNMP versions are involved.
Editors' Addresses
Rob Frye
Vibrant Solutions
2711 Prosperity Ave
Fairfax, Virginia 22031
U.S.A.
Phone: +1 703 270 2000
EMail: rfrye@vibrant-1.com
David B. Levi
Nortel Networks
3505 Kesterwood Drive
Knoxville, TN 37918
U.S.A.
Phone: +1 865 686 0432
EMail: dlevi@nortelnetworks.com
Shawn A. Routhier
Wind River Systems, Inc.
500 Wind River Way
Alameda, CA 94501
U.S.A.
Phone: + 1 510 749 2095
EMail: sar@epilogue.com
Bert Wijnen
Lucent Technologies
Schagen 33
3461 GL Linschoten
Netherlands
Phone: +31 348 407 775
EMail: bwijnen@lucent.com
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFCEditor function is currently provided by the
Internet Society.