idnits 2.17.1 draft-ietf-avt-rtp-mib-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 17 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 42 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 467: '... RTP Monitors MUST initialize to 't...' RFC 2119 keyword, line 468: '... Hosts MUST initialize this 'fal...' RFC 2119 keyword, line 481: '... state MAY be removed after 5 m...' RFC 2119 keyword, line 493: '...TP sending hosts MUST have an entry in...' RFC 2119 keyword, line 494: '...sent. RTP reveiving hosts MAY have an...' (19 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 269 has weird spacing: '... "This objec...' == Line 270 has weird spacing: '...onIndex as de...' == Line 271 has weird spacing: '...entions for ...' == Line 272 has weird spacing: '...em, the netwo...' == Line 273 has weird spacing: '... the objec...' == (5 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 12, 1999) is 9146 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1889 (ref. '1') (Obsoleted by RFC 3550) ** Obsolete normative reference: RFC 2271 (ref. '2') (Obsoleted by RFC 2571) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '5') ** Obsolete normative reference: RFC 1902 (ref. '6') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '7') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1904 (ref. '8') (Obsoleted by RFC 2580) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '9') ** Downref: Normative reference to an Historic RFC: RFC 1901 (ref. '10') ** Obsolete normative reference: RFC 1906 (ref. '11') (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2272 (ref. '12') (Obsoleted by RFC 2572) ** Obsolete normative reference: RFC 2274 (ref. '13') (Obsoleted by RFC 2574) ** Obsolete normative reference: RFC 1905 (ref. '14') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 2273 (ref. '15') (Obsoleted by RFC 2573) ** Obsolete normative reference: RFC 2275 (ref. '16') (Obsoleted by RFC 2575) Summary: 25 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Audio Video Transport Group Mark Baugher 2 Internet-Draft Intel Corp. 3 Expires October 1999 Irena Suconick 4 VideoServer Corp. 5 Bill Strahm 6 Intel Corp. 7 April 12, 1999 9 Real-Time Transport Protocol 10 Management Information Base 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance 16 with all provisions of section 10 of RFC2026. Internet-Drafts are 17 working documents of the Internet Engineering Task Force 18 (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months. Internet-Drafts may be updated, replaced, or made 22 obsolete by other documents at any time. It is not 23 appropriate to use Internet-Drafts as reference material or to 24 cite them other than as a ``working draft'' or ``work inprogress.'' 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 33 Copyright (C) The Internet Society (1999). All Rights Reserved. 35 Abstract 37 This memo defines a portion of the Management Information Base 38 (MIB) for use with network management protocols in the Internet 39 community. In particular, it defines objects for managing Real-Time 40 Transport Protocol(RTP) systems [1]. 42 Table of Contents 44 1 The Network Management Framework ................................... 3 45 2 Overview ........................................................... 4 46 2.1 Components ....................................................... 4 47 2.2 Applicability of the MIB to RTP System Implementations ........... 4 48 2.3 The Structure of the RTP MIB ..................................... 5 49 3 Definitions ........................................................ 6 50 4 Security Issues .................................................... 27 51 5 Acknowledgements ................................................... 27 52 6 Intellectual Property .............................................. 28 53 7 References ......................................................... 28 54 8 Authors Addresses .................................................. 30 55 9 Full Copyright Statement ........................................... 31 56 1. The Network Management Framework 58 The SNMP Management Framework presently consists of five major 59 components: 61 o An overall architecture, described in RFC 2271 [2]. 63 o Mechanisms for describing and naming objects and events for the 64 purpose of management. The first version of this Structure of 65 Management Information (SMI) is called SMIv1 and described in 66 RFC 1155 [3], RFC 1212 [4] and RFC 1215 [5]. The second version, 67 called SMIv2, is described in RFC 1902 [6], RFC 1903 [7] and RFC 68 1904 [8]. 70 o Message protocols for transferring management information. The 71 first version of the SNMP message protocol is called SNMPv1 and 72 described in RFC 1157 [9]. A second version of the SNMP message 73 protocol, which is not an Internet standards track protocol, is 74 called SNMPv2c and described in RFC 1901 [10] and RFC 1906 [11]. 75 The third version of the message protocol is called SNMPv3 and 76 described in RFC 1906 [11], RFC 2272 [12] and RFC 2274 [13]. 78 o Protocol operations for accessing management information. The 79 first set of protocol operations and associated PDU formats is 80 described in RFC 1157 [9]. A second set of protocol operations 81 and associated PDU formats is described in RFC 1905 [14]. 83 o A set of fundamental applications described in RFC 2273 [15] and 84 the view-based access control mechanism described in RFC 2275 85 [16]. 87 Managed objects are accessed via a virtual information store, termed 88 the Management Information Base or MIB. Objects in the MIB are 89 defined using the mechanisms defined in the SMI. 91 This memo specifies a MIB module that is compliant to the SMIv2. A 92 MIB conforming to the SMIv1 can be produced through the appropriate 93 translations. The resulting translated MIB must be semantically 94 equivalent, except where objects or events are omitted because no 95 translation is possible (use of Counter64). Some machine readable 96 information in SMIv2 will be converted into textual descriptions in 97 SMIv1 during the translation process. However, this loss of machine 98 readable information is not considered to change the semantics of the 99 MIB. 101 2. Overview 103 An "RTP System" may be a host end-system that runs an application 104 program that sends or receives RTP data packets, or it may be an 105 intermediate-system that forwards RTP packets. RTP Control 106 Protocol (RTCP) packets are sent by senders and receivers to 107 convey information about RTP packet transmission and reception [1]. 108 RTP monitors may collect RTCP information on senders and receivers 109 to and from an RTP host or intermediate-system. 111 2.1 Components 113 The RTP MIB is structured around "session," "Receiver" and "Sender" 114 conceptual abstractions. 116 2.1.1 An "RTP session" is the "...association of participants 117 communicating with RTP. For each participant, the session is 118 defined by a particular pair of destination transport addresses 119 (one network address plus a port pair for RTP and RTCP). The 120 destination transport addresses may be common for all participants, 121 as in the case of IP multicast, or may be different for each, as in 122 the case of individual unicast addresses plus a common port pair," 123 as defined in section 3 of [1]. 125 2.1.2 A "Sender" is identified within an RTP session by a 32-bit numeric 126 "Synchronization Source," or "SSRC", value and is "...the source of a 127 stream of RTP packets" as defined in section 3 of [1]. The sender is 128 also a source of RTCP Sender Report packets as specified in section 6 of [1]. 130 2.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or 131 multicast Receiver as described in 2.1.1, above. An RTP Receiver has 132 an SSRC value that is unique to the session. An RTP Receiver is a 133 source of RTCP Receiver Reports as specified in section 6 of [1]. 135 2.2 Applicability of the MIB to RTP System Implementations 137 The RTP MIB may be used in two types of RTP implementations, RTP Host 138 Systems (end systems) and RTP Monitors, see section 3 of [1]. 139 Use of the RTP MIB for RTP Translators and Mixers, as defined in 140 section 7 of [1], is for further study. 142 2.2.1 RTP host Systems are end-systems that may use the RTP MIB 143 to collect RTP session and stream data that the host is sending or 144 receiving; these data may be used by a network manager to detect and 145 diagnose faults that occur over the life time of an RTP session as 146 in a "help-desk" scenario. 148 2.2.2 RTP Monitors of multicast RTP sessions may be third-party, or 149 may be located in an RTP intermediate-system or in the RTP host. RTP 150 Monitors may use the RTP MIB to collect RTP session and stream 151 statistical data; these data may be used by a network manager for 152 capacity planning and other network-management purposes. An RTP 153 Monitor may use the RTP MIB to collect data to permit a network 154 manager to detect and diagnose faults in RTP sessions, or to permit 155 a network manger to configure its operation. 157 2.2.3 Many host systems will want to keep track of streams beyond what 158 they are sending and receiving. In a mixed mode system a host would use 159 RTP data from the host to maintain data about streams it is sending and 160 receiving, and RTCP data to collect data about other hosts in the session. 161 For example an RTP host that is sending a stream would use data from 162 its RTP stack to maintain the rtpSenderTable, however it may want to 163 maintain a rtpReceiverTable for endpoints that are receiving its stream. 164 To do this the host will collect RTCP data from the receivers of its 165 stream to build the rtpReceiverTable. 167 2.3 The Structure of the RTP MIB 169 There are three tables in the RTP MIB. The rtpSessionTable contains 170 objects that describe active sessions at the host, intermediate system, 171 or monitor. The rtpSenderTable contains information about senders 172 to the RTP session. The rtpRcvrTable contains information about 173 receivers of RTP session data. 175 For any particular RTP session, the rtpSessionMonitor object indicates 176 whether information about remote senders or receivers to the RTP 177 session are to be monitored. RTP sessions are monitored by the 178 RTP agent that updates rtpSenderTable and rtpRcvrTable objects with 179 information from RTCP reports from remote senders or remote receivers 180 respectively. 182 rtpSessionNewIndex is a global object that permits a network-management 183 application to obtain a unique index for conceptual row creation 184 in the rtpSessionTable. In this way the SNMP Set operation may 185 be used to configure a monitor. 187 3. Definitions 188 RTP-MIB DEFINITIONS ::= BEGIN 189 IMPORTS 190 Counter32, Counter64, Gauge32, mib-2, Integer32, 191 MODULE-IDENTITY, OBJECT-IDENTITY, 192 OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI 193 DisplayString, RowStatus, TAddress, 194 TDomain, TestAndIncr, TEXTUAL-CONVENTION, 195 TimeStamp, TruthValue FROM SNMPv2-TC 196 OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF 197 InterfaceIndex FROM IF-MIB; 199 rtpMIB MODULE-IDENTITY 200 LAST-UPDATED "990222000Z" 201 ORGANIZATION "IETF AVT Working Group" 202 CONTACT-INFO 203 "Mark Baugher 204 Postal: Intel Corporation 205 2111 NE 25th Avenue 206 Hillsboro, OR 97124 207 United States 208 Tel: +1 503 264 3849 209 Email: mbaugher@intel.com 211 Bill Strahm 212 Postal: Intel Corporation 213 2111 NE 25th Avenue 214 Hillsboro, OR 97124 215 United States 216 Tel: +1 503 264 4632 217 Email: bill.strahm@intel.com 219 Irina Suconick 220 Postal: Videoserver Corporation 221 63 Third Street 222 Burlington, MA 01803 223 United States 224 Tel: +1 781-505-2155 225 Email: isuconick@videoserver.com" 226 DESCRIPTION 227 "The managed objects of RTP systems. The MIB is 228 structured around three types of information. 229 1. General information about RTP sessions such 230 as the session address. 231 2. Information about RTP streams being sent to 232 an RTP session by a particular sender. 233 3. Information about RTP streams received on an 234 RTP session by a particular receiver from a 235 particular sender. 236 There are two types of RTP Systems, RTP hosts and 237 RTP monitors. As described below, certain objects 238 are unique to a particular type of RTP System. An 239 RTP host may also function as an RTP monitor. 240 Refer to RFC 1889, 'RTP: A Transport Protocol for 241 Real-Time Applications,' section 3.0, for definitions." 242 ::== { mib-2 xx } -- to be assigned by IANA when going to Proposed 244 -- 245 -- OBJECTS 246 -- 247 rtpMIBObjects OBJECT IDENTIFIER ::= { rtpMIB 1 } 248 rtpAdmin OBJECT IDENTIFIER ::= { rtpMIB 2 } 249 rtpConformance OBJECT IDENTIFIER ::= { rtpMIB 3 } 250 rtpDomains OBJECT IDENTIFIER ::= { rtpMIB 4 } 252 rtpUDPDomain OBJECT-IDENTITY 253 STATUS current 254 DESCRIPTION 255 "RTP over UDP transport domain over IPv4. This definition 256 uses the transport address type, snmpUDPAddress, which is 257 defined in SNMPv2-TM, 'Transport Mappings for Version 2 of 258 the Simple Network Management Protocol (SNMPv2)'." 259 REFERENCE "RFC 1906, sec. 2 " ::= { rtpDomains 1 } 261 -- 262 -- SESSION TABLE 263 -- 264 rtpSessionNewIndex OBJECT-TYPE 265 SYNTAX TestAndIncr 266 MAX-ACCESS read-write 267 STATUS current 268 DESCRIPTION 269 "This object is used to assign values to 270 rtpSessionIndex as described in 'Textual 271 Conventions for SNMPv2'. For an RTP monitor 272 system, the network manager would read 273 the object, and then write the value back in 274 the Set that creates a new instance of 275 rtpSessionEntry. If the Set fails with the code 276 'inconsistentValue,' then the process must be 277 repeated; If the Set succeeds, then the object 278 is incremented, and the new instance is 279 created according to the manager's directions. 280 However, if the RTP agent is not acting as a monitor, 281 only the RTP agent may create conceptual rows in the 282 RTP session table. The RTP agent is a monitor for a 283 paricular session only if rtpSessionMonitor is set to 284 'true(1)'." 285 ::= { rtpMIBObjects 1 } 287 rtpSessionTable OBJECT-TYPE 288 SYNTAX SEQUENCE OF RtpSessionEntry 289 MAX-ACCESS not-accessible 290 STATUS current 291 DESCRIPTION 292 "There's one entry in rtpSessionTable for each RTP session 293 on which packets are being sent, received, and/or 294 monitored." 295 ::= { rtpMIBObjects 2 } 297 rtpSessionEntry OBJECT-TYPE 298 SYNTAX RtpSessionEntry 299 MAX-ACCESS not-accessible 300 STATUS current 301 DESCRIPTION 302 "Data in rtpSessionTable uniquely identify an RTP 303 session. A host RTP agent will create a read-only row for 304 each session to which packets are being sent or received. 305 An RTP session can be monitored to create management 306 information on all RTP streams being sent or received when 307 the rtpSessionMonitor has the TruthValue of 'true(1)'. An 308 RTP monitor may permit row creation with the side 309 effect of causing the RTP System to join the multicast session for 310 the purposes of gathering management information (thus 311 additional conceptual rows are created in the rtpRcvrTable 312 and rtpSenderTable). Thus, rtpSessionTable rows can be created 313 for RTP session monitoring purposes. Rows created by a 314 management application may be deleted via SNMP operations. 315 Rows created by a management application (rtpSessionMonitor 316 is 'true(1)') are deleted by the management application. 317 When rtpSessionMonitor is 'false(2), rows are created by the 318 RTP Agent at the start of a session when one or more or more 319 senders or receivers are observed. Rows created by an RTP 320 agent are deleted when the session is over and there are no 321 rtpRcvrEntry and no rtpSenderEntry for this session." 322 INDEX { rtpSessionIndex } 323 ::= { rtpSessionTable 1 } 325 RtpSessionEntry ::= SEQUENCE { 326 rtpSessionIndex Integer32, 327 rtpSessionDomain TDomain, 328 rtpSessionRemAddr TAddress, 329 rtpSessionLocAddr TAddress, 330 rtpSessionIfIndex InterfaceIndex, 331 rtpSessionSenderJoins Counter32, 332 rtpSessionReceiverJoins Counter32, 333 rtpSessionByes Counter32, 334 rtpSessionStartTime TimeStamp, 335 rtpSessionMonitor TruthValue, 336 rtpSessionRowStatus RowStatus 337 } 339 rtpSessionIndex OBJECT-TYPE 340 SYNTAX Integer32 (1..2147483647) 341 MAX-ACCESS not-accessible 342 STATUS current 343 DESCRIPTION 344 "The index of the conceptual row which is for SNMP purposes 345 only and has no relation to any protocol value. There is 346 no requirement that these rows are created or maintained 347 sequentially." 348 ::= { rtpSessionEntry 1} 350 rtpSessionDomain OBJECT-TYPE 351 SYNTAX TDomain 352 MAX-ACCESS read-create 353 STATUS current 354 DESCRIPTION 355 "The transport-layer protocol used for sending or receiving 356 the stream of RTP data packets on this session. 357 Cannot be changed if rtpSessionRowStatus is 'active'." 358 DEFVAL { rtpUDPDomain } 359 ::= { rtpSessionEntry 2 } 361 rtpSessionRemAddr OBJECT-TYPE 362 SYNTAX TAddress 363 MAX-ACCESS read-create 364 STATUS current 365 DESCRIPTION 366 "The remote destination transport address on which the 367 RTP data packet stream is sent and/or received. 'The 368 destination address pair may be common for all participants, 369 as in the case of IP multicast, or may be different for each, 370 as in the case of individual unicast network address pairs.' 371 See RFC 1889, 'RTP: A Transport Protocol for Real-Time 372 Applications,' sec. 3. The transport service is identified 373 by rtpSessionDomain. For rtpUDPDomain, this is an IP address 374 and even-numbered UDP Port with the RTCP being sent on the 375 next higher odd-numbered port, see RFC 1889, sec. 5. Cannot 376 be changed if rtpSessionRowStatus is 'active'." 377 ::= { rtpSessionEntry 3 } 379 rtpSessionLocAddr OBJECT-TYPE 380 SYNTAX TAddress 381 MAX-ACCESS read-only 382 STATUS current 383 DESCRIPTION 384 "The local destination transport address on which the stream 385 of data packets is being sent and/or received. For unicast 386 RTP sessions, this is the local address of the 387 RTP session. For multicast RTP sessions, this object should 388 have the same value as rtpSessionRemoteAddr. See RFC 1889, 389 'RTP: A Transport Protocol for Real-Time Applications,' sec. 390 3. The transport service is identified by rtpSessionDomain. 391 For rtpUDPDomain, this is an IP address and even-numbered 392 UDP Port with the RTCP being sent on the next higher 393 odd-numbered port, see RFC 1889, sec. 5." 394 ::= { rtpSessionEntry 4 } 396 rtpSessionIfIndex OBJECT-TYPE 397 SYNTAX InterfaceIndex 398 MAX-ACCESS read-create 399 STATUS current 400 DESCRIPTION 401 "The ifIndex value is set to the corresponding value 402 from the Internet Standard MIB. This is the interface 403 that the RTP stream is being sent to or received from, 404 or in the case of an RTP Monitor the interface that RTCP 405 packets will be received on. Cannot be changed if 406 rtpSessionRowStatus is 'active'." 407 DEFVAL { 1 } 408 ::= { rtpSessionEntry 5 } 410 rtpSessionSenderJoins OBJECT-TYPE 411 SYNTAX Counter32 412 MAX-ACCESS read-only 413 STATUS current 414 DESCRIPTION 415 "The number of senders that have been observed to have 416 joined the session since this conceptual row was created 417 (rtpSessionStartTime). A sender 'joins' an RTP 418 session by sending to it. Senders that leave and then 419 re-join following an RTCP BYE (See RFC 1889, 'RTP: A 420 Transport Protocol for Real-Time Applications,' sec. 6.6) 421 or session timeout may be counted twice. Every time a new 422 RTP sender is detected either using RTP or RTCP, this counter 423 is incremented." 424 ::= { rtpSessionEntry 6 } 426 rtpSessionReceiverJoins OBJECT-TYPE 427 SYNTAX Counter32 428 MAX-ACCESS read-only 429 STATUS current 430 DESCRIPTION 431 "The number of receivers that have been been observed to 432 have joined this session since this conceptual row was 433 created (rtpSessionStartTime). Receivers that leave and 434 then re-join following an RTCP BYE (See RFC 1889, 'RTP: A 435 Transport Protocol for Real-Time Applications,' sec. 6.6) 436 or session timeout may be counted twice. Every time an 437 RTP receiver is detected using RTCP, this counter is 438 incremented." 439 ::= { rtpSessionEntry 7 } 441 rtpSessionByes OBJECT-TYPE 442 SYNTAX Counter32 443 MAX-ACCESS read-only 444 STATUS current 445 DESCRIPTION 446 "A count of RTCP BYE (See RFC 1889, 'RTP: A Transport 447 Protocol for Real-Time Applications,' sec. 6.6) messages 448 received by this entity." 449 ::= { rtpSessionEntry 8 } 451 rtpSessionStartTime OBJECT-TYPE 452 SYNTAX TimeStamp 453 MAX-ACCESS read-only 454 STATUS current 455 DESCRIPTION 456 "The value of SysUpTime at the time that this row was 457 created." 458 ::= { rtpSessionEntry 9 } 460 rtpSessionMonitor OBJECT-TYPE 461 SYNTAX TruthValue 462 MAX-ACCESS read-only 463 STATUS current 464 DESCRIPTION 465 "Boolean, Set to 'true(1)' if senders or receivers in 466 addition to the local RTP System are to be monitored. 467 RTP Monitors MUST initialize to 'true(1)' and RTP 468 Hosts MUST initialize this 'false(2)'." 469 ::= { rtpSessionEntry 10 } 471 rtpSessionRowStatus OBJECT-TYPE 472 SYNTAX RowStatus 473 MAX-ACCESS read-create 474 STATUS current 475 DESCRIPTION 476 "Value of 'active' when RTP or RTCP messages are being 477 sent or received by an RTP System. A newly-created 478 conceptual row must have the rtpSessionRemAddr and 479 rtpSessionLocAddr initialized before becoming 'active'. 480 A conceptual row that is in the 'notReady' or 'notInService' 481 state MAY be removed after 5 minutes." 482 ::= { rtpSessionEntry 11 } 484 -- 485 -- SENDERS TABLE 486 -- 487 rtpSenderTable OBJECT-TYPE 488 SYNTAX SEQUENCE OF RtpSenderEntry 489 MAX-ACCESS not-accessible 490 STATUS current 491 DESCRIPTION 492 "Table of information about a sender or senders to an RTP 493 Session. RTP sending hosts MUST have an entry in this table 494 for each stream being sent. RTP reveiving hosts MAY have an 495 entry in this table for each sending stream being received 496 by this host. RTP monitors create an entry for each observed 497 sender to a multicast RTP Session as a side-effect when a 498 conceptual row in the rtpSessionTable is made 'active' by a 499 manager." 500 ::= { rtpMIBObjects 3 } 502 rtpSenderEntry OBJECT-TYPE 503 SYNTAX RtpSenderEntry 504 MAX-ACCESS not-accessible 505 STATUS current 506 DESCRIPTION 507 "Each entry contains information from a single RTP Sender 508 Synchronization Source (SSRC, see RFC 1889 'RTP: A Transport 509 Protocol for Real-Time Applications' sec.6). The session is 510 identified to the the SNMP entity by rtpSessionIndex. 511 Rows are removed by the RTP agent when a BYE is received 512 from the sender or when the sender times out (see RFC 513 1889, Sec. 6.2.1)." 514 INDEX { rtpSessionIndex, rtpSenderSSRC } 515 ::= { rtpSenderTable 1 } 517 RtpSenderEntry ::= SEQUENCE { 518 rtpSenderSSRC Unsigned32, 519 rtpSenderCNAME DisplayString, 520 rtpSenderAddr TAddress, 521 rtpSenderPackets Counter64, 522 rtpSenderOctets Counter64, 523 rtpSenderTool DisplayString, 524 rtpSRs Counter32, 525 rtpSenderSRTime TimeStamp, 526 rtpSenderPT INTEGER, 527 rtpSenderStartTime TimeStamp 528 } 529 rtpSenderSSRC OBJECT-TYPE 530 SYNTAX Unsigned32 531 MAX-ACCESS not-accessible 532 STATUS current 533 DESCRIPTION 534 "The RTP SSRC, or synchronization source identifier of the 535 sender. The RTP session address plus an SSRC uniquely 536 identify a sender to an RTP stream (see RFC 1889, 'RTP: A 537 Transport Protocol for Real-Time Applications' sec.3)." 538 ::= { rtpSenderEntry 1 } 540 rtpSenderCNAME OBJECT-TYPE 541 SYNTAX DisplayString (SIZE(0..255)) 542 MAX-ACCESS read-only 543 STATUS current 544 DESCRIPTION 545 "The RTP canonical name of the sender." 546 ::= { rtpSenderEntry 2 } 548 rtpSenderAddr OBJECT-TYPE 549 SYNTAX TAddress 550 MAX-ACCESS read-only 551 STATUS current 552 DESCRIPTION 553 "The unicast transport source address of the sender." 554 ::= { rtpSenderEntry 3 } 556 rtpSenderPackets OBJECT-TYPE 557 SYNTAX Counter64 558 MAX-ACCESS read-only 559 STATUS current 560 DESCRIPTION 561 "Count of RTP packets sent by this sender, or observed by 562 an RTP monitor, since rtpSenderStartTime." 563 ::= { rtpSenderEntry 4 } 565 rtpSenderOctets OBJECT-TYPE 566 SYNTAX Counter64 567 MAX-ACCESS read-only 568 STATUS current 569 DESCRIPTION 570 "Count of RTP octets sent by this sender, or observed by 571 an RTP monitor, since rtpSenderStartTime." 572 ::= { rtpSenderEntry 5 } 574 rtpSenderTool OBJECT-TYPE 575 SYNTAX DisplayString (SIZE(0..127)) 576 MAX-ACCESS read-only 577 STATUS current 578 DESCRIPTION 579 "Name of the application program source of the stream." 580 DEFVAL { ''H } -- Null if not available 581 ::= { rtpSenderEntry 6 } 583 rtpSRs OBJECT-TYPE 584 SYNTAX Counter32 585 MAX-ACCESS read-only 586 STATUS current 587 DESCRIPTION 588 "A count of the number of RTCP Sender Reports that have 589 been sent from this sender, or observed if the RTP entity 590 is a monitor, since rtpSenderStartTime." 591 ::= { rtpSenderEntry 7 } 593 rtpSenderSRTime OBJECT-TYPE 594 SYNTAX TimeStamp 595 MAX-ACCESS read-only 596 STATUS current 597 DESCRIPTION 598 "rtpSenderSRTime is the value of SysUpTime at the time that 599 the last SR was received from this sender, in the case of a 600 monitor or receiving host. Or sent by this sender, in the 601 case of a sending host." 602 ::= { rtpSenderEntry 8 } 604 rtpSenderPT OBJECT-TYPE 605 SYNTAX INTEGER (0..127) 606 MAX-ACCESS read-only 607 STATUS current 608 DESCRIPTION 609 "Static or dynamic payload type from the RTP header (see 610 RFC 1889, 'RTP: A Transport Protocol for Real-Time 611 Applications' sec. 5)." 612 ::= { rtpSenderEntry 9 } 614 rtpSenderStartTime OBJECT-TYPE 615 SYNTAX TimeStamp 616 MAX-ACCESS read-only 617 STATUS current 618 DESCRIPTION 619 "The value of SysUpTime at the time that this row was 620 created." 621 ::= { rtpSenderEntry 10 } 623 -- 624 -- RECEIVERS TABLE 625 -- 626 rtpRcvrTable OBJECT-TYPE 627 SYNTAX SEQUENCE OF RtpRcvrEntry 628 MAX-ACCESS not-accessible 629 STATUS current 630 DESCRIPTION 631 "Table of information about a receiver or receivers of RTP 632 session data. RTP hosts that receive RTP session packets 633 MUST create an entry in this table for that receiver/sender 634 pair. RTP hosts that send RTP session packets MAY create 635 an entry in this table for each receiver to their stream 636 using RTCP feedback from the RTP group. RTP monitors 637 create an entry for each observed RTP session receiver as 638 a side effect when a conceptual row in the rtpSessionTable 639 is made 'active' by a manager." 640 ::= { rtpMIBObjects 4 } 642 rtpRcvrEntry OBJECT-TYPE 643 SYNTAX RtpRcvrEntry 644 MAX-ACCESS not-accessible 645 STATUS current 646 DESCRIPTION 647 "Each entry contains information from a single RTP 648 Synchronization Source that is receiving packets from the 649 sender identified by rtpRcvrSRCSSRC (SSRC, see RFC 1889, 650 'RTP: A Transport Protocol for Real-Time Applications' 651 sec.6). The session is identified to the the SNMP entity by 652 rtpSessionIndex. Rows are removed by the RTP agent when 653 a BYE is received from the sender or when the sender times 654 out (see RFC 1889, Sec. 6.2.1)." 655 INDEX { rtpSessionIndex, rtpRcvrSRCSSRC, rtpRcvrSSRC } 656 ::= { rtpRcvrTable 1 } 658 RtpRcvrEntry ::= SEQUENCE { 659 rtpRcvrSRCSSRC Unsigned32, 660 rtpRcvrSSRC Unsigned32, 661 rtpRcvrCNAME DisplayString, 662 rtpRcvrAddr TAddress, 663 rtpRcvrRTT Gauge32, 664 rtpRcvrLostPackets Counter64, 665 rtpRcvrJitter Gauge32, 666 rtpRcvrTool DisplayString, 667 rtpRRs Counter32, 668 rtpRcvrRRTime TimeStamp, 669 rtpRcvrPT INTEGER, 670 rtpRcvrPackets Counter64, 671 rtpRcvrOctets Counter64, 672 rtpRcvrStartTime TimeStamp 673 } 675 rtpRcvrSRCSSRC OBJECT-TYPE 676 SYNTAX Unsigned32 677 MAX-ACCESS not-accessible 678 STATUS current 679 DESCRIPTION 680 "The RTP SSRC, or synchronization source identifier of the 681 sender. The RTP session address plus an SSRC uniquely 682 identify a sender or receiver of an RTP stream (see RFC 683 1889, 'RTP: A Transport Protocol for Real-Time 684 Applications' sec.3)." 685 ::= { rtpRcvrEntry 1 } 687 rtpRcvrSSRC OBJECT-TYPE 688 SYNTAX Unsigned32 689 MAX-ACCESS not-accessible 690 STATUS current 691 DESCRIPTION 692 "The RTP SSRC, or synchronization source identifier of the 693 receiver. The RTP session address plus an SSRC uniquely 694 identify a receiver of an RTP stream (see RFC 1889, 'RTP: 695 A Transport Protocol for Real-Time Applications' sec.3)." 696 ::= { rtpRcvrEntry 2 } 698 rtpRcvrCNAME OBJECT-TYPE 699 SYNTAX DisplayString (SIZE(0..255)) 700 MAX-ACCESS read-only 701 STATUS current 702 DESCRIPTION 703 "The RTP canonical name of the receiver." 704 ::= { rtpRcvrEntry 3 } 706 rtpRcvrAddr OBJECT-TYPE 707 SYNTAX TAddress 708 MAX-ACCESS read-only 709 STATUS current 710 DESCRIPTION 711 "The unicast transport address of the receiver." 712 ::= { rtpRcvrEntry 4 } 714 rtpRcvrRTT OBJECT-TYPE 715 SYNTAX Gauge32 716 MAX-ACCESS read-only 717 STATUS current 718 DESCRIPTION 719 "The round trip time measurement taken by the source of the 720 RTP stream based on the algorithm described on sec. 6 of 721 RFC 1889, 'RTP: A Transport Protocol for Real-Time 722 Applications.' This algorithm can produce meaningful 723 results when the RTP agent has the same clock as the stream 724 sender (when the RTP monitor is also the sending host for the 725 particular reciever). Otherwise, the entity should return 726 'noSuchInstance' in response to queries against rtpRcvrRTT." 727 ::= { rtpRcvrEntry 5 } 729 rtpRcvrLostPackets OBJECT-TYPE 730 SYNTAX Counter64 731 MAX-ACCESS read-only 732 STATUS current 733 DESCRIPTION 734 "A count of RTP packets lost as observed by this receiver 735 since rtpRcvrStartTime." 736 ::= { rtpRcvrEntry 6 } 738 rtpRcvrJitter OBJECT-TYPE 739 SYNTAX Gauge32 740 MAX-ACCESS read-only 741 STATUS current 742 DESCRIPTION 743 "An estimate of delay variation as observed by this 744 receiver. (see RFC 1889, 'RTP: A Transport Protocol 745 for Real-Time Applications' sec.6.3.1 and A.8)." 746 ::= { rtpRcvrEntry 7 } 748 rtpRcvrTool OBJECT-TYPE 749 SYNTAX DisplayString (SIZE(0..127)) 750 MAX-ACCESS read-only 751 STATUS current 752 DESCRIPTION 753 "Name of the application program source of the stream." 754 DEFVAL { ''H } -- Null if not available 755 ::= { rtpRcvrEntry 8 } 757 rtpRRs OBJECT-TYPE 758 SYNTAX Counter32 759 MAX-ACCESS read-only 760 STATUS current 761 DESCRIPTION 762 "A count of the number of RTCP Receiver Reports that have 763 been sent from this receiver, or observed if the RTP entity 764 is a monitor, since rtpRcvrStartTime." 765 ::= { rtpRcvrEntry 9 } 767 rtpRcvrRRTime OBJECT-TYPE 768 SYNTAX TimeStamp 769 MAX-ACCESS read-only 770 STATUS current 771 DESCRIPTION 772 "rtpRcvrRRTime is the value of SysUpTime at the time that the 773 last RTCP Receiver Report was received from this receiver, in 774 the case of a monitor or RR receiver (the RTP Sender). It is the 775 value of SysUpTime at the time that the last RR was sent by 776 this receiver in the case of an RTP receiver sending the RR." 777 ::= { rtpRcvrEntry 10 } 779 rtpRcvrPT OBJECT-TYPE 780 SYNTAX INTEGER (0..127) 781 MAX-ACCESS read-only 782 STATUS current 783 DESCRIPTION 784 "Static or dynamic payload type from the RTP header (see 785 RFC 1889, 'RTP: A Transport Protocol for Real-Time 786 Applications' sec. 5)." 787 ::= { rtpRcvrEntry 11 } 789 rtpRcvrPackets OBJECT-TYPE 790 SYNTAX Counter64 791 MAX-ACCESS read-only 792 STATUS current 793 DESCRIPTION 794 "Count of RTP packets received by this RTP host receiver 795 since rtpRcvrStartTime. RTP monitors may not have this 796 information and should return 'noSuchInstance.'" 797 ::= { rtpRcvrEntry 12 } 799 rtpRcvrOctets OBJECT-TYPE 800 SYNTAX Counter64 801 MAX-ACCESS read-only 802 STATUS current 803 DESCRIPTION 804 "Count of RTP octets received by this receiving RTP host 805 since rtpRcvrStartTime. RTP monitors may not have this 806 this information and should return 'noSuchInstance.'" 807 ::= { rtpRcvrEntry 13 } 809 rtpRcvrStartTime OBJECT-TYPE 810 SYNTAX TimeStamp 811 MAX-ACCESS read-only 812 STATUS current 813 DESCRIPTION 814 "The value of SysUpTime at the time that this row was 815 created." 816 ::= { rtpRcvrEntry 14 } 818 -- 819 -- MODULE GROUPS 820 -- 821 rtpGroups OBJECT IDENTIFIER ::= { rtpConformance 1 } 822 rtpSystemGroup OBJECT-GROUP 823 OBJECTS { 824 rtpSessionDomain, 825 rtpSessionRemAddr, 826 rtpSessionIfIndex, 827 rtpSessionSenderJoins, 828 rtpSessionReceiverJoins, 829 rtpSessionStartTime, 830 rtpSessionRowStatus, 831 rtpSessionByes, 832 rtpSessionMonitor, 833 rtpSenderCNAME, 834 rtpSenderAddr, 835 rtpSenderPackets, 836 rtpSenderOctets, 837 rtpSenderTool, 838 rtpSRs, 839 rtpSenderSRTime, 840 rtpSenderStartTime, 841 rtpRcvrCNAME, 842 rtpRcvrAddr, 843 rtpRcvrLostPackets, 844 rtpRcvrJitter, 845 rtpRcvrTool, 846 rtpRRs, 847 rtpRcvrRRTime, 848 rtpRcvrStartTime 849 } 850 STATUS current 851 DESCRIPTION 852 "Objects used by any RTP systems." 853 ::= { rtpGroups 1 } 855 rtpHostGroup OBJECT-GROUP 856 OBJECTS { 857 rtpSessionLocAddr, 858 rtpSenderPT, 859 rtpRcvrPT, 860 rtpRcvrRTT, 861 rtpRcvrOctets, 862 rtpRcvrPackets 863 } 864 STATUS current 865 DESCRIPTION 866 "Objects used by RTP host systems." 867 ::= { rtpGroups 2 } 869 rtpMonitorGroup OBJECT-GROUP 870 OBJECTS { 871 rtpSessionNewIndex 872 } 873 STATUS current 874 DESCRIPTION 875 "Objects used by RTP monitor systems." 876 ::= { rtpGroups 3 } 878 -- 879 -- Compliance 880 -- 881 rtpCompliances OBJECT IDENTIFIER ::= { rtpConformance 2 } 883 rtpHostCompliance MODULE-COMPLIANCE 884 STATUS current 885 DESCRIPTION 886 "Host implementations must comply." 887 MODULE RTP-MIB 888 MANDATORY-GROUPS { rtpSystemGroup } 889 GROUP rtpHostGroup 890 DESCRIPTION 891 "The objects in the rtpHostGroup MUST be 892 implemented in RTP host systems that are the source 893 or the destination of RTP data packets." 894 ::= { rtpCompliances 1 } 896 rtpMonitorCompliance MODULE-COMPLIANCE 897 STATUS current 898 DESCRIPTION 899 "Monitor implementations must comply." 900 MODULE RTP-MIB 901 MANDATORY-GROUPS { 902 rtpSystemGroup, 903 rtpHostGroup 904 } 905 GROUP rtpMonitorGroup 906 DESCRIPTION 907 "The objects in the rtpMonitorGroup MUST be 908 implemented in RTP monitors." 909 OBJECT rtpSessionNewIndex 910 MIN-ACCESS not-accessible 911 DESCRIPTION 912 "RTP host system implementations support of 913 row creation and deletion is OPTIONAL so 914 implementation of this object is OPTIONAL." 915 OBJECT rtpSessionDomain 916 MIN-ACCESS read-only 917 DESCRIPTION 918 "RTP host system implementation support of 919 row creation and deletion is OPTIONAL. When 920 it is not supported so write access is 921 OPTIONAL." 922 OBJECT rtpSessionRemAddr 923 MIN-ACCESS read-only 924 DESCRIPTION 925 "Row creation and deletion is OPTIONAL so 926 read-create access to this object is OPTIONAL." 927 OBJECT rtpSessionIfIndex 928 MIN-ACCESS read-only 929 DESCRIPTION 930 "Row creation and deletion is OPTIONAL so 931 read-create access to this object is OPTIONAL." 933 OBJECT rtpSessionRowStatus 934 MIN-ACCESS not-accessible 935 DESCRIPTION 936 "Row creation and deletion is OPTIONAL so 937 read-create access to this object is OPTIONAL." 938 OBJECT rtpSessionLocAddr 939 MIN-ACCESS not-accessible 940 DESCRIPTION 941 "RTP monitor sourcing of RTP or RTCP data packets 942 is OPTIONAL and implementation of this object is 943 OPTIONAL." 944 OBJECT rtpRcvrPT 945 MIN-ACCESS not-accessible 946 DESCRIPTION 947 "RTP monitor systems NEED NOT support 948 retrieval of the RTP Payload Type from the RTP 949 header (and may receive RTCP messages only). When 950 queried for the payload type information, the 951 RTP agent may return 'noSuchObject'." 952 OBJECT rtpSenderPT 953 MIN-ACCESS not-accessible 954 DESCRIPTION 955 "RTP monitor systems may recieve only the RTCP messages 956 and not the RTP messages that contain the payload type 957 information in the header. Thus implementation of this 958 object is OPTIONAL." 959 OBJECT rtpRcvrOctets 960 MIN-ACCESS not-accessible 961 DESCRIPTION 962 "RTP monitor systems may recieve only the RTCP messages 963 and not the RTP messages that contain the octet count 964 of the RTP message. Thus implementation of this 965 object is OPTIONAL." 966 OBJECT rtpRcvrPackets 967 MIN-ACCESS not-accessible 968 DESCRIPTION 969 "RTP monitor systems may recieve only the RTCP messages 970 and not the RTP messages that contain the octet count 971 of the RTP message. Thus implementation of this 972 object is OPTIONAL." 973 ::= { rtpCompliances 2 } 974 END 975 4. Security Issues 977 In most cases, MIBs are not themselves security risks; if SNMP security is 978 operating as intended, the use of a MIB to view information about a 979 system, or to change some parameter at the system, is a tool, not a threat. 981 None of the read-only objects in this MIB reports a password, though 982 some SDES items such as the CNAME, the canonical name, may be deemed 983 sensitive depending on the security policies of a particular 984 enterprise. If access to these objects is not limited by an 985 appropriate access control policy, these objects can provide an 986 attacker with information about a system's configuration and the 987 services that that system is providing. Some enterprises view their 988 network and system configurations, as well as information about 989 usage and performance, as corporate assets; such enterprises may 990 wish to restrict SNMP access to most of the objects in the MIB. 991 This MIB supports read-write operations against rtpSessionNewIndex which 992 has the side effect of creating an entry in the rtpSessionTable when it 993 is written to. Five objects in rtpSessionEntry have read-create access: 994 rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex, 995 rtpSessionRowStatus rtpSessionIfAddr identify an RTP session to be 996 monitored on a particular interface. The values of these objects are 997 not to be changed once created, and initialization of these objects 998 affects only the monitoring of an RTP session and not the operation of 999 an RTP session on any host end-system. Since write operations to 1000 rtpSessionNewIndex and the five objects in rtpSessionEntry affect the 1001 operation of the monitor, write access to these objects should be 1002 subject to the appropriate access control policy. 1004 Confidentiality of RTP and RTCP data packets is defined in section 9 of 1005 the RTP specification [1]. Encryption may be performed on RTP packets, 1006 RTCP packets, or both. Encryption of RTCP packets may pose a problem 1007 for third-party monitors though "For RTCP, it is allowed to split a 1008 compound RTCP packet into two lower-layer packets, one to be encrypted 1009 and one to be sent in the clear. For example, SDES information might 1010 be encrypted while reception reports were sent in the clear to 1011 accommodate third-party monitors [1]." 1013 5. Acknowledgements 1015 The authors wish to thank Bert Wijnen and the participants from the 1016 ITU SG-16 management effort for their helpful comments. Alan Batie 1017 and Bill Lewis from Intel also contributed greatly to the RTP MIB 1018 through their review of various drafts of the MIB and their work 1019 on the implementation of an SNMP RTP Monitor. Stan Naudus from 3Com 1020 and John Du from Intel contributed to the original RTP MIB design and 1021 co-authored the original RTP MIB draft documents; much of their work 1022 remains in the current RTP MIB. 1024 6. Intellectual Property 1026 The IETF takes no position regarding the validity or scope of any 1027 intellectual property or other rights that might be claimed to 1028 pertain to the implementation or use of the technology described in 1029 this document or the extent to which any license under such rights 1030 might or might not be available; neither does it represent that it 1031 has made any effort to identify any such rights. Information on the 1032 IETF's procedures with respect to rights in standards-track and 1033 standards-related documentation can be found in BCP-11. Copies of 1034 claims of rights made available for publication and any assurances of 1035 licenses to be made available, or the result of an attempt made to 1036 obtain a general license or permission for the use of such 1037 proprietary rights by implementors or users of this specification can 1038 be obtained from the IETF Secretariat. 1040 The IETF invites any interested party to bring to its attention any 1041 copyrights, patents or patent applications, or other proprietary 1042 rights which may cover technology that may be required to practice 1043 this standard. Please address the information to the IETF Executive 1044 Director. 1046 7. References 1048 [1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 1049 A Transport Protocol for real-time applications," RFC 1889. 1051 [2] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1052 Describing SNMP Management Frameworks", RFC 2271, Cabletron 1053 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 1054 January 1998 1056 [3] Rose, M., and K. McCloghrie, "Structure and Identification of 1057 Management Information for TCP/IP-based Internets", RFC 1155, 1058 Performance Systems International, Hughes LAN Systems, May 1990 1060 [4] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 1061 Performance Systems International, Hughes LAN Systems, March 1991 1063 [5] M. Rose, "A Convention for Defining Traps for use with the SNMP", 1064 RFC 1215, Performance Systems International, March 1991 1066 [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1067 of Management Information for Version 2 of the Simple Network 1068 Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco 1069 Systems, Inc., Dover Beach Consulting, Inc., International Network 1070 Services, January 1996. 1072 [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 1073 Conventions for Version 2 of the Simple Network Management Protocol 1074 (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., 1075 Dover Beach Consulting, Inc., International Network Services, 1076 January 1996. 1078 [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 1079 Statements for Version 2 of the Simple Network Management Protocol 1080 (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., 1081 Dover Beach Consulting, Inc., International Network Services, 1082 January 1996. 1084 [9] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1085 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1086 International, Performance Systems International, MIT Laboratory 1087 for Computer Science, May 1990. 1089 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1090 "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, 1091 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1092 International Network Services, January 1996. 1094 [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 1095 Mappings for Version 2 of the Simple Network Management Protocol 1096 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., 1097 Dover Beach Consulting, Inc., International Network Services, 1098 January 1996. 1100 [12] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1101 Processing and Dispatching for the Simple Network Management 1102 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 1103 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 1105 [13] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 1106 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 1107 2274, IBM T. J. Watson Research, January 1998. 1109 [14] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1110 Operations for Version 2 of the Simple Network Management Protocol 1111 (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., 1112 Dover Beach Consulting, Inc., International Network Services, 1113 January 1996. 1115 [15] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1116 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco 1117 Systems, January 1998 1119 [16] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1120 Control Model (VACM) for the Simple Network Management Protocol 1121 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 1122 Cisco Systems, Inc., January 1998 1124 8. Authors Addresses 1126 Mark Baugher Email: mbaugher@intel.com 1127 Intel Corporation 1128 2111 N.E.25th Avenue 1129 Hillsboro, Oregon 97124 1130 U.S.A. 1132 Bill Strahm Email: Bill.Strahm@intel.com 1133 Intel Corporation 1134 2111 N.E.25th Avenue 1135 Hillsboro, Oregon 97124 1136 U.S.A. 1138 Irena Suconick Email: isuconick@videoserver.com 1139 Videoserver Corporation 1140 63 Third Street 1141 Burlington, Massachusetts 01803 1142 U.S.A. 1144 9. Full Copyright Statement 1146 Copyright (C) The Internet Society (1999). All Rights Reserved. 1148 This document and translations of it may be copied and furnished to 1149 others, and derivative works that comment on or otherwise explain it 1150 or assist in its implementation may be prepared, copied, published 1151 and distributed, in whole or in part, without restriction of any 1152 kind, provided that the above copyright notice and this paragraph are 1153 included on all such copies and derivative works. However, this 1154 document itself may not be modified in any way, such as by removing 1155 the copyright notice or references to the Internet Society or other 1156 Internet organizations, except as needed for the purpose of 1157 developing Internet standards in which case the procedures for 1158 copyrights defined in the Internet Standards process must be 1159 followed, or as required to translate it into languages other than 1160 English. 1162 The limited permissions granted above are perpetual and will not be 1163 revoked by the Internet Society or its successors or assigns. 1165 This document and the information contained herein is provided on an 1166 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1167 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1168 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1169 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1170 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.