draft-ietf-snmpv3-coex-05.txt   draft-ietf-snmpv3-coex-06.txt 
INTERNET-DRAFT Rob Frye INTERNET-DRAFT Rob Frye
MCI WorldCom CoSine Communications
David B. Levi David B. Levi
Nortel Networks Nortel Networks
Shawn A. Routhier Shawn A. Routhier
Integrated Systems Inc. Integrated Systems Inc.
Bert Wijnen Bert Wijnen
IBM T.J. Watson Research IBM T.J. Watson Research
Coexistence between Version 1, Version 2, and Version 3 Coexistence between Version 1, Version 2, and Version 3
of the Internet-standard Network Management Framework of the Internet-standard Network Management Framework
<draft-ietf-snmpv3-coex-05.txt> <draft-ietf-snmpv3-coex-06.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
skipping to change at page 3, line 34 skipping to change at page 3, line 34
4.1 Multi-lingual implementations .............................. 18 4.1 Multi-lingual implementations .............................. 18
4.1.1 Command Generator ........................................ 18 4.1.1 Command Generator ........................................ 18
4.1.2 Command Responder ........................................ 19 4.1.2 Command Responder ........................................ 19
4.1.2.1 Handling Counter64 ..................................... 19 4.1.2.1 Handling Counter64 ..................................... 19
4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20 4.1.2.2 Mapping SNMPv2 Exceptions .............................. 20
4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 21 4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 21
4.1.2.2.2 Mapping endOfMibView ................................. 21 4.1.2.2.2 Mapping endOfMibView ................................. 21
4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21 4.1.2.3 Processing An SNMPv1 GetRequest ........................ 21
4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22 4.1.2.4 Processing An SNMPv1 GetNextRequest .................... 22
4.1.2.5 Processing An SNMPv1 SetRequest ........................ 24 4.1.2.5 Processing An SNMPv1 SetRequest ........................ 24
4.1.2.6 Translation of authorizationError ...................... 24
4.1.3 Notification Originator .................................. 24 4.1.3 Notification Originator .................................. 24
4.1.4 Notification Receiver .................................... 25 4.1.4 Notification Receiver .................................... 25
4.2 Proxy Implementations ...................................... 25 4.2 Proxy Implementations ...................................... 25
4.2.1 Upstream Version Greater Than Downstream Version ......... 26 4.2.1 Upstream Version Greater Than Downstream Version ......... 26
4.2.2 Upstream Version Less Than Downstream Version ............ 27 4.2.2 Upstream Version Less Than Downstream Version ............ 27
4.3 Error Status Mappings ...................................... 28 4.3 Error Status Mappings ...................................... 28
5 Message Processing Models and Security Models ................ 30 5 Message Processing Models and Security Models ................ 30
5.1 Mappings ................................................... 30 5.1 Mappings ................................................... 30
5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security 5.2 The SNMPv1 MP Model and SNMPv1 Community-based Security
Model ..................................................... 30 Model ..................................................... 30
skipping to change at page 8, line 27 skipping to change at page 8, line 27
2.1. MIB Modules 2.1. MIB Modules
MIB modules defined using the SMIv1 may continue to be used with MIB modules defined using the SMIv1 may continue to be used with
protocol versions which use SNMPv2 PDUs. However, for the MIB protocol versions which use SNMPv2 PDUs. However, for the MIB
modules to conform to the SMIv2, the following changes SHALL be made: modules to conform to the SMIv2, the following changes SHALL be made:
2.1.1. Object Definitions 2.1.1. Object Definitions
In general, conversion of a MIB module does not require the In general, conversion of a MIB module does not require the
deprecation of the objects contained therein. If the semantics of an deprecation of the objects contained therein. If the definition of
object truly changes, the object SHALL be deprecated, otherwise an object is truly inadequate for its intended purpose, the object
deprecation is not required. SHALL be deprecated or obsoleted, otherwise deprecation is not
required.
(1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of (1) The IMPORTS statement MUST reference SNMPv2-SMI, instead of
RFC1155-SMI and RFC-1212. RFC1155-SMI and RFC-1212.
(2) The MODULE-IDENTITY macro MUST be invoked immediately after any (2) The MODULE-IDENTITY macro MUST be invoked immediately after any
IMPORTs statement. IMPORTs statement.
(3) For any object with an integer-valued SYNTAX clause, in which the (3) For any object with an integer-valued SYNTAX clause, in which the
corresponding INTEGER does not have a range restriction (i.e., the corresponding INTEGER does not have a range restriction (i.e., the
INTEGER has neither a defined set of named-number enumerations nor INTEGER has neither a defined set of named-number enumerations nor
skipping to change at page 10, line 17 skipping to change at page 10, line 17
requires all OBJECT-TYPEs to be a member of at least one OBJECT- requires all OBJECT-TYPEs to be a member of at least one OBJECT-
GROUP. GROUP.
Other changes are desirable, but not necessary: Other changes are desirable, but not necessary:
(1) Creation and deletion of conceptual rows is inconsistent using the (1) Creation and deletion of conceptual rows is inconsistent using the
SMIv1. The SMIv2 corrects this. As such, if the MIB module SMIv1. The SMIv2 corrects this. As such, if the MIB module
undergoes review early in its lifetime, and it contains conceptual undergoes review early in its lifetime, and it contains conceptual
tables which allow creation and deletion of conceptual rows, then tables which allow creation and deletion of conceptual rows, then
the objects relating to those tables MAY be deprecated and replaced the objects relating to those tables MAY be deprecated and replaced
with objects defined using the new approach. The approach base on with objects defined using the new approach. The approach based on
SMIv2 can be found in section 7 of RFC2578 [7], and the RowStatus SMIv2 can be found in section 7 of RFC2578 [7], and the RowStatus
and StorageType TEXTUAL-CONVENTIONs are described in section 2 of and StorageType TEXTUAL-CONVENTIONs are described in section 2 of
RFC2579 [8]. RFC2579 [8].
(2) For any object with a string-valued SYNTAX clause, in which the (2) For any object with a string-valued SYNTAX clause, in which the
corresponding OCTET STRING does not have a size restriction (i.e., corresponding OCTET STRING does not have a size restriction (i.e.,
the OCTET STRING has no assignment of lower- and upper-bounds on the OCTET STRING has no assignment of lower- and upper-bounds on
its length), the bounds for the size of the object SHOULD be its length), the bounds for the size of the object SHOULD be
defined. defined.
skipping to change at page 11, line 46 skipping to change at page 11, line 46
(7) One or more NOTIFICATION-GROUPs MUST be defined, and related (7) One or more NOTIFICATION-GROUPs MUST be defined, and related
notifications MUST be collected into those groups. Note that SMIv2 notifications MUST be collected into those groups. Note that SMIv2
requires that all NOTIFICATION-TYPEs be a member of at least one requires that all NOTIFICATION-TYPEs be a member of at least one
NOTIFICATION-GROUP. NOTIFICATION-GROUP.
2.2. Compliance Statements 2.2. Compliance Statements
For those information modules which are "standards track", a For those information modules which are "standards track", a
corresponding invocation of the MODULE-COMPLIANCE macro and related corresponding invocation of the MODULE-COMPLIANCE macro and related
OBJECT-GROUP macros MUST be included within the information module OBJECT-GROUP and/or NOTIFICATION-GROUP macros MUST be included within
(or in a companion information module), and any commentary text in the information module (or in a companion information module), and
the information module which relates to compliance SHOULD be removed. any commentary text in the information module which relates to
Typically this editing can occur when the information module compliance SHOULD be removed. Typically this editing can occur when
undergoes review. the information module undergoes review.
Note that a MODULE-COMPLIANCE statement is not required for a MIB Note that a MODULE-COMPLIANCE statement is not required for a MIB
document that is not on the standards track (for example, an document that is not on the standards track (for example, an
enterprise MIB), though it may be useful in some circumstances to enterprise MIB), though it may be useful in some circumstances to
define a MODULE-COMPLIANCE statement for such a MIB document. define a MODULE-COMPLIANCE statement for such a MIB document.
2.3. Capabilities Statements 2.3. Capabilities Statements
RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's RFC1303 [5] uses the MODULE-CONFORMANCE macro to describe an agent's
capabilities with respect to one or more MIB modules. Converting capabilities with respect to one or more MIB modules. Converting
skipping to change at page 16, line 7 skipping to change at page 16, line 7
- If the SNMPv2 snmpTrapOID parameter is one of the standard - If the SNMPv2 snmpTrapOID parameter is one of the standard
traps as defined in RFC1907 [12], then the SNMPv1 enterprise traps as defined in RFC1907 [12], then the SNMPv1 enterprise
parameter SHALL be set to the value of the variable-binding in parameter SHALL be set to the value of the variable-binding in
the SNMPv2 variable-bindings whose name is the SNMPv2 variable-bindings whose name is
snmpTrapEnterprise.0 if that variable-binding exists. If it snmpTrapEnterprise.0 if that variable-binding exists. If it
does not exist, the SNMPv1 enterprise parameter SHALL be set does not exist, the SNMPv1 enterprise parameter SHALL be set
to the value 'snmpTraps' as defined in RFC1907 [12]. to the value 'snmpTraps' as defined in RFC1907 [12].
- If the SNMPv2 snmpTrapOID parameter is not one of the standard - If the SNMPv2 snmpTrapOID parameter is not one of the standard
traps as defined in RFC1907 [12], then the SNMPv1 enterprise traps as defined in RFC1907 [12], then the SNMPv1 enterprise
parameter SHALL be set to the SNMPv2 snmpTrapOID parameter as parameter SHALL be determined from the SNMPv2 snmpTrapOID
follows: parameter as follows:
- If the next-to-last sub-identifier of the snmpTrapOID is - If the next-to-last sub-identifier of the snmpTrapOID is
zero, then the SMIv1 enterprise SHALL be the SMIv2 zero, then the SMIv1 enterprise SHALL be the SNMPv2
snmpTrapOID with the last 2 sub-identifiers removed, snmpTrapOID with the last 2 sub-identifiers removed,
otherwise otherwise
- If the next-to-last sub-identifier of the snmpTrapOID is - If the next-to-last sub-identifier of the snmpTrapOID is
non-zero, then the SMIv1 enterprise SHALL be the SMIv2 non-zero, then the SMIv1 enterprise SHALL be the SNMPv2
snmpTrapOID with the last sub-identifier removed. snmpTrapOID with the last sub-identifier removed.
(2) The SNMPv1 agent-addr parameter SHALL be determined based on the (2) The SNMPv1 agent-addr parameter SHALL be determined based on the
situation in which the translation occurs. situation in which the translation occurs.
- If the translation occurs within a notification originator - If the translation occurs within a notification originator
application, and the notification is to be sent over IP, the application, and the notification is to be sent over IP, the
SNMPv1 agent-addr parameter SHALL be set to the IP address of SNMPv1 agent-addr parameter SHALL be set to the IP address of
the SNMP entity in which the notification originator resides. the SNMP entity in which the notification originator resides.
If the notification is to be sent over some other transport, If the notification is to be sent over some other transport,
skipping to change at page 24, line 24 skipping to change at page 24, line 24
- The error status SHALL be translated to an SNMPv1 error-status - The error status SHALL be translated to an SNMPv1 error-status
using the table in section 4.3, "Error Status Mappings". using the table in section 4.3, "Error Status Mappings".
- The error-index SHALL be set to the position (in the original - The error-index SHALL be set to the position (in the original
request) of the variable binding that caused the error-status. request) of the variable binding that caused the error-status.
- The variable binding list of the response PDU SHALL be made - The variable binding list of the response PDU SHALL be made
exactly the same as the variable binding list that was exactly the same as the variable binding list that was
received in the original request. received in the original request.
In addition, whenever the SNMPv2 error-status value of 4.1.2.6. Translation of authorizationError
authorizationError is translated to an SNMPv1 error-status value of
noSuchName, the value of snmpInBadCommunityUses MUST be incremented. Whenever the SNMPv2 error-status value of authorizationError is
translated to an SNMPv1 error-status value of noSuchName, the value
of snmpInBadCommunityUses MUST be incremented.
4.1.3. Notification Originator 4.1.3. Notification Originator
A notification originator must be able to translate between SNMPv1 A notification originator must be able to translate between SNMPv1
notifications parameters and SNMPv2 notification parameters in order notifications parameters and SNMPv2 notification parameters in order
to send a notification using a particular SNMP message version. If a to send a notification using a particular SNMP message version. If a
notification is generated using SNMPv1 notification parameters, and notification is generated using SNMPv1 notification parameters, and
configuration information specifies that notifications be sent using configuration information specifies that notifications be sent using
SNMPv2c or SNMPv3, the notification parameters must be translated to SNMPv2c or SNMPv3, the notification parameters must be translated to
SNMPv2 notification parameters. Likewise, if a notification is SNMPv2 notification parameters. Likewise, if a notification is
skipping to change at page 34, line 42 skipping to change at page 34, line 42
single address per entry). This would typically be used to specify a single address per entry). This would typically be used to specify a
subnet in an snmpTargetAddrTable rather than just a single address. subnet in an snmpTargetAddrTable rather than just a single address.
The mask value is used to select which bits of a transport address The mask value is used to select which bits of a transport address
must match bits of the corresponding instance of must match bits of the corresponding instance of
snmpTargetAddrTAddress, in order for the transport address to match a snmpTargetAddrTAddress, in order for the transport address to match a
particular entry in the snmpTargetAddrTable. The value of an particular entry in the snmpTargetAddrTable. The value of an
instance of snmpTargetAddrTMask must always be an OCTET STRING whose instance of snmpTargetAddrTMask must always be an OCTET STRING whose
length is either zero or the same as that of the corresponding length is either zero or the same as that of the corresponding
instance of snmpTargetAddrTAddress. instance of snmpTargetAddrTAddress.
Note that the snmpTargetAddrTMask object is only used where
explicitly stated. In particular, it is not used when generating
notifications (i.e., when generating notifications, entries in the
snmpTargetAddrTable only specify individual addresses).
When checking whether a transport address matches an entry in the When checking whether a transport address matches an entry in the
snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero- snmpTargetAddrTable, if the value of snmpTargetAddrTMask is a zero-
length OCTET STRING, the mask value is ignored, and the value of length OCTET STRING, the mask value is ignored, and the value of
snmpTargetAddrTAddress must exactly match a transport address. snmpTargetAddrTAddress must exactly match a transport address.
Otherwise, each bit of each octet in the snmpTargetAddrTMask value Otherwise, each bit of each octet in the snmpTargetAddrTMask value
corresponds to the same bit of the same octet in the corresponds to the same bit of the same octet in the
snmpTargetAddrTAddress value. For bits that are set in the snmpTargetAddrTAddress value. For bits that are set in the
snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding snmpTargetAddrTMask value (i.e., bits equal to 1), the corresponding
bits in the snmpTargetAddrTAddress value must match the bits in a bits in the snmpTargetAddrTAddress value must match the bits in a
transport address. If all such bits match, the transport address is transport address. If all such bits match, the transport address is
skipping to change at page 36, line 4 skipping to change at page 36, line 9
Subscribe: majordomo@lists.tislabs.com Subscribe: majordomo@lists.tislabs.com
In msg body: subscribe snmpv3 In msg body: subscribe snmpv3
Chair: Russ Mundy Chair: Russ Mundy
TIS Labs at Network Associates TIS Labs at Network Associates
Postal: 3060 Washington Rd Postal: 3060 Washington Rd
Glenwood MD 21738 Glenwood MD 21738
USA USA
Email: mundy@tislabs.com Email: mundy@tislabs.com
Phone: +1-301-854-6889 Phone: +1-301-854-6889
Co-editor: Rob Frye Co-editor: Rob Frye
MCI WorldCom CoSine Communications
Postal: 2100 Reston Parkway, Suite 600 Postal: 1200 Bridge Parkway
Reston, VA 20191 Redwood City, CA 94065
USA USA
E-mail: Rob.Frye@wcom.com E-mail: rfrye@cosinecom.com
Phone: +1 703 715 7225 Phone: +1 650 637 4777
Co-editor: David B. Levi Co-editor: David B. Levi
Nortel Networks Nortel Networks
Postal: 3505 Kesterwood Drive Postal: 3505 Kesterwood Drive
Knoxville, TN 37918 Knoxville, TN 37918
E-mail: dlevi@nortelnetworks.com E-mail: dlevi@nortelnetworks.com
Phone: +1 423 686 0432 Phone: +1 423 686 0432
Co-editor: Shawn A. Routhier Co-editor: Shawn A. Routhier
Integrated Systems Inc. Integrated Systems Inc.
 End of changes. 14 change blocks. 
23 lines changed or deleted 33 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/