idnits 2.17.1 draft-ietf-forces-mib-05.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 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 815. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 821. 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 (March 1, 2007) is 6266 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 226, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3654 ** Downref: Normative reference to an Informational RFC: RFC 3746 Summary: 3 errors (**), 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 March 1, 2007 5 Intended status: Standards Track 6 Expires: September 2, 2007 8 ForCES MIB 9 draft-ietf-forces-mib-05 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 September 2, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This memo defines a Management Information Base (MIB) module for use 43 with network management protocols in the Internet community. In 44 particular, it defines managed objects for the Forwarding and Control 45 Element Separation (ForCES) Network Element (NE). 47 Table of Contents 49 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 50 2. The Internet-Standard Management Framework . . . . . . . . . . 3 51 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 4. ForCES MIB Overview . . . . . . . . . . . . . . . . . . . . . 3 53 5. ForCES MIB Definition . . . . . . . . . . . . . . . . . . . . 5 54 6. Associations kept in the MIB . . . . . . . . . . . . . . . . . 12 55 7. Support for multiple CEs and FEs . . . . . . . . . . . . . . . 13 56 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 57 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 58 10. Changes from Previous Draft Revisions . . . . . . . . . . . . 14 59 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 60 11.1. Normative References . . . . . . . . . . . . . . . . . . 17 61 11.2. Informative References . . . . . . . . . . . . . . . . . 17 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 17 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 64 Intellectual Property and Copyright Statements . . . . . . . . . . 19 66 1. Requirements notation 68 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 69 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 70 document are to be interpreted as described in [RFC2119]. 72 2. The Internet-Standard Management Framework 74 For a detailed overview of the documents that describe the current 75 Internet-Standard Management Framework, please refer to section 7 of 76 [RFC3410]. 78 Managed objects are accessed via a virtual information store, termed 79 the Management Information Base or MIB. MIB objects are generally 80 accessed through the Simple Network Management Protocol (SNMP). 81 Objects in the MIB are defined using the mechanisms defined in the 82 Structure of Management Information (SMI). This memo specifies a MIB 83 module that is compliant to the SMIv2, which is described in STD 58, 84 [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580]. 86 3. Introduction 88 The ForCES MIB module is a read-only MIB module that captures 89 information related to the ForCES protocol ([RFC3654], [RFC3746], 90 [forces-applicability-draft] and [forces-protocol-draft]). 92 The ForCES MIB module does not include information that is specified 93 in other MIB modules, such as packet counters for interfaces, etc. 95 More specifically, the information in the ForCES MIB module relative 96 to associations that are up includes: 98 o identifiers of the elements in the association, 100 o configuration parameters of the association, and 102 o statistics of the association. 104 4. ForCES MIB Overview 106 The MIB module contains the latest ForCES protocol version supported 107 by the CE (forcesLatestProtocolVersionSupported). Note that the CE 108 must also allow interaction with FEs supporting earlier versions. 110 For each association identified by the pair CE ID and FE ID, the 111 following associated information is provided by the MIB module as an 112 entry (forcesAssociationEntry) in the association table 113 (forcesAssociationTable): 115 o Version number of the ForCES protocol running in this association 116 (forcesAssociationRunningProtocolVersion). 118 o Time when the association entered the UP state 119 (forcesAssociationTimeUp). 121 o Time when the association left the UP state 122 (forcesAssociationTimeDown). Note that this is only used for 123 notification purposes as the association is removed from the MIB 124 immediately after it leaves the UP state. 126 o Number of ForCES Heartbeat messages sent from the CE 127 (forcesAssociationHBMsgSent) and received by the CE 128 (forcesAssociationHBMsgReceived) since the association entered the 129 UP state. 131 o Number of other ForCES messages sent from the CE 132 (forcesAssociationOtherMsgSent) and received by the CE 133 (forcesAssociationOtherMsgReceived) since the association entered 134 the UP state. Only messages other than Heartbeat, Association 135 Setup, Association Setup Response, and Association Teardown are 136 counted. 138 Finally, the MIB module defines the following notifications: 140 o Whenever an association enters the UP state, a notification 141 (forcesAssociationEntryUp) is issued containing the version of the 142 ForCES protocol running. Note that as CE ID and FE ID are 143 indexes, they appear in the OID of the ForCES-protocol running- 144 version object. Optionally, a notification 145 (forcesAssociationEntryUpStats) can instead be issued with all 146 associated information for this association, except 147 forcesAssociationTimeDown. 149 o Whenever an association leaves the UP state, a notification 150 (forcesAssociationEntryDown) is issued containing the version of 151 the ForCES protocol running. Optionally, a notification 152 (forcesAssociationEntryDownStats) can instead be issued with all 153 associated information for this association. The reason is that 154 the association and all its associated information will be removed 155 from the MIB immediately after this notification has been issued. 157 5. ForCES MIB Definition 158 FORCES-MIB DEFINITIONS ::= BEGIN 160 IMPORTS 161 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 162 mib-2, Integer32, Counter32 163 FROM SNMPv2-SMI 165 TEXTUAL-CONVENTION, TimeStamp 166 FROM SNMPv2-TC 168 MODULE-COMPLIANCE, OBJECT-GROUP, 169 NOTIFICATION-GROUP 170 FROM SNMPv2-CONF; 172 forcesMib MODULE-IDENTITY 173 LAST-UPDATED "200703011200Z" -- Mar 1, 2007 174 ORGANIZATION "IETF Forwarding and Control Element 175 Separation (ForCES) Working Group" 176 CONTACT-INFO 177 "WG Charter: 178 http://www.ietf.org/html.charters/forces-charter.html 180 Mailing lists: 181 General Discussion: forces@peach.ease.lsoft.com 182 To Subscribe: listserv@peach.ease.lsoft.com 183 In Body: subscribe forces 185 Chairs: Patrick Droz 186 Email: dro@zurich.ibm.com 187 David Putzolu 188 Email: David.Putzolu@intel.com 190 Editor: Robert Haas 191 IBM 192 Email: rha@zurich.ibm.com" 193 DESCRIPTION 194 "This MIB module contains managed object definitions 195 for the ForCES Protocol. 196 Copyright (C) The Internet Society (2007). This 197 version of this MIB module is part of RFC yyyy; see 198 the RFC itself for full legal notices." 199 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 200 REVISION "200703011200Z" -- Mar 01, 2007 201 DESCRIPTION 202 "Initial version, published as RFC yyyy." 203 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 204 ::= { mib-2 XXX } 206 -- RFC Ed.: replace XXX with IANA-assigned number & remove this note 208 --**************************************************************** 210 forcesMibNotifications OBJECT IDENTIFIER ::= { forcesMib 0 } 211 forcesMibObjects OBJECT IDENTIFIER ::= { forcesMib 1 } 212 forcesMibConformance OBJECT IDENTIFIER ::= { forcesMib 2 } 214 ForcesID ::= TEXTUAL-CONVENTION 215 STATUS current 216 DESCRIPTION 217 "The ForCES identifier is a four octet quantity." 218 SYNTAX OCTET STRING (SIZE (4)) 220 ForcesProtocolVersion ::= TEXTUAL-CONVENTION 221 STATUS current 222 DESCRIPTION 223 "ForCES protocol version number. 224 The version numbers used are defined in the 225 specifications of the respective protocol: 226 1 - ForCESv1 [RFCzzzz]." 227 -- RFC Ed.: replace zzzz with actual RFC number of ForCES protocol 228 -- & remove this note 230 SYNTAX Integer32 (1..255) 231 DISPLAY-HINT "d" 233 -- Notifications 235 forcesAssociationEntryUp NOTIFICATION-TYPE 236 OBJECTS { 237 forcesAssociationRunningProtocolVersion 238 } 239 STATUS current 240 DESCRIPTION 241 "This notification is generated as soon 242 as an association enters the UP state. 243 Note that these notifications are not 244 throttled as the CE itself should 245 throttle the setup of associations." 246 ::= { forcesMibNotifications 1 } 248 forcesAssociationEntryDown NOTIFICATION-TYPE 249 OBJECTS { 250 forcesAssociationRunningProtocolVersion 251 } 252 STATUS current 253 DESCRIPTION 254 "This notification is generated as soon 255 as an association leaves the UP state. 256 Note that these notifications are not 257 throttled as the CE itself should 258 throttle the setup of associations." 259 ::= { forcesMibNotifications 2 } 261 forcesAssociationEntryUpStats NOTIFICATION-TYPE 262 OBJECTS { 263 forcesAssociationRunningProtocolVersion, 264 forcesAssociationTimeUp, 265 forcesAssociationHBMsgSent, 266 forcesAssociationHBMsgReceived, 267 forcesAssociationOtherMsgSent, 268 forcesAssociationOtherMsgReceived 269 } 270 STATUS current 271 DESCRIPTION 272 "This notification is generated as soon 273 as an association enters the UP state. 274 Note that these notifications are not 275 throttled as the CE itself should 276 throttle the setup of associations." 277 ::= { forcesMibNotifications 3 } 279 forcesAssociationEntryDownStats NOTIFICATION-TYPE 280 OBJECTS { 281 forcesAssociationRunningProtocolVersion, 282 forcesAssociationTimeUp, 283 forcesAssociationTimeDown, 284 forcesAssociationHBMsgSent, 285 forcesAssociationHBMsgReceived, 286 forcesAssociationOtherMsgSent, 287 forcesAssociationOtherMsgReceived 288 } 289 STATUS current 290 DESCRIPTION 291 "This notification is generated as soon 292 as an association leaves the UP state. 293 Note that these notifications are not 294 throttled as the CE itself should 295 throttle the setup of associations." 296 ::= { forcesMibNotifications 4 } 298 -- Objects 300 forcesLatestProtocolVersionSupported OBJECT-TYPE 301 SYNTAX ForcesProtocolVersion 302 MAX-ACCESS read-only 303 STATUS current 304 DESCRIPTION 305 "The ForCES protocol version supported by the CE. 306 The current protocol version is 1. 307 Note that the CE must also allow interaction 308 with FEs supporting earlier versions." 309 ::= { forcesMibObjects 1 } 311 forcesAssociations OBJECT IDENTIFIER ::= { forcesMibObjects 2 } 313 forcesAssociationTable OBJECT-TYPE 314 SYNTAX SEQUENCE OF ForcesAssociationEntry 315 MAX-ACCESS not-accessible 316 STATUS current 317 DESCRIPTION 318 "The (conceptual) table of associations." 319 ::= { forcesAssociations 1 } 321 forcesAssociationEntry OBJECT-TYPE 322 SYNTAX ForcesAssociationEntry 323 MAX-ACCESS not-accessible 324 STATUS current 325 DESCRIPTION 326 "A (conceptual) entry for one association." 327 INDEX { forcesAssociationCEID, forcesAssociationFEID } 328 ::= { forcesAssociationTable 1 } 330 ForcesAssociationEntry ::= SEQUENCE { 331 forcesAssociationCEID ForcesID, 332 forcesAssociationFEID ForcesID, 334 forcesAssociationRunningProtocolVersion 335 ForcesProtocolVersion, 337 forcesAssociationTimeUp TimeStamp, 338 forcesAssociationTimeDown TimeStamp, 340 forcesAssociationHBMsgSent Counter32, 341 forcesAssociationHBMsgReceived Counter32, 342 forcesAssociationOtherMsgSent Counter32, 343 forcesAssociationOtherMsgReceived Counter32 } 345 forcesAssociationCEID OBJECT-TYPE 346 SYNTAX ForcesID 347 MAX-ACCESS not-accessible 348 STATUS current 349 DESCRIPTION 350 "The ForCES ID of the CE." 351 ::= { forcesAssociationEntry 1 } 353 forcesAssociationFEID OBJECT-TYPE 354 SYNTAX ForcesID 355 MAX-ACCESS not-accessible 356 STATUS current 357 DESCRIPTION 358 "The ForCES ID of the FE." 359 ::= { forcesAssociationEntry 2 } 361 forcesAssociationRunningProtocolVersion OBJECT-TYPE 362 SYNTAX ForcesProtocolVersion 363 MAX-ACCESS read-only 364 STATUS current 365 DESCRIPTION 366 "The current ForCES protocol version used in this 367 association. 368 The current protocol version is 1." 369 ::= { forcesAssociationEntry 3 } 371 forcesAssociationTimeUp OBJECT-TYPE 372 SYNTAX TimeStamp 373 MAX-ACCESS read-only 374 STATUS current 375 DESCRIPTION 376 "The value of sysUpTime at the time this 377 association entered the UP state. 378 If this association started prior to the last 379 initialization of the network subsystem, then 380 this object contains a zero value. 381 This object allows to uniquely identify 382 associations with the same CE and FE IDs." 383 ::= { forcesAssociationEntry 4 } 385 forcesAssociationTimeDown OBJECT-TYPE 386 SYNTAX TimeStamp 387 MAX-ACCESS accessible-for-notify 388 STATUS current 389 DESCRIPTION 390 "The value of sysUpTime at the time this 391 association left the UP state." 392 ::= { forcesAssociationEntry 5 } 394 forcesAssociationHBMsgSent OBJECT-TYPE 395 SYNTAX Counter32 396 MAX-ACCESS read-only 397 STATUS current 398 DESCRIPTION 399 "A counter of how many heartbeat messages have 400 have been sent by the CE on this association 401 since the association entered the UP state. 402 If this association started prior to the last 403 initialization of the network subsystem, then 404 this object contains the value since the 405 initialization." 406 ::= { forcesAssociationEntry 6 } 408 forcesAssociationHBMsgReceived OBJECT-TYPE 409 SYNTAX Counter32 410 MAX-ACCESS read-only 411 STATUS current 412 DESCRIPTION 413 "A counter of how many heartbeat messages 414 have been received by the CE on this association 415 since the association entered the UP state. 416 If this association started prior to the last 417 initialization of the network subsystem, then 418 this object contains the value since the 419 initialization." 420 ::= { forcesAssociationEntry 7 } 422 forcesAssociationOtherMsgSent OBJECT-TYPE 423 SYNTAX Counter32 424 MAX-ACCESS read-only 425 STATUS current 426 DESCRIPTION 427 "A counter of how many messages other than 428 heartbeat (i.e., config and query) 429 have been sent by the CE on this association 430 since the association entered the UP state. 431 If this association started prior to the last 432 initialization of the network subsystem, then 433 this object contains the value since the 434 initialization." 435 ::= { forcesAssociationEntry 8 } 437 forcesAssociationOtherMsgReceived OBJECT-TYPE 438 SYNTAX Counter32 439 MAX-ACCESS read-only 440 STATUS current 441 DESCRIPTION 442 "A counter of how many messages other than 443 heartbeat (i.e., config response, query response, 444 event notification, and packet redirect) 445 have been received by the CE on this association 446 since the association entered the UP state. 447 If this association started prior to the last 448 initialization of the network subsystem, then 449 this object contains the value since the 450 initialization." 451 ::= { forcesAssociationEntry 9 } 453 -- Conformance 455 forcesMibCompliances OBJECT IDENTIFIER 456 ::= { forcesMibConformance 1 } 457 forcesMibGroups OBJECT IDENTIFIER 458 ::= { forcesMibConformance 2 } 460 -- Compliance statements 462 forcesMibCompliance MODULE-COMPLIANCE 463 STATUS current 464 DESCRIPTION 465 "The compliance statement for routers running ForCES and 466 implementing the ForCES MIB." 467 MODULE -- this module 468 MANDATORY-GROUPS { forcesMibGroup, forcesNotificationGroup } 470 GROUP forcesNotificationStatsGroup 471 DESCRIPTION 472 "Implementation of this group is recommended." 474 GROUP forcesStatsGroup 475 DESCRIPTION 476 "Implementation of this group is recommended." 478 ::= { forcesMibCompliances 1 } 480 -- Units of conformance 482 forcesNotificationGroup NOTIFICATION-GROUP 483 NOTIFICATIONS { forcesAssociationEntryUp, 484 forcesAssociationEntryDown 485 } 486 STATUS current 487 DESCRIPTION 489 "A collection of notifications for signaling important 490 ForCES events." 491 ::= { forcesMibGroups 1 } 493 forcesMibGroup OBJECT-GROUP 494 OBJECTS { forcesLatestProtocolVersionSupported, 495 forcesAssociationRunningProtocolVersion 496 } 497 STATUS current 498 DESCRIPTION 499 "A collection of objects to support management of ForCES 500 routers." 501 ::= { forcesMibGroups 2 } 503 forcesNotificationStatsGroup NOTIFICATION-GROUP 504 NOTIFICATIONS { forcesAssociationEntryUpStats, 505 forcesAssociationEntryDownStats 506 } 507 STATUS current 508 DESCRIPTION 510 "A collection of optional notifications for signaling 511 important ForCES events including statistics." 512 ::= { forcesMibGroups 3 } 514 forcesStatsGroup OBJECT-GROUP 515 OBJECTS { forcesAssociationTimeUp, 516 forcesAssociationTimeDown, 517 forcesAssociationHBMsgSent, 518 forcesAssociationHBMsgReceived, 519 forcesAssociationOtherMsgSent, 520 forcesAssociationOtherMsgReceived 521 } 522 STATUS current 523 DESCRIPTION 524 "A collection of optional objects to provide extra 525 information about the associations. There is no protocol 526 reason to keep such information, but these objects can 527 be very useful in debugging connectivity problems." 528 ::= { forcesMibGroups 4} 530 END 532 6. Associations kept in the MIB 534 Only associations that are UP are reflected in this MIB module. 535 Associations enter the UP state as soon as the CE has sent to the FE 536 an Association Setup Response message containing a successful 537 Association Setup Result. 539 Associations are removed from the MIB module as soon as they leave 540 the UP state, i.e., if the CE has not received any message (Heartbeat 541 or other protocol message) from the FE within a given time period or 542 if an Association Teardown message has been sent by the CE. 544 Statistics counters are not initialized to zero when the association 545 is created. Instead, a delta value must be calculated from two 546 successive readings. Note that the optional up and down 547 notifications contain the statistics with the initial and final value 548 of the statistics. 550 7. Support for multiple CEs and FEs 552 An NE consists of one or more FEs and one or more CEs. Where there 553 is a single CE, that CE will have knowledge of all the associations 554 in the NE and so can provide the information necessary to support the 555 managed objects defined in this MIB module. Where there is more than 556 one CE, information about the associations may be distributed among 557 the CEs. Whether each CE implements the managed objects for the 558 associations of which it is aware or whether the CEs cooperate to 559 present the appearance of a single set of managed objects for all the 560 associations in the NE is outside the scope of this document. 562 8. Security Considerations 564 There are no management objects defined in this MIB module that have 565 a MAX-ACCESS clause of read-write and/or read-create. So, if this 566 MIB module is implemented correctly, then there is no risk that an 567 intruder can alter or create any management objects of this MIB 568 module via direct SNMP SET operations. 570 Some of the readable objects in this MIB module (i.e., objects with a 571 MAX-ACCESS other than not-accessible) may be considered sensitive or 572 vulnerable in some network environments. It is thus important to 573 control even GET and/or NOTIFY access to these objects and possibly 574 to even encrypt the values of these objects when sending them over 575 the network via SNMP. These are the tables and objects and their 576 sensitivity/vulnerability: 578 o Objects in the forcesMibGroup are protocol versions. They are 579 neither sensitive nor vulnerable. 581 o Objects in the forcesStatsGroup are statistics. They are neither 582 sensitive nor vulnerable. 584 SNMP versions prior to SNMPv3 did not include adequate security. 586 Even if the network itself is secure (for example by using IPsec), 587 even then, there is no control as to who on the secure network is 588 allowed to access and GET/SET (read/change/create/delete) the objects 589 in this MIB module. 591 It is RECOMMENDED that implementers consider the security features as 592 provided by the SNMPv3 framework (see [RFC3410], section 8), 593 including full support for the SNMPv3 cryptographic mechanisms (for 594 authentication and privacy). 596 Further, deployment of SNMP versions prior to SNMPv3 is NOT 597 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 598 enable cryptographic security. It is then a customer/operator 599 responsibility to ensure that the SNMP entity giving access to an 600 instance of this MIB module is properly configured to give access to 601 the objects only to those principals (users) that have legitimate 602 rights to indeed GET or SET (change/create/delete) them. 604 9. IANA Considerations 606 The MIB module in this document uses the following IANA-assigned 607 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 609 Descriptor OBJECT IDENTIFIER value 610 ---------- ----------------------- 612 forcesMIB { mib-2 XXX } 614 Editor's Note (to be removed prior to publication): the IANA is 615 requested to assign a value for "XXX" under the 'mib-2' subtree and 616 to record the assignment in the SMI Numbers registry. When the 617 assignment has been made, the RFC Editor is asked to replace "XXX" 618 (here and in the MIB module) with the assigned value and to remove 619 this note. 621 10. Changes from Previous Draft Revisions 623 Editor's Note (to be removed prior to publication): Prior to RFC 624 publication of this document, the RFC Editor is asked to remove this 625 entire section titled "Changes from Previous Draft Versions". 627 Changes from draft-ietf-forces-mib-04. They are changes suggested by 628 the MIB doctor review, according to the MIB Review Checklist in 629 Appendix A of RFC 4181: 631 o Changed MIB descriptions with "since the association entered the 632 UP state" instead of "since the association is up". 634 o Updated the I-D boilerplate copyright statement. 636 o Removed last sentence of abstract. 638 o Moved the MIB boilerplate into a section of its own. 640 o Moved the MIB definition into a section of its own. 642 o Updated the Security Considerations section according to the 643 boilerplate at http://www.ops.ietf.org/mib-security.html. 645 o Updated the MIB description with the copyright statement. 647 o Added DISPLAY-HINT to the ForCESProtocolVersion. Note that the 648 smilint tool doesn't like it. 650 o Added IETF to the MODULE-IDENTITY ORGANIZATION. 652 o Updated CONTACT-INFO to indicate how to reach the group. 654 o Changed forcesAssocationTimeDown MAX-ACCESS to accessible-for- 655 notify. 657 o Added text to DESCRIPTION of forcesAssociationTimeUp to indicate 658 that it allows to uniquely identify associations with the same FE 659 and CE IDs. 661 o Added two optional notifications that carry stats and added 662 corresponding text in the last paragraph of section titled 663 "Associations kept in the MIB". The reason is that optional 664 objects such as stats in a mandatory notification are not 665 supported. 667 Changes from draft-ietf-forces-mib-03. They are small fixes to the 668 text and the MIB module: 670 o Added MIB boilerplate according to 671 http://www.ops.ietf.org/mib-boilerplate.html 673 o Clarified terminology with respect to MIB module and MIB managed 674 objects. 676 o Added RFC Editor note to indicate RFC number for version 1 of 677 ForCES protocol under ForcesProtocolVersion. 679 o Renumbered elements in forcesAssociationEntry starting with 1. 681 o Changed ForcesProtocolVersion from INTEGER to Integer32. 683 o Added forcesLatestProtocolVersionSupported into the mandatory 684 forcesMibGroups conformance group. 686 o Explicitely added the forcesStatsGroup to the forcesMibCompliance 687 compliance statement as optional. 689 o Moved the MIB Definition section to the front. 691 o Rephrased IANA Considerations section according to RFC 4181 692 Section 3.5.2. 694 o Added RFC Editor note to remove the "Changes from Previous Draft 695 Revisions" section prior to publication. 697 Changes from draft-ietf-forces-mib-02. They are refinements of the 698 MIB module: 700 o Changed forcesAssociationCEID and forcesAssociationFEID from read- 701 only to not-accessible to conform with Section 7.7 in [RFC2578]. 703 o Removed forcesAssociationCEID and forcesAssociationFEID from the 704 notifications. This information is conveyed in the OID anyway. 706 o Added MIB conformance information. 708 Changes from draft-ietf-forces-mib-01. The changes are in response 709 to the Working Group Last Call: 711 o Addition of two traps/notifications to signal the associations 712 that enter or leave the UP state. 714 o Suppression of the DOWN and ESTABLISHING states. Only 715 associations in the UP state are kept in the table. 717 o Split of the Message counters into Heartbeat and other messages. 719 o Addition of the current running version of ForCES protocol for 720 each association in the UP state. 722 o Addition of the latest version of the ForCES protocol supported by 723 the CE. 725 11. References 726 11.1. Normative References 728 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 729 Requirement Levels", BCP 14, RFC 2119, March 1997. 731 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 732 Schoenwaelder, Ed., "Structure of Management Information 733 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 735 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 736 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 737 STD 58, RFC 2579, April 1999. 739 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 740 "Conformance Statements for SMIv2", STD 58, RFC 2580, 741 April 1999. 743 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 744 of IP Control and Forwarding", RFC 3654, November 2003. 746 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 747 "Forwarding and Control Element Separation (ForCES) 748 Framework", RFC 3746, April 2004. 750 [forces-protocol-draft] 751 Doria, A., Haas, R., Hadi Salim, J., Khosravi, H., and W. 752 Wang, "ForCES Protocol Specification", ID Document: 753 draft-ietf-forces-protocol-08.txt, March 2006. 755 11.2. Informative References 757 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 758 "Introduction and Applicability Statements for Internet- 759 Standard Management Framework", RFC 3410, December 2002. 761 [forces-applicability-draft] 762 Crouch, A., Khosravi, H., Handley, M., and A. Doria, 763 "ForCES Applicability Statement", ID Document: 764 draft-ietf-forces-applicability-04.txt, February 2006. 766 Appendix A. Acknowledgments 768 The author gratefully acknowledges the contributions of: Jinrong 769 Fenggen, John Flick, Xiaoyi Guo, Joel Halpern, Tom Petch, and Jamal 770 Hadi Salim. 772 Author's Address 774 Robert Haas 775 IBM 776 Saeumerstrasse 4 777 Rueschlikon 8803 778 CH 780 Email: rha@zurich.ibm.com 781 URI: http://www.zurich.ibm.com/~rha 783 Full Copyright Statement 785 Copyright (C) The IETF Trust (2007). 787 This document is subject to the rights, licenses and restrictions 788 contained in BCP 78, and except as set forth therein, the authors 789 retain all their rights. 791 This document and the information contained herein are provided on an 792 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 793 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 794 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 795 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 796 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 797 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 799 Intellectual Property 801 The IETF takes no position regarding the validity or scope of any 802 Intellectual Property Rights or other rights that might be claimed to 803 pertain to the implementation or use of the technology described in 804 this document or the extent to which any license under such rights 805 might or might not be available; nor does it represent that it has 806 made any independent effort to identify any such rights. Information 807 on the procedures with respect to rights in RFC documents can be 808 found in BCP 78 and BCP 79. 810 Copies of IPR disclosures made to the IETF Secretariat and any 811 assurances of licenses to be made available, or the result of an 812 attempt made to obtain a general license or permission for the use of 813 such proprietary rights by implementers or users of this 814 specification can be obtained from the IETF on-line IPR repository at 815 http://www.ietf.org/ipr. 817 The IETF invites any interested party to bring to its attention any 818 copyrights, patents or patent applications, or other proprietary 819 rights that may cover technology that may be required to implement 820 this standard. Please address the information to the IETF at 821 ietf-ipr@ietf.org. 823 Acknowledgment 825 Funding for the RFC Editor function is provided by the IETF 826 Administrative Support Activity (IASA).