draft-ietf-snmpv2-tm-ds-02.txt   draft-ietf-snmpv2-tm-ds-03.txt 
Transport Mappings for Version 2 of the Transport Mappings for Version 2 of the
Simple Network Management Protocol (SNMPv2) Simple Network Management Protocol (SNMPv2)
31 May 1995 | 20 September 1995 |
draft-ietf-snmpv2-tm-ds-02.txt |
Jeffrey D. Case draft-ietf-snmpv2-tm-ds-03.txt |
SNMP Research, Inc.
case@snmp.com
Keith McCloghrie Keith McCloghrie
Editor +
Cisco Systems, Inc. Cisco Systems, Inc.
kzm@cisco.com kzm@cisco.com
Marshall T. Rose Status of this Memo -
Dover Beach Consulting, Inc.
mrose@dbc.mtview.ca.us
Steven Waldbusser
Carnegie Mellon University
waldbusser@cmu.edu
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. 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 material time. It is inappropriate to use Internet- Drafts as reference material
or to cite them other than as ``work in progress.'' or to cite them other than as ``work in progress.''
skipping to change at page 3, line 5 skipping to change at page 3, line 5
interoperability, systems which choose to deploy other mappings should interoperability, systems which choose to deploy other mappings should
also provide for proxy service to the UDP mapping. also provide for proxy service to the UDP mapping.
1.1. A Note on Terminology 1.1. A Note on Terminology
For the purpose of exposition, the original Internet-standard Network For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in RFCs 1155, 1157, and 1212, is Management Framework, as described in RFCs 1155, 1157, and 1212, is
termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 1 framework (SNMPv1). The current framework is
termed the SNMP version 2 framework (SNMPv2). termed the SNMP version 2 framework (SNMPv2).
2. Definitions - 2. Definitions
SNMPv2-TM DEFINITIONS ::= BEGIN SNMPv2-TM DEFINITIONS ::= BEGIN
IMPORTS IMPORTS
OBJECT-IDENTITY, snmpDomains, snmpProxys | OBJECT-IDENTITY, snmpDomains, snmpProxys
FROM SNMPv2-SMI FROM SNMPv2-SMI
TEXTUAL-CONVENTION TEXTUAL-CONVENTION
FROM SNMPv2-TC; FROM SNMPv2-TC;
-- SNMPv2 over UDP over IPv4 -- SNMPv2 over UDP over IPv4
snmpUDPDomain OBJECT-IDENTITY snmpUDPDomain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The SNMPv2 over UDP transport domain. The corresponding "The SNMPv2 over UDP transport domain. The corresponding
skipping to change at page 5, line 19 skipping to change at page 5, line 19
DESCRIPTION DESCRIPTION
"The SNMPv2 over DDP transport domain. The corresponding "The SNMPv2 over DDP transport domain. The corresponding
transport address is of type SnmpNBPAddress." transport address is of type SnmpNBPAddress."
::= { snmpDomains 4 } ::= { snmpDomains 4 }
SnmpNBPAddress ::= TEXTUAL-CONVENTION SnmpNBPAddress ::= TEXTUAL-CONVENTION
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"Represents an NBP name: "Represents an NBP name:
octets contents encoding | octets contents encoding
1 length of object 'n' as an unsigned integer| 1 length of object 'n' as an unsigned integer
2..(n+1) object string of (up to 32) octets| 2..(n+1) object string of (up to 32) octets
n+2 length of type 'p' as an unsigned integer| n+2 length of type 'p' as an unsigned integer
(n+3)..(n+2+p) type string of (up to 32) octets| (n+3)..(n+2+p) type string of (up to 32) octets
n+3+p length of zone 'q' as an unsigned integer| n+3+p length of zone 'q' as an unsigned integer
(n+4+p)..(n+3+p+q) zone string of (up to 32) octets| (n+4+p)..(n+3+p+q) zone string of (up to 32) octets
For comparison purposes, strings are case-insensitive All For comparison purposes, strings are case-insensitive All
strings may contain any octet other than 255 (hex ff)." strings may contain any octet other than 255 (hex ff)."
SYNTAX OCTET STRING (SIZE (3..99)) SYNTAX OCTET STRING (SIZE (3..99))
-- SNMPv2 over IPX -- SNMPv2 over IPX
snmpIPXDomain OBJECT-IDENTITY snmpIPXDomain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
skipping to change at page 6, line 27 skipping to change at page 6, line 27
DESCRIPTION DESCRIPTION
"Represents an IPX address: "Represents an IPX address:
octets contents encoding octets contents encoding
1-4 network-number network-byte order 1-4 network-number network-byte order
5-10 physical-address network-byte order 5-10 physical-address network-byte order
11-12 socket-number network-byte order 11-12 socket-number network-byte order
" "
SYNTAX OCTET STRING (SIZE (12)) SYNTAX OCTET STRING (SIZE (12))
-- for proxy to SNMPv1 (RFC 1157) |
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 } rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
rfc1157Domain OBJECT-IDENTITY rfc1157Domain OBJECT-IDENTITY
STATUS current STATUS current
DESCRIPTION DESCRIPTION
"The transport domain for SNMPv1 over UDP. The "The transport domain for SNMPv1 over UDP. The
corresponding transport address is of type SnmpUDPAddress." corresponding transport address is of type SnmpUDPAddress."
::= { rfc1157Proxy 1 } ::= { rfc1157Proxy 1 }
rfc1157noAuth OBJECT-IDENTITY -- ::= { rfc1157Proxy 2 } this OID is obsolete +
STATUS current
DESCRIPTION
"The SNMPv1 community-based (non-) authentication protocol."
::= { rfc1157Proxy 2 }
END END -
3. SNMPv2 over UDP 3. SNMPv2 over UDP
This is the preferred transport mapping. This is the preferred transport mapping.
3.1. Serialization 3.1. Serialization
Each instance of a message is serialized (i.e., encoded according to the Each instance of a message is serialized (i.e., encoded according to the
convention of [1]) onto a single UDP[2] datagram, using the algorithm convention of [1]) onto a single UDP[2] datagram, using the algorithm
specified in Section 8. specified in Section 8.
3.2. Well-known Values 3.2. Well-known Values
Although the partyTable gives transport addressing information for an It is suggested that administrators configure their SNMPv2 entities |
SNMPv2 party, it is suggested that administrators configure their SNMPv2 acting in an agent role to listen on UDP port 161. Further, it is
entities acting in an agent role to listen on UDP port 161. Further, it suggested that notification sinks be configured to listen on UDP port
is suggested that notification sinks be configured to listen on UDP port
162. 162.
The partyTable also lists the maximum message size which a SNMPv2 party When an SNMPv2 entity uses this transport mapping, it must be capable of |
is willing to accept. This value must be at least 1472 octets. accepting messages that are at least 484 octets in size. |
Implementation of larger values is encouraged whenever possible. Implementation of larger values is encouraged whenever possible.
4. SNMPv2 over OSI 4. SNMPv2 over OSI
This is an optional transport mapping. This is an optional transport mapping.
4.1. Serialization 4.1. Serialization
Each instance of a message is serialized onto a single TSDU [3,4] for Each instance of a message is serialized onto a single TSDU [3,4] for
the OSI Connectionless-mode Transport Service (CLTS), using the the OSI Connectionless-mode Transport Service (CLTS), using the
algorithm specified in Section 8. algorithm specified in Section 8.
4.2. Well-known Values 4.2. Well-known Values
Although the partyTable gives transport addressing information for an It is suggested that administrators configure their SNMPv2 entities |
SNMPv2 party, it is suggested that administrators configure their SNMPv2 acting in an agent role to listen on transport selector "snmp-l" (which
entities acting in an agent role to listen on transport selector "snmp- consists of six ASCII characters), when using a CL-mode network service
l" (which consists of six ASCII characters), when using a CL-mode to realize the CLTS. Further, it is suggested that notification sinks
network service to realize the CLTS. Further, it is suggested that be configured to listen on transport selector "snmpt-l" (which consists
notification sinks be configured to listen on transport selector of seven ASCII characters, six letters and a hyphen) when using a CL-
"snmpt-l" (which consists of seven ASCII characters, six letters and a mode network service to realize the CLTS. Similarly, when using a CO-
hyphen) when using a CL-mode network service to realize the CLTS. mode network service to realize the CLTS, the suggested transport
Similarly, when using a CO-mode network service to realize the CLTS, the selectors are "snmp-o" and "snmpt-o", for agent and notification sink,
suggested transport selectors are "snmp-o" and "snmpt-o", for agent and respectively.
notification sink, respectively.
The partyTable also lists the maximum message size which a SNMPv2 party When an SNMPv2 entity uses this transport mapping, it must be capable of |
is willing to accept. This value must be at least 1472 octets. accepting messages that are at least 484 octets in size. |
Implementation of larger values is encouraged whenever possible. Implementation of larger values is encouraged whenever possible.
5. SNMPv2 over DDP 5. SNMPv2 over DDP
This is an optional transport mapping. This is an optional transport mapping.
5.1. Serialization 5.1. Serialization
Each instance of a message is serialized onto a single DDP datagram [5], Each instance of a message is serialized onto a single DDP datagram [5],
using the algorithm specified in Section 8. using the algorithm specified in Section 8.
5.2. Well-known Values 5.2. Well-known Values
SNMPv2 messages are sent using DDP protocol type 8. SNMPv2 entities SNMPv2 messages are sent using DDP protocol type 8. SNMPv2 entities
acting in an agent role listens on DDP socket number 8, whilst acting in an agent role listens on DDP socket number 8, whilst
notification sinks listen on DDP socket number 9. notification sinks listen on DDP socket number 9.
Although the partyTable gives transport addressing information for an Administrators must configure their SNMPv2 entities |
SNMPv2 party, administrators must configure their SNMPv2 entities acting acting in an agent role to use NBP type "SNMP Agent" (which consists of
in an agent role to use NBP type "SNMP Agent" (which consists of ten ten ASCII characters), whilst notification sinks must be configured to
ASCII characters), whilst notification sinks must be configured to use use NBP type "SNMP Trap Handler" (which consists of seventeen ASCII
NBP type "SNMP Trap Handler" (which consists of seventeen ASCII
characters). characters).
The NBP name for agents and notification sinks should be stable - NBP The NBP name for agents and notification sinks should be stable - NBP
names should not change any more often than the IP address of a typical names should not change any more often than the IP address of a typical
TCP/IP node. It is suggested that the NBP name be stored in some form TCP/IP node. It is suggested that the NBP name be stored in some form
of stable storage. of stable storage.
The partyTable also lists the maximum message size which a SNMPv2 party When an SNMPv2 entity uses this transport mapping, it must be capable of |
is willing to accept. This value must be at least 484 octets. accepting messages that are at least 484 octets in size. |
Implementation of larger values is encouraged whenever possible. Implementation of larger values is encouraged whenever possible.
5.3. Discussion of AppleTalk Addressing 5.3. Discussion of AppleTalk Addressing
The AppleTalk protocol suite has certain features not manifest in the The AppleTalk protocol suite has certain features not manifest in the
TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of
address assignment can cause problems for SNMPv2 entities that wish to address assignment can cause problems for SNMPv2 entities that wish to
manage AppleTalk networks. TCP/IP nodes have an associated IP address manage AppleTalk networks. TCP/IP nodes have an associated IP address
which distinguishes each from the other. In contrast, AppleTalk nodes which distinguishes each from the other. In contrast, AppleTalk nodes
generally have no such characteristic. The network-level address, while generally have no such characteristic. The network-level address, while
skipping to change at page 13, line 19 skipping to change at page 13, line 19
6.1. Serialization 6.1. Serialization
Each instance of a message is serialized onto a single IPX datagram [7], Each instance of a message is serialized onto a single IPX datagram [7],
using the algorithm specified in Section 8. using the algorithm specified in Section 8.
6.2. Well-known Values 6.2. Well-known Values
SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet Exchange SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet Exchange
Protocol). Protocol).
Although the partyTable gives transport addressing information for an It is suggested that administrators configure their SNMPv2 entities |
SNMPv2 party, it is suggested that administrators configure their SNMPv2 acting in an agent role to listen on IPX socket 36879 (900f
entities acting in an agent role to listen on IPX socket 36879 (900f
hexadecimal). Further, it is suggested that notification sinks be hexadecimal). Further, it is suggested that notification sinks be
configured to listen on IPX socket 36880 (9010 hexadecimal) configured to listen on IPX socket 36880 (9010 hexadecimal)
The partyTable also lists the maximum message size which a SNMPv2 party When an SNMPv2 entity uses this transport mapping, it must be capable of |
is willing to accept. This value must be at least 546 octets. accepting messages that are at least 546 octets in size. |
Implementation of larger values is encouraged whenever possible. Implementation of larger values is encouraged whenever possible.
7. Proxy to SNMPv1 7. Proxy to SNMPv1 +
In order to provide proxy to community-based SNMP [8], some definitions
are necessary for both transport domains and authentication protocols.
7.1. Transport Domain: rfc1157Domain
The transport domain, rfc1157Domain, indicates the transport mapping for
community-based SNMP messages defined in RFC 1157. When a party's
transport domain (partyTDomain) is rfc1157Domain:
(1) the party's transport address (partyTAddress) shall be 6 octets
long, the initial 4 octets containing the IP-address in network-
byte order, and the last two octets containing the UDP port in
network-byte order; and,
(2) the party's authentication protocol (partyAuthProtocol) shall be
rfc1157noAuth.
When a proxy context specifies a proxy destination party which has
rfc1157Domain as its transport domain:
(1) the proxy source party (contextProxySrcParty) and proxied context
(contextProxyContext) components of the proxy context are
irrelevant; and,
(2) Section 3.1 of [9] specifies the behavior of the proxy agent.
7.2. Authentication Algorithm: rfc1157noAuth
A party's authentication protocol (partyAuthProtocol) specifies the
protocol and mechanism by which the party authenticates the integrity
and origin of the SNMPv1 or SNMPv2 PDUs it generates. When a party's
authentication protocol is rfc1157noAuth:
(1) the party's public authentication key (partyAuthPublic), clock
(partyAuthClock), and lifetime (partyAuthLifetime) are irrelevant;
and,
(2) the party's private authentication key (partyAuthPrivate) shall be
used as the 1157 community for the proxy destination, and shall be
at least one octet in length. (No maximum length is specified.)
Note that when setting the party's private authentication key, the In order to provide proxy to SNMPv1 [8], it may be useful to define a |
exclusive-OR semantics specified in [10] still apply. transport domain, rfc1157Domain, which indicates the transport mapping |
for SNMP messages as defined in RFC 1157. |
Section 3.1 of [9] specifies the behavior of the proxy agent.
8. Serialization using the Basic Encoding Rules 8. Serialization using the Basic Encoding Rules -
When the Basic Encoding Rules [11] are used for serialization: When the Basic Encoding Rules [10] are used for serialization: |
(1) When encoding the length field, only the definite form is used; use (1) When encoding the length field, only the definite form is used; use
of the indefinite form encoding is prohibited. Note that when of the indefinite form encoding is prohibited. Note that when
using the definite-long form, it is permissible to use more than using the definite-long form, it is permissible to use more than
the minimum number of length octets necessary to encode the length the minimum number of length octets necessary to encode the length
field. field.
(2) When encoding the value field, the primitive form shall be used for (2) When encoding the value field, the primitive form shall be used for
all simple types, i.e., INTEGER, OCTET STRING, and OBJECT all simple types, i.e., INTEGER, OCTET STRING, and OBJECT
IDENTIFIER (either IMPLICIT or explicit). The constructed form of IDENTIFIER (either IMPLICIT or explicit). The constructed form of
encoding shall be used only for structured types, i.e., a SEQUENCE encoding shall be used only for structured types, i.e., a SEQUENCE
or an IMPLICIT SEQUENCE. or an IMPLICIT SEQUENCE.
(3) When encoding an object whose syntax is described using the BITS (3) When encoding an object whose syntax is described using the BITS
construct, the value is encoded as an OCTET STRING, in which all construct, the value is encoded as an OCTET STRING, in which all
the named bits in (the definition of) the bitstring, commencing | the named bits in (the definition of) the bitstring, commencing
with the first bit and proceeding to | with the first bit and proceeding to the last bit, are placed in
the last bit, are placed in bits 8 to 1 of the first octet, bits 8 to 1 of the first octet, followed by bits 8 to 1 of each
followed by bits 8 to 1 of each subsequent octet in turn, followed subsequent octet in turn, followed by as many bits as are needed of
by as many bits as are needed of the final subsequent octet, the final subsequent octet, commencing with bit 8. Remaining bits,
commencing with bit 8. Remaining bits, if any, of the final octet + if any, of the final octet are set to zero on generation and
are set to zero on generation and ignored on receipt. + ignored on receipt.
These restrictions apply to all aspects of ASN.1 encoding, including the These restrictions apply to all aspects of ASN.1 encoding, including the
message wrappers, protocol data units, and the data objects they message wrappers, protocol data units, and the data objects they
contain. contain.
8.1. Usage Example 8.1. Usage Example
As an example of applying the Basic Encoding Rules, suppose one wanted As an example of applying the Basic Encoding Rules, suppose one wanted
to encode an instance of the GetBulkRequest-PDU [1]: to encode an instance of the GetBulkRequest-PDU [1]:
skipping to change at page 18, line 7 skipping to change at page 17, line 7
SEQUENCE 30 0d SEQUENCE 30 0d
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04 OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04
NULL 05 00 NULL 05 00
Note that the initial SEQUENCE is not encoded using the minimum number Note that the initial SEQUENCE is not encoded using the minimum number
of length octets. (The first octet of the length, 82, indicates that of length octets. (The first octet of the length, 82, indicates that
the length of the content is encoded in the next two octets.) the length of the content is encoded in the next two octets.)
9. Acknowledgements 9. Acknowledgements
The authors wish to acknowledge the contributions of the SNMPv2 Working This document is the result of significant work by the four major
Group in general. In particular, the following individuals contributors:
Dave Arneson (Cabletron), Jeffrey Case (SNMP Research, case@snmp.com)
Uri Blumenthal (IBM), Keith McCloghrie (Cisco Systems, kzm@cisco.com)
Doug Book (Chipcom), Marshall Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
Maria Greene (Ascom Timeplex), Steven Waldbusser (International Network Services, stevew@uni.ins.com)
Deirdre Kostik (Bellcore),
Dave Harrington (Cabletron),
Jeff Johnson (Cisco Systems),
Brian O'Keefe (Hewlett Packard),
Dave Perkins (Bay Networks),
Randy Presuhn (Peer Networks),
Shawn Routhier (Epilogue),
Bob Stewart (Cisco Systems),
Kaj Tesink (Bellcore).
deserve special thanks for their contributions. In addition, the contributions of the SNMPv2 Working Group are
acknowledged. In particular, a special thanks is extended for the
contributions of:
Alexander I. Alten (Novell)
Dave Arneson (Cabletron)
Uri Blumenthal (IBM)
Doug Book (Chipcom)
Kim Curran (Bell-Northern Research)
Jim Galvin (Trusted Information Systems)
Maria Greene (Ascom Timeplex)
Iain Hanson (Digital)
Dave Harrington (Cabletron)
Nguyen Hien (IBM)
Jeff Johnson (Cisco Systems)
Michael Kornegay (Object Quest)
Deirdre Kostick (AT&T Bell Labs)
David Levi (SNMP Research)
Daniel Mahoney (Cabletron)
Bob Natale (ACE*COMM)
Brian O'Keefe (Hewlett Packard)
Andrew Pearson (SNMP Research)
Dave Perkins (Peer Networks)
Randy Presuhn (Peer Networks)
Aleksey Romanov (Quality Quorum)
Shawn Routhier (Epilogue)
Jon Saperia (BGS Systems)
Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
Kaj Tesink (Bellcore)
Glenn Waters (Bell-Northern Research)
Bert Wijnen (IBM)
10. References 10. References
[1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., "Protocol [1] McCloghrie, K., Editor, |
Operations for Version 2 of the Simple Network Management Protocol "Protocol Operations for Version 2 of the Simple Network Management
(SNMPv2)", Internet Draft, SNMP Research, Inc., Cisco Systems, Protocol (SNMPv2)", Internet Draft, Cisco Systems, September 1995. |
Dover Beach Consulting, Inc., Carnegie Mellon University, May 1995. |
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980. USC/Information Sciences Institute, August 1980.
[3] Information processing systems - Open Systems Interconnection - [3] Information processing systems - Open Systems Interconnection -
Transport Service Definition, International Organization for Transport Service Definition, International Organization for
Standardization. International Standard 8072, (June, 1986). Standardization. International Standard 8072, (June, 1986).
[4] Information processing systems - Open Systems Interconnection - [4] Information processing systems - Open Systems Interconnection -
Transport Service Definition - Addendum 1: Connectionless-mode Transport Service Definition - Addendum 1: Connectionless-mode
skipping to change at page 19, line 16 skipping to change at page 18, line 37
Carnegie Mellon University, July 1991. Carnegie Mellon University, July 1991.
[7] Network System Technical Interface Overview. Novell, Inc, (June, [7] Network System Technical Interface Overview. Novell, Inc, (June,
1989). 1989).
[8] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network [8] Case, J., Fedor, M., Schoffstall, M., Davin, J., "Simple Network
Management Protocol", STD 15, RFC 1157, SNMP Research, Performance Management Protocol", STD 15, RFC 1157, SNMP Research, Performance
Systems International, MIT Laboratory for Computer Science, May Systems International, MIT Laboratory for Computer Science, May
1990. 1990.
[9] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S., [9] McCloghrie, K., Editor, |
"Coexistence between Version 1 and Version 2 of the Internet- "Coexistence between Version 1 and Version 2 of the Internet-
standard Network Management Framework", Internet Draft, SNMP standard Network Management Framework", Internet Draft, Cisco |
Research, Inc., Cisco Systems, Dover Beach Consulting, Inc., Systems, September 1995. |
Carnegie Mellon University, May 1995. |
[10] Case, J., Galvin, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Party MIB for Version 2 of the Simple Network Management Protocol
(SNMPv2)", Internet Draft, SNMP Research, Inc., Trusted Information
Systems, Cisco Systems, Dover Beach Consulting, Inc., Carnegie
Mellon University, May 1995. |
[11] Information processing systems - Open Systems Interconnection - [10] -
Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation Specification of Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1), International Organization for Standardization. One (ASN.1), International Organization for Standardization.
International Standard 8825, December 1987. - International Standard 8825, December 1987.
11. Security Considerations 11. Security Considerations
Security issues are not discussed in this memo. Security issues are not discussed in this memo.
12. Authors' Addresses 12. Editor's Address
Jeffrey D. Case
SNMP Research, Inc.
3001 Kimberlin Heights Rd.
Knoxville, TN 37920-9716
US
Phone: +1 615 573 1434
Email: case@snmp.com
Keith McCloghrie Keith McCloghrie -
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive, 170 West Tasman Drive |
San Jose CA 95134-1706. San Jose, CA 95134-1706 |
US |
Phone: +1 408 526 5260 Phone: +1 408 526 5260
Email: kzm@cisco.com Email: kzm@cisco.com
Marshall T. Rose Table of Contents -
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
US
Phone: +1 415 968 1052
Email: mrose@dbc.mtview.ca.us
Steven Waldbusser
Carnegie Mellon University
5000 Forbes Ave
Pittsburgh, PA 15213
US
Phone: +1 412 268 6628
Email: waldbusser@cmu.edu
Table of Contents
1 Introduction .................................................... 2 1 Introduction .................................................... 2
1.1 A Note on Terminology ......................................... 2 1.1 A Note on Terminology ......................................... 2
2 Definitions ..................................................... 3 2 Definitions ..................................................... 3
3 SNMPv2 over UDP ................................................. 7 3 SNMPv2 over UDP ................................................. 7
3.1 Serialization ................................................. 7 3.1 Serialization ................................................. 7
3.2 Well-known Values ............................................. 7 3.2 Well-known Values ............................................. 7
4 SNMPv2 over OSI ................................................. 8 4 SNMPv2 over OSI ................................................. 8
4.1 Serialization ................................................. 8 4.1 Serialization ................................................. 8
4.2 Well-known Values ............................................. 8 4.2 Well-known Values ............................................. 8
skipping to change at page 21, line 28 skipping to change at page 20, line 28
5.2 Well-known Values ............................................. 9 5.2 Well-known Values ............................................. 9
5.3 Discussion of AppleTalk Addressing ............................ 9 5.3 Discussion of AppleTalk Addressing ............................ 9
5.3.1 How to Acquire NBP names .................................... 10 5.3.1 How to Acquire NBP names .................................... 10
5.3.2 When to Turn NBP names into DDP addresses ................... 10 5.3.2 When to Turn NBP names into DDP addresses ................... 10
5.3.3 How to Turn NBP names into DDP addresses .................... 11 5.3.3 How to Turn NBP names into DDP addresses .................... 11
5.3.4 What if NBP is broken ....................................... 11 5.3.4 What if NBP is broken ....................................... 11
6 SNMPv2 over IPX ................................................. 13 6 SNMPv2 over IPX ................................................. 13
6.1 Serialization ................................................. 13 6.1 Serialization ................................................. 13
6.2 Well-known Values ............................................. 13 6.2 Well-known Values ............................................. 13
7 Proxy to SNMPv1 ................................................. 14 7 Proxy to SNMPv1 ................................................. 14
7.1 Transport Domain: rfc1157Domain ............................... 14 8 Serialization using the Basic Encoding Rules .................... 15
7.2 Authentication Algorithm: rfc1157noAuth ....................... 14 8.1 Usage Example ................................................. 16
8 Serialization using the Basic Encoding Rules .................... 16 9 Acknowledgements ................................................ 17
8.1 Usage Example ................................................. 17
9 Acknowledgements ................................................ 18
10 References ..................................................... 18 10 References ..................................................... 18
11 Security Considerations ........................................ 20 11 Security Considerations ........................................ 19
12 Authors' Addresses ............................................. 20 12 Editor's Address ............................................... 19
 End of changes. 37 change blocks. 
183 lines changed or deleted 113 lines changed or added

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