idnits 2.17.1 draft-ietf-forces-mib-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 809. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 833. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (August 25, 2008) is 5723 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: 'RFCzzzz' is mentioned on line 222, but not defined Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Forwarding and Control Element R. Haas 3 Separation (forces) IBM 4 Internet-Draft August 25, 2008 5 Intended status: Standards Track 6 Expires: February 26, 2009 8 ForCES MIB 9 draft-ietf-forces-mib-07 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 26, 2009. 36 Abstract 38 This memo defines a Management Information Base (MIB) module for use 39 with network management protocols in the Internet community. In 40 particular, it defines managed objects for the Forwarding and Control 41 Element Separation (ForCES) Network Element (NE). 43 Table of Contents 45 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 46 2. The Internet-Standard Management Framework . . . . . . . . . . 3 47 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 4. ForCES MIB Overview . . . . . . . . . . . . . . . . . . . . . 3 49 5. ForCES MIB Definition . . . . . . . . . . . . . . . . . . . . 5 50 6. Associations kept in the MIB . . . . . . . . . . . . . . . . . 12 51 7. Support for multiple CEs and FEs . . . . . . . . . . . . . . . 13 52 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 53 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 54 10. Changes from Previous Draft Revisions . . . . . . . . . . . . 14 55 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 56 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 57 11.2. Informative References . . . . . . . . . . . . . . . . . 17 58 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 59 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 60 Intellectual Property and Copyright Statements . . . . . . . . . . 19 62 1. Requirements notation 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 2. The Internet-Standard Management Framework 70 For a detailed overview of the documents that describe the current 71 Internet-Standard Management Framework, please refer to section 7 of 72 [RFC3410]. 74 Managed objects are accessed via a virtual information store, termed 75 the Management Information Base or MIB. MIB objects are generally 76 accessed through the Simple Network Management Protocol (SNMP). 77 Objects in the MIB are defined using the mechanisms defined in the 78 Structure of Management Information (SMI). This memo specifies a MIB 79 module that is compliant to the SMIv2, which is described in STD 58, 80 [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580]. 82 3. Introduction 84 The ForCES MIB module is a read-only MIB module that captures 85 information related to the ForCES protocol ([RFC3654], [RFC3746], 86 [forces-applicability-draft] and [forces-protocol-draft]). 88 The ForCES MIB module does not include information that is specified 89 in other MIB modules, such as packet counters for interfaces, etc. 91 More specifically, the information in the ForCES MIB module relative 92 to associations that are up includes: 94 o identifiers of the elements in the association, 96 o configuration parameters of the association, and 98 o statistics of the association. 100 4. ForCES MIB Overview 102 The MIB module contains the latest ForCES protocol version supported 103 by the CE (forcesLatestProtocolVersionSupported). Note that the CE 104 must also allow interaction with FEs supporting earlier versions. 106 For each association identified by the pair CE ID and FE ID, the 107 following associated information is provided by the MIB module as an 108 entry (forcesAssociationEntry) in the association table 109 (forcesAssociationTable): 111 o Version number of the ForCES protocol running in this association 112 (forcesAssociationRunningProtocolVersion). 114 o Time when the association entered the UP state 115 (forcesAssociationTimeUp). 117 o Time when the association left the UP state 118 (forcesAssociationTimeDown). Note that this is only used for 119 notification purposes as the association is removed from the MIB 120 immediately after it leaves the UP state. 122 o Number of ForCES Heartbeat messages sent from the CE 123 (forcesAssociationHBMsgSent) and received by the CE 124 (forcesAssociationHBMsgReceived) since the association entered the 125 UP state. 127 o Number of other ForCES messages sent from the CE 128 (forcesAssociationOtherMsgSent) and received by the CE 129 (forcesAssociationOtherMsgReceived) since the association entered 130 the UP state. Only messages other than Heartbeat, Association 131 Setup, Association Setup Response, and Association Teardown are 132 counted. 134 Finally, the MIB module defines the following notifications: 136 o Whenever an association enters the UP state, a notification 137 (forcesAssociationEntryUp) is issued containing the version of the 138 ForCES protocol running. Note that as CE ID and FE ID are 139 indexes, they appear in the OID of the ForCES-protocol running- 140 version object. Optionally, a notification 141 (forcesAssociationEntryUpStats) can instead be issued with all 142 associated information for this association, except 143 forcesAssociationTimeDown. 145 o Whenever an association leaves the UP state, a notification 146 (forcesAssociationEntryDown) is issued containing the version of 147 the ForCES protocol running. Optionally, a notification 148 (forcesAssociationEntryDownStats) can instead be issued with all 149 associated information for this association. The reason is that 150 the association and all its associated information will be removed 151 from the MIB immediately after this notification has been issued. 153 5. ForCES MIB Definition 154 FORCES-MIB DEFINITIONS ::= BEGIN 156 IMPORTS 157 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 158 mib-2, Integer32, Counter32 159 FROM SNMPv2-SMI 161 TEXTUAL-CONVENTION, TimeStamp 162 FROM SNMPv2-TC 164 MODULE-COMPLIANCE, OBJECT-GROUP, 165 NOTIFICATION-GROUP 166 FROM SNMPv2-CONF; 168 forcesMib MODULE-IDENTITY 169 LAST-UPDATED "200808251200Z" -- Aug 25, 2008 170 ORGANIZATION "IETF Forwarding and Control Element 171 Separation (ForCES) Working Group" 172 CONTACT-INFO 173 "WG Charter: 174 http://www.ietf.org/html.charters/forces-charter.html 176 Mailing lists: 177 General Discussion: forces@peach.ease.lsoft.com 178 To Subscribe: listserv@peach.ease.lsoft.com 179 In Body: subscribe forces 181 Chairs: Patrick Droz 182 Email: dro@zurich.ibm.com 183 Jamal Hadi Salim 184 Email: hadi@znyx.com 186 Editor: Robert Haas 187 IBM 188 Email: rha@zurich.ibm.com" 189 DESCRIPTION 190 "This MIB module contains managed object definitions 191 for the ForCES Protocol. 192 Copyright (C) The Internet Trust (2008). This 193 version of this MIB module is part of RFC yyyy; see 194 the RFC itself for full legal notices." 195 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 196 REVISION "200808251200Z" -- Aug 25, 2008 197 DESCRIPTION 198 "Initial version, published as RFC yyyy." 199 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 200 ::= { mib-2 XXX } 202 -- RFC Ed.: replace XXX with IANA-assigned number & remove this note 204 --**************************************************************** 206 forcesMibNotifications OBJECT IDENTIFIER ::= { forcesMib 0 } 207 forcesMibObjects OBJECT IDENTIFIER ::= { forcesMib 1 } 208 forcesMibConformance OBJECT IDENTIFIER ::= { forcesMib 2 } 210 ForcesID ::= TEXTUAL-CONVENTION 211 STATUS current 212 DESCRIPTION 213 "The ForCES identifier is a four octet quantity." 214 SYNTAX OCTET STRING (SIZE (4)) 216 ForcesProtocolVersion ::= TEXTUAL-CONVENTION 217 STATUS current 218 DESCRIPTION 219 "ForCES protocol version number. 220 The version numbers used are defined in the 221 specifications of the respective protocol: 222 1 - ForCESv1 [RFCzzzz]." 223 -- RFC Ed.: replace zzzz with actual RFC number of ForCES protocol 224 -- & remove this note 226 SYNTAX Integer32 (1..255) 227 DISPLAY-HINT "d" 229 -- Notifications 231 forcesAssociationEntryUp NOTIFICATION-TYPE 232 OBJECTS { 233 forcesAssociationRunningProtocolVersion 234 } 235 STATUS current 236 DESCRIPTION 237 "This notification is generated as soon 238 as an association enters the UP state. 239 Note that these notifications are not 240 throttled as the CE itself should 241 throttle the setup of associations." 242 ::= { forcesMibNotifications 1 } 244 forcesAssociationEntryDown NOTIFICATION-TYPE 245 OBJECTS { 246 forcesAssociationRunningProtocolVersion 247 } 248 STATUS current 249 DESCRIPTION 250 "This notification is generated as soon 251 as an association leaves the UP state. 252 Note that these notifications are not 253 throttled as the CE itself should 254 throttle the setup of associations." 255 ::= { forcesMibNotifications 2 } 257 forcesAssociationEntryUpStats NOTIFICATION-TYPE 258 OBJECTS { 259 forcesAssociationRunningProtocolVersion, 260 forcesAssociationTimeUp, 261 forcesAssociationHBMsgSent, 262 forcesAssociationHBMsgReceived, 263 forcesAssociationOtherMsgSent, 264 forcesAssociationOtherMsgReceived 265 } 266 STATUS current 267 DESCRIPTION 268 "This notification is generated as soon 269 as an association enters the UP state. 270 Note that these notifications are not 271 throttled as the CE itself should 272 throttle the setup of associations." 273 ::= { forcesMibNotifications 3 } 275 forcesAssociationEntryDownStats NOTIFICATION-TYPE 276 OBJECTS { 277 forcesAssociationRunningProtocolVersion, 278 forcesAssociationTimeUp, 279 forcesAssociationTimeDown, 280 forcesAssociationHBMsgSent, 281 forcesAssociationHBMsgReceived, 282 forcesAssociationOtherMsgSent, 283 forcesAssociationOtherMsgReceived 284 } 285 STATUS current 286 DESCRIPTION 287 "This notification is generated as soon 288 as an association leaves the UP state. 289 Note that these notifications are not 290 throttled as the CE itself should 291 throttle the setup of associations." 292 ::= { forcesMibNotifications 4 } 294 -- Objects 296 forcesLatestProtocolVersionSupported OBJECT-TYPE 297 SYNTAX ForcesProtocolVersion 298 MAX-ACCESS read-only 299 STATUS current 300 DESCRIPTION 301 "The ForCES protocol version supported by the CE. 302 The current protocol version is 1. 303 Note that the CE must also allow interaction 304 with FEs supporting earlier versions." 305 ::= { forcesMibObjects 1 } 307 forcesAssociations OBJECT IDENTIFIER ::= { forcesMibObjects 2 } 309 forcesAssociationTable OBJECT-TYPE 310 SYNTAX SEQUENCE OF ForcesAssociationEntry 311 MAX-ACCESS not-accessible 312 STATUS current 313 DESCRIPTION 314 "The (conceptual) table of associations." 315 ::= { forcesAssociations 1 } 317 forcesAssociationEntry OBJECT-TYPE 318 SYNTAX ForcesAssociationEntry 319 MAX-ACCESS not-accessible 320 STATUS current 321 DESCRIPTION 322 "A (conceptual) entry for one association." 323 INDEX { forcesAssociationCEID, forcesAssociationFEID } 324 ::= { forcesAssociationTable 1 } 326 ForcesAssociationEntry ::= SEQUENCE { 327 forcesAssociationCEID ForcesID, 328 forcesAssociationFEID ForcesID, 330 forcesAssociationRunningProtocolVersion 331 ForcesProtocolVersion, 333 forcesAssociationTimeUp TimeStamp, 334 forcesAssociationTimeDown TimeStamp, 336 forcesAssociationHBMsgSent Counter32, 337 forcesAssociationHBMsgReceived Counter32, 338 forcesAssociationOtherMsgSent Counter32, 339 forcesAssociationOtherMsgReceived Counter32 } 341 forcesAssociationCEID OBJECT-TYPE 342 SYNTAX ForcesID 343 MAX-ACCESS not-accessible 344 STATUS current 345 DESCRIPTION 346 "The ForCES ID of the CE." 347 ::= { forcesAssociationEntry 1 } 349 forcesAssociationFEID OBJECT-TYPE 350 SYNTAX ForcesID 351 MAX-ACCESS not-accessible 352 STATUS current 353 DESCRIPTION 354 "The ForCES ID of the FE." 355 ::= { forcesAssociationEntry 2 } 357 forcesAssociationRunningProtocolVersion OBJECT-TYPE 358 SYNTAX ForcesProtocolVersion 359 MAX-ACCESS read-only 360 STATUS current 361 DESCRIPTION 362 "The current ForCES protocol version used in this 363 association. 364 The current protocol version is 1." 365 ::= { forcesAssociationEntry 3 } 367 forcesAssociationTimeUp OBJECT-TYPE 368 SYNTAX TimeStamp 369 MAX-ACCESS read-only 370 STATUS current 371 DESCRIPTION 372 "The value of sysUpTime at the time this 373 association entered the UP state. 374 If this association started prior to the last 375 initialization of the network subsystem, then 376 this object contains a zero value. 377 This object allows to uniquely identify 378 associations with the same CE and FE IDs." 379 ::= { forcesAssociationEntry 4 } 381 forcesAssociationTimeDown OBJECT-TYPE 382 SYNTAX TimeStamp 383 MAX-ACCESS accessible-for-notify 384 STATUS current 385 DESCRIPTION 386 "The value of sysUpTime at the time this 387 association left the UP state." 388 ::= { forcesAssociationEntry 5 } 390 forcesAssociationHBMsgSent OBJECT-TYPE 391 SYNTAX Counter32 392 MAX-ACCESS read-only 393 STATUS current 394 DESCRIPTION 395 "A counter of how many heartbeat messages have 396 have been sent by the CE on this association 397 since the association entered the UP state. 398 If this association started prior to the last 399 initialization of the network subsystem, then 400 this object contains the value since the 401 initialization." 402 ::= { forcesAssociationEntry 6 } 404 forcesAssociationHBMsgReceived OBJECT-TYPE 405 SYNTAX Counter32 406 MAX-ACCESS read-only 407 STATUS current 408 DESCRIPTION 409 "A counter of how many heartbeat messages 410 have been received by the CE on this association 411 since the association entered the UP state. 412 If this association started prior to the last 413 initialization of the network subsystem, then 414 this object contains the value since the 415 initialization." 416 ::= { forcesAssociationEntry 7 } 418 forcesAssociationOtherMsgSent OBJECT-TYPE 419 SYNTAX Counter32 420 MAX-ACCESS read-only 421 STATUS current 422 DESCRIPTION 423 "A counter of how many messages other than 424 heartbeat (i.e., config and query) 425 have been sent by the CE on this association 426 since the association entered the UP state. 427 If this association started prior to the last 428 initialization of the network subsystem, then 429 this object contains the value since the 430 initialization." 431 ::= { forcesAssociationEntry 8 } 433 forcesAssociationOtherMsgReceived OBJECT-TYPE 434 SYNTAX Counter32 435 MAX-ACCESS read-only 436 STATUS current 437 DESCRIPTION 438 "A counter of how many messages other than 439 heartbeat (i.e., config response, query response, 440 event notification, and packet redirect) 441 have been received by the CE on this association 442 since the association entered the UP state. 443 If this association started prior to the last 444 initialization of the network subsystem, then 445 this object contains the value since the 446 initialization." 447 ::= { forcesAssociationEntry 9 } 449 -- Conformance 451 forcesMibCompliances OBJECT IDENTIFIER 452 ::= { forcesMibConformance 1 } 453 forcesMibGroups OBJECT IDENTIFIER 454 ::= { forcesMibConformance 2 } 456 -- Compliance statements 458 forcesMibCompliance MODULE-COMPLIANCE 459 STATUS current 460 DESCRIPTION 461 "The compliance statement for routers running ForCES and 462 implementing the ForCES MIB." 463 MODULE -- this module 464 MANDATORY-GROUPS { forcesMibGroup, forcesNotificationGroup } 466 GROUP forcesNotificationStatsGroup 467 DESCRIPTION 468 "Implementation of this group is recommended." 470 GROUP forcesStatsGroup 471 DESCRIPTION 472 "Implementation of this group is recommended." 474 ::= { forcesMibCompliances 1 } 476 -- Units of conformance 478 forcesNotificationGroup NOTIFICATION-GROUP 479 NOTIFICATIONS { forcesAssociationEntryUp, 480 forcesAssociationEntryDown 481 } 482 STATUS current 483 DESCRIPTION 485 "A collection of notifications for signaling important 486 ForCES events." 487 ::= { forcesMibGroups 1 } 489 forcesMibGroup OBJECT-GROUP 490 OBJECTS { forcesLatestProtocolVersionSupported, 491 forcesAssociationRunningProtocolVersion 492 } 493 STATUS current 494 DESCRIPTION 495 "A collection of objects to support management of ForCES 496 routers." 497 ::= { forcesMibGroups 2 } 499 forcesNotificationStatsGroup NOTIFICATION-GROUP 500 NOTIFICATIONS { forcesAssociationEntryUpStats, 501 forcesAssociationEntryDownStats 502 } 503 STATUS current 504 DESCRIPTION 506 "A collection of optional notifications for signaling 507 important ForCES events including statistics." 508 ::= { forcesMibGroups 3 } 510 forcesStatsGroup OBJECT-GROUP 511 OBJECTS { forcesAssociationTimeUp, 512 forcesAssociationTimeDown, 513 forcesAssociationHBMsgSent, 514 forcesAssociationHBMsgReceived, 515 forcesAssociationOtherMsgSent, 516 forcesAssociationOtherMsgReceived 517 } 518 STATUS current 519 DESCRIPTION 520 "A collection of optional objects to provide extra 521 information about the associations. There is no protocol 522 reason to keep such information, but these objects can 523 be very useful in debugging connectivity problems." 524 ::= { forcesMibGroups 4} 526 END 528 6. Associations kept in the MIB 530 Associations enter the UP state as soon as the CE has sent to the FE 531 an Association Setup Response message containing a successful 532 Association Setup Result. Only associations that are UP are 533 reflected in this MIB module. 535 Associations are removed from the MIB module as soon as they leave 536 the UP state, i.e., if the CE has not received any message (Heartbeat 537 or other protocol message) from the FE within a given time period or 538 if an Association Teardown message has been sent by the CE. 540 Statistics counters are not initialized to zero when the association 541 is created. Instead, a delta value must be calculated from two 542 successive readings. Note that the optional up and down 543 notifications contain the statistics with the initial and final value 544 of the statistics. 546 7. Support for multiple CEs and FEs 548 An NE consists of one or more FEs and one or more CEs. Where there 549 is a single CE, that CE will have knowledge of all the associations 550 in the NE and so can provide the information necessary to support the 551 managed objects defined in this MIB module. Where there is more than 552 one CE, information about the associations may be distributed among 553 the CEs. Whether each CE implements the managed objects for the 554 associations of which it is aware or whether the CEs cooperate to 555 present the appearance of a single set of managed objects for all the 556 associations in the NE is outside the scope of this document. 558 8. Security Considerations 560 There are no management objects defined in this MIB module that have 561 a MAX-ACCESS clause of read-write and/or read-create. So, if this 562 MIB module is implemented correctly, then there is no risk that an 563 intruder can alter or create any management objects of this MIB 564 module via direct SNMP SET operations. 566 Some of the readable objects in this MIB module (i.e., objects with a 567 MAX-ACCESS other than not-accessible) may be considered sensitive or 568 vulnerable in some network environments. It is thus important to 569 control even GET and/or NOTIFY access to these objects and possibly 570 to even encrypt the values of these objects when sending them over 571 the network via SNMP. These are the tables and objects and their 572 sensitivity/vulnerability: 574 o Objects in the forcesMibGroup are protocol versions. They are 575 neither sensitive nor vulnerable. 577 o Objects in the forcesStatsGroup are statistics. They are neither 578 sensitive nor vulnerable. 580 SNMP versions prior to SNMPv3 did not include adequate security. 582 Even if the network itself is secure (for example by using IPsec), 583 even then, there is no control as to who on the secure network is 584 allowed to access and GET/SET (read/change/create/delete) the objects 585 in this MIB module. 587 It is RECOMMENDED that implementers consider the security features as 588 provided by the SNMPv3 framework (see [RFC3410], section 8), 589 including full support for the SNMPv3 cryptographic mechanisms (for 590 authentication and privacy). 592 Further, deployment of SNMP versions prior to SNMPv3 is NOT 593 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 594 enable cryptographic security. It is then a customer/operator 595 responsibility to ensure that the SNMP entity giving access to an 596 instance of this MIB module is properly configured to give access to 597 the objects only to those principals (users) that have legitimate 598 rights to indeed GET or SET (change/create/delete) them. 600 9. IANA Considerations 602 The MIB module in this document uses the following IANA-assigned 603 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 605 Descriptor OBJECT IDENTIFIER value 606 ---------- ----------------------- 608 forcesMIB { mib-2 XXX } 610 Editor's Note (to be removed prior to publication): the IANA is 611 requested to assign a value for "XXX" under the 'mib-2' subtree and 612 to record the assignment in the SMI Numbers registry. When the 613 assignment has been made, the RFC Editor is asked to replace "XXX" 614 (here and in the MIB module) with the assigned value and to remove 615 this note. 617 10. Changes from Previous Draft Revisions 619 Editor's Note (to be removed prior to publication): Prior to RFC 620 publication of this document, the RFC Editor is asked to remove this 621 entire section titled "Changes from Previous Draft Versions". 623 Changes from draft-ietf-forces-mib-06: 625 o Informational RFCs 3654 and 3746 moved to Informative References 626 section. 628 o Updated chairs' names in the MIB description. 630 o Update references to protocol and applicability drafts. 632 o Reversed the order of the two first sentences in section 633 "Associations kept in the MIB" 635 Changes from draft-ietf-forces-mib-05: Copyright statement in the MIB 636 description corrected to IETF Trust. 638 Changes from draft-ietf-forces-mib-04. They are changes suggested by 639 the MIB doctor review, according to the MIB Review Checklist in 640 Appendix A of RFC 4181: 642 o Changed MIB descriptions with "since the association entered the 643 UP state" instead of "since the association is up". 645 o Updated the I-D boilerplate copyright statement. 647 o Removed last sentence of abstract. 649 o Moved the MIB boilerplate into a section of its own. 651 o Moved the MIB definition into a section of its own. 653 o Updated the Security Considerations section according to the 654 boilerplate at http://www.ops.ietf.org/mib-security.html. 656 o Updated the MIB description with the copyright statement. 658 o Added DISPLAY-HINT to the ForCESProtocolVersion. Note that the 659 smilint tool doesn't like it. 661 o Added IETF to the MODULE-IDENTITY ORGANIZATION. 663 o Updated CONTACT-INFO to indicate how to reach the group. 665 o Changed forcesAssocationTimeDown MAX-ACCESS to accessible-for- 666 notify. 668 o Added text to DESCRIPTION of forcesAssociationTimeUp to indicate 669 that it allows to uniquely identify associations with the same FE 670 and CE IDs. 672 o Added two optional notifications that carry stats and added 673 corresponding text in the last paragraph of section titled 674 "Associations kept in the MIB". The reason is that optional 675 objects such as stats in a mandatory notification are not 676 supported. 678 Changes from draft-ietf-forces-mib-03. They are small fixes to the 679 text and the MIB module: 681 o Added MIB boilerplate according to 682 http://www.ops.ietf.org/mib-boilerplate.html 684 o Clarified terminology with respect to MIB module and MIB managed 685 objects. 687 o Added RFC Editor note to indicate RFC number for version 1 of 688 ForCES protocol under ForcesProtocolVersion. 690 o Renumbered elements in forcesAssociationEntry starting with 1. 692 o Changed ForcesProtocolVersion from INTEGER to Integer32. 694 o Added forcesLatestProtocolVersionSupported into the mandatory 695 forcesMibGroups conformance group. 697 o Explicitely added the forcesStatsGroup to the forcesMibCompliance 698 compliance statement as optional. 700 o Moved the MIB Definition section to the front. 702 o Rephrased IANA Considerations section according to RFC 4181 703 Section 3.5.2. 705 o Added RFC Editor note to remove the "Changes from Previous Draft 706 Revisions" section prior to publication. 708 Changes from draft-ietf-forces-mib-02. They are refinements of the 709 MIB module: 711 o Changed forcesAssociationCEID and forcesAssociationFEID from read- 712 only to not-accessible to conform with Section 7.7 in [RFC2578]. 714 o Removed forcesAssociationCEID and forcesAssociationFEID from the 715 notifications. This information is conveyed in the OID anyway. 717 o Added MIB conformance information. 719 Changes from draft-ietf-forces-mib-01. The changes are in response 720 to the Working Group Last Call: 722 o Addition of two traps/notifications to signal the associations 723 that enter or leave the UP state. 725 o Suppression of the DOWN and ESTABLISHING states. Only 726 associations in the UP state are kept in the table. 728 o Split of the Message counters into Heartbeat and other messages. 730 o Addition of the current running version of ForCES protocol for 731 each association in the UP state. 733 o Addition of the latest version of the ForCES protocol supported by 734 the CE. 736 11. References 738 11.1. Normative References 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", BCP 14, RFC 2119, March 1997. 743 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 744 Schoenwaelder, Ed., "Structure of Management Information 745 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 747 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 748 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 749 STD 58, RFC 2579, April 1999. 751 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 752 "Conformance Statements for SMIv2", STD 58, RFC 2580, 753 April 1999. 755 [forces-protocol-draft] 756 Doria, A., Haas, R., Hadi Salim, J., Khosravi, H., and W. 757 Wang, "ForCES Protocol Specification", ID Document: 758 draft-ietf-forces-protocol-15.txt, August 2008. 760 11.2. Informative References 762 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 763 "Introduction and Applicability Statements for Internet- 764 Standard Management Framework", RFC 3410, December 2002. 766 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 767 of IP Control and Forwarding", RFC 3654, November 2003. 769 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 770 "Forwarding and Control Element Separation (ForCES) 771 Framework", RFC 3746, April 2004. 773 [forces-applicability-draft] 774 Crouch, A., Khosravi, H., Handley, M., and A. Doria, 775 "ForCES Applicability Statement", ID Document: 776 draft-ietf-forces-applicability-05.txt, July 2006. 778 Appendix A. Acknowledgments 780 The author gratefully acknowledges the contributions of: Jinrong 781 Fenggen, John Flick, Xiaoyi Guo, Joel Halpern, Tom Petch, and Jamal 782 Hadi Salim. 784 Author's Address 786 Robert Haas 787 IBM 788 Saeumerstrasse 4 789 Rueschlikon 8803 790 CH 792 Email: rha@zurich.ibm.com 793 URI: http://www.zurich.ibm.com/~rha 795 Full Copyright Statement 797 Copyright (C) The IETF Trust (2008). 799 This document is subject to the rights, licenses and restrictions 800 contained in BCP 78, and except as set forth therein, the authors 801 retain all their rights. 803 This document and the information contained herein are provided on an 804 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 805 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 806 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 807 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 808 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 809 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 811 Intellectual Property 813 The IETF takes no position regarding the validity or scope of any 814 Intellectual Property Rights or other rights that might be claimed to 815 pertain to the implementation or use of the technology described in 816 this document or the extent to which any license under such rights 817 might or might not be available; nor does it represent that it has 818 made any independent effort to identify any such rights. Information 819 on the procedures with respect to rights in RFC documents can be 820 found in BCP 78 and BCP 79. 822 Copies of IPR disclosures made to the IETF Secretariat and any 823 assurances of licenses to be made available, or the result of an 824 attempt made to obtain a general license or permission for the use of 825 such proprietary rights by implementers or users of this 826 specification can be obtained from the IETF on-line IPR repository at 827 http://www.ietf.org/ipr. 829 The IETF invites any interested party to bring to its attention any 830 copyrights, patents or patent applications, or other proprietary 831 rights that may cover technology that may be required to implement 832 this standard. Please address the information to the IETF at 833 ietf-ipr@ietf.org.