idnits 2.17.1 draft-ietf-forces-mib-04.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 on line 648. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 659. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 666. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 672. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 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 (July 27, 2006) is 6477 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 196, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3654 ** Downref: Normative reference to an Informational RFC: RFC 3746 Summary: 5 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 July 27, 2006 5 Intended status: Standards Track 6 Expires: January 28, 2007 8 ForCES MIB 9 draft-ietf-forces-mib-04 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 January 28, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 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). The ForCES working 46 group is defining a protocol to allow a Control Element (CE) to 47 control the behavior of a Forwarding Element (FE). 49 Table of Contents 51 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. ForCES MIB Definition . . . . . . . . . . . . . . . . . . . . 3 54 4. Associations kept in the MIB . . . . . . . . . . . . . . . . . 11 55 5. Support for multiple CEs and FEs . . . . . . . . . . . . . . . 11 56 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 57 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 58 8. Changes from Previous Draft Revisions . . . . . . . . . . . . 12 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 60 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 61 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 Intellectual Property and Copyright Statements . . . . . . . . . . 16 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. Introduction 74 The ForCES MIB module is a read-only MIB module that captures 75 information related to the ForCES protocol ([RFC3654], [RFC3746], 76 [forces-applicability-draft] and [forces-protocol-draft]). 78 For a detailed overview of the documents that describe the current 79 Internet-Standard Management Framework, please refer to section 7 of 80 [RFC3410]. 82 Managed objects are accessed via a virtual information store, termed 83 the Management Information Base or MIB. MIB objects are generally 84 accessed through the Simple Network Management Protocol (SNMP). 85 Objects in the MIB are defined using the mechanisms defined in the 86 Structure of Management Information (SMI). This memo specifies a MIB 87 module that is compliant to the SMIv2, which is described in STD 58, 88 [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580]. 90 The ForCES MIB module does not include information that is specified 91 in other MIB modules, such as packet counters for interfaces, etc. 93 More specifically, the information in the ForCES MIB module relative 94 to associations that are up includes: 96 o identifiers of the elements in the association, 98 o configuration parameters of the association, and 100 o statistics of the association. 102 3. ForCES MIB Definition 104 The MIB module contains the latest ForCES protocol version supported 105 by the CE (forcesLatestProtocolVersionSupported). Note that the CE 106 must also allow interaction with FEs supporting earlier versions. 108 For each association identified by the pair CE ID and FE ID, the 109 following associated information is provided by the MIB module as an 110 entry (forcesAssociationEntry) in the association table 111 (forcesAssociationTable): 113 o Version number of the ForCES protocol running in this association 114 (forcesAssociationRunningProtocolVersion). 116 o Time when the association entered the UP state 117 (forcesAssociationTimeUp). 119 o Time when the association left the UP state 120 (forcesAssociationTimeDown). Note that this is only used for 121 notification purposes as the association is removed from the MIB 122 immediately after it leaves the UP state. 124 o Number of ForCES Heartbeat messages sent from the CE 125 (forcesAssociationHBMsgSent) and received by the CE 126 (forcesAssociationHBMsgReceived) since the association is UP. 128 o Number of other ForCES messages sent from the CE 129 (forcesAssociationOtherMsgSent) and received by the CE 130 (forcesAssociationOtherMsgReceived) since the association is UP. 131 Only messages other than Heartbeat, Association Setup, Association 132 Setup Response, and Association Teardown are 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. 142 o Whenever an association leaves the UP state, a notification 143 (forcesAssociationEntryDown) is issued containing all associated 144 information for this association. The reason is that the 145 association and all its associated information will be removed 146 from the MIB immediately after this notification has been issued. 148 FORCES-MIB DEFINITIONS ::= BEGIN 150 IMPORTS 151 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 152 mib-2, Integer32, Counter32 153 FROM SNMPv2-SMI 155 TEXTUAL-CONVENTION, TimeStamp 156 FROM SNMPv2-TC 158 MODULE-COMPLIANCE, OBJECT-GROUP, 159 NOTIFICATION-GROUP 160 FROM SNMPv2-CONF; 162 forcesMib MODULE-IDENTITY 163 LAST-UPDATED "200607261200Z" -- Jul 26, 2006 164 ORGANIZATION "Forwarding and Control Element Separation 165 (ForCES) Working Group" 166 CONTACT-INFO 167 "Robert Haas (rha@zurich.ibm.com), IBM" 168 DESCRIPTION 169 "This MIB module contains managed object definitions 170 for the ForCES Protocol." 171 REVISION "200607261200Z" -- Jul 26, 2006 172 DESCRIPTION 173 "Initial version, published as RFC yyyy." 174 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 175 ::= { mib-2 XXX } 176 -- RFC Ed.: replace XXX with IANA-assigned number & remove this note 178 --**************************************************************** 180 forcesMibNotifications OBJECT IDENTIFIER ::= { forcesMib 0 } 181 forcesMibObjects OBJECT IDENTIFIER ::= { forcesMib 1 } 182 forcesMibConformance OBJECT IDENTIFIER ::= { forcesMib 2 } 184 ForcesID ::= TEXTUAL-CONVENTION 185 STATUS current 186 DESCRIPTION 187 "The ForCES identifier is a four octet quantity." 188 SYNTAX OCTET STRING (SIZE (4)) 190 ForcesProtocolVersion ::= TEXTUAL-CONVENTION 191 STATUS current 192 DESCRIPTION 193 "ForCES protocol version number. 194 The version numbers used are defined in the 195 specifications of the respective protocol: 196 1 - ForCESv1 [RFCzzzz]." 197 -- RFC Ed.: replace zzzz with actual RFC number of ForCES protocol 198 -- & remove this note 200 SYNTAX Integer32 (1..255) 202 -- Notifications 204 forcesAssociationEntryUp NOTIFICATION-TYPE 205 OBJECTS { 206 forcesAssociationRunningProtocolVersion 208 } 209 STATUS current 210 DESCRIPTION 211 "This notification is generated as soon 212 as an association enters the UP state." 213 ::= { forcesMibNotifications 1 } 215 forcesAssociationEntryDown NOTIFICATION-TYPE 216 OBJECTS { 217 forcesAssociationRunningProtocolVersion, 218 forcesAssociationTimeUp, 219 forcesAssociationTimeDown, 220 forcesAssociationHBMsgSent, 221 forcesAssociationHBMsgReceived, 222 forcesAssociationOtherMsgSent, 223 forcesAssociationOtherMsgReceived } 224 STATUS current 225 DESCRIPTION 226 "This notification is generated as soon 227 as an association leaves the UP state." 228 ::= { forcesMibNotifications 2 } 230 -- Objects 232 forcesLatestProtocolVersionSupported OBJECT-TYPE 233 SYNTAX ForcesProtocolVersion 234 MAX-ACCESS read-only 235 STATUS current 236 DESCRIPTION 237 "The ForCES protocol version supported by the CE. 238 The current protocol version is 1. 239 Note that the CE must also allow interaction 240 with FEs supporting earlier versions." 241 ::= { forcesMibObjects 1 } 243 forcesAssociations OBJECT IDENTIFIER ::= { forcesMibObjects 2 } 245 forcesAssociationTable OBJECT-TYPE 246 SYNTAX SEQUENCE OF ForcesAssociationEntry 247 MAX-ACCESS not-accessible 248 STATUS current 249 DESCRIPTION 250 "The (conceptual) table of associations." 251 ::= { forcesAssociations 1 } 253 forcesAssociationEntry OBJECT-TYPE 254 SYNTAX ForcesAssociationEntry 255 MAX-ACCESS not-accessible 256 STATUS current 257 DESCRIPTION 258 "A (conceptual) entry for one association." 259 INDEX { forcesAssociationCEID, forcesAssociationFEID } 260 ::= { forcesAssociationTable 1 } 262 ForcesAssociationEntry ::= SEQUENCE { 263 forcesAssociationCEID ForcesID, 264 forcesAssociationFEID ForcesID, 266 forcesAssociationRunningProtocolVersion 267 ForcesProtocolVersion, 269 forcesAssociationTimeUp TimeStamp, 270 forcesAssociationTimeDown TimeStamp, 272 forcesAssociationHBMsgSent Counter32, 273 forcesAssociationHBMsgReceived Counter32, 274 forcesAssociationOtherMsgSent Counter32, 275 forcesAssociationOtherMsgReceived Counter32 } 277 forcesAssociationCEID OBJECT-TYPE 278 SYNTAX ForcesID 279 MAX-ACCESS not-accessible 280 STATUS current 281 DESCRIPTION 282 "The ForCES ID of the CE." 283 ::= { forcesAssociationEntry 1 } 285 forcesAssociationFEID OBJECT-TYPE 286 SYNTAX ForcesID 287 MAX-ACCESS not-accessible 288 STATUS current 289 DESCRIPTION 290 "The ForCES ID of the FE." 291 ::= { forcesAssociationEntry 2 } 293 forcesAssociationRunningProtocolVersion OBJECT-TYPE 294 SYNTAX ForcesProtocolVersion 295 MAX-ACCESS read-only 296 STATUS current 297 DESCRIPTION 298 "The current ForCES protocol version used in this 299 association. 300 The current protocol version is 1." 301 ::= { forcesAssociationEntry 3 } 303 forcesAssociationTimeUp OBJECT-TYPE 304 SYNTAX TimeStamp 305 MAX-ACCESS read-only 306 STATUS current 307 DESCRIPTION 308 "The value of sysUpTime at the time this 309 association entered the UP state. 310 If this association started prior to the last 311 initialization of the network subsystem, then 312 this object contains a zero value." 313 ::= { forcesAssociationEntry 4 } 315 forcesAssociationTimeDown OBJECT-TYPE 316 SYNTAX TimeStamp 317 MAX-ACCESS read-only 318 STATUS current 319 DESCRIPTION 320 "The value of sysUpTime at the time this 321 association left the UP state." 322 ::= { forcesAssociationEntry 5 } 324 forcesAssociationHBMsgSent OBJECT-TYPE 325 SYNTAX Counter32 326 MAX-ACCESS read-only 327 STATUS current 328 DESCRIPTION 329 "A counter of how many heartbeat messages have 330 have been sent by the CE on this association 331 since it is up. 332 If this association started prior to the last 333 initialization of the network subsystem, then 334 this object contains the value since the 335 initialization." 336 ::= { forcesAssociationEntry 6 } 338 forcesAssociationHBMsgReceived OBJECT-TYPE 339 SYNTAX Counter32 340 MAX-ACCESS read-only 341 STATUS current 342 DESCRIPTION 343 "A counter of how many heartbeat messages 344 have been received by the CE on this association 345 since it is up. 346 If this association started prior to the last 347 initialization of the network subsystem, then 348 this object contains the value since the 349 initialization." 350 ::= { forcesAssociationEntry 7 } 352 forcesAssociationOtherMsgSent OBJECT-TYPE 353 SYNTAX Counter32 354 MAX-ACCESS read-only 355 STATUS current 356 DESCRIPTION 357 "A counter of how many messages other than 358 heartbeat (i.e., config and query) 359 have been sent by the CE on this association 360 since it is up. 361 If this association started prior to the last 362 initialization of the network subsystem, then 363 this object contains the value since the 364 initialization." 365 ::= { forcesAssociationEntry 8 } 367 forcesAssociationOtherMsgReceived OBJECT-TYPE 368 SYNTAX Counter32 369 MAX-ACCESS read-only 370 STATUS current 371 DESCRIPTION 372 "A counter of how many messages other than 373 heartbeat (i.e., config response, query response, 374 event notification, and packet redirect) 375 have been received by the CE on this association 376 since it is up. 377 If this association started prior to the last 378 initialization of the network subsystem, then 379 this object contains the value since the 380 initialization." 381 ::= { forcesAssociationEntry 9 } 383 -- Conformance 385 forcesMibCompliances OBJECT IDENTIFIER 386 ::= { forcesMibConformance 1 } 387 forcesMibGroups OBJECT IDENTIFIER 388 ::= { forcesMibConformance 2 } 390 -- Compliance statements 392 forcesMibCompliance MODULE-COMPLIANCE 393 STATUS current 394 DESCRIPTION 395 "The compliance statement for routers running ForCES and 396 implementing the ForCES MIB." 397 MODULE -- this module 398 MANDATORY-GROUPS { forcesMibGroup, forcesNotificationGroup } 399 GROUP forcesStatsGroup 400 DESCRIPTION 401 "Implementation of this group is recommended." 403 ::= { forcesMibCompliances 1 } 405 -- Units of conformance 407 forcesNotificationGroup NOTIFICATION-GROUP 408 NOTIFICATIONS { forcesAssociationEntryUp, 409 forcesAssociationEntryDown 410 } 411 STATUS current 412 DESCRIPTION 414 "A collection of notifications for signaling important 415 ForCES events." 416 ::= { forcesMibGroups 1 } 418 forcesMibGroup OBJECT-GROUP 419 OBJECTS { forcesLatestProtocolVersionSupported, 420 forcesAssociationRunningProtocolVersion 421 } 422 STATUS current 423 DESCRIPTION 424 "A collection of objects to support management of ForCES 425 routers." 426 ::= { forcesMibGroups 2 } 428 forcesStatsGroup OBJECT-GROUP 429 OBJECTS { forcesAssociationTimeUp, 430 forcesAssociationTimeDown, 431 forcesAssociationHBMsgSent, 432 forcesAssociationHBMsgReceived, 433 forcesAssociationOtherMsgSent, 434 forcesAssociationOtherMsgReceived 435 } 436 STATUS current 437 DESCRIPTION 438 "A collection of optional objects to provide extra 439 information about the associations. There is no protocol 440 reason to keep such information, but these objects can 441 be very useful in debugging connectivity problems." 442 ::= { forcesMibGroups 3 } 444 END 446 4. Associations kept in the MIB 448 Only associations that are UP are reflected in this MIB module. 449 Associations enter the UP state as soon as the CE has sent to the FE 450 an Association Setup Response message containing a successful 451 Association Setup Result. 453 Associations are removed from the MIB module as soon as they leave 454 the UP state, i.e., if the CE has not received any message (Heartbeat 455 or other protocol message) from the FE within a given time period or 456 if an Association Teardown message has been sent by the CE. 458 5. Support for multiple CEs and FEs 460 An NE consists of one or more FEs and one or more CEs. Where there 461 is a single CE, that CE will have knowledge of all the associations 462 in the NE and so can provide the information necessary to support the 463 managed objects defined in this MIB module. Where there is more than 464 one CE, information about the associations may be distributed among 465 the CEs. Whether each CE implements the managed objects for the 466 associations of which it is aware or whether the CEs cooperate to 467 present the appearance of a single set of managed objects for all the 468 associations in the NE is outside the scope of this document. 470 6. Security Considerations 472 Some of the readable objects in this MIB module may be considered 473 sensitive or vulnerable in some network environment. 475 SNMP versions prior to SNMPv3 did not include adequate security. 476 Even if the network itself is secure (for example by using IPSec), 477 even then, there is no control as to who on the secure network is 478 allowed to access and GET/SET (read/change/create/delete) the objects 479 in this MIB module. 481 It is RECOMMENDED that implementers consider the security features as 482 provided by the SNMPv3 framework (see [RFC3410], section 8), 483 including full support for the SNMPv3 cryptographic mechanisms (for 484 authentication and privacy). 486 Further, deployment of SNMP versions prior to SNMPv3 is NOT 487 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 488 enable cryptographic security. It is then a customer/operator 489 responsibility to ensure that the SNMP entity giving access to an 490 instance of this MIB module is properly configured to give access to 491 the objects only to those principals (users) that have legitimate 492 rights to indeed GET or SET (change/create/delete) them. 494 7. IANA Considerations 496 The MIB module in this document uses the following IANA-assigned 497 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 499 Descriptor OBJECT IDENTIFIER value 500 ---------- ----------------------- 502 forcesMIB { mib-2 XXX } 504 Editor's Note (to be removed prior to publication): the IANA is 505 requested to assign a value for "XXX" under the 'mib-2' subtree and 506 to record the assignment in the SMI Numbers registry. When the 507 assignment has been made, the RFC Editor is asked to replace "XXX" 508 (here and in the MIB module) with the assigned value and to remove 509 this note. 511 8. Changes from Previous Draft Revisions 513 Editor's Note (to be removed prior to publication): Prior to RFC 514 publication of this document, the RFC Editor is asked to remove this 515 entire section titled "Changes from Previous Draft Versions". 517 Changes from draft-ietf-forces-mib-03. They are small fixes to the 518 text and the MIB module: 520 o Added MIB boilerplate according to 521 http://www.ops.ietf.org/mib-boilerplate.html 523 o Clarified terminology with respect to MIB module and MIB managed 524 objects. 526 o Added RFC Editor note to indicate RFC number for version 1 of 527 ForCES protocol under ForcesProtocolVersion. 529 o Renumbered elements in forcesAssociationEntry starting with 1. 531 o Changed ForcesProtocolVersion from INTEGER to Integer32. 533 o Added forcesLatestProtocolVersionSupported into the mandatory 534 forcesMibGroups conformance group. 536 o Explicitely added the forcesStatsGroup to the forcesMibCompliance 537 compliance statement as optional. 539 o Moved the MIB Definition section to the front. 541 o Rephrased IANA Considerations section according to RFC 4181 542 Section 3.5.2. 544 o Added RFC Editor note to remove the "Changes from Previous Draft 545 Revisions" section prior to publication. 547 Changes from draft-ietf-forces-mib-02. They are refinements of the 548 MIB module: 550 o Changed forcesAssociationCEID and forcesAssociationFEID from read- 551 only to not-accessible to conform with Section 7.7 in [RFC2578]. 553 o Removed forcesAssociationCEID and forcesAssociationFEID from the 554 notifications. This information is conveyed in the OID anyway. 556 o Added MIB conformance information. 558 Changes from draft-ietf-forces-mib-01. The changes are in response 559 to the Working Group Last Call: 561 o Addition of two traps/notifications to signal the associations 562 that enter or leave the UP state. 564 o Suppression of the DOWN and ESTABLISHING states. Only 565 associations in the UP state are kept in the table. 567 o Split of the Message counters into Heartbeat and other messages. 569 o Addition of the current running version of ForCES protocol for 570 each association in the UP state. 572 o Addition of the latest version of the ForCES protocol supported by 573 the CE. 575 9. References 577 9.1. Normative References 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, March 1997. 582 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 584 Schoenwaelder, Ed., "Structure of Management Information 585 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 587 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 588 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 589 STD 58, RFC 2579, April 1999. 591 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 592 "Conformance Statements for SMIv2", STD 58, RFC 2580, 593 April 1999. 595 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 596 of IP Control and Forwarding", RFC 3654, November 2003. 598 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 599 "Forwarding and Control Element Separation (ForCES) 600 Framework", RFC 3746, April 2004. 602 [forces-protocol-draft] 603 Doria, A., Haas, R., Hadi Salim, J., Khosravi, H., and W. 604 Wang, "ForCES Protocol Specification", ID Document: 605 draft-ietf-forces-protocol-08.txt, March 2006. 607 9.2. Informative References 609 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 610 "Introduction and Applicability Statements for Internet- 611 Standard Management Framework", RFC 3410, December 2002. 613 [forces-applicability-draft] 614 Crouch, A., Khosravi, H., Handley, M., and A. Doria, 615 "ForCES Applicability Statement", ID Document: 616 draft-ietf-forces-applicability-04.txt, February 2006. 618 Appendix A. Acknowledgments 620 The author gratefully acknowledges the contributions of: Jinrong 621 Fenggen, Xiaoyi Guo, Joel Halpern, Tom Petch, and Jamal Hadi Salim. 623 Author's Address 625 Robert Haas 626 IBM 627 Saeumerstrasse 4 628 Rueschlikon 8803 629 CH 631 Email: rha@zurich.ibm.com 632 URI: http://www.zurich.ibm.com/~rha 634 Full Copyright Statement 636 Copyright (C) The Internet Society (2006). 638 This document is subject to the rights, licenses and restrictions 639 contained in BCP 78, and except as set forth therein, the authors 640 retain all their rights. 642 This document and the information contained herein are provided on an 643 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 644 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 645 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 646 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 647 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 648 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 650 Intellectual Property 652 The IETF takes no position regarding the validity or scope of any 653 Intellectual Property Rights or other rights that might be claimed to 654 pertain to the implementation or use of the technology described in 655 this document or the extent to which any license under such rights 656 might or might not be available; nor does it represent that it has 657 made any independent effort to identify any such rights. Information 658 on the procedures with respect to rights in RFC documents can be 659 found in BCP 78 and BCP 79. 661 Copies of IPR disclosures made to the IETF Secretariat and any 662 assurances of licenses to be made available, or the result of an 663 attempt made to obtain a general license or permission for the use of 664 such proprietary rights by implementers or users of this 665 specification can be obtained from the IETF on-line IPR repository at 666 http://www.ietf.org/ipr. 668 The IETF invites any interested party to bring to its attention any 669 copyrights, patents or patent applications, or other proprietary 670 rights that may cover technology that may be required to implement 671 this standard. Please address the information to the IETF at 672 ietf-ipr@ietf.org. 674 Acknowledgment 676 Funding for the RFC Editor function is provided by the IETF 677 Administrative Support Activity (IASA).