As per Relevance of the word mappings, we have this rfc below:
Network Working Group J.
Request for Comments: 1449 SNMP Research, Inc
K.
Hughes LAN
M.
Dover Beach Consulting, Inc
S.
Carnegie Mellon
April 1993
Transport
for version 2 of
Simple Network Management Protocol (SNMPv2)
Status of this
This RFC specifes an IAB standards track protocol for
Internet community, and requests discussion and
for improvements. Please refer to the current edition of
"IAB Official Protocol Standards" for the
state and status of this protocol. Distribution of this
is unlimited
Table of
1 Introduction .......................................... 2
1.1 A Note on Terminology ............................... 2
2 Definitions ........................................... 3
3 SNMPv2 over UDP ....................................... 7
3.1 Serialization ....................................... 7
3.2 Well-known Values ................................... 7
4 SNMPv2 over OSI ....................................... 8
4.1 Serialization ....................................... 8
4.2 Well-known Values ................................... 8
5 SNMPv2 over DDP ....................................... 9
5.1 Serialization ....................................... 9
5.2 Well-known Values ................................... 9
5.3 Discussion of AppleTalk Addressing .................. 9
5.3.1 How to Acquire NBP names .......................... 10
5.3.2 When 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 ............................. 12
6 SNMPv2 over IPX ....................................... 13
6.1 Serialization ....................................... 13
6.2 Well-known Values ................................... 13
7 Proxy to SNMPv1 ....................................... 14
7.1 Transport Domain: rfc1157Domain ..................... 14
7.2 Authentication Algorithm: rfc1157noAuth ............. 14
Case, McCloghrie, Rose & Waldbusser [Page i
RFC 1449 Transport Mappings for SNMPv2 April 1993
8 Serialization using the Basic Encoding Rules .......... 16
8.1 Usage Example ....................................... 17
9 Acknowledgements ...................................... 18
10 References ........................................... 22
11 Security Considerations .............................. 24
12 Authors' Addresses ................................... 24
13 Security Considerations .............................. 25
14 Authors' Addresses ................................... 25
Case, McCloghrie, Rose & Waldbusser [Page 1]
RFC 1449 Transport Mappings for SNMPv2 April 1993
1.
A network management system contains: several (
many) nodes, each with a processing entity, termed an agent
which has access to management instrumentation; at least
management station; and, a management protocol, used to
management information between the agents and
stations. Operations of the protocol are carried out under
administrative framework which defines both authentication
authorization policies
Network management stations execute management
which monitor and control network elements. Network
are devices such as hosts, routers, terminal servers, etc.,
which are monitored and controlled through access to
management information
The management protocol, version 2 of the Simple
Management Protocol [1], may be used over a variety
protocol suites. It is the purpose of this document to
how the SNMPv2 maps onto an initial set of transport domains
Other mappings may be defined in the future
Although several mappings are defined, the mapping onto UDP
the preferred mapping. As such, to provide for the
level of interoperability, systems which choose to
other mappings should also provide for proxy service to
UDP mapping
1.1. A Note on
For the purpose of exposition, the original Internet-
Network 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 2
(SNMPv2).
Case, McCloghrie, Rose & Waldbusser [Page 2]
RFC 1449 Transport Mappings for SNMPv2 April 1993
2.
SNMPv2-TM DEFINITIONS ::=
snmpDomains,
FROM SNMPv2-
TEXTUAL-
FROM SNMPv2-TC
-- SNMPv2 over
snmpUDPDomain OBJECT IDENTIFIER ::= { snmpDomains 1 }
-- for a SnmpUDPAddress of length 6:
--
-- octets contents
-- 1-4 IP-address network-byte
-- 5-6 UDP-port network-byte
--
SnmpUDPAddress ::= TEXTUAL-
DISPLAY-HINT "1d.1d.1d.1d/2d
STATUS
"Represents a UDP address."
SYNTAX OCTET STRING (SIZE (6))
Case, McCloghrie, Rose & Waldbusser [Page 3]
RFC 1449 Transport Mappings for SNMPv2 April 1993
-- SNMPv2 over
snmpCLNSDomain OBJECT IDENTIFIER ::= { snmpDomains 2 }
snmpCONSDomain OBJECT IDENTIFIER ::= { snmpDomains 3 }
-- for a SnmpOSIAddress of length m
--
-- octets contents
-- 1 length of NSAP "n" as an unsigned-
-- (either 0 or from 3 to 20)
-- 2..(n+1) NSAP concrete binary
-- (n+2)..m TSEL string of (up to 64)
--
SnmpOSIAddress ::= TEXTUAL-
DISPLAY-HINT "*1x:/1x:"
STATUS
"Represents an OSI transport-address."
SYNTAX OCTET STRING (SIZE (1 | 4..85))
Case, McCloghrie, Rose & Waldbusser [Page 4]
RFC 1449 Transport Mappings for SNMPv2 April 1993
-- SNMPv2 over
snmpDDPDomain OBJECT IDENTIFIER ::= { snmpDomains 4 }
-- for a SnmpNBPAddress of length m
--
-- octets contents
-- 1 length of object "n" as an unsigned
-- 2..(n+1) object string of (up to 32)
-- n+2 length of type "p" as an unsigned
-- (n+3)..(n+2+p) type string of (up to 32)
-- n+3+p length of zone "q" as an unsigned
-- (n+4+p)..m zone string of (up to 32)
--
-- for comparison purposes, strings are case-
--
-- all strings may contain any octet other than 255 (hex ff
--
SnmpNBPAddress ::= TEXTUAL-
STATUS
"Represents an NBP name."
SYNTAX OCTET STRING (SIZE (3..99))
-- SNMPv2 over
snmpIPXDomain OBJECT IDENTIFIER ::= { snmpDomains 5 }
-- for a SnmpIPXAddress of length 12:
--
-- octets contents
-- 1-4 network-number network-byte
-- 5-10 physical-address network-byte
-- 11-12 socket-number network-byte
--
SnmpIPXAddress ::= TEXTUAL-
DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d
STATUS
"Represents an IPX address."
SYNTAX OCTET STRING (SIZE (12))
Case, McCloghrie, Rose & Waldbusser [Page 5]
RFC 1449 Transport Mappings for SNMPv2 April 1993
-- for proxy to community-based SNMPv1 (RFC 1157)
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
-- uses
rfc1157Domain OBJECT IDENTIFIER ::= { rfc1157Proxy 1 }
-- the community-based
rfc1157noAuth OBJECT IDENTIFIER ::= { rfc1157Proxy 2 }
Case, McCloghrie, Rose & Waldbusser [Page 6]
RFC 1449 Transport Mappings for SNMPv2 April 1993
3. SNMPv2 over
This is the preferred transport mapping
3.1.
Each instance of a message is serialized onto a single UDP[2]
datagram, using the algorithm specified in Section 8.
3.2. Well-known
Although the partyTable gives transport addressing
for an SNMPv2 party, it is suggested that
configure their SNMPv2 entities acting in an agent role
listen on UDP port 161. Further, it is suggested
notification sinks be configured to listen on UDP port 162.
The partyTable also lists the maximum message size which
SNMPv2 party is willing to accept. This value must be
least 484 octets. Implementation of larger values
encouraged whenever possible
Case, McCloghrie, Rose & Waldbusser [Page 7]
RFC 1449 Transport Mappings for SNMPv2 April 1993
4. SNMPv2 over
This is an optional transport mapping
4.1.
Each instance of a message is serialized onto a single
[3,4] for the OSI Connectionless-mode Transport
(CLTS), using the algorithm specified in Section 8.
4.2. Well-known
Although the partyTable gives transport addressing
for an SNMPv2 party, it is suggested that
configure their SNMPv2 entities acting in an agent role
listen on transport selector "snmp-l" (which consists of
ASCII characters), when using a CL-mode network service
realize the CLTS. Further, it is suggested that
sinks be configured to listen on transport selector "snmpt-l
(which consists of seven ASCII characters) when using a CL
mode network service to realize the CLTS. Similarly,
using a CO-mode network service to realize the CLTS,
suggested transport selectors are "snmp-o" and "snmpt-o",
agent and notification sink, respectively
The partyTable also lists the maximum message size which
SNMPv2 party is willing to accept. This value must be
least 484 octets. Implementation of larger values
encouraged whenever possible
Case, McCloghrie, Rose & Waldbusser [Page 8]
RFC 1449 Transport Mappings for SNMPv2 April 1993
5. SNMPv2 over
This is an optional transport mapping
5.1.
Each instance of a message is serialized onto a single
datagram [5], using the algorithm specified in Section 8.
5.2. Well-known
SNMPv2 messages are sent using DDP protocol type 8. SNMPv
entities acting in an agent role listens on DDP socket
8, whilst notification sinks listen on DDP socket number 9.
Although the partyTable gives transport addressing
for an SNMPv2 party, administrators must configure
SNMPv2 entities acting in an agent role to use NBP type "
Agent" (which consists of ten ASCII characters),
notification sinks must be configured to use NBP type "
Trap Handler" (which consists of seventeen ASCII characters).
The NBP name for agents and notification sinks should
stable - NBP names should not change any more often than
IP address of a typical TCP/IP node. It is suggested that
NBP name be stored in some form of stable storage
The partyTable also lists the maximum message size which
SNMPv2 party is willing to accept. This value must be
least 484 octets. Implementation of larger values
encouraged whenever possible
5.3. Discussion of AppleTalk
The AppleTalk protocol suite has certain features not
in the TCP/IP suite. AppleTalk's naming strategy and
dynamic nature of address assignment can cause problems
SNMPv2 entities that wish to manage AppleTalk networks
TCP/IP nodes have an associated IP address which
each from the other. In contrast, AppleTalk nodes
have no such characteristic. The network-level address,
often relatively stable, can change at every reboot (or
Case, McCloghrie, Rose & Waldbusser [Page 9]
RFC 1449 Transport Mappings for SNMPv2 April 1993
frequently).
Thus, when SNMPv2 is mapped over DDP, nodes are identified
a "name", rather than by an "address". Hence, all
nodes that implement this mapping are required to respond
NBP lookups and confirms (e.g., implement the NBP
stub), which guarantees that a mapping from NBP name to
address will be possible
In determining the SNMP identity to register for an SNMPv
entity, it is suggested that the SNMP identity be a name
is associated with other network services offered by
machine
NBP lookups, which are used to map NBP names into
addresses, can cause large amounts of network traffic as
as consume CPU resources. It is also the case that
ability to perform an NBP lookup is sensitive to
network disruptions (such as zone table inconsistencies)
would not prevent direct AppleTalk communications between
SNMPv2 entities
Thus, it is recommended that NBP lookups be used infrequently
primarily to create a cache of name-to-address mappings
These cached mappings should then be used for any further
traffic. It is recommended that SNMPv2 entities acting in
manager role should maintain this cache between reboots.
caching can help minimize network traffic, reduce CPU load
the network, and allow for (some amount of) network
shooting when the basic name-to-address translation
is broken
5.3.1. How to Acquire NBP
An SNMPv2 entity acting in a manager role may have a pre
configured list of names of "known" SNMPv2 entities acting
an agent role. Similarly, an SNMPv2 entity acting in
manager role might interact with an operator. Finally,
SNMPv2 entity acting in a manager role might communicate
all SNMPv2 entities acting in an agent role in a set of
or networks
Case, McCloghrie, Rose & Waldbusser [Page 10]
RFC 1449 Transport Mappings for SNMPv2 April 1993
5.3.2. When to Turn NBP names into DDP
When an SNMPv2 entity uses a cache entry to address an
packet, it should attempt to confirm the validity mapping,
the mapping hasn't been confirmed within the last T1 seconds
This cache entry lifetime, T1, has a minimum, default value
60 seconds, and should be configurable
An SNMPv2 entity acting in a manager role may decide to
its cache of names prior to actually communicating
another SNMPv2 entity. In general, it is expected that
an entity may want to keep certain mappings "more current
than other mappings, e.g., those nodes which represent
network infrastructure (e.g., routers) may be deemed "
important".
Note that an SNMPv2 entity acting in a manager role should
prime its entire cache upon initialization - rather, it
attempt resolutions over an extended period of time (
in some pre-determined or configured priority order). Each
these resolutions might, in fact, be a wildcard lookup in
given zone
An SNMPv2 entity acting in an agent role must never prime
cache. Such an entity should do NBP lookups (or confirms
only when it needs to send an SNMP trap. When generating
response, such an entity does not need to confirm a
entry
5.3.3. How to Turn NBP names into DDP
If the only piece of information available is the NBP name
then an NBP lookup should be performed to turn that name
a DDP address. However, if there is a piece of
information, it can be used as a hint to perform an
confirm (which sends a unicast to the network address which
presumed to be the target of the name lookup) to see if
stale information is, in fact, still valid
An NBP name to DDP address mapping can also be
implicitly using only SNMP transactions. For example,
SNMPv2 entity acting in a manager role issuing a
operation could also retrieve the relevant objects from
NBP group [6] for the SNMPv2 entity acting in an agent role
Case, McCloghrie, Rose & Waldbusser [Page 11]
RFC 1449 Transport Mappings for SNMPv2 April 1993
This information can then be correlated with the source
address of the response
5.3.4. What if NBP is
Under some circumstances, there may be connectivity
two SNMPv2 entities, but the NBP mapping machinery may
broken, e.g.,
o the NBP FwdReq (forward NBP lookup onto local
network) mechanism might be broken at a router on
other entity's network; or
o the NBP BrRq (NBP broadcast request) mechanism might
broken at a router on the entity's own network; or
o NBP might be broken on the other entity's node
An SNMPv2 entity acting in a manager role which is
to AppleTalk management might choose to alleviate some
these failures by directly implementing the router portion
NBP. For example, such an entity might already know all
zones on the AppleTalk internet and the networks on which
zone appears. Given an NBP lookup which fails, the
could send an NBP FwdReq to the network in which the agent
last located. If that failed, the station could then send
NBP LkUp (NBP lookup packet) as a directed (DDP) multicast
each network number on that network. Of the above (single
failures, this combined approach will solve the case
either the local router's BrRq-to-FwdReq mechanism is
or the remote router's FwdReq-to-LkUp mechanism is broken
Case, McCloghrie, Rose & Waldbusser [Page 12]
RFC 1449 Transport Mappings for SNMPv2 April 1993
6. SNMPv2 over
This is an optional transport mapping
6.1.
Each instance of a message is serialized onto a single
datagram [7], using the algorithm specified in Section 8.
6.2. Well-known
SNMPv2 messages are sent using IPX packet type 4 (i.e.,
Exchange Packet).
Although the partyTable gives transport addressing
for an SNMPv2 party, it is suggested that
configure their SNMPv2 entities acting in an agent role
listen on IPX socket 36879 (900f hexadecimal). Further, it
suggested that notification sinks be configured to listen
IPX socket 36880 (9010 hexadecimal
The partyTable also lists the maximum message size which
SNMPv2 party is willing to accept. This value must be
least 546 octets. Implementation of larger values
encouraged whenever possible
Case, McCloghrie, Rose & Waldbusser [Page 13]
RFC 1449 Transport Mappings for SNMPv2 April 1993
7. Proxy to SNMPv
In order to provide proxy to community-based SNMP [8],
definitions are necessary for both transport domains
authentication protocols
7.1. Transport Domain: rfc1157
The transport domain, rfc1157Domain, indicates the
mapping for community-based SNMP messages defined in RFC 1157.
When a party's transport domain (partyTDomain)
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
containing the UDP port in network-byte order; and
(2) the party's authentication protocol (partyAuthProtocol
shall be rfc1157noAuth
When a proxy relationship identifies a proxy destination
which has rfc1157Domain as its transport domain
(1) the proxy source party (contextSrcPartyIndex) and
context (contextProxyContext) components of the
relationship are irrelevant; and
(2) Section 3.1 of [9] specifies the behavior of the
agent
7.2. Authentication Algorithm: rfc1157
A party's authentication protocol (partyAuthProtocol
specifies the protocol and mechanism by which the
authenticates the integrity and origin of the SNMPv1 or SNMPv
PDUs it generates. When a party's authentication protocol
rfc1157noAuth
(1) the party's public authentication key (partyAuthPublic),
clock (partyAuthClock), and lifetime (partyAuthLifetime
are irrelevant; and
Case, McCloghrie, Rose & Waldbusser [Page 14]
RFC 1449 Transport Mappings for SNMPv2 April 1993
(2) the party's private authentication
(partySecretsAuthPrivate) shall be used as the 1157
community for the proxy destination, and shall be
least one octet in length. (No maximum length
specified.)
Note that when setting the party's private authentication key
the exclusive-OR semantics specified in [10] still apply
Case, McCloghrie, Rose & Waldbusser [Page 15]
RFC 1449 Transport Mappings for SNMPv2 April 1993
8. Serialization using the Basic Encoding
When the Basic Encoding Rules [11] are used for serialization
(1) When encoding the length field, only the definite form
used; use of the indefinite form encoding is prohibited
Note that when using the definite-long form, it
permissible to use more than the minimum number of
octets necessary to encode the length field
(2) When encoding the value field, the primitive form
be used for all simple types, i.e., INTEGER,
STRING, OBJECT IDENTIFIER, and BIT STRING (
IMPLICIT or explicit). The constructed form of
shall be used only for structured types, i.e., a
or an IMPLICIT SEQUENCE
(3) When a BIT STRING is serialized, all named-bits
transferred regardless of their truth-value. Further,
the number of named-bits is not an integral multiple
eight, then the fewest number of additional zero-
bits are transferred so that an integral multiple
eight bits is transferred
These restrictions apply to all aspects of ASN.1 encoding
including the message wrappers, protocol data units, and
data objects they contain
Case, McCloghrie, Rose & Waldbusser [Page 16]
RFC 1449 Transport Mappings for SNMPv2 April 1993
8.1. Usage
As an example of applying the Basic Encoding Rules,
one wanted to encode an instance of the GetBulkRequest-
[1]:
[5] IMPLICIT SEQUENCE {
request-id 1414684022,
non-repeaters 1,
max-repetitions 2,
variable-bindings {
{ name sysUpTime
value { unspecified NULL } },
{ name ipNetToMediaPhysAddress
value { unspecified NULL } },
{ name ipNetToMediaType
value { unspecified NULL } }
}
}
Applying the BER, this would be encoded (in hexadecimal) as
[5] IMPLICIT SEQUENCE a5 82 00 39
INTEGER 02 04 52 54 5d 76
INTEGER 02 01 01
INTEGER 02 01 02
SEQUENCE 30 2
SEQUENCE 30 0
OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03
NULL 05 00
SEQUENCE 30 0
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02
NULL 05 00
SEQUENCE 30 0
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04
NULL 05 00
Note that the initial SEQUENCE is not encoded using
minimum number of length octets. (The first octet of
length, 82, indicates that the length of the content
encoded in the next two octets.)
Case, McCloghrie, Rose & Waldbusser [Page 17]
RFC 1449 Transport Mappings for SNMPv2 April 1993
9.
The UDP-based mapping is based, in part, on RFC 1157.
The OSI-based mapping is based, in part, on RFC 1283.
The DDP-based mapping is based, in part, on earlier work
Greg Minshall of Novell, Inc., and Mike Ritter of
Computer, Inc
The IPX-based mapping is based, in part, on RFC 1298.
The section on proxy to community-based SNMP is based
earlier work that was based in part on a suggestion
Jonathan Biggar of Netlabs, Inc
Finally, the comments of the SNMP version 2 working group
gratefully acknowledged
Beth Adams, Network Management
Steve Alexander, INTERACTIVE Systems
David Arneson, Cabletron
Toshiya
Fred Baker,
Jim Barnes, Xylogics, Inc
Brian
Andy Bierman, SynOptics Communications, Inc
Uri Blumenthal, IBM
Fred Bohle,
Jack
Theodore Brunner,
Stephen F. Bush, GE Information
Jeffrey D. Case, University of Tennessee,
John Chang, IBM
Szusin Chen, Sun
Robert
Chris Chiotasso, Ungermann-
Bobby A. Clay, NASA/
John Cooke,
Tracy Cox,
Juan Cruz, Datability, Inc
David Cullerot, Cabletron
Cathy Cunningham,
James R. (Chuck) Davin,
Michael Davis,
Case, McCloghrie, Rose & Waldbusser [Page 18]
RFC 1449 Transport Mappings for SNMPv2 April 1993
Mike Davison,
Cynthia DellaTorre,
Taso N. Devetzis,
Manual Diaz, DAVID Systems, Inc
Jon Dreyer, Sun
David Engel, Optical Data
Mike Erlinger,
Roger Fajman,
Daniel Fauvarque, Sun
Karen Frisa,
Shari Galitzer,
Shawn Gallagher, Digital Equipment
Richard Graveman,
Maria Greene, Xyplex, Inc
Michel Guittet,
Robert Gutierrez,
Bill Hagerty, Cabletron
Gary W. Haney, Martin Marietta Energy
Patrick Hanil, Nokia
Matt Hecht, SNMP Research, Inc
Edward A. Heiner, Jr., Synernetics Inc
Susan E. Hicks, Martin Marietta Energy
Geral Holzhauer,
John Hopprich, DAVID Systems, Inc
Jeff Hughes, Hewlett-
Robin Iddon, Axon Networks, Inc
David
Kevin M. Jackson, Concord Communications, Inc
Ole J. Jacobsen, Interop
Ronald Jacoby, Silicon Graphics, Inc
Satish Joshi, SynOptics Communications, Inc
Frank Kastenholz, FTP
Mark Kepke, Hewlett-
Ken Key, SNMP Research, Inc
Zbiginew Kielczewski,
Jongyeoi
Andrew Knutsen, The Santa Cruz
Michael L. Kornegay,
Deirdre C. Kostik,
Cheryl Krupczak, Georgia
Mark S. Lewis,
David
David Lindemulder, AT&T/
Ben Lisowski,
David Liu, Bell-Northern
Case, McCloghrie, Rose & Waldbusser [Page 19]
RFC 1449 Transport Mappings for SNMPv2 April 1993
John Lunny, The Wollongong
Robert C. Lushbaugh Martin, Marietta Energy
Michael Luufer,
Carl Madison, Star-Tek, Inc
Keith McCloghrie, Hughes LAN
Evan McGinnis, 3Com
Bill McKenzie, IBM
Donna McMaster, SynOptics Communications, Inc
John Medicke, IBM
Doug Miller,
Dave Minnich,
Mohammad Mirhakkak,
Rohit Mital,
George Mouradian, AT&T Bell
Patrick Mullaney, Cabletron
Dan Myers, 3Com
Rina Nathaniel, Rad Network Devices Ltd
Hien V. Nguyen,
Mo
Tom
William B. Norton,
Steve Onishi, Wellfleet Communications, Inc
David T. Perkins, SynOptics Communications, Inc
Carl Powell,
Ilan Raab, SynOptics Communications, Inc
Richard Ramons, AT&
Venkat D. Rangan, Metric Network Systems, Inc
Louise Reingold,
Sam Roberts, Farallon Computing, Inc
Kary Robertson, Concord Communications, Inc
Dan Romascanu, Lannet Data Communications Ltd
Marshall T. Rose, Dover Beach Consulting, Inc
Shawn A. Routhier, Epilogue Technology
Chris
Asaf Rubissa,
Jon Saperia, Digital Equipment
Michael
Mike Scanlon,
Sam Schaen,
John Seligson, Ultra Network
Paul A. Serice, Corporation for Open
Chris Shaw, Banyan
Timon
Robert Snyder, Cisco
Joo Young
Case, McCloghrie, Rose & Waldbusser [Page 20]
RFC 1449 Transport Mappings for SNMPv2 April 1993
Roy Spitier,
Einar Stefferud, Network Management
John Stephens, Cayman Systems, Inc
Robert L. Stewart, Xyplex, Inc. (chair
Kaj Tesink,
Dean Throop, Data
Ahmet Tuncay, France Telecom-
Maurice Turcotte, Racal
Warren Vik, INTERACTIVE Systems
Yannis
Steven L. Waldbusser, Carnegie Mellon
Timothy M. Walden,
Alice Wang, Sun
James Watt,
Luanne Waul,
Donald E. Westlake III, Digital Equipment
Gerry
Bert Wijnen, IBM
Peter Wilson, 3Com
Steven Wong, Digital Equipment
Randy Worzella, IBM
Daniel Woycke,
Honda
Jeff Yarnell,
Chris Young,
Kiho Yum, 3Com
Case, McCloghrie, Rose & Waldbusser [Page 21]
RFC 1449 Transport Mappings for SNMPv2 April 1993
10.
[1] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Protocol Operations for version 2 of the Simple
Management Protocol (SNMPv2)", RFC 1448, SNMP Research
Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
Carnegie Mellon University, April 1993.
[2] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[3] Information processing systems - Open
Interconnection - Transport Service Definition
International Organization for Standardization
International Standard 8072, (June, 1986).
[4] Information processing systems - Open
Interconnection - Transport Service Definition -
1: Connectionless-mode Transmission,
Organization for Standardization. International
8072/AD 1, (December, 1986).
[5] G. Sidhu, R. Andrews, A. Oppenheimer, Inside
(second edition). Addison-Wesley, 1990.
[6] Waldbusser, S., "AppleTalk Management Information Base",
RFC 1243, Carnegie Mellon University, July 1991.
[7] Network System Technical Interface Overview. Novell
Inc, (June, 1989).
[8] Case, J., Fedor, M., Schoffstall, M., Davin, J., "
Network Management Protocol", STD 15, RFC 1157,
Research, Performance Systems International,
Laboratory for Computer Science, May 1990.
[9] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Coexistence between version 1 and version 2 of
Internet-standard Network Management Framework",
1452, SNMP Research, Inc., Hughes LAN Systems,
Beach Consulting, Inc., Carnegie Mellon University,
1993.
[10] McCloghrie, K., and Galvin, J., "Party MIB for version 2
of the Simple Network Management Protocol (SNMPv2)",
Case, McCloghrie, Rose & Waldbusser [Page 22]
RFC 1449 Transport Mappings for SNMPv2 April 1993
1447, Hughes LAN Systems, Trusted Information Systems
April 1993.
[11] Information processing systems - Open
Interconnection - Specification of Basic Encoding
for Abstract Syntax Notation One (ASN.1),
Organization for Standardization. International
8825, (December, 1987).
Case, McCloghrie, Rose & Waldbusser [Page 23]
RFC 1449 Transport Mappings for SNMPv2 April 1993
11. Security
Security issues are not discussed in this memo
12. Authors'
Jeffrey D.
SNMP Research, Inc
3001 Kimberlin Heights Rd
Knoxville, TN 37920-9716
Phone: +1 615 573 1434
Email: case@snmp.
Keith
Hughes LAN
1225 Charleston
Mountain View, CA 94043
Phone: +1 415 966 7934
Email: kzm@hls.
Marshall T.
Dover Beach Consulting, Inc
420 Whisman
Mountain View, CA 94043-2186
Phone: +1 415 968 1052
Email: mrose@dbc.mtview.ca.
Steven
Carnegie Mellon
4910 Forbes
Pittsburgh, PA 15213
Phone: +1 412 268 6628
Email: waldbusser@cmu.
Case, McCloghrie, Rose & Waldbusser [Page 24]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
