idnits 2.17.1 draft-ietf-pppext-bridgemib-03.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-26) 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 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: ' 1. Abstract' ) ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** 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. ** The abstract seems to contain references ([2], [3], [4], [5], [6], [7], [8], [9], [5,6], [10], [11], [12], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 208 has weird spacing: '...ridging over...' == 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 (11 May 1993) is 11308 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? '10' on line 700 looks like a reference -- Missing reference section? '3' on line 670 looks like a reference -- Missing reference section? '5' on line 682 looks like a reference -- Missing reference section? '6' on line 686 looks like a reference -- Missing reference section? '1' on line 658 looks like a reference -- Missing reference section? '2' on line 664 looks like a reference -- Missing reference section? '4' on line 676 looks like a reference -- Missing reference section? '7' on line 690 looks like a reference -- Missing reference section? '8' on line 693 looks like a reference -- Missing reference section? '9' on line 697 looks like a reference -- Missing reference section? '11' on line 703 looks like a reference -- Missing reference section? '12' on line 706 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 3 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft 4 The Definitions of Managed Objects for 5 the Bridge Network Control Protocol of 6 the Point-to-Point Protocol 8 11 May 1993 10 Frank Kastenholz 11 FTP Software, Inc 12 2 High Street 13 North Andover, Mass 01845 USA 15 kasten@ftp.com 17 Status of this Memo 19 This document is an Internet Draft. Internet Drafts are 20 working documents of the Internet Engineering Task Force 21 (IETF), its Areas, and its Working Groups. Note that other 22 groups may also distribute working documents as Internet 23 Drafts. 25 Internet Drafts are draft documents valid for a maximum of six 26 months. Internet Drafts may be updated, replaced, or 27 obsoleted by other documents at any time. It is not 28 appropriate to use Internet Drafts as reference material or to 29 cite them other than as a ``working draft'' or ``work in 30 progress.'' Please check the 1id-abstracts.txt listing 31 contained in the internet-drafts Shadow Directories on 32 nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or 33 munnari.oz.au to learn the current status of any Internet 34 Draft. 36 This document will be submitted to the Internet Activities 37 Board as a Draft Standard. This document defines an 38 experimental extension to the SNMP MIB. Upon publication as a 39 Draft Standard, a new MIB number will be assigned. This is a 40 working document only, it should neither be cited nor quoted 41 in any formal document. 43 This document will expire before 16 Nov. 1993. 45 Distribution of this document is unlimited. 47 Please send comments to the author. 49 1. Abstract 51 This memo defines an experimental portion of the Management 52 Information Base (MIB) for use with network management 53 protocols in TCP/IP-based internets. In particular, it 54 describes managed objects used for managing the bridge Network 55 Control Protocol[10] on subnetwork interfaces using the family 56 of Point-to-Point Protocols. 58 This memo does not specify a standard for the Internet 59 community. 61 2. The Network Management Framework 63 The Internet-standard Network Management Framework consists of 64 three components. They are: 66 RFC 1155 which defines the SMI, the mechanisms used for 67 describing and naming objects for the purpose of 68 management. RFC 1212 defines a more concise description 69 mechanism, which is wholly consistent with the SMI. 71 RFC 1213 defines MIB-II, the core set of managed objects 72 for the Internet suite of protocols. 74 RFC 1157 which defines the SNMP, the protocol used for 75 network access to managed objects. 77 The Framework permits new objects to be defined for the 78 purpose of experimentation and evaluation. 80 3. Objects 82 Managed objects are accessed via a virtual information store, 83 termed the Management Information Base or MIB. Objects in the 84 MIB are defined using the subset of Abstract Syntax Notation 85 One (ASN.1) [3] defined in the SMI. In particular, each 86 object type is named by an OBJECT IDENTIFIER, an 87 administratively assigned name. The object type together with 88 an object instance serves to uniquely identify a specific 89 instantiation of the object. For human convenience, we often 90 use a textual string, termed the descriptor, to refer to the 91 object type. 93 3.1. Format of Definitions 95 Section 5 contains the specification of all object types 96 contained in this MIB module. The object types are defined 97 using the conventions defined in the SMI, as amended by the 98 extensions specified in [5,6]. 100 4. Overview 102 4.1. Object Selection Criteria 104 To be consistent with IAB directives and good engineering 105 practice, an explicit attempt was made to keep this MIB as 106 simple as possible. This was accomplished by applying the 107 following criteria to objects proposed for inclusion: 109 (1) Require objects be essential for either fault or 110 configuration management. In particular, objects for 111 which the sole purpose was to debug implementations were 112 explicitly excluded from the MIB. 114 (2) Consider evidence of current use and/or utility. 116 (3) Limit the total number of objects. 118 (4) Exclude objects which are simply derivable from others in 119 this or other MIBs. 121 4.2. Structure of the PPP 123 This section describes the basic model of PPP used in 124 developing the PPP MIB. This information should be useful to 125 the implementor in understanding some of the basic design 126 decisions of the MIB. 128 The PPP is not one single protocol but a large family of 129 protocols. Each of these is, in itself, a fairly complex 130 protocol. The PPP protocols may be divided into three rough 131 categories: 133 Control Protocols 134 The Control Protocols are used to control the operation 135 of the PPP. The Control Protocols include the Link 136 Control Protocol (LCP), the Password Authentication 137 Protocol (PAP), the Link Quality Report (LQR), and the 138 Challenge Handshake Authentication Protocol (CHAP). 140 Network Protocols 141 The Network Protocols are used to move the network 142 traffic over the PPP interface. A Network Protocol 143 encapsulates the datagrams of a specific higher-layer 144 protocol that is using the PPP as a data link. Note that 145 within the context of PPP, the term "Network Protocol" 146 does not imply an OSI Layer-3 protocol; for instance, 147 there is a Bridging network protocol. 149 Network Control Protocols (NCPs) 150 The NCPs are used to control the operation of the Network 151 Protocols. Generally, each Network Protocol has its own 152 Network Control Protocol; thus, the IP Network Protocol 153 has its IP Control Protocol, the Bridging Network 154 Protocol has its Bridging Network Control Protocol and so 155 on. 157 This document specifies the objects used in managing one of 158 these protocols, namely the Bridge Network Control Protocol. 160 4.3. MIB Groups 162 Objects in this MIB are arranged into several MIB groups. 163 Each group is organized as a set of related objects. 165 These groups are the basic unit of conformance: if the 166 semantics of a group are applicable to an implementation then 167 all objects in the group must be implemented. 169 The PPP MIB is organized into several MIB Groups, including, 170 but not limited to, the following groups: 171 o The PPP Link Group 172 o The PPP LQR Group 173 o The PPP LQR Extensions Group 174 o The PPP IP Group 175 o The PPP Bridge Group 176 o The PPP Security Group 178 This document specifies the following group: 180 The PPP Bridge Group 181 The PPP Bridge Group contains configuration, status, and 182 control variables that apply to the operation of Bridging 183 over PPP. 185 Implementation of this group is mandatory for all 186 implementations of PPP that support the Bridging over 187 PPP. 189 5. Definitions 191 PPP-BRIDGE-NCP-MIB DEFINITIONS ::= BEGIN 193 IMPORTS 194 experimental, Counter 195 FROM RFC1155-SMI 196 ifIndex 197 FROM RFC1213-MIB 198 OBJECT-TYPE 199 FROM RFC-1212 200 ppp 201 FROM PPP-LCP-MIB; 203 pppBridge OBJECT IDENTIFIER ::= { ppp 4 } 205 -- 206 -- The PPP Bridge NCP Group. 207 -- Implementation of this group is mandatory for all 208 -- PPP implementations that support MAC Bridging over 209 -- PPP (RFC1220). 210 -- 212 -- The following object reflect the values of the option 213 -- parameters used in the PPP Link Control Protocol 214 -- pppBridgeLocalToRemoteTinygramCompression 215 -- pppBridgeRemoteToLocalTinygramCompression 216 -- pppBridgeLocalToRemoteLanId 217 -- pppBridgeRemoteToLocalLanId 218 -- 219 -- These values are not available until after the PPP Option 220 -- negotiation has completed, which is indicated by the link 221 -- reaching the open state (i.e. pppBridgeOperStatus is set to 222 -- opened). 223 -- 224 -- Therefore, when pppBridgeOperStatus is not opened 225 -- the contents of these objects is undefined. The value 226 -- returned when accessing the objects is an implementation 227 -- dependent issue. 229 pppBridgeTable OBJECT-TYPE 230 SYNTAX SEQUENCE OF PppBridgeEntry 231 ACCESS not-accessible 232 STATUS mandatory 233 DESCRIPTION 234 "Table containing the parameters and statistics 235 for the local PPP entity that are related to 236 the operation of Bridging over the PPP." 237 ::= { pppBridge 1 } 239 pppBridgeEntry OBJECT-TYPE 240 SYNTAX PppBridgeEntry 241 ACCESS not-accessible 242 STATUS mandatory 243 DESCRIPTION 244 "Bridging information for a particular PPP 245 link." 246 INDEX { ifIndex } 247 ::= { pppBridgeTable 1 } 249 PppBridgeEntry ::= SEQUENCE { 250 pppBridgeOperStatus 251 INTEGER, 252 pppBridgeLocalToRemoteTinygramCompression 253 INTEGER, 254 pppBridgeRemoteToLocalTinygramCompression 255 INTEGER, 256 pppBridgeLocalToRemoteLanId 257 INTEGER, 258 pppBridgeRemoteToLocalLanId 259 INTEGER 260 } 262 pppBridgeOperStatus OBJECT-TYPE 263 SYNTAX INTEGER {opened(1), not-opened(2)} 264 ACCESS read-only 265 STATUS mandatory 266 DESCRIPTION 267 "The operational status of the Bridge network 268 protocol. If the value of this object is up 269 then the finite state machine for the Bridge 270 network protocol has reached the Opened state." 271 ::= { pppBridgeEntry 1 } 273 pppBridgeLocalToRemoteTinygramCompression OBJECT-TYPE 274 SYNTAX INTEGER { false(1), true(2) } 275 ACCESS read-only 276 STATUS mandatory 277 DESCRIPTION 278 "Indicates whether the local node will perform 279 Tinygram Compression when sending packets to 280 the remote entity. If false then the local 281 entity will not perform Tinygram Compression. 282 If true then the local entity will perform 283 Tinygram Compression. The value of this object 284 is meaningful only when the link has reached 285 the open state (pppBridgeOperStatus is 286 opened)." 287 REFERENCE 288 "Section 6.7, Tinygram Compression Option, of 289 RFC1220" 290 ::= { pppBridgeEntry 2 } 292 pppBridgeRemoteToLocalTinygramCompression OBJECT-TYPE 293 SYNTAX INTEGER { false(1), true(2) } 294 ACCESS read-only 295 STATUS mandatory 296 DESCRIPTION 297 "If false(1) then the remote entity is not 298 expected to perform Tinygram Compression. If 299 true then the remote entity is expected to 300 perform Tinygram Compression. The value of this 301 object is meaningful only when the link has 302 reached the open state (pppBridgeOperStatus is 303 opened)." 304 REFERENCE 305 "Section 6.7, Tinygram Compression Option, of 306 RFC1220" 307 ::= { pppBridgeEntry 3 } 309 pppBridgeLocalToRemoteLanId OBJECT-TYPE 310 SYNTAX INTEGER { false(1), true(2) } 311 ACCESS read-only 312 STATUS mandatory 313 DESCRIPTION 314 "Indicates whether the local node will include 315 the LAN Identification field in transmitted 316 packets or not. If false(1) then the local node 317 will not transmit this field, true(2) means 318 that the field will be transmitted. The value 319 of this object is meaningful only when the link 320 has reached the open state (pppBridgeOperStatus 321 is opened)." 322 REFERENCE 323 "Section 6.8, LAN Identification Option, of 324 RFC1220" 325 ::= { pppBridgeEntry 4 } 327 pppBridgeRemoteToLocalLanId OBJECT-TYPE 328 SYNTAX INTEGER { false(1), true(2) } 329 ACCESS read-only 330 STATUS mandatory 331 DESCRIPTION 332 "Indicates whether the remote node has 333 indicated that it will include the LAN 334 Identification field in transmitted packets or 335 not. If false(1) then the field will not be 336 transmitted, if true(2) then the field will be 337 transmitted. The value of this object is 338 meaningful only when the link has reached the 339 open state (pppBridgeOperStatus is opened)." 340 REFERENCE 341 "Section 6.8, LAN Identification Option, of 342 RFC1220" 343 ::= { pppBridgeEntry 5 } 345 -- 346 -- The PPP Bridge Configuration table 347 -- 349 pppBridgeConfigTable OBJECT-TYPE 350 SYNTAX SEQUENCE OF PppBridgeConfigEntry 351 ACCESS not-accessible 352 STATUS mandatory 353 DESCRIPTION 354 "Table containing the parameters and statistics 355 for the local PPP entity that are related to 356 the operation of Bridging over the PPP." 357 ::= { pppBridge 2 } 359 pppBridgeConfigEntry OBJECT-TYPE 360 SYNTAX PppBridgeConfigEntry 361 ACCESS not-accessible 362 STATUS mandatory 363 DESCRIPTION 364 "Bridging Configuration information for a 365 particular PPP link." 366 INDEX { ifIndex } 367 ::= { pppBridgeConfigTable 1 } 369 PppBridgeConfigEntry ::= SEQUENCE { 370 pppBridgeConfigAdminStatus 371 INTEGER, 372 pppBridgeConfigTinygram 373 INTEGER, 374 pppBridgeConfigRingId 375 INTEGER, 376 pppBridgeConfigLineId 377 INTEGER, 378 pppBridgeConfigLanId 379 INTEGER 380 } 382 pppBridgeConfigAdminStatus OBJECT-TYPE 383 SYNTAX INTEGER { open(1), close(2) } 384 ACCESS read-write 385 STATUS mandatory 386 DESCRIPTION 387 "The immediate desired status of the Bridging 388 network protocol. Setting this object to open 389 will inject an administrative open event into 390 the Bridging network protocol's finite state 391 machine. Setting this object to close will 392 inject an administrative close event into the 393 Bridging network protocol's finite state 394 machine." 395 ::= { pppBridgeConfigEntry 1 } 397 pppBridgeConfigTinygram OBJECT-TYPE 398 SYNTAX INTEGER { false(1), true(2) } 399 ACCESS read-write 400 STATUS mandatory 401 DESCRIPTION 402 "If false then the local BNCP entity will not 403 initiate the Tinygram Compression Option 404 Negotiation. If true then the local BNCP entity 405 will initiate negotiation of this option." 406 REFERENCE 407 "Section 6.7, Tinygram Compression Option, of 408 RFC1220" 409 DEFVAL { true } 410 ::= { pppBridgeConfigEntry 2 } 412 pppBridgeConfigRingId OBJECT-TYPE 413 SYNTAX INTEGER { false(1), true(2) } 414 ACCESS read-write 415 STATUS mandatory 416 DESCRIPTION 417 "If false then the local PPP Entity will not 418 initiate a Remote Ring Identification Option 419 negotiation. If true then the local PPP entity 420 will intiate this negotiation. This MIB object 421 is relevant only if the interface is for 802.5 422 Token Ring bridging." 423 REFERENCE 424 "Section 6.4, IEEE 802.5 Remote Ring 425 Identification Option, of RFC1220" 426 DEFVAL { false } 427 ::= { pppBridgeConfigEntry 3 } 429 pppBridgeConfigLineId OBJECT-TYPE 430 SYNTAX INTEGER { false(1), true(2) } 431 ACCESS read-write 432 STATUS mandatory 433 DESCRIPTION 434 "If false then the local PPP Entity is not to 435 initiate a Line Identification Option 436 negotiation. If true then the local PPP entity 437 will intiate this negotiation. This MIB object 438 is relevant only if the interface is for 802.5 439 Token Ring bridging." 440 REFERENCE 441 "Section 6.5, IEEE 802.5 Line Identification 442 Option, of RFC1220" 443 DEFVAL { false } 444 ::= { pppBridgeConfigEntry 4 } 446 pppBridgeConfigLanId OBJECT-TYPE 447 SYNTAX INTEGER { false(1), true(2) } 448 ACCESS read-write 449 STATUS mandatory 450 DESCRIPTION 451 "If false then the local BNCP entity will not 452 initiate the LAN Identification Option 453 Negotiation. If true then the local BNCP entity 454 will initiate negotiation of this option." 455 REFERENCE 456 "Section 6.8, LAN Identification Option, of 457 RFC1220" 458 DEFVAL { false } 459 ::= { pppBridgeConfigEntry 5 } 461 -- 462 -- The PPP Bridge Media Status Table 463 -- 465 pppBridgeMediaTable OBJECT-TYPE 466 SYNTAX SEQUENCE OF PppBridgeMediaEntry 467 ACCESS not-accessible 468 STATUS mandatory 469 DESCRIPTION 470 "Table identifying which MAC media types are 471 enabled for the Bridging NCPs." 472 ::= { pppBridge 3 } 474 pppBridgeMediaEntry OBJECT-TYPE 475 SYNTAX PppBridgeMediaEntry 476 ACCESS not-accessible 477 STATUS mandatory 478 DESCRIPTION 479 "Status of a specific MAC Type for a specific 480 PPP Link." 481 INDEX { ifIndex, pppBridgeMediaMacType } 482 ::= { pppBridgeMediaTable 1 } 484 PppBridgeMediaEntry ::= SEQUENCE { 485 pppBridgeMediaMacType 486 INTEGER, 487 pppBridgeMediaLocalStatus 488 INTEGER, 489 pppBridgeMediaRemoteStatus 490 INTEGER 491 } 493 pppBridgeMediaMacType OBJECT-TYPE 494 SYNTAX INTEGER(0..2147483648) 495 ACCESS read-only 496 STATUS mandatory 497 DESCRIPTION 498 "The MAC type for which this entry in the 499 pppBridgeMediaTable is providing status 500 information. Valid values for this object are 501 defined in Section 6.6 MAC Type Support 502 Selection of RFC1220 (Bridging Point-to-Point 503 Protocol)." 504 REFERENCE 505 "Section 6.6, MAC Type Support Selection, of 506 RFC1212." 507 ::= { pppBridgeMediaEntry 1 } 509 pppBridgeMediaLocalStatus OBJECT-TYPE 510 SYNTAX INTEGER { accept(1), dont-accept(2) } 511 ACCESS read-only 512 STATUS mandatory 513 DESCRIPTION 514 "Indicates whether the local PPP Bridging 515 Entity will accept packets of the protocol type 516 identified in pppBridgeMediaMacType on the PPP 517 link identified by ifIndex or not. If this 518 object is accept then any packets of the 519 indicated MAC type will be received and 520 properly processed. If this object is dont- 521 accept then received packets of the indicated 522 MAC type will not be properly processed." 523 REFERENCE 524 "Section 6.6, MAC Type Support Selection, of 525 RFC1212." 526 ::= { pppBridgeMediaEntry 2 } 528 pppBridgeMediaRemoteStatus OBJECT-TYPE 529 SYNTAX INTEGER { accept(1), dont-accept(2) } 530 ACCESS read-only 531 STATUS mandatory 532 DESCRIPTION 533 "Indicates whether the local PPP Bridging 534 Entity believes that the remote PPP Bridging 535 Entity will accept packets of the protocol type 536 identified in pppBridgeMediaMacType on the PPP 537 link identified by ifIndex or not." 538 REFERENCE 539 "Section 6.6, MAC Type Support Selection, of 540 RFC1212." 541 ::= { pppBridgeMediaEntry 3 } 543 -- 544 -- The PPP Bridge Media Configuration Table 545 -- 547 pppBridgeMediaConfigTable OBJECT-TYPE 548 SYNTAX SEQUENCE OF PppBridgeMediaConfigEntry 549 ACCESS not-accessible 550 STATUS mandatory 551 DESCRIPTION 552 "Table identifying which MAC media types are 553 enabled for the Bridging NCPs." 554 ::= { pppBridge 4 } 556 pppBridgeMediaConfigEntry OBJECT-TYPE 557 SYNTAX PppBridgeMediaConfigEntry 558 ACCESS not-accessible 559 STATUS mandatory 560 DESCRIPTION 561 "Status of a specific MAC Type for a specific 562 PPP Link." 563 INDEX { ifIndex, pppBridgeMediaConfigMacType } 564 ::= { pppBridgeMediaConfigTable 1 } 566 PppBridgeMediaConfigEntry ::= SEQUENCE { 567 pppBridgeMediaConfigMacType 568 INTEGER, 569 pppBridgeMediaConfigLocalStatus 570 INTEGER 571 } 573 pppBridgeMediaConfigMacType OBJECT-TYPE 574 SYNTAX INTEGER(0..2147483648) 575 ACCESS read-write 576 STATUS mandatory 577 DESCRIPTION 578 "The MAC type for which this entry in the 579 pppBridgeMediaConfigTable is providing status 580 information. Valid values for this object are 581 defined in Section 6.6 MAC Type Support 582 Selection of RFC1220 (Bridging Point-to-Point 583 Protocol)." 584 REFERENCE 585 "Section 6.6, MAC Type Support Selection, of 586 RFC1212." 587 ::= { pppBridgeMediaConfigEntry 1 } 589 pppBridgeMediaConfigLocalStatus OBJECT-TYPE 590 SYNTAX INTEGER { accept(1), dont-accept(2) } 591 ACCESS read-write 592 STATUS mandatory 593 DESCRIPTION 594 "Indicates whether the local PPP Bridging 595 Entity should accept packets of the protocol 596 type identified in pppBridgeMediaConfigMacType 597 on the PPP link identified by ifIndex or not. 598 Setting this object to the value dont-accept 599 has the affect of invalidating the 600 corresponding entry in the 601 pppBridgeMediaConfigTable object. It is an 602 implementation-specific matter as to whether 603 the agent removes an invalidated entry from the 604 table. Accordingly, management stations must be 605 prepared to receive tabular information from 606 agents that corresponds to entries not 607 currently in use. Changing this object will 608 have effect when the link is next restarted." 609 REFERENCE 610 "Section 6.6, MAC Type Support Selection, of 611 RFC1212." 612 ::= { pppBridgeMediaConfigEntry 2 } 614 END 615 6. Acknowledgements 617 This document was produced by the PPP working group. In 618 addition to the working group, the author wishes to thank the 619 following individuals for their comments and contributions: 621 Bill Simpson -- Daydreamer 622 Glenn McGregor -- Merit 623 Jesse Walker -- DEC 624 Chris Gunner -- DEC 625 7. Security Considerations 627 The PPP MIB affords the network operator the ability to 628 configure and control the PPP links of a particular system, 629 including the PPP authentication protocols. This represents a 630 security risk. 632 These risks are addressed in the following manners: 634 (1) All variables which represent a significant security risk 635 are placed in separate, optional, MIB Groups. As the MIB 636 Group is the quantum of implementation within a MIB, the 637 implementor of the MIB may elect not to implement these 638 groups. 640 (2) The implementor may choose to implement the variables 641 which present a security risk so that they may not be 642 written, i.e., the variables are READ-ONLY. This method 643 still presents a security risk, and is not recommended, 644 in that the variables, specifically the PPP 645 Authentication Protocols' variables, may be easily read. 647 (3) Using SNMPv2, the operator can place the variables into 648 MIB views which are protected in that the parties which 649 have access to those MIB views use authentication and 650 privacy protocols, or the operator may elect to make 651 these views not accessible to any party. In order to 652 facilitate this placement, all security-related variables 653 are placed in separate MIB Tables. This eases the 654 identification of the necessary MIB View Subtree. 656 8. References 658 [1] M.T. Rose and K. McCloghrie, Structure and Identification 659 of Management Information for TCP/IP-based internets, 660 Internet Working Group Request for Comments 1155. 661 Network Information Center, SRI International, Menlo 662 Park, California, (May, 1990). 664 [2] K. McCloghrie and M.T. Rose, Management Information Base 665 for Network Management of TCP/IP-based internets - MIB-2, 666 Internet Working Group Request for Comments 1213. 667 Network Information Center, SRI International, Menlo 668 Park, California, (March, 1991). 670 [3] Information processing systems - Open Systems 671 Interconnection - Specification of Abstract Syntax 672 Notation One (ASN.1), International Organization for 673 Standardization. International Standard 8824, (December, 674 1987). 676 [4] Information processing systems - Open Systems 677 Interconnection - Specification of Basic Encoding Rules 678 for Abstract Notation One (ASN.1), International 679 Organization for Standardization. International Standard 680 8825, (December, 1987). 682 [5] Rose, M., and K. McCloghrie, Editors, Concise MIB 683 Definitions, RFC 1212, Performance Systems International, 684 Hughes LAN Systems, March 1991. 686 [6] Rose, M., Editor, A Convention for Defining Traps for use 687 with the SNMP, RFC 1215, Performance Systems 688 International, March 1991. 690 [7] K. McCloghrie, Extensions to the Generic-Interface MIB, 691 RFC1229, Hughes LAN Systems, May 1991. 693 [8] W. Simpson, The Point-to-Point Protocol for the 694 Transmission of Multi-protocol Datagrams over Point-to- 695 Point Links, RFC 1331, May 1992. 697 [9] G. McGregor, The PPP Internet Protocol Control Protocol, 698 RFC 1332, Merit, May 1992. 700 [10] F. Baker, Point-to-Point Protocol Extensions for 701 Bridging, RFC1220, ACC, April 1991. 703 [11] B. Lloyd, and Simpson, W., PPP Authentication Protocols 704 RFC1334, October 1992. 706 [12] W. Simpson, PPP Link Quality Monitoring, RFC 1333, May 707 1992. 709 Table of Contents 711 Status of this Memo .................................... 1 712 1 Abstract .............................................. 2 713 2 The Network Management Framework ...................... 3 714 3 Objects ............................................... 4 715 3.1 Format of Definitions ............................... 4 716 4 Overview .............................................. 5 717 4.1 Object Selection Criteria ........................... 5 718 4.2 Structure of the PPP ................................ 5 719 4.3 MIB Groups .......................................... 6 720 5 Definitions ........................................... 8 721 6 Acknowledgements ...................................... 19 722 7 Security Considerations ............................... 20 723 8 References ............................................ 21