idnits 2.17.1 draft-schoenw-sming-lessons-01.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 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. 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 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 (September 25, 2007) is 6057 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder 3 Internet-Draft Jacobs University Bremen 4 Intended status: Informational September 25, 2007 5 Expires: March 28, 2008 7 Protocol Independent Network Management Data Modeling Languages - 8 Lessons Learned from the SMIng Project 9 draft-schoenw-sming-lessons-01.txt 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 March 28, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 A data modeling language for network management protocols called 43 SMIng was developed within the Network Management Research Group of 44 the Internet Research Task Force over a period of several years. 45 This memo documents some of the lessons learned during the project 46 for consideration by designers of future data modeling languages for 47 network management protocols. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. SMIng Goals and History . . . . . . . . . . . . . . . . . . . 4 53 3. Lessons Learned . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Readers, Writers, Tool Developers . . . . . . . . . . . . 5 55 3.2. Data vs. Command vs. Object vs. Document . . . . . . . . . 5 56 3.3. Naming Independence . . . . . . . . . . . . . . . . . . . 7 57 3.4. Errors and Exceptions . . . . . . . . . . . . . . . . . . 7 58 3.5. Configuration Storage Models . . . . . . . . . . . . . . . 8 59 3.6. Selection of Language Features . . . . . . . . . . . . . . 8 60 3.7. Syntax versus Semantics . . . . . . . . . . . . . . . . . 8 61 3.8. Reuse of Definitions . . . . . . . . . . . . . . . . . . . 9 62 3.9. Versioning and Meta Information . . . . . . . . . . . . . 9 63 3.10. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9 64 3.11. Language Independence . . . . . . . . . . . . . . . . . . 10 65 3.12. Compliance and Conformance . . . . . . . . . . . . . . . . 10 66 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 70 8. Informative References . . . . . . . . . . . . . . . . . . . . 11 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 Intellectual Property and Copyright Statements . . . . . . . . . . 14 74 1. Introduction 76 Network management is often performed using a collection of different 77 management protocols. Many operators use several different 78 management protocols to access a single managed device for different 79 purposes, such as device configuration, event and notification 80 delivery, and collection of statistics. While some operators manage 81 to settle on a single protocol for a given management task and/or 82 domain, it is not uncommon that different operators select different 83 competing management protocols for the same management task and/or 84 domain. 86 As a result, device vendors are forced to support multiple management 87 interfaces to satisfy their customers. This increases software 88 complexity and costs. It is therefore understandable that device 89 vendors are interested to reduce the complexity and efforts 90 associated with supporting multiple management interfaces. One 91 obvious step in this direction could be to have a common data model 92 which is underlying all management protocol interfaces instead of the 93 current situation where every management protocol interface has its 94 own slightly different data model. As a consequence, it is 95 attractive to design data modeling languages that are protocol 96 independent and allow for a "late binding" to concrete management 97 protocols. 99 The Network Management Research Group (NMRG) of the Internet Research 100 Task Force (IRTF) has developed a new protocol independent data 101 modeling language for network management protocols called SMIng 102 [RFC3780]. Work on SMIng started in 1999 and concluded with the 103 publication of the core language [RFC3780] and an extension providing 104 mappings to the Simple Network Management Protocol (SNMP) [RFC3781] 105 in 2004. 107 This memo documents some of the lessons learned during the project 108 for consideration by engineers of future data modeling languages for 109 network management protocols. Our focus is on technical design 110 aspects that have turned out to be more difficult than expected as 111 well as aspects that required significant discussions in order to 112 understand trade-offs. 114 The rest of this document is structured as follows. Section 2 115 provides a short review of the goals and the history of the SMIng 116 project. Section 3 discusses twelve lessons learned. The document 117 concludes in Section 4. 119 2. SMIng Goals and History 121 The SMIng project started in 1999 as a research project to address 122 some drawbacks of SMIv2 [RFC2578] [RFC2579] [RFC2580], the current 123 standard data modeling language for management information base 124 modules in the IETF [DSOM99]. Primarily, SMIv2's partial dependence 125 on ASN.1 and a number of exception rules were considered to be 126 problematic. In 2000, the work was handed over to the IRTF Network 127 Management Research Group where SMIng was significantly detailed. In 128 1999/2000, the work of the Resource Allocation Protocol (RAP) working 129 group on the Common Open Policy Service (COPS) usage for Policy 130 Provisioning (COPS-PR) [RFC3084] lead to the creation of the 131 Structure of Policy Provisioning Information (SPPI) [RFC3159]. As a 132 consequence, SMIng was split into two parts: a core protocol 133 independent data definition language and protocol specific mappings 134 to allow the access of core definitions through (potentially) 135 multiple management protocols. The replacement of SMIv2 and SPPI by 136 a single merged data definition language was also a primary goal of 137 the IETF SMING working group chartered at the end of 2000. The SMING 138 working group, after carefully documenting the objectives [RFC3216], 139 could not reach agreement on a common solution, resulting in the 140 working group being closed down in April 2003. The NMRG then 141 published the SMIng specifications in 2004 in [RFC3780] and [RFC3781] 142 in order to document the results achieved in the NMRG. 144 The published version of SMIng aimed at being a data modeling 145 language that can be adapted for different management protocols and 146 thus be closer to an information modeling language. See RFC 3444 147 [RFC3444] for a more detailed discussion of the terms data modeling 148 language and information modeling language. 150 The problem which drove the development of SMIng, namely duplicated 151 data modeling efforts and often also duplicated instrumentation code, 152 is still widely unsolved and it even may have become more pressing. 153 A standard data modeling language capable to drive tools that can 154 automate the implementation of command line interfaces, monitoring 155 interfaces, and configuration interfaces from a single specification 156 surely would have significant value for the networking industry and 157 standardization bodies. 159 During the SMIng project, people have looked at various issues that 160 have to be dealt with in this context. The purpose of this memo is 161 to document these issues and some of the alternatives that have been 162 explored to tackle them so that future language designers can learn 163 from the SMIng experiment. 165 3. Lessons Learned 167 This section summarizes the lessons learned from the SMIng project. 168 Designers of future data modeling languages for network management 169 protocols are encouraged to study these lessons to avoid potential 170 pitfalls. 172 3.1. Readers, Writers, Tool Developers 174 Network management data modeling languages are used by engineers to 175 develop and specify data models for (sub-components of) managed 176 systems. The data models are later read by implementers with the 177 goal to create interoperable implementations. Network operators 178 often read data models while managing networks and services. A data 179 modeling language is therefore used by both data model writers and 180 data model readers. In most cases, the number of data model readers 181 is much larger than the number of data model writers. Hence, when 182 taking design decisions, it may be necessary to consider to what 183 extent the design choice simplifies the task of data model readers 184 and the task of data model writers. All other things being equal, 185 preference should be given to solutions that simplify the task of 186 data model readers. 188 The third group to be considered in the data modeling language design 189 process are tool developers creating parser libraries or compilers. 190 In general, language features should be simple and straight forward 191 to implement in order to achieve wide spread tool support. However, 192 when considering alternatives, it is important to realize that in 193 most cases the number of data model writers is much larger than the 194 number of developers of tools (e.g., parsers, compilers) supporting a 195 data modeling language. 197 As a consequence, preference should be give to solutions that 198 simplify the task of readers. Reduction of the efforts required by 199 writers is of secondary importance and the reduction of the efforts 200 required by tool developers is of least important preference. While 201 this perhaps seems obvious, it is at times difficult to take 202 according design decisions, especially if the group working on a new 203 data modeling language is dominated by tool developers or data model 204 writers. 206 3.2. Data vs. Command vs. Object vs. Document 208 There are different approaches to model network management interfaces 209 and to design supporting protocols: 211 o The data-oriented approach models all management aspects through 212 data objects that can be read, written, created, and destroyed. 213 The SNMP technology is an extreme example of this approach where 214 even create and destroy operations are handled as side effects of 215 write operations. While the data-oriented approach is 216 conceptually simple, it is usually difficult to use for modeling 217 complex operations, for example due to atomicity issues. 218 o The command-oriented approach does not model data objects but 219 instead treats the state maintained by a managed element as a 220 black box and provides specific commands to cause state changes or 221 to retrieve/modify some selected internal state information. The 222 command-oriented approach is widely used by command line 223 interfaces. 224 o The object-oriented approach can be seen as a combination of the 225 data-oriented and the command-oriented approach where commands are 226 bound to data objects and the black-box state is limited to the 227 internal state of objects. The object-oriented approach is being 228 used for example by the Common Information Model. 229 o The document-oriented approach represents the state of a device 230 and its configuration as a structured document. As a consequence, 231 primitive operations are the retrieval of (parts of) a document 232 and the application of changes to move from one document version 233 to the next. Since a configuration is treated as a complete 234 document, it becomes more natural to support coarse grained atomic 235 operations. The document-oriented approach is used by the Network 236 Configuration (NETCONF) protocol [RFC4741] recently published by 237 the IETF. 239 Note that the choice of the data modeling approach has impact on the 240 features required by a data modeling language. Trying to be protocol 241 neutral may imply to support multiple of these approaches, which 242 clearly increases the complexity of the language design. A data 243 modeling language aiming at supporting a document-oriented view for 244 configuration, a data-oriented view for monitoring, and a command- 245 oriented view for ad-hoc operations on a device must be able to link 246 say a command to the data objects that may be manipulated to achieve 247 the behaviour defined for that command. This quickly becomes 248 difficult and it might be better to avoid mixing different data 249 modeling approaches. 251 Unfortunately, in many real-world implementations, new management 252 protocols will be used together with existing interfaces or 253 databases, which already follow one of the approaches. This will 254 force the designers of new data modeling languages to accommodate 255 features of multiple approaches, even if this makes the result more 256 complicated. 258 3.3. Naming Independence 260 One of the goals of the SMIng project was to provide a data 261 definition language where the data definitions are not tied to a 262 specific management protocol. Since protocols typically use 263 different approaches to name instances of managed objects, it is 264 required to support multiple instance naming systems. While this may 265 sound easy to do, it turns out that trying to achieve naming 266 independence has many implications: 268 o There is in general a need to model relationships. A common 269 approach is to refer to other definitions using names as pointers. 270 Being naming system independent, such a pointer needs to be 271 abstracted and the protocol mappings then need to explain how the 272 pointer works for a given protocol. This quickly becomes 273 difficult since management protocols tend to impose protocol 274 specific constraints, resulting from the different naming systems. 275 o Many relationships between data model components are typically 276 explained in description clauses. Being protocol neutral, 277 description clauses have to be worded carefully so that they make 278 sense with the various protocol mappings. This significantly 279 increases the efforts to write data models and to review them. 280 o When thinking about relationships, it is crucial to think about 281 fate sharing of data objects, namely does the removal of an object 282 imply the removal of other objects? Being naming system 283 independent causes some additional challenges here since some fate 284 sharing properties may be implicit in the naming system used in 285 one protocol mapping while they must be explicit in other protocol 286 mappings. 288 3.4. Errors and Exceptions 290 Well written data definitions include clear definitions how 291 implementations should react in various error situations or during 292 run-time exceptions. It is often a mistake if a data model writer 293 assumes that implementers will choose a particular error code in a 294 given error situation. For interoperability reasons, it is far 295 better to spell out the precise behaviour in error situations and 296 run-time exceptions. Unfortunately, it becomes quite difficult to be 297 precise about errors and exceptions in a protocol and naming system 298 neutral data modeling framework such as SMIng since all error and 299 exception reporting mechanisms of the underlying protocols need to be 300 abstracted because otherwise description clauses become protocol 301 specific. Furthermore, due to the varying features of the underlying 302 protocols, some errors and exceptions may only exist in some of the 303 mappings and must therefore be dealt with when the generic data model 304 is mapped to a concrete protocol. 306 3.5. Configuration Storage Models 308 Management protocols use different mechanisms to deal with 309 persistence of configuration state. The SNMP protocol uses 310 StorageType [RFC2579] columns in conceptual tables to indicate which 311 rows are persistent. The COPS-PR [RFC3084] protocol binds 312 provisioned information to the existence of the COPS-PR session which 313 provisioned policy information. The NETCONF protocol [RFC4741] has a 314 concept of different data stores (running, startup, candidate) that 315 imply whether configuration state is persistent or not. 317 Given these fundamentally different approaches, it is difficult to 318 write protocol neutral configuration data models that work equally 319 well with the various management protocols. While it is possible to 320 introduce say StorageType columns in protocol mappings, it is 321 sometimes awkward to define the semantics of data objects if the 322 persistence model is left to the protocol mappings. 324 3.6. Selection of Language Features 326 A data modeling language, like any good language, should be based on 327 a small orthogonal set of language features to control the overall 328 complexity of the language, both in terms of usage and 329 implementation. While it is relatively easy to invent and propose 330 new features, it seems much harder to find a minimal and orthogonal 331 set of basic features that addresses the requirements. 333 During the design of the SMIng language, it was found useful to 334 repeatedly ask the question why certain features are needed or 335 whether there are any language rules without a strong and convincing 336 justification. The general principle stated by Antoine de Saint- 337 Exupery was followed: 339 Perfection [in design] is achieved, not when there is nothing more 340 to add, but when there is nothing left to take away. 342 Language features should be selected by considering what tools can 343 actually do with the information formalized by a language feature. 344 In general, language features should raise automation and improve 345 clarity. Features without a clear justification that they actually 346 reduce implementation efforts or significantly improve the clarity of 347 a data model specification should not be accepted. 349 3.7. Syntax versus Semantics 351 During the design of a data modeling language, it is most important 352 to focus on a clear semantic of all language constructs. Syntactical 353 issues are of secondary importance. While this may sound obvious, it 354 is important, especially in open consensus driven processes, to keep 355 contributors reminded that semantics of language constructs come 356 first while the syntactic aspects are of secondary importance. 358 3.8. Reuse of Definitions 360 A good data modeling language should allow data model writers to 361 produce reusable definitions. However, not all definitions are 362 equally easy to reuse. Experience has shown that data types derived 363 from a small set of base types are usually very easy to reuse; 364 structured data types are often getting slightly more complex to 365 reuse. Reusing collections of structured data types with non-trivial 366 interrelationships are often difficult to reuse. The low hanging 367 fruits are therefor the simple type definitions. 369 Sub-typing is frequently used to add specific semantics to a more 370 generic type and to constrain the set of possible values. While 371 constraining values is often a good thing, it should be noted that 372 too strict constraints can turn out to be painful in the future. 373 There are many examples where data types proved too constrained to 374 represent protocols that followed a natural evolution. 376 3.9. Versioning and Meta Information 378 Changes to data models are inevitable. Even the most careful design 379 and review process will not be able to predict how technologies 380 evolve in the future. It is therefore crucial that the data modeling 381 language supports a suitable versioning model and that it establishes 382 clear rules which changes are possible without having to change a 383 version number or (module) name. Supporting complex collections of 384 meta data (e.g., a granular revision log) as part of the data 385 modeling language may be less of an issue since such information can 386 often be maintained in revision control systems and automatically 387 placed into comments where needed. 389 3.10. Extensibility 391 It has proven to be useful to support language extensibility features 392 that avoid backward compatibility problems with existing parsers when 393 new language features are introduced. If a data modeling language 394 supports language extensions, it should be possible to gradually 395 introduce new language features. 397 Supporting language extensions essentially requires to be very 398 consistent with the syntactic structure so that deployed 399 implementations can skip over new language constructs. In addition, 400 it is necessary to precisely identify language extensions so that 401 implementations supporting extensions know where to apply the 402 appropriate additional processing. 404 3.11. Language Independence 406 One way to define a new data modeling language is to start from an 407 existing language and to extend it and/or subset it as needed. 408 However, there are some dangers associated with this approach. 410 Since languages that are in actual use are not static, it is 411 important to deal with conflicts that can arise if the base language 412 is revised such that the extensions or subsets do not work anymore. 413 This issue becomes particularly important if different organizations 414 have change control since this makes coordination relatively complex. 415 Things get even worse if the data modeling extension constitutes not 416 a significant usage of the core language. 418 Another risk associated with sub-setting an existing language is that 419 generic tools are likely not aware of the subset allowed in data 420 models and hence such tools will not help to restrict the features of 421 the general language to the subset adequate to define management data 422 models. 424 The alternative is to provide a complete and self-contained 425 definition for the data modeling language. This protects against 426 change control issues and also makes it simpler for implementers or 427 data model writers to find all language rules in one place. 429 As a general rule, there is hardly a reason to import language 430 definitions from other organizations. If you like to import 431 something from a source that is likely to change, do not import. If, 432 however, the source is assumed to be stable, then you can just import 433 by value and explain the relationship to the original source. 435 3.12. Compliance and Conformance 437 Any successful data modeling language will at some point have to deal 438 with compliance and conformance definitions. However, designing 439 language features to express compliance and conformance statements is 440 non-trivial. Very fine grained mechanisms to define implementation 441 requirements for different usage scenarios can lead to very detailed 442 but also very complex compliance and conformance definitions that are 443 difficult to understand, review and maintain. 445 It is therefore important to make a good trade-off between the 446 required expressiveness and the pragmatic usage of compliance and 447 conformance definitions. The general considerations for language 448 features discussed Section 3.6 particularly apply here. One approach 449 is to first gain experience with the usage of a new data modeling 450 language and to support compliance and conformance definitions 451 through language extensions, improving their expressiveness over time 452 as needed. 454 4. Conclusions 456 This memo documents some of the insights gained in the SMIng project 457 in order to guide future data modeling language designers by making 458 them aware of some of the problems encountered in the SMIng project 459 and some of the design guidelines that have been developed through 460 the project. 462 While protocol independent data modeling languages seem like a very 463 good idea in world which uses several different management protocols 464 for different tasks and deployments, the complexity associated with 465 the design and effective usage of protocol independent data modeling 466 languages should not be underestimated. 468 5. IANA Considerations 470 This document has no IANA actions. 472 6. Security Considerations 474 This document discusses lessons learned during the design of a 475 network management data modeling language and they have no impact on 476 the security of the Internet. 478 7. Acknowledgements 480 Many people contributed directly or indirectly to this documented 481 through their participation in the SMIng project. Martin Bjorklund, 482 David Harrington, Balazs Lengyel, Frank Strauss and Bert Wijnen 483 provided valuable feedback on earlier versions of this document. 485 8. Informative References 487 [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 488 "Structure of Management Information Version 2 (SMIv2)", 489 RFC 2578, STD 58, April 1999. 491 [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 492 "Textual Conventions for SMIv2", RFC 2579, STD 58, 493 April 1999. 495 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 496 "Conformance Statements for SMIv2", RFC 2580, STD 58, 497 April 1999. 499 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 500 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 501 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", 502 RFC 3084, March 2001. 504 [RFC3159] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, 505 S., Sahita, R., Smith, A., and F. Reichmeyer, "Structure 506 of Policy Provisioning Information (SPPI)", RFC 3159, 507 August 2001. 509 [RFC3216] Elliot, C., Harrington, D., Jason, J., Schoenwaelder, J., 510 Strauss, F., and W. Weiss, "SMIng Objectives", RFC 3216, 511 December 2001. 513 [RFC3780] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation 514 Structure of Management Information", RFC 3780, May 2004. 516 [RFC3781] Strauss, F. and J. Schoenwaelder, "Next Generation 517 Structure of Management Information (SMIng) Mappings to 518 the Simple Network Management Protocol (SNMP)", RFC 3781, 519 May 2004. 521 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 522 Information Models and Data Models", RFC 3444, 523 January 2003. 525 [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, 526 December 2006. 528 [DSOM99] Schoenwaelder, J. and F. Strauss, "Next Generation 529 Structure of Management Information for the Internet", 530 Springer LNCS 1700, October 1999. 532 Author's Address 534 Juergen Schoenwaelder 535 Jacobs University Bremen 536 Campus Ring 1 537 28725 Bremen 538 Germany 540 Phone: +49 421 200-3587 541 Email: j.schoenwaelder@jacobs-university.de 543 Full Copyright Statement 545 Copyright (C) The IETF Trust (2007). 547 This document is subject to the rights, licenses and restrictions 548 contained in BCP 78, and except as set forth therein, the authors 549 retain all their rights. 551 This document and the information contained herein are provided on an 552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 554 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 555 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 556 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 559 Intellectual Property 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Acknowledgment 585 Funding for the RFC Editor function is provided by the IETF 586 Administrative Support Activity (IASA).