Internet DRAFT - draft-clark-avt-rtpmibv2
draft-clark-avt-rtpmibv2
Audio/Video Working Group Alan Clark
Internet-Draft Telchemy
Expires: January 15, 2005 Amy Pendleton
Nortel Networks
Proposed Real-Time Transport Protocol
Management Information Base Version 2
draft-clark-avt-rtpmibv2-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it defines objects for managing Real-Time Transport
Control Protocol Extended Reports (RTCP XR) VoIP Metrics (RFC3611).
Clark Expires January 2005 [Page 1]
draft-clark-avt-rtpmibv2-01.txt July 2004
Table of Contents
1. The Network Management Framework ............................. 2
2. Overview ..................................................... 3
2.1 Components .................................................. 3
2.2 Applicability of the MIB to RTP System Implementations ...... 4
2.3 The Structure of the RTCP XR MIB ............................ 4
3 Definitions ................................................... 4
4. Security Considerations ...................................... 11
5. Acknowledgements ............................................. 11
6. Intellectual Property ........................................ 11
7. References ................................................... 12
8. Authors' Addresses ........................................... 14
9. Full Copyright Statement ..................................... 14
1. The SNMP Management Framework
The SNMP Management Framework presently consists of five major
components:
o An overall architecture, described in RFC 2571 [RFC2571].
o Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in
STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC
1215 [RFC1215]. The second version, called SMIv2, is described
in STD 58, RFC 2578, RFC 2579 and RFC 2580.
o Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [RFC1157]. A second version of
the SNMP message protocol, which is not an Internet standards
track protocol, is called SNMPv2c and described in RFC 1901
[RFC1901] and RFC 1906 [RFC1906]. The third version of the
message protocol is called SNMPv3 and described in RFC 1906
[RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
o Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [RFC1157]. A second set of
protocol operations and associated PDU formats is described in
RFC 1905 [RFC1905].
o A set of fundamental applications described in RFC 2573
[RFC2573] and the view-based access control mechanism described
in RFC 2575 [RFC2575].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [RFC2570].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
Clark Expires January 2005 [Page 2]
draft-clark-avt-rtpmibv2-01.txt July 2004
This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
2. Overview
An "RTP System" may be a host end-system that runs an application
program that sends or receives RTP data packets, or it may be an
intermediate-system that forwards RTP packets. RTP Control Protocol
(RTCP) packets are sent by senders and receivers to convey
information about RTP packet transmission and reception [RFC3550].
RTP monitors may collect RTCP information on senders and receivers to
and from an RTP host or intermediate-system.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2.1 Components
The RTCP XR MIB is structured around "Session," "Receiver" and "Sender"
conceptual abstractions.
2.1.1 An RTP Session is an association of two or more participants
communicating with RTP. For each participant, the session is defined
by a particular pair of destination transport addresses (one network
address plus a port pair for RTP and RTCP). The destination
transport addresses may be common for all participants, as in the
case of IP multicast, or may be different for each, as in the case of
individual unicast addresses plus a common port pair," as defined in
section 3 of [RFC3550].
2.1.2 A "Sender" is identified within an RTP session by a 32-bit
numeric "Synchronization Source," or "SSRC", value and is "...the
source of a stream of RTP packets" as defined in section 3 of
[RFC3550]. The sender is also a source of RTCP Sender Report packets
as specified in section 6 of [RFC3550].
2.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or
multicast Receiver as described in 2.1.1, above. An RTP Receiver has
an SSRC value that is unique to the session. An RTP Receiver is a
source of RTCP Receiver Reports as specified in section 6 of
[RFC3550].
Clark Expires January 2005 [Page 3]
draft-clark-avt-rtpmibv2-01.txt July 2004
2.2 Applicability of the MIB to RTP System Implementations
The RTCP XR MIB may be used in RTP Host Systems (end systems), see
section 3 of [RFC3550] that are supporting Voice over IP (VoIP host
systems).
2.2.1 VoIP host Systems are end-systems that may use the RTCP XR MIB
to collect RTP Voice over IP session data that the host is sending or
receiving; these data may be used by a network manager to detect and
diagnose faults that occur over the lifetime of a VoIP session as in
a "help-desk" scenario.
2.2.2 Monitors of RTP Voice over IP sessions may be third-party or
may be located in the RTP host. Monitors may use the RTCP XR MIB to
collect Voice over IP session statistical data; these data may be
used by a network manager for capacity planning and other network-
management purposes. A Monitor may use the RTCP XR MIB to collect
data to permit a network manager to detect and diagnose faults in
VoIP sessions.
2.2.3 Many host systems will want to keep track of streams beyond
what they are sending and receiving. In a host monitor system, a
host agent would use RTP data from the host to maintain data about
streams it is sending and receiving, and RTCP data to collect data
about other hosts in the session.
2.3 The Structure of the RTCP XR MIB
There is one table in the RTCP XR MIB. The rtpXrVoipTable contains
objects that describe completed sessions at the host or monitor.
rtpXrVoipIndex is a global object that permits a network-
management application to obtain a unique index for conceptual row
creation in the rtpSessionTable. In this way the SNMP Set operation
MAY be used to configure a monitor.
3. Definitions
RTCPXR-MIB DEFINITIONS ::= BEGIN
IMPORTS
Counter32, Counter64, Gauge32, mib-2, Integer32,
MODULE-IDENTITY,
OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI
OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF
InterfaceIndex FROM IF-MIB;
Clark Expires January 2005 [Page 4]
draft-clark-avt-rtpmibv2-01.txt July 2004
rtcpXrMIB MODULE-IDENTITY
LAST-UPDATED TBD
ORGANIZATION
"IETF AVT Working Group"
DESCRIPTION
"The managed objects of RTCP XR systems.
Refer to RFC 3611, Real Time Control Protocol Extended
Reports (RTCP XR) Section 4.7 VoIP Metrics"
REVISION TBD
DESCRIPTION "Initial version of this MIB.
Published as draft-clark-avt-rtpmibv2-01.txt."
::= { mib-2 TBD }
--
-- OBJECTS
--
rtcpXrMIBObjects OBJECT IDENTIFIER ::= { rtcpXrMIB 1 }
rtcpXrConformance OBJECT IDENTIFIER ::= { rtcpXrMIB 2 }
--
-- RTCP Extended Reports - Voice over IP Metrics
--
rtcpXrVoipTable OBJECT-TYPE
SYNTAX SEQUENCE OF rtcpXrVoipEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"Table of information about a receiver or receivers of RTCP XR
session data. RTP hosts that receive RTCP XR session packets
MUST create an entry in this table for that receiver/sender
pair. RTP hosts that send RTCP XR session packets MAY create
an entry in this table for each receiver to their stream
using RTCP XR feedback from the RTP group. "
::= { rtcpXrMIBObjects 1 }
rtcpXrVoipEntry OBJECT-TYPE
SYNTAX rtcpXrVoipEntry
ACCESS not-accessible
STATUS mandatory
DESCRIPTION
"An entry in the table of call records. A row in this table
is created for each RTP session endpoint participating."
INDEX { rtcpXrVoipIndex }
::= { rtcpXrVoipTable 1 }
rtcpXrVoipEntry ::= SEQUENCE {
rtcpXrVoipIndex INTEGER,
rtcpXrVoipCallIdentifier OCTET STRING,
rtcpXrVoipSourceIPaddress IpAddress,
rtcpXrVoipSourcePort INTEGER,
Clark Expires January 2005 [Page 5]
draft-clark-avt-rtpmibv2-01.txt July 2004
rtcpXrVoipVocoderType INTEGER,
rtcpXrVoipCallDurationMs INTEGER,
rtcpXrVoipNetworkLossRate INTEGER,
rtcpXrVoipAverageDiscardRate INTEGER,
rtcpXrVoipBurstLossDensity INTEGER,
rtcpXrVoipBurstLenMs INTEGER,
rtcpXrVoipGapLossDensity INTEGER,
rtcpXrVoipGapLenMs INTEGER,
rtcpXrVoipAverageOneWayDelay INTEGER,
rtcpXrVoipEndSystemDelay INTEGER,
rtcpXrVoipNoiseLeveldBm INTEGER,
rtcpXrVoipSignalLeveldBm INTEGER,
rtcpXrVoipLocalRERLdB INTEGER,
rtcpXrVoipConversationalRCQ INTEGER,
rtcpXrVoipListeningMOSLQ INTEGER,
rtcpXrVoipConversationalMOSCQ INTEGER,
rtcpXrVoipPlcType INTEGER,
rtcpXrVoipJitterBufferAdaptationMode INTEGER,
rtcpXrVoipJitterBufferAdaptationRate INTEGER,
rtcpXrVoipJitterBufferAverageDelay INTEGER,
rtcpXrVoipJitterBufferMaximumDelay INTEGER,
rtcpXrVoipJitterBufferSize INTEGER
}
rtcpXrVoipIndex OBJECT-TYPE
SYNTAX INTEGER (0..65535)
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Index for this call."
::= { rtcpXrVoipEntry 1 }
rtcpXrVoipCallIdentifier OBJECT-TYPE
SYNTAX OCTET STRING
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Call identifier for this call (= SDES?)."
::= { rtcpXrVoipEntry 2 }
rtcpXrVoipSourceIPaddress OBJECT-TYPE
SYNTAX IpAddress
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Source IP address for this session."
::= { rtcpXrVoipEntry 3 }
rtcpXrVoipSourcePort OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Source UDP Port for this call."
Clark Expires January 2005 [Page 6]
draft-clark-avt-rtpmibv2-01.txt July 2004
::= { rtcpXrVoipEntry 4 }
rtcpXrVoipVocoderType OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Vocoder type used on this call."
::= { rtcpXrVoipEntry 5 }
rtcpXrVoipCallDurationMs OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Duration of call in milliseconds."
::= { rtcpXrVoipEntry 6 }
rtcpXrVoipNetworkLossRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Average rate of network packet loss (see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 7 }
rtcpXrVoipAverageDiscardRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Average rate of discards due to jitter(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 8 }
rtcpXrVoipBurstLossDensity OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Density of loss and discarded packets during burst periods.
(see RFC3611 Section 4.7)"
::= { rtcpXrVoipEntry 9 }
rtcpXrVoipBurstLenMs OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Average length of bursts in milliseconds (see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 10 }
rtcpXrVoipGapLossDensity OBJECT-TYPE
SYNTAX INTEGER
Clark Expires January 2005 [Page 7]
draft-clark-avt-rtpmibv2-01.txt July 2004
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Density of loss and discarded packets during gap periods
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 11 }
rtcpXrVoipGapLenMs OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Average length of gaps in milliseconds (see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 12 }
rtcpXrVoipAverageOneWayDelay OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Average (symmetric) one way RTCP delay on call. A value of zero may
indicate that this value has not yet been determined.
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 13 }
rtcpXrVoipEndSystemDelay OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Average end system delay on call. A value of zero may
indicate that this value has not yet been determined
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 14 }
rtcpXrVoipNoiseLeveldBm OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Measured received silent period noise level in dBm
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 15 }
rtcpXrVoipSignalLeveldBm OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Measured received signal level during talkspurts in dBm
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 16 }
Clark Expires January 2005 [Page 8]
draft-clark-avt-rtpmibv2-01.txt July 2004
rtcpXrVoipLocalRERLdB OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Residual Echo Return Loss measured at this endpoint
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 17 }
rtcpXrVoipConversationalRCQ OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Conversational quality R factor for this call
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 18 }
rtcpXrVoipListeningMOSLQ OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Estimated listening quality MOS for this call
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 19 }
rtcpXrVoipConversationalMOSCQ OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Estimated conversational quality MOS for this call
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 20 }
rtcpXrVoipPlcType OBJECT-TYPE
SYNTAX INTEGER { disabled(1),
enhanced(2),
standard(3),
unspecified (4)}
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Defines type of packet loss concealment used on this call
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 21 }
rtcpXrVoipJitterBufferAdaptationMode OBJECT-TYPE
SYNTAX INTEGER { reserved (1),
nonAdaptive (2),
adaptive (3),
Clark Expires January 2005 [Page 9]
draft-clark-avt-rtpmibv2-01.txt July 2004
unknown (4) }
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Defines if jitter buffer is in fixed or adaptive mode
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 22 }
rtcpXrVoipJitterBufferAdaptationRate OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Estimated adaptation rate of jitter buffer
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 23 }
rtcpXrVoipJitterBufferAverageDelay OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Average size of jitter buffer in mS
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 24 }
rtcpXrVoipJitterBufferMaximumDelay OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Maximum delay through jitter buffer at current size in mS
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 25 }
rtcpXrVoipJitterBufferSize OBJECT-TYPE
SYNTAX INTEGER
ACCESS read-only
STATUS mandatory
DESCRIPTION
"Absolute maximum size jitter buffer can reach in mS
(see RFC3611 Section 4.7)."
::= { rtcpXrVoipEntry 26 }
END
Clark Expires January 2005 [Page 10]
draft-clark-avt-rtpmibv2-01.txt July 2004
4. Security Considerations
In most cases, MIBs are not themselves security risks; if SNMP
security is operating as intended, the use of a MIB to view
information about a system, or to change some parameter at the
system, is a tool, not a threat.
None of the read-only objects in this MIB reports a password, though
some SDES [RFC3550] items such as the CNAME [RFC3550], the canonical
name, may be deemed sensitive depending on the security policies of a
particular enterprise. If access to these objects is not limited by
an appropriate access control policy, these objects can provide an
attacker with information about a system's configuration and the
services that that system is providing. Some enterprises view their
network and system configurations, as well as information about usage
and performance, as corporate assets; such enterprises may wish to
restrict SNMP access to most of the objects in the MIB.
Confidentiality of RTP and RTCP data packets is defined in section 9
of the RTP specification [RFC3550]. Encryption may be performed on
RTP packets, RTCP packets, or both. Encryption of RTCP packets may
pose a problem for third-party monitors though "For RTCP, it is
allowed to split a compound RTCP packet into two lower-layer packets,
one to be encrypted and one to be sent in the clear. For example,
SDES information might be encrypted while reception reports were sent
in the clear to accommodate third-party monitors [RFC3550]."
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), there is no control as
to who on the secure network is allowed to access and GET/SET
(read/change/create/delete) the objects in this MIB. It is
recommended that the implementers consider the security features as
provided by the SNMPv3 framework. Specifically, the use of the
User-based Security Model RFC 2574 [RFC2574] and the View-based
Access Control Model RFC 2575 [RFC2575] is recommended. It is then a
customer/user responsibility to ensure that the SNMP entity giving
access to an instance of this MIB, is properly configured to give
access to the objects only to those principals (users) that have
legitimate rights to indeed GET or SET (change/create/delete) them.
5. Acknowledgements
6. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
Clark Expires January 2005 [Page 11]
draft-clark-avt-rtpmibv2-01.txt July 2004
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
7. References
[RFC3550] Shulzrinne, H., Casner, S., Frederick, R. and V.
Jacobson, "RTP: A Transport Protocol for real-time
applications," RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., Clark, A., "RTP Control
Protocol Reporting Extensions (RTCP XR)," RFC 3611,
[October/November] 2003
[RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks",
RFC 2571, December 1999.
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification
of Management Information for TCP/IP-based Internets",
STD 16, RFC 1155, May 1990.
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[RFC1215] Rose, M., "A Convention for Defining Traps for use with
the SNMP", RFC 1215, March 1991.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, December
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, December 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, December 1999.
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin,
"Simple Network Management Protocol", STD 15, RFC 1157,
May 1990.
Clark Expires January 2005 [Page 12]
draft-clark-avt-rtpmibv2-01.txt July 2004
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901,
January 1996.
[RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", RFC 2572, December
1999.
[RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", RFC 2574, December 1999.
[RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Protocol Operations for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3
Applications", RFC 2573, December 1999.
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", RFC 2575, December 1999.
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart,
"Introduction to Version 3 of the Internet-standard
Network
Management Framework", RFC 2570, December 1999.
Clark Expires January 2005 [Page 13]
draft-clark-avt-rtpmibv2-01.txt July 2004
8. Authors' Addresses
Alan Clark
Telchemy Incorporated
3360 Martins Farm Road, Ste 200
Suwanee, Georgia 30024
U.S.A.
Email: alan@telchemy.com
Amy Pendleton
Nortel Networks
2380 Performance Drive
Richardson, Texas 75081
U.S.A.
Email: aspen@nortelnetworks.com
9. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Clark Expires January 2005 [Page 14]
