idnits 2.17.1 draft-ietf-snmp-interfacemibext-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 21 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Abstract' ) ** The document seems to lack an Introduction section. ** 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 an Authors' Addresses Section. ** There are 81 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [4,6], [7], [8], [9], [10], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 1990) is 12245 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) -- Missing reference section? '1' on line 748 looks like a reference -- Missing reference section? '2' on line 754 looks like a reference -- Missing reference section? '6' on line 777 looks like a reference -- Missing reference section? '3' on line 759 looks like a reference -- Missing reference section? '4' on line 765 looks like a reference -- Missing reference section? '5' on line 771 looks like a reference -- Missing reference section? '7' on line 783 looks like a reference -- Missing reference section? '8' on line 789 looks like a reference -- Missing reference section? '10' on line 804 looks like a reference -- Missing reference section? '9' on line 798 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet draft Interface MIB Extensions October 1990 3 Extensions to the Generic-Interface MIB 5 15 October 1990 7 Keith McCloghrie 8 Hughes LAN Systems, Inc. 9 kzm@hls.com 11 1. Status of this Memo 13 This draft document will be submitted to the RFC editor as an 14 experimental extension to the SNMP MIB. Distribution of this 15 memo is unlimited. Please send comments to the author. 17 2. Abstract 19 This memo defines an experimental portion of the Management 20 Information Base (MIB) for use with network management 21 protocols in TCP/IP-based internets. In particular, it defines 22 managed object types as experimental extensions to the generic 23 interfaces structure of MIB-II. 25 This memo does not specify a standard for the Internet 26 community. However, after experimentation, if sufficient 27 consensus is reached in the Internet community, then a 28 subsequent revision of this document may be incorporated into 29 the Internet-standard MIB. 31 Internet draft Interface MIB Extensions October 1990 33 3. Historical Perspective 35 As reported in RFC 1052, IAB Recommendations for the 36 Development of Internet Network Management Standards [1], a 37 two-prong strategy for network management of TCP/IP-based 38 internets was undertaken. In the short-term, the Simple 39 Network Management Protocol (SNMP), defined in RFC 1067, was 40 to be used to manage nodes in the Internet community. In the 41 long-term, the use of the OSI network management framework was 42 to be examined. Two documents were produced to define the 43 management information: RFC 1065, which defined the Structure 44 of Management Information (SMI), and RFC 1066, which defined 45 the Management Information Base (MIB). Both of these 46 documents were designed so as to be compatible with both the 47 SNMP and the OSI network management framework. 49 This strategy was quite successful in the short-term: 50 Internet-based network management technology was fielded, by 51 both the research and commercial communities, within a few 52 months. As a result of this, portions of the Internet 53 community became network manageable in a timely fashion. 55 As reported in RFC 1109, Report of the Second Ad Hoc Network 56 Management Review Group [2], the requirements of the SNMP and 57 the OSI network management frameworks were more different than 58 anticipated. As such, the requirement for compatibility 59 between the SMI/MIB and both frameworks was suspended. This 60 action permitted the operational network management framework, 61 based on the SNMP, to respond to new operational needs in the 62 Internet community by producing MIB-II [6]. 64 In May of 1990, the core documents were elevated to Standard 65 Protocols with Recommended status. As such, the Internet- 66 standard network management framework consists of: Structure 67 and Identification of Management Information for TCP/IP-based 68 internets, RFC 1155 [3], which describes how managed objects 69 contained in the MIB are defined; Management Information Base 70 for Network Management of TCP/IP-based internets, which 71 describes the managed objects contained in the MIB, RFC 1156 72 [4]; and, the Simple Network Management Protocol, RFC 1157 73 [5], which defines the protocol used to manage these objects. 75 Consistent with the IAB directive to produce simple, workable 76 systems in the short-term, the list of managed objects defined 77 in the Internet-standard MIB was derived by taking only those 79 Internet draft Interface MIB Extensions October 1990 81 elements which are considered essential. However, the SMI 82 defined three extensibility mechanisms: one, the addition of 83 new standard objects through the definitions of new versions 84 of the MIB; two, the addition of widely-available but non- 85 standard objects through the experimental subtree; and three, 86 the addition of private objects through the enterprises 87 subtree. Such additional objects can not only be used for 88 vendor-specific elements, but also for experimentation as 89 required to further the knowledge of which other objects are 90 essential. 92 This memo defines extensions to the MIB using the second 93 method. It contains definitions of managed objects used as 94 experimental extensions to the generic interfaces structure of 95 MIB-II. After experimentation, if sufficient consensus is 96 reached in the Internet community, then a subsequent revision 97 of this memo may be placed in the Internet-standard MIB. 99 Internet draft Interface MIB Extensions October 1990 101 4. Objects 103 Managed objects are accessed via a virtual information store, 104 termed the Management Information Base or MIB. Objects in the 105 MIB are defined using the subset of Abstract Syntax Notation 106 One (ASN.1) [7] defined in the SMI. In particular, each 107 object has a name, a syntax, and an encoding. The name is an 108 object identifier, an administratively assigned name, which 109 specifies an object type. The object type together with an 110 object instance serves to uniquely identify a specific 111 instantiation of the object. For human convenience, we often 112 use a textual string, termed the OBJECT DESCRIPTOR, to also 113 refer to the object type. 115 The syntax of an object type defines the abstract data 116 structure corresponding to that object type. The ASN.1 117 language is used for this purpose. However, the SMI [3] 118 purposely restricts the ASN.1 constructs which may be used. 119 These restrictions are explicitly made for simplicity. 121 The encoding of an object type is simply how that object type 122 is represented using the object type's syntax. Implicitly 123 tied to the notion of an object type's syntax and encoding is 124 how the object type is represented when being transmitted on 125 the network. 127 The SMI specifies the use of the basic encoding rules of ASN.1 128 [8], subject to the additional requirements imposed by the 129 SNMP. 131 4.1. Format of Definitions 133 The next section contains the specification of all object 134 types specified in this section of the MIB. The object types 135 are defined using the conventions specified in the SMI, as 136 amended by the extensions specified in [10]. 138 Internet draft Interface MIB Extensions October 1990 140 5. Overview 142 The Internet Standard MIB [4,6] contains a group of management 143 objects pertaining to a network device's generic network 144 interface(s). These objects are generic in the sense that 145 they apply to all network interfaces, irrespective of the type 146 of communication media and protocols used on such interfaces. 147 This has proved to be necessary but not sufficient; there are 148 efforts underway to define additional MIB objects which are 149 specific to particular media and lower-level (subnetwork-layer 150 and below) protocol stacks. 152 However, some of these efforts have identified objects which 153 are required (or at least useful), but are not specific to the 154 interface-type on which the effort is focusing. In order to 155 avoid redundancy, it is better that such objects be defined as 156 extensions to the generic interface group, rather than defined 157 in multiple specific-interface-type MIBs. 159 This memo defines the resultant extensions to the generic 160 interface group. These extensions are spread over three 161 tables: the generic Interface Extension table, the generic 162 Interface Test table, and the generic Receive Address table. 164 5.1. Generic Interface Extension Table 166 This table consists of new objects applicable to all types of 167 subnetwork interface. 169 5.2. Generic Interface Test Table 171 This section defines objects which allow a network manager to 172 instruct an agent to test an interface for various faults. A 173 few common types of tests are defined in this document but 174 most will be defined elsewhere dependent on the particular 175 type of interface. After invoking a test, the object 176 ifExtnsTestResult can be read to determine the outcome. If an 177 agent can not perform the test, ifExtnsTestResult is set to so 178 indicate. The object ifExtnsTestCode can be used to provide 179 further test-specific or interface-specific (or even 180 enterprise-specific) information concerning the outcome of the 181 test. Only one test can be in progress on each interface at 182 any one time. If one test is in progress when another test is 184 Internet draft Interface MIB Extensions October 1990 186 invoked, the second test is rejected. Some agents may reject 187 a test when a prior test is active on another interface. 189 When a test is invoked, the authentication service user 190 identity (as defined in [9]) originating the request is saved 191 by the agent, in the objects ifExtnsTestUser and 192 ifExtnsTestCommunity. These values remain set until the next 193 test is invoked. In the (rare) event that the invocation of 194 tests by two network managers were to overlap, then there is a 195 possibility that the first test's results might be overwritten 196 by the second test's results prior to the first results being 197 read. This unlikely circumstance can be detected by a network 198 manager retrieving the test-invoking authentication service 199 user identity at the same time as the test results are 200 retrieved, and ensuring that the results are for the desired 201 user identity. 203 In general, a Management station must not retransmit a request 204 to invoke a test for which it does not receive a response; 205 instead, it properly inspects an agent's MIB to determine if 206 the invocation was successful. Only if the invocation was 207 unsuccessful, is the invocation request retransmitted. 209 Some tests may require the interface to be taken off-line in 210 order to execute them, or may even require the agent to reboot 211 after completion of the test. In these circumstances, 212 communication with the management station invoking the test 213 may be lost until after completion of the test. The agent 214 should make every effort to transmit a response to the request 215 which invoked the test prior to losing communication. When 216 the agent is restored to normal service, the results of the 217 test are properly made available in the appropriate objects. 218 An agent which cannot, perhaps due to resource constraints, 219 retain even the minimum amount of information in these 220 situations, must reject any test which can cause one of these 221 situations to occur. 223 5.3. Generic Receive Address Table 225 This table of objects contains objects relating to an 226 interface's support for receiving packets/frames at more than 227 one address on the same interface. 229 Internet draft Interface MIB Extensions October 1990 231 6. Definitions 233 RFCxxxx-MIB DEFINITIONS ::= BEGIN 235 -- Extensions to MIB-II's Generic Interface Table 237 IMPORTS 238 experimental, Counter FROM RFC1155-SMI 239 DisplayString FROM RFC1158-MIB 240 PhysAddress FROM RFC-mmmm-MIB-II 241 OBJECT-TYPE FROM RFC-oooo; 243 -- This MIB Module uses the extended OBJECT-TYPE macro as 244 -- defined in [10] 246 ifExtensions OBJECT IDENTIFIER ::= { experimental 6 } 248 -- Generic Interface Extension Table 249 -- 250 -- This group of objects is mandatory for all types of 251 -- subnetwork interface. 253 ifExtnsTable OBJECT-TYPE 254 SYNTAX SEQUENCE OF IfExtnsEntry 255 ACCESS not-accessible 256 STATUS mandatory 257 DESCRIPTION 258 "A list of interfaces extension entries. 259 The number of entries is given by the value 260 of ifNumber, defined in [4,6]." 261 ::= { ifExtensions 1 } 263 ifExtnsEntry OBJECT-TYPE 264 SYNTAX IfExtnsEntry 265 ACCESS not-accessible 266 STATUS mandatory 267 DESCRIPTION 268 "An extension to the interfaces entry, 269 defined in [4,6], containing additional 271 Internet draft Interface MIB Extensions October 1990 273 objects at the subnetwork layer and below 274 for a particular interface." 275 INDEX { ifExtnsIfIndex } 276 ::= { ifExtnsTable 1 } 278 IfExtnsEntry ::= SEQUENCE { 279 ifExtnsIfIndex 280 INTEGER, 281 ifExtnsChipSet 282 OBJECT IDENTIFIER, 283 ifExtnsRevWare 284 DisplayString, 285 ifExtnsMulticastsTransmittedOks 286 Counter, 287 ifExtnsBroadcastsTransmittedOks 288 Counter, 289 ifExtnsMulticastsReceivedOks 290 Counter, 291 ifExtnsBroadcastsReceivedOks 292 Counter, 293 ifExtnsPromiscuous 294 INTEGER 295 } 297 ifExtnsIfIndex OBJECT-TYPE 298 SYNTAX INTEGER 299 ACCESS read-only 300 STATUS mandatory 301 DESCRIPTION 302 "The value of this object identifies the 303 interface for which this entry contains 304 extended management information. The value 305 of this object for a particular interface 306 has the same value as the ifIndex object, 307 defined in [4,6], for the same interface." 308 ::= { ifExtnsEntry 1 } 310 ifExtnsChipSet OBJECT-TYPE 311 SYNTAX OBJECT IDENTIFIER 312 ACCESS read-only 313 STATUS mandatory 314 DESCRIPTION 315 "This object identifies the hardware chip 316 set being used in the interface. The 317 assignment of OBJECT IDENTIFIERs to various 319 Internet draft Interface MIB Extensions October 1990 321 types of hardware chip sets is defined 322 elsewhere. This document assigns only the 323 value: unknownChipSet for use if the chip 324 set in use is unknown. 325 Note that unknownChipSet is a 326 syntactically valid object identifier, and 327 any conformant implementation of ASN.1 and 328 the BER must be able to generate and 329 recognize this value." 330 ::= { ifExtnsEntry 2 } 332 -- for unknown hardware chip set 333 unknownChipSet OBJECT IDENTIFIER ::= { 0 0 } 335 ifExtnsRevWare OBJECT-TYPE 336 SYNTAX DisplayString (SIZE (0..255)) 337 ACCESS read-only 338 STATUS mandatory 339 DESCRIPTION 340 "An arbitrary octet string that describes 341 the firmware version of this interface. 342 It is intended that this should be human 343 readable. It must only contain ASCII 344 printable characters. Typically this 345 will be the firmware version of the main 346 interface software." 347 ::= { ifExtnsEntry 3 } 349 ifExtnsMulticastsTransmittedOks OBJECT-TYPE 350 SYNTAX Counter 351 ACCESS read-only 352 STATUS mandatory 353 DESCRIPTION 354 "The count of frames successfully 355 transmitted to a subnetwork or link-layer 356 multicast destination address other than a 357 broadcast address. For a MAC layer protocol, 358 this includes both Group and Functional 359 addresses." 360 ::= { ifExtnsEntry 4 } 362 ifExtnsBroadcastsTransmittedOks OBJECT-TYPE 363 SYNTAX Counter 364 ACCESS read-only 365 STATUS mandatory 367 Internet draft Interface MIB Extensions October 1990 369 DESCRIPTION 370 "The count of frames successfully 371 transmitted to a subnetwork or link-layer 372 broadcast addresses. It does not include 373 frames sent to a multicast address." 374 ::= { ifExtnsEntry 5 } 376 ifExtnsMulticastsReceivedOks OBJECT-TYPE 377 SYNTAX Counter 378 ACCESS read-only 379 STATUS mandatory 380 DESCRIPTION 381 "The count of frames successfully received 382 that are directed to an active subnetwork 383 or link-layer multicast address (for a MAC 384 layer protocol, this includes both Group and 385 Functional addresses). This does not include 386 frames directed to a broadcast address, nor 387 frames received with errors." 388 ::= { ifExtnsEntry 6 } 390 ifExtnsBroadcastsReceivedOks OBJECT-TYPE 391 SYNTAX Counter 392 ACCESS read-only 393 STATUS mandatory 394 DESCRIPTION 395 "The count of frames successfully received 396 that are directed to a subnetwork or 397 link-layer broadcast address." 398 ::= { ifExtnsEntry 7 } 400 ifExtnsPromiscuous OBJECT-TYPE 401 SYNTAX INTEGER { 402 true(1), 403 false(2) 404 } 405 ACCESS read-only -- Note: agent implementors are 406 -- encouraged to extend this 407 -- access to read-write if that 408 -- makes sense in their agent. 409 STATUS mandatory 410 DESCRIPTION 411 "This object has a value of false(2) if 412 this interface only accepts packets/frames 413 that are addressed to this station. This 415 Internet draft Interface MIB Extensions October 1990 417 object has a value of true(1) when the 418 station accepts all packets/frames 419 transmitted on the media. The value 420 true(1) is only legal on certain types of 421 media. If legal, setting this object to a 422 value of true(1) may require the interface 423 to be reset before becoming effective." 424 ::= { ifExtnsEntry 8 } 426 -- 427 -- Generic Interface Test Table 428 -- 429 -- This group of objects is optional, but if the table is 430 -- implemented, all objects in the table must be implemented. 432 ifExtnsTestTable OBJECT-TYPE 433 SYNTAX SEQUENCE OF IfExtnsTestEntry 434 ACCESS not-accessible 435 STATUS mandatory 436 DESCRIPTION 437 "This table contains one entry per 438 interface." 439 ::= { ifExtensions 2 } 441 ifExtnsTestEntry OBJECT-TYPE 442 SYNTAX IfExtnsTestEntry 443 ACCESS not-accessible 444 STATUS mandatory 445 DESCRIPTION 446 "An entry containing objects for 447 invoking tests on an interface." 448 INDEX { ifExtnsTestIfIndex } 449 ::= { ifExtnsTestTable 1 } 451 IfExtnsTestEntry ::= SEQUENCE { 452 ifExtnsTestIfIndex 453 INTEGER, 454 ifExtnsTestUser 455 OCTET STRING, 456 ifExtnsTestCommunity 457 OCTET STRING, 458 ifExtnsTestType 459 OBJECT IDENTIFIER, 460 ifExtnsTestResult 461 INTEGER, 463 Internet draft Interface MIB Extensions October 1990 465 ifExtnsTestCode 466 OBJECT IDENTIFIER 467 } 469 ifExtnsTestUser OBJECT-TYPE 470 SYNTAX OCTET STRING 471 ACCESS read-only 472 STATUS mandatory 473 DESCRIPTION 474 "This object contains the name of the 475 authentication service user [9] who 476 originated the SNMP Message which invoked 477 the current or most recent test on this 478 interface. If the authentication service 479 user is unknown or undefined, this value 480 contains the zero-length string." 481 ::= { ifExtnsTestEntry 1 } 483 ifExtnsTestCommunity OBJECT-TYPE 484 SYNTAX OCTET STRING 485 ACCESS read-only 486 STATUS mandatory 487 DESCRIPTION 488 "This object contains the name of the 489 SNMP authentication community [9] which 490 was used to authenticate the SNMP Message 491 which invoked the current or most recent 492 test on this interface. If the 493 authentication community is unknown or 494 undefined, this value contains the 495 zero-length string." 496 ::= { ifExtnsTestEntry 2 } 498 ifExtnsTestIfIndex OBJECT-TYPE 499 SYNTAX INTEGER 500 ACCESS read-only 501 STATUS mandatory 502 DESCRIPTION 503 "The value of this object identifies the 504 interface for which this entry contains 505 information on interface tests. The value 506 of this object for a particular interface 507 has the same value as the ifIndex object, 508 defined in [4,6], for the same interface." 509 ::= { ifExtnsTestEntry 3 } 511 Internet draft Interface MIB Extensions October 1990 513 ifExtnsTestType OBJECT-TYPE 514 SYNTAX OBJECT IDENTIFIER 515 ACCESS read-write 516 STATUS mandatory 517 DESCRIPTION 518 "A control variable used to start and stop 519 operator-initiated interface tests. If 520 the value noTest is written, then this 521 aborts any test in progress, or if no test 522 is in progress, acts as a no-operation. 523 If any other value is used, writing to 524 this object is only valid when no test is 525 currently in progress, in which case the 526 indicated test is initiated. 527 Most OBJECT IDENTIFIER values assigned 528 to tests are defined elsewhere, in associ- 529 ation with specific types of interface. 530 However, this document does assign a value 531 for a full-duplex loopback test. Also, 532 the subject identifier, noTest, is defined 533 here. 534 Note that noTest is a syntactically 535 valid object identifier, and any conformant 536 implementation of ASN.1 and BER must be able 537 to generate and recognize this value. 538 When read, this object always returns 539 the most recent value that ifExtnsTestType 540 was set to. If it has not been set since 541 the last initialization of the network 542 management subsystem on the node, it returns 543 a value of noTest." 544 ::= { ifExtnsTestEntry 4 } 546 -- abort Test in progress/ no Test in progress 547 noTest OBJECT IDENTIFIER ::= { 0 0 } 549 wellKnownTests OBJECT IDENTIFIER ::= { ifExtensions 4 } 551 -- full-duplex loopback test 552 testFullDuplexLoopBack OBJECT IDENTIFIER ::= { wellKnownTests 1 } 554 ifExtnsTestResult OBJECT-TYPE 555 SYNTAX INTEGER { 556 none(1), -- no test yet requested 558 Internet draft Interface MIB Extensions October 1990 560 success(2), 561 inProgress(3), 562 notSupported(4), 563 unAbleToRun(5), -- due to state of system 564 aborted(6), 565 failed(7) 566 } 567 ACCESS read-only 568 STATUS mandatory 569 DESCRIPTION 570 "This object contains the result of the most 571 recently requested test, or the value 572 none(1) if no tests have been requested since 573 the last reset. Note that this facility 574 provides no provision for saving the results 575 of one test when starting another, as could 576 be required if used by multiple managers 577 concurrently." 578 ::= { ifExtnsTestEntry 5 } 580 ifExtnsTestCode OBJECT-TYPE 581 SYNTAX OBJECT IDENTIFIER 582 ACCESS read-only 583 STATUS mandatory 584 DESCRIPTION 585 "This object contains a code which contains 586 more specific information on the test result, 587 for example an error-code after a failed 588 test. Error codes and other values this 589 object may take are specific to the type of 590 interface and/or test. However, one subject 591 identifier, testCodeUnknown, is defined here 592 for use if no additional result code is 593 available. 594 Note that testCodeUnknown is a 595 syntactically valid object identifier, and 596 any conformant implementation of ASN.1 and 597 the BER must be able to generate and 598 recognize this value." 599 ::= { ifExtnsTestEntry 6 } 601 -- no additional result code available 602 testCodeUnknown OBJECT IDENTIFIER ::= { 0 0 } 604 Internet draft Interface MIB Extensions October 1990 606 -- Generic Receive Address Table 607 -- 608 -- This group of objects is mandatory for all types of 609 -- interfaces which can receive packets/frames addressed to 610 -- more than one address. 612 ifExtnsRcvAddrTable OBJECT-TYPE 613 SYNTAX SEQUENCE OF IfExtnsRcvAddrEntry 614 ACCESS not-accessible 615 STATUS mandatory 616 DESCRIPTION 617 "This table contains an entry for each 618 address (broadcast, multicast, or uni-cast) 619 for which the system will receive packets/ 620 frames on a particular interface. When an 621 interface is operating in promiscuous mode, 622 entries are only required for those 623 addresses for which the system would receive 624 frames were it not operating in promiscuous 625 mode." 626 ::= { ifExtensions 3 } 628 ifExtnsRcvAddrEntry OBJECT-TYPE 629 SYNTAX IfExtnsRcvAddrEntry 630 ACCESS not-accessible 631 STATUS mandatory 632 DESCRIPTION 633 "A list of objects identifying an address 634 for which the system will accept packets/ 635 frames on a particular interface." 636 INDEX { ifExtnsRcvAddrIfIndex, ifExtnsRcvAddress } 637 ::= { ifExtnsRcvAddrTable 1 } 639 IfExtnsRcvAddrEntry ::= SEQUENCE { 640 ifExtnsRcvAddrIfIndex 641 INTEGER, 642 ifExtnsRcvAddress 643 PhysAddress, 644 ifExtnsRcvAddrStatus 645 INTEGER 646 } 648 ifExtnsRcvAddrIfIndex OBJECT-TYPE 649 SYNTAX INTEGER 650 ACCESS read-only 652 Internet draft Interface MIB Extensions October 1990 654 STATUS mandatory 655 DESCRIPTION 656 "The value of ifIndex, defined in [4,6], 657 of an interface which recognizes this 658 entry's address." 659 ::= { ifExtnsRcvAddrEntry 1 } 661 ifExtnsRcvAddress OBJECT-TYPE 662 SYNTAX PhysAddress 663 ACCESS read-only 664 STATUS mandatory 665 DESCRIPTION 666 "An address for which the system will 667 accept packets/frames on this entry's 668 interface." 669 ::= { ifExtnsRcvAddrEntry 2 } 671 ifExtnsRcvAddrStatus OBJECT-TYPE 672 SYNTAX INTEGER { 673 other(1), 674 invalid(2), 675 volatile(3), 676 nonVolatile(4) 677 } 678 ACCESS read-write 679 STATUS mandatory 680 DESCRIPTION 681 "This object has the value nonVolatile(4) 682 for those entries in the table which are 683 valid and will not be deleted by the next 684 restart of the managed system. Entries 685 having the value volatile(3) are valid 686 and exist, but have not been saved, so 687 that will not exist after the next 688 restart of the managed system. Entries 689 having the value other(1) are valid and 690 exist but are not classified as to whether 691 they will continue to exist after the next 692 restart. Entries having the value invalid(2) 693 are invalid and do not represent an address 694 for which an interface accepts frames. 695 Setting an object instance to one of 696 the values other(1), volatile(3), or 697 nonVolatile(4) causes the corresponding 698 entry to exist or continue to exist, and 700 Internet draft Interface MIB Extensions October 1990 702 to take on the respective status as regards 703 the next restart of the managed system. 704 Setting an object instance to the value 705 invalid(2) causes the corresponding entry 706 to become invalid or cease to exist. 707 It is an implementation-specific matter 708 as to whether the agent removes an 709 invalidated entry from the table. 710 Accordingly, management stations must be 711 prepared to receive tabular information 712 from agents that corresponds to entries not 713 currently in use. Proper interpretation of 714 such entries requires examination of the 715 relevant ifExtnsRcvAddrStatus object 716 instance." 717 DEFVAL { volatile } 718 ::= { ifExtnsRcvAddrEntry 3 } 720 END 722 Internet draft Interface MIB Extensions October 1990 724 7. Acknowledgements 726 Most of the MIB objects defined in this document were 727 originally proposed as a part of the IEEE 802.5 MIB, as 728 prepared by: 730 Eric B. Decker, cisco Systems, Inc., and 731 Richard Fox, Synoptics Inc. 733 In addition, the comments of the following individuals are 734 acknowledged: 736 James R. Davin, MIT-LCS, 737 Stan Froyd, ACC, 738 Frank Kastenholz, Racal Interlan 739 Marshall T. Rose, PSI, 740 Bob Stewart, Xyplex, 741 David Waitzman, BBN, 742 Wengyik Yeong, PSI, 744 Internet draft Interface MIB Extensions October 1990 746 8. References 748 [1] V. Cerf, IAB Recommendations for the Development of 749 Internet Network Management Standards. Internet Working 750 Group Request for Comments 1052. Network Information 751 Center, SRI International, Menlo Park, California, 752 (April, 1988). 754 [2] V. Cerf, Report of the Second Ad Hoc Network Management 755 Review Group, Internet Working Group Request for Comments 756 1109. Network Information Center, SRI International, 757 Menlo Park, California, (August, 1989). 759 [3] M.T. Rose and K. McCloghrie, Structure and Identification 760 of Management Information for TCP/IP-based internets, 761 Internet Working Group Request for Comments 1155. 762 Network Information Center, SRI International, Menlo 763 Park, California, (May, 1990). 765 [4] K. McCloghrie and M.T. Rose, Management Information Base 766 for Network Management of TCP/IP-based internets, 767 Internet Working Group Request for Comments 1156. 768 Network Information Center, SRI International, Menlo 769 Park, California, (May, 1990). 771 [5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin, 772 Simple Network Management Protocol, Internet Working 773 Group Request for Comments 1157. Network Information 774 Center, SRI International, Menlo Park, California, (May, 775 1990). 777 [6] M.T. Rose (editor), Management Information Base for 778 Network Management of TCP/IP-based internets, Internet 779 Working Group Request for Comments 1158. Network 780 Information Center, SRI International, Menlo Park, 781 California, (May, 1990). 783 [7] Information processing systems Open Systems 784 Interconnection Specification of Abstract Syntax Notation 785 One (ASN.1), International Organization for 786 Standardization. International Standard 8824, (December, 787 1987). 789 [8] Information processing systems Open Systems 790 Interconnection Specification of Basic Encoding Rules for 792 Internet draft Interface MIB Extensions October 1990 794 Abstract Notation One (ASN.1), International Organization 795 for Standardization. International Standard 8825, 796 (December, 1987). 798 [9] J.M. Galvin, K. McCloghrie, J.R. Davin, Authentication 799 and Privacy in the SNMP, Internet Working Group, Request 800 for Comments (in preparation), Network Information 801 Center, SRI International, Menlo Park, California, 802 (September, 1990). 804 [10] M.T. Rose, K. McCloghrie (editors), Towards Concise MIB 805 Definitions, Internet Draft, Internet Engineering Task 806 Force, (September, 1990). 808 Internet draft Interface MIB Extensions October 1990 810 Table of Contents 812 1 Status of this Memo ................................... 1 813 2 Abstract .............................................. 1 814 3 Historical Perspective ................................ 2 815 4 Objects ............................................... 4 816 4.1 Format of Definitions ............................... 4 817 5 Overview .............................................. 5 818 5.1 Generic Interface Extension Table ................... 5 819 5.2 Generic Interface Test Table ........................ 5 820 5.3 Generic Receive Address Table ....................... 6 821 6 Definitions ........................................... 7 822 7 Acknowledgements ...................................... 18 823 8 References ............................................ 19 825 ------- End of Forwarded Message