draft-ietf-snmpv3-coex-02.txt   draft-ietf-snmpv3-coex-03.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
INTERNET-DRAFT Rob Frye INTERNET-DRAFT Rob Frye
MCI Communications Corp. MCI Communications Corp.
David B. Levi David B. Levi
SNMP Research, Inc. SNMP Research, Inc.
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-02.txt> <draft-ietf-snmpv3-coex-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft and is in full conformance with
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
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the The list of current Internet-Drafts can be accessed at
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.ietf.org (US East Coast), nic.nordu.net
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific The list of Internet-Draft Shadow Directories can be accessed at
Rim). http://www.ietf.org/shadow.html
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (1999). All Rights Reserved.
Abstract Abstract
The purpose of this document is to describe coexistence between The purpose of this document is to describe coexistence between
version 3 of the Internet-standard Network Management Framework, version 3 of the Internet-standard Network Management Framework,
(SNMPv3), version 2 of the Internet-standard Network Management (SNMPv3), version 2 of the Internet-standard Network Management
Framework (SNMPv2), and the original Internet-standard Network Framework (SNMPv2), and the original Internet-standard Network
Management Framework (SNMPv1). This document obsoletes RFC 1908 [13] Management Framework (SNMPv1). This document obsoletes RFC 1908 [13]
and RFC2089 [14]. and RFC2089 [14].
skipping to change at page 3, line 28 skipping to change at page 3, line 28
3.1 Translating SNMPv1 Notification Parameters to SNMPv2 No- 3.1 Translating SNMPv1 Notification Parameters to SNMPv2 No-
tification Parameters ..................................... 14 tification Parameters ..................................... 14
3.2 Translating SNMPv2 Notification Parameters to SNMPv1 No- 3.2 Translating SNMPv2 Notification Parameters to SNMPv1 No-
tification Parameters ..................................... 15 tification Parameters ..................................... 15
4 Approaches to Coexistence in a Multi-lingual Network ......... 18 4 Approaches to Coexistence in a Multi-lingual Network ......... 18
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 ........................................ 18 4.1.2 Command Responder ........................................ 18
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 .............. 20 4.1.2.2.1 Mapping noSuchObject and noSuchInstance .............. 20
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.3 Notification Originator .................................. 23 4.1.3 Notification Originator .................................. 23
4.1.4 Notification Receiver .................................... 24 4.1.4 Notification Receiver .................................... 24
4.2 Proxy Implementations ...................................... 24 4.2 Proxy Implementations ...................................... 24
4.3 Error Status Mappings ...................................... 26 4.3 Error Status Mappings ...................................... 26
5 Message Processing Models and Security Models ................ 27 5 Message Processing Models and Security Models ................ 27
5.1 Mappings ................................................... 27 5.1 Mappings ................................................... 27
5.2 The SNMPv1 Message Processing Model ........................ 27 5.2 The SNMPv1 Message Processing Model ........................ 27
5.2.1 Processing An Incoming Request ........................... 28 5.2.1 Processing An Incoming Request ........................... 28
5.2.2 Generating An Outgoing Response .......................... 30 5.2.2 Generating An Outgoing Response .......................... 30
5.2.3 Generating An Outgoing Notification ...................... 30 5.2.3 Generating An Outgoing Notification ...................... 30
5.3 The SNMP Community MIB Module .............................. 31 5.3 The SNMP Community MIB Module .............................. 31
6 Intellectual Property ........................................ 40 6 Intellectual Property ........................................ 41
7 Acknowledgments .............................................. 41 7 Acknowledgments .............................................. 42
8 Security Considerations ...................................... 42 8 Security Considerations ...................................... 43
9 References ................................................... 43 9 References ................................................... 44
10 Editor's Address ............................................ 45 10 Editor's Address ............................................ 46
A. Full Copyright Statement .................................... 46 A. Full Copyright Statement .................................... 47
1. Overview 1. Overview
The purpose of this document is to describe coexistence between The purpose of this document is to describe coexistence between
version 3 of the Internet-standard Network Management Framework, version 3 of the Internet-standard Network Management Framework,
termed the SNMP version 3 framework (SNMPv3), version 2 of the termed the SNMP version 3 framework (SNMPv3), version 2 of the
Internet-standard Network Management Framework, termed the SNMP Internet-standard Network Management Framework, termed the SNMP
version 2 framework (SNMPv2), and the original Internet-standard version 2 framework (SNMPv2), and the original Internet-standard
Network Management Framework (SNMPv1). Network Management Framework (SNMPv1).
skipping to change at page 18, line 11 skipping to change at page 18, line 11
- Any variable-binding whose type is Counter64 which exists in - Any variable-binding whose type is Counter64 which exists in
the SNMPv2 variable-bindings SHALL be removed. the SNMPv2 variable-bindings SHALL be removed.
4. Approaches to Coexistence in a Multi-lingual Network 4. Approaches to Coexistence in a Multi-lingual Network
There are two basic approaches to coexistence in a multi-lingual There are two basic approaches to coexistence in a multi-lingual
network, multi-lingual implementations and proxy implementations. network, multi-lingual implementations and proxy implementations.
Multi-lingual implementations allow elements in a network to Multi-lingual implementations allow elements in a network to
communicate with each other using an SNMP version which both elements communicate with each other using an SNMP version which both elements
support. This allows a multi-lingual implentation to communicate support. This allows a multi-lingual implementation to communicate
with any mono-lingual implementation, regardless of the SNMP version with any mono-lingual implementation, regardless of the SNMP version
supported by the mono-lingual implementation. supported by the mono-lingual implementation.
Proxy implementations provide a mechanism for translating between Proxy implementations provide a mechanism for translating between
SNMP versions using a third party network element. This allows SNMP versions using a third party network element. This allows
network elements which support only a single, but different, SNMP network elements which support only a single, but different, SNMP
version to communicate with each other. Proxy implementations are version to communicate with each other. Proxy implementations are
also useful for securing communications over an insecure link between also useful for securing communications over an insecure link between
two locally secure networks. two locally secure networks.
skipping to change at page 19, line 43 skipping to change at page 19, line 43
version. version.
Multi-lingual command responders SHALL take the approach that object Multi-lingual command responders SHALL take the approach that object
instances whose type is Counter64 are implicitly excluded from view instances whose type is Counter64 are implicitly excluded from view
when processing an SNMPv1 message. So: when processing an SNMPv1 message. So:
- On an SNMPv1 GET request, an error-status of noSuchName SHALL - On an SNMPv1 GET request, an error-status of noSuchName SHALL
be returned, and the error-index SHALL be set to the variable be returned, and the error-index SHALL be set to the variable
binding that caused this error. binding that caused this error.
- On an SNMPv1 GETNEXT request, any object instance which - On an SNMPv1 GetNext request, any object instance which
contains a syntax of Counter64 shall be skipped, and the next contains a syntax of Counter64 shall be skipped, and the next
object instance that follows the one with a syntax of object instance that follows the one with a syntax of
Counter64 SHALL be fetched. This step may need to be repeated Counter64 SHALL be fetched. This step may need to be repeated
several times in order to find an object whose syntax is not several times in order to find an object whose syntax is not
Counter64. Counter64.
- Any SET request that has a variable binding with a Counter64 - Any SET request that has a variable binding with a Counter64
value must have come from a SNMPv2 manager, and so it should value must have come from a SNMPv2 manager, and so it should
not cause a problem. However, if an object with SYNTAX of not cause a problem. However, if an object with SYNTAX of
Counter64 is received in an SNMPv1 SET packet, it SHALL result Counter64 is received in an SNMPv1 SET packet, it SHALL result
skipping to change at page 20, line 42 skipping to change at page 20, line 42
may be returned. may be returned.
- For a GetNextRequest, an endOfMibView exception may be - For a GetNextRequest, an endOfMibView exception may be
returned. returned.
- No exceptions will be returned for a SetRequest, and a - No exceptions will be returned for a SetRequest, and a
GetBulkRequest should only be received in an SNMPv2c or SNMPv3 GetBulkRequest should only be received in an SNMPv2c or SNMPv3
message, so these request types may be ignored when mapping message, so these request types may be ignored when mapping
exceptions. exceptions.
4.1.2.2.1. Mapping nosuchObject and noSuchInstance 4.1.2.2.1. Mapping noSuchObject and noSuchInstance
A noSuchObject or noSuchInstance exception generated by SNMPv2 MIB A noSuchObject or noSuchInstance exception generated by SNMPv2 MIB
instrumentation indicates that the requested object instance can not instrumentation indicates that the requested object instance can not
be returned. The SNMPv1 error code for this condition is noSuchName, be returned. The SNMPv1 error code for this condition is noSuchName,
and so the error-status field of the response PDU SHALL be set to and so the error-status field of the response PDU SHALL be set to
noSuchName. Also, the error-index field SHALL be set to the index of noSuchName. Also, the error-index field SHALL be set to the index of
the variable binding for which an exception occurred, and the the variable binding for which an exception occurred, and the
variable binding list from the original request SHALL be returned variable binding list from the original request SHALL be returned
with the response PDU. with the response PDU.
skipping to change at page 24, line 26 skipping to change at page 24, line 26
Note also that access control and notification filtering are Note also that access control and notification filtering are
performed in the usual manner for notifications, regardless of the performed in the usual manner for notifications, regardless of the
SNMP message version to be used when sending a notification. The SNMP message version to be used when sending a notification. The
parameters for performing access control are found in the usual parameters for performing access control are found in the usual
manner (i.e. from inspecting the SNMP-TARGET-MIB and SNMP- manner (i.e. from inspecting the SNMP-TARGET-MIB and SNMP-
NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in NOTIFICATION-MIB). In particular, when generating an SNMPv1 Trap, in
order to perform the access check specified in [18], section 3.3, order to perform the access check specified in [18], section 3.3,
bullet (3), the notification originator may need to generate a value bullet (3), the notification originator may need to generate a value
for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of for snmpTrapOID.0 as described in section 3.1, bullets (2) and (3) of
this document. If the SNMPv1 notificaton parameters being used were this document. If the SNMPv1 notification parameters being used were
previously translated from a set of SNMPv2 notification parameters, previously translated from a set of SNMPv2 notification parameters,
this value may already be known, in which case it need not be this value may already be known, in which case it need not be
generated. generated.
4.1.4. Notification Receiver 4.1.4. Notification Receiver
There are no special requirements of a notification receiver. There are no special requirements of a notification receiver.
However, an implementation may find it useful to allow a higher level However, an implementation may find it useful to allow a higher level
application to request whether notifications should be delivered to a application to request whether notifications should be delivered to a
higher level application using SNMPv1 notification parameter or higher level application using SNMPv1 notification parameter or
skipping to change at page 31, line 21 skipping to change at page 31, line 21
5.3. The SNMP Community MIB Module 5.3. The SNMP Community MIB Module
The SNMP-COMMUNITY-MIB contains objects for mapping between community The SNMP-COMMUNITY-MIB contains objects for mapping between community
strings and version-independent SNMP message parameters. In strings and version-independent SNMP message parameters. In
addition, this MIB provides a mechanism for performing source address addition, this MIB provides a mechanism for performing source address
validation on incoming requests, and for selecting community strings validation on incoming requests, and for selecting community strings
based on target addresses for outgoing notifications. These two based on target addresses for outgoing notifications. These two
features are accomplished by providing a tag in the features are accomplished by providing a tag in the
snmpCommunityTable which selects sets of entries in the snmpCommunityTable which selects sets of entries in the
snmpTargetAddrTable [18]. In addition, the SNMP-COMMUNITY-MIB snmpTargetAddrTable [18]. In addition, the SNMP-COMMUNITY-MIB
augments the snmpTargetAddrTable with a transport address mask value. augments the snmpTargetAddrTable with a transport address mask value
This allows selected entries in the snmpTargetAddrTable to specify and a maximum message size value. These values are used only where
multiple addresses (rather than just a single address per entry). explicitly stated. In cases where the snmpTargetAddrTable is used
This would typically be used to specify a subnet in an without mention of these augmenting values, the augmenting values
snmpTargetAddrTable rather than just a single address. should be ignored.
The mask value, snmpTargetAddrTMask, is used to select which bits of The mask value, snmpTargetAddrTMask, allows selected entries in the
a transport address must match bits of the corresponding instance of snmpTargetAddrTable to specify multiple addresses (rather than just a
single address per entry). This would typically be used to specify a
subnet in an snmpTargetAddrTable rather than just a single address.
The mask value is used to select which bits of a transport address
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.
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
matched by that snmpTargetAddrTable entry. Otherwise, the transport matched by that snmpTargetAddrTable entry. Otherwise, the transport
address is not matched. address is not matched.
The maximum message size value, snmpTargetAddrMMS, is used to
determine the maximum message size acceptable to another SNMP entity
when the value cannot be determined from the protocol.
SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN SNMP-COMMUNITY-MIB DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
IpAddress IpAddress
FROM RFC1155-SMI FROM RFC1155-SMI
MODULE-IDENTITY, MODULE-IDENTITY,
OBJECT-TYPE, OBJECT-TYPE,
Integer32, Integer32,
Counter32,
UInteger32
FROM SNMPv2-SMI FROM SNMPv2-SMI
RowStatus, RowStatus,
TestAndIncr, TestAndIncr,
StorageType StorageType
FROM SNMPv2-TC FROM SNMPv2-TC
SnmpAdminString SnmpAdminString
FROM SNMP-FRAMEWORK-MIB FROM SNMP-FRAMEWORK-MIB
SnmpTagValue SnmpTagValue
FROM SNMP-TARGET-MIB FROM SNMP-TARGET-MIB
MODULE-COMPLIANCE, MODULE-COMPLIANCE,
skipping to change at page 36, line 30 skipping to change at page 36, line 37
"The status of this conceptual row in the snmpCommunityTable. "The status of this conceptual row in the snmpCommunityTable.
An entry in this table is not qualified for activation An entry in this table is not qualified for activation
until instances of all corresponding columns have been until instances of all corresponding columns have been
initialized, either through default values, or through initialized, either through default values, or through
Set operations. The snmpCommunityName and Set operations. The snmpCommunityName and
snmpCommunitySecurityName objects must be explicitly set." snmpCommunitySecurityName objects must be explicitly set."
::= { snmpCommunityEntry 8 } ::= { snmpCommunityEntry 8 }
-- --
-- The snmpTargetAddrMaskTable augments the snmpTargetAddrTable with -- The snmpTargetAddrExtTable augments the snmpTargetAddrTable with
-- a transport address mask value. This allows entries in the -- a transport address mask value and a maximum message size value.
-- The transport address mask allows entries in the
-- snmpTargetAddrTable to define a set of addresses instead of just -- snmpTargetAddrTable to define a set of addresses instead of just
-- a single address. -- a single address. The maximum message size value allows the
-- maximum message size of another SNMP entity to be configured
-- for use in SNMPv1 (and SNMPv2c) transactions, where the message
-- format does not specify a maximum message size.
-- --
snmpTargetAddrMaskTable OBJECT-TYPE snmpTargetAddrExtTable OBJECT-TYPE
SYNTAX SEQUENCE OF SnmpTargetAddrMaskEntry SYNTAX SEQUENCE OF SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The table of mask values associated with the "The table of mask and mms values associated with the
snmpTargetAddrTable." snmpTargetAddrTable."
::= { snmpCommunityMIBObjects 2 } ::= { snmpCommunityMIBObjects 2 }
snmpTargetAddrMaskEntry OBJECT-TYPE snmpTargetAddrExtEntry OBJECT-TYPE
SYNTAX SnmpTargetAddrMaskEntry SYNTAX SnmpTargetAddrExtEntry
MAX-ACCESS not-accessible MAX-ACCESS not-accessible
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Information about a particular mask value." "Information about a particular mask and mms value."
AUGMENTS { snmpTargetAddrEntry } AUGMENTS { snmpTargetAddrEntry }
::= { snmpTargetAddrMaskTable 1 } ::= { snmpTargetAddrExtTable 1 }
SnmpTargetAddrMaskEntry ::= SEQUENCE { SnmpTargetAddrExtEntry ::= SEQUENCE {
snmpTargetAddrTMask OCTET STRING snmpTargetAddrTMask OCTET STRING,
snmpTargetAddrMMS Integer32
} }
snmpTargetAddrTMask OBJECT-TYPE snmpTargetAddrTMask OBJECT-TYPE
SYNTAX OCTET STRING (SIZE (0..255)) SYNTAX OCTET STRING (SIZE (0..255))
MAX-ACCESS read-create MAX-ACCESS read-create
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The mask value associated with an entry in the "The mask value associated with an entry in the
snmpTargetAddrTable. The value of this object must snmpTargetAddrTable. The value of this object must
have the same length as the corresponding instance of have the same length as the corresponding instance of
snmpTargetAddrTAddress, or must have length 0." snmpTargetAddrTAddress, or must have length 0."
DEFVAL { ''H } DEFVAL { ''H }
::= { snmpTargetAddrMaskEntry 1 } ::= { snmpTargetAddrExtEntry 1 }
snmpTargetAddrMMS OBJECT-TYPE
SYNTAX Integer32 (484..65535)
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The maximum message size value associated with an entry
in the snmpTargetAddrTable."
DEFVAL { 2048 }
::= { snmpTargetAddrExtEntry 2 }
-- --
-- The snmpTrapAddress and snmpTrapCommunity objects are included -- The snmpTrapAddress and snmpTrapCommunity objects are included
-- in notifications that are forwarded by a proxy, which were -- in notifications that are forwarded by a proxy, which were
-- originally received as SNMPv1 Trap messages. -- originally received as SNMPv1 Trap messages.
-- --
snmpTrapAddress OBJECT-TYPE snmpTrapAddress OBJECT-TYPE
SYNTAX IpAddress SYNTAX IpAddress
MAX-ACCESS accessible-for-notify MAX-ACCESS accessible-for-notify
skipping to change at page 39, line 24 skipping to change at page 39, line 44
snmpCommunityGroup OBJECT-GROUP snmpCommunityGroup OBJECT-GROUP
OBJECTS { OBJECTS {
snmpCommunityIndex, snmpCommunityIndex,
snmpCommunityName, snmpCommunityName,
snmpCommunitySecurityName, snmpCommunitySecurityName,
snmpCommunityContextEngineID, snmpCommunityContextEngineID,
snmpCommunityContextName, snmpCommunityContextName,
snmpCommunityTransportTag, snmpCommunityTransportTag,
snmpCommunityStorageType, snmpCommunityStorageType,
snmpCommunityStatus, snmpCommunityStatus,
snmpTargetAddrTMask snmpTargetAddrTMask,
snmpTargetAddrMMS
} }
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"A collection of objects providing for configuration "A collection of objects providing for configuration
of community strings for SNMPv1 (and SNMPv2c) usage." of community strings for SNMPv1 (and SNMPv2c) usage."
::= { snmpCommunityMIBGroups 1 } ::= { snmpCommunityMIBGroups 1 }
END END
6. Intellectual Property 6. Intellectual Property
skipping to change at page 44, line 31 skipping to change at page 45, line 31
[14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi- [14] Levi, D., Wijnen, B., "Mapping SNMPv2 onto SNMPv1 within a bi-
lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January lingual SNMP agent", RFC2089, SNMP Research, Inc., IBM, January
1997. 1997.
[15] Bradner, S., "Key words for use in RFCs to Indicate Requirement [15] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An [16] The SNMPv3 Working Group, Harrington, D., Wijnen, B., "An
Architecture for Describing SNMP Management Frameworks", draft- Architecture for Describing SNMP Management Frameworks", draft-
ietf-snmpv3-arch-01.txt, September 1998. ietf-snmpv3-arch-05.txt, February 1999.
[17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B., [17] The SNMPv3 Working Group, Case, J., Harrington, D., Wijnen, B.,
"Message Processing and Dispatching for the Simple Network "Message Processing and Dispatching for the Simple Network
Management Protocol (SNMP)", draft-ietf-snmpv3-mpc-01.txt, Management Protocol (SNMP)", draft-ietf-snmpv3-mpc-05.txt, February
September 1998. 1999.
[18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP [18] The SNMPv3 Working Group, Levi, D., Meyer, P., Stewart, B., "SNMP
Applications", draft-ietf-snmpv3-appl-v2-01.txt, September 1998. Applications", draft-ietf-snmpv3-appl-v2-03.txt, February 1999.
[19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User- [19] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The User-
Based Security Model for Version 3 of the Simple Network Management Based Security Model for Version 3 of the Simple Network Management
Protocol (SNMP)", draft-ietf-snmpv3-usm-v2-02.txt, September 1998. Protocol (SNMP)", draft-ietf-snmpv3-usm-v2-05.txt, February 1999.
[20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K., [20] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., McCloghrie, K.,
"View-based Access Control Model for the Simple Network Management "View-based Access Control Model for the Simple Network Management
Protocol (SNMP)", draft-ietf-snmpv3-vacm-01.txt, September 1998. Protocol (SNMP)", draft-ietf-snmpv3-vacm-04.txt, February 1999.
10. Editor's Address 10. Editor's Address
Rob Frye Rob Frye
MCI Communications Corp. MCI Communications Corp.
2100 Reston Parkway, Suite 600 2100 Reston Parkway, Suite 600
Reston, VA 20191 Reston, VA 20191
U.S.A. U.S.A.
Phone: +1 703 715 7225 Phone: +1 703 715 7225
EMail: Rob.Frye@mci.com EMail: Rob.Frye@mci.com
 End of changes. 30 change blocks. 
49 lines changed or deleted 72 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/