idnits 2.17.1 draft-ietf-ippm-framework-compagg-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 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 574. ** 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 'Intended status' indicated for this document; assuming Proposed Standard 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 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 (June 24, 2006) is 6516 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) == Unused Reference: 'I-D.ietf-ippm-multimetrics' is defined on line 516, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-ippm-multimetrics-00 ** Downref: Normative reference to an Informational RFC: RFC 2330 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton, Ed. 3 Internet-Draft AT&T Labs 4 Expires: December 26, 2006 S. Van den Berghe, Ed. 5 Ghent University - IBBT 6 June 24, 2006 8 Framework for Metric Composition 9 draft-ietf-ippm-framework-compagg-01 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 December 26, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This memo describes a framework for composing and aggregating metrics 43 (both in time and in space) defined by RFC 2330 and developed by the 44 IPPM working group. The framework describes the generic composition 45 and aggregation mechanisms. It provides a basis for additional 46 documents that implement this framework for detailed, and practically 47 useful, compositions and aggregations of metrics. 49 Requirements Language 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1.1. Reducing Measurement Overhead . . . . . . . . . . . . 3 60 1.1.2. Measurement Re-use . . . . . . . . . . . . . . . . . . 4 61 1.1.3. Data Reduction and Consolidation . . . . . . . . . . . 4 62 1.1.4. Implications on Measurement Design and Reporting . . . 5 63 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Description of Metric Types . . . . . . . . . . . . . . . . . 5 65 3.1. Temporal Aggregation Description . . . . . . . . . . . . . 5 66 3.2. Spatial Aggregation Description . . . . . . . . . . . . . 6 67 3.3. Spatial Composition Description . . . . . . . . . . . . . 7 68 3.4. Help Metrics . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.5. Higher Order Composition . . . . . . . . . . . . . . . . . 7 70 4. Requirements for Composed Metrics . . . . . . . . . . . . . . 7 71 5. Guidelines for Defining Composed Metrics . . . . . . . . . . . 9 72 5.1. Ground Truth: Comparison with other IPPM Metrics . . . . . 9 73 5.2. Deviation from the Ground Truth . . . . . . . . . . . . . 11 74 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 75 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 76 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 81 Intellectual Property and Copyright Statements . . . . . . . . . . 15 83 1. Introduction 85 The IPPM framework RFC 2330 [RFC2330] describes two forms of metric 86 composition, spatial and temporal. Also, the text suggests that the 87 concepts of the analytical framework (or A-frame) would help to 88 develop useful relationships to derive the composed metrics from real 89 metrics. The effectiveness of composed metrics is dependent on their 90 usefulness in analysis and applicability to practical measurement 91 circumstances. 93 This memo expands on the notion of composition, and provides a 94 detailed framework for several classes of metrics that were mentioned 95 in the original IPPM framework. The classes include temporal 96 aggregation, spatial aggregation, and spatial composition. 98 1.1. Motivation 100 Network operators have deployed measurement systems to serve many 101 purposes, including performance monitoring, maintenance support, 102 network engineering, and customer reporting. The collection of 103 elementary measurements alone is not enough to understand a network's 104 behaviour. In general, measurements need to be post-processed to 105 present the most relevant information for each purpose. The first 106 step is often a process of "composition" of single measurements or 107 measurement sets into other forms. Composition and aggregation 108 present several more post-processing opportunites to the network 109 operator, and we describe the key motivations below. 111 1.1.1. Reducing Measurement Overhead 113 A network's measurement possibilities scale upward with the square of 114 the number of nodes. But each measurement implies overhead, in terms 115 of the storage for the results, the traffic on the network (assuming 116 active methods), and the OA&M for the measurement system itself. In 117 a large network, it is impossible to perform measurements from each 118 node to all others. 120 An individual network operator should be able to organize their 121 measurement paths along the lines of physical topology, or routing 122 areas/Autonomous Systems, and thus minimize dependencies and overlap 123 between different measurement paths. This way, the sheer number of 124 measurements can be reduced, as long as the operator has a set of 125 methods to estimate performance between any particular nodes when 126 needed. 128 Composition and aggregation play a key role when the path of interest 129 spans multiple networks, and where each operator conducts their own 130 measurements. Here, the complete path performance may be estimated 131 from measurements on the component parts. 133 Operators that take advantage of the composition and aggregation 134 methods recognize that the estimates may exhibit some additional 135 error beyond that inherent in the measurements themselves, and so 136 they are making a trade-off to achieve reasonable measurement system 137 overhead. 139 1.1.2. Measurement Re-use 141 There are many different measurement users, each bringing specific 142 requirements for the reporting timescale. Network managers and 143 maintenance forces prefer to see results presented very rapidly, to 144 detect problems quickly or see if their action has corrected a 145 problem. On the other hand, network capacity planners and even 146 network users sometimes prefer a long-term view of performance, for 147 example to check trends. How can one set of measurements serve both 148 needs? 150 The answer lies in temporal aggregation, where the short-term 151 measurements needed by the operations community are combined to 152 estimate a longer-term result for others. Also, problems with the 153 measurement system itself may be isolated to one or more of the 154 short-term measurements, rather than possibly invalidating an entire 155 long-term measurement if the problem was undetected. 157 1.1.3. Data Reduction and Consolidation 159 Another motivation is data reduction. Assume there is a network 160 domain in which delay measurements are performed among a subset of 161 its nodes. A network manager might ask whether there is a problem 162 with the network delay in general. It would be desirable to obtain a 163 single value that gives an indication of the overall network delay. 164 Spatial aggregation methods would address this need, and can produce 165 the desired "single figure of merit" asked for, one that may also be 166 useful in trend analysis. 168 The overall value would be calculated from the elementary delay 169 measurements, but it not obvious how: for example, it may not to be 170 reasonable to average all delay measurements, as some paths (e.g. 171 having a higher bandwidth or more important customers) might be 172 considered more critical than others. 174 Metric composition can help to provide, from raw measurement data, 175 some tangible, well-understood and agreed upon information about the 176 service guarantees provided by a network. Such information can be 177 used in the Service Level Agreement/Service Level Specification (SLA/ 178 SLS) contracts between a service provider and its customers. 180 1.1.4. Implications on Measurement Design and Reporting 182 If a network operator can anticipate needing to aggregate or compose 183 overall metrics in the future, it is more efficient to start by 184 considering the tenants of these methods in the measurement design/ 185 sampling plan, and reporting the results. The Summary Statistics of 186 certain metrics are more conducive to composition than others. This 187 figures prominently in the design of measurements and the results 188 reports. 190 2. Purpose and Scope 192 The purpose of this memo is provide a common framework for the 193 various classes of metrics based on composition of primary metrics. 194 The scope is limited to the definitions of metrics that are composed 195 from primary metrics using a deterministic function. Key information 196 about each metric, such as its assumptions under which the 197 relationship holds, and possible sources of error/circumstances where 198 the composition may fail, are included. 200 At this time, the scope of effort is limited to the metrics for 201 packet loss, delay, and delay variation. Composition of packet 202 reordering metrics is considered a research topic, and beyond the 203 scope at the time this memo was prepared. 205 This memo will retain the terminology of the IPPM Framework as much 206 as possible, but will extend the terminology when necessary. 208 3. Description of Metric Types 210 This section defines the various classes of Composition. There are 211 two classes more accurately referred to as aggregation over time and 212 space, and the third is simply composition in space. 214 3.1. Temporal Aggregation Description 216 Aggregation in time is defined as the composition of metrics with the 217 same type and scope obtained in different time instants or time 218 windows. For example, starting from a time series of One-Way Delay 219 measurements on a certain network path obtained in 5-minute periods 220 and averaging groups of 12 consecutive values, we obtain a time 221 series measurement with a coarser resolution (60 minutes). The main 222 reason for doing time aggregation is to reduce the amount of data 223 that has to be stored, and make the visualization/spotting of regular 224 cycles and/or growing or decreasing trends easier. Another useful 225 application is to detect anomalies or abnormal changes in the network 226 characteristics. 228 In RFC 2330, the term "temporal composition" is introduced and 229 differs from temporal aggregation in that it refers to methodologies 230 to predict future metrics on the basis of past observations, 231 exploiting the time correlation that certain metrics can exhibit. We 232 do not consider this type of composition here. 234 >>>>>>>>Comment: Why no forecasting? This was apparently a limit on 235 the Geant2 project, but may not apply here. 237 3.2. Spatial Aggregation Description 239 Aggregation in space is defined as the combination of metrics of the 240 same type and different scope, in order to estimate the overall 241 performance of a larger domain. This combination may involve 242 weighing the contributions of the input metrics. 244 Suppose we want to compose the average One-Way-Delay (OWD) 245 experienced by flows traversing all the Origin-Destination (OD) pairs 246 of a network domain (where the inputs are already metric 247 "statistics"). Since we wish to include the effect of the traffic 248 matrix on the result, it makes sense to weight each metric according 249 to the traffic carried on the corresponding OD pair: 251 OWD_sum=f1*OWD_1+f2*OWD_2+...+fn*OWD_n 253 where fi=load_OD_i/total_load. 255 A simple average OWD across all network OD pairs would not use the 256 traffic weighting. 258 Another example metric that is "aggregated in space", is the maximum 259 edge-to-edge delay across a single domain. Assume that a Service 260 Provider wants to advertise the maximum delay that transit traffic 261 will experience while passing through his/her domain. There can be 262 multiple edge-to-edge paths across a domain, and the Service Provider 263 chooses either to publish a list of delays (each corresponding to a 264 specific edge-to-edge path), or publish a single maximum value. The 265 latter approach simplifies the publication of measurement 266 information, and may be sufficient for some purposes. Similar 267 operations can be provided to other metrics, e.g. "maximum edge-to- 268 edge packet loss", etc. 270 We suggest that space aggregation is generally useful to obtain a 271 summary view of the behaviour of large network portions, or in 272 general of coarser aggregates. The metric collection time instant, 273 i.e. the metric collection time window of measured metrics is not 274 considered in space aggregation. We assume that either it is 275 consistent for all the composed metrics, e.g. compose a set of 276 average delays all referred to the same time window, or the time 277 window of each composed metric does not affect aggregated metric. 279 3.3. Spatial Composition Description 281 Concatenation in space is defined as the composition of metrics of 282 same type and (ideally) different spatial scope, so that the 283 resulting metric is representative of what the metric would be if 284 obtained with a direct measurement over the sequence of the several 285 spatial scopes. An example is the sum of OWDs of different edge-to- 286 edge domain's delays, where the intermediate edge points are close to 287 each other or happen to be the same. In this way, we can for example 288 estimate OWD_AC starting from the knowledge of OWD_AB and OWD_BC. 289 Note that there may be small gaps in measurement coverage, likewise 290 there may be small overlaps (e.g., the link where test equipment 291 connects to the network). 293 One key difference from examples of aggregation in space is that all 294 sub-paths contribute equally to the composed metric, independent of 295 the traffic load present. 297 3.4. Help Metrics 299 Finally, note that in practice there is often the need of extracting 300 a new metric making some computation over one or more metrics with 301 the same spatial and time scope. For example, the composed metric 302 rtt_sample_variance may be composed from two different metrics: the 303 help metric rtt_square_sum and the statistical metric rtt_sum. This 304 operation is however more a simple calculation and not an aggregation 305 or a concatenation, and we'll not investigate it further in this 306 memo. 308 3.5. Higher Order Composition 310 Composed metrics might themselves be subject to further steps of 311 composition or aggregation. An example would be a the delay of a 312 maximal domain obtained through the spatial composition of several 313 composed end-to-end delays (obtained through spatial composition). 314 All requirements for first order composition metrics apply to higher 315 order composition. 317 >>>>> Comment Response: are more examples needed here? 319 4. Requirements for Composed Metrics 320 The definitions for all composed metrics MUST include sections to 321 treat the following topics. 323 The description of each metric will clearly state: 325 1. the definition (and statistic, where appropriate); 327 2. the composition or aggregation relationship; 329 3. the specific conjecture on which the relationship is based; 331 4. a justification of practical utility or usefulness for analysis 332 using the A-frame concepts; 334 5. one or more examples of how the conjecture could be incorrect and 335 lead to inaccuracy; 337 6. the information to be reported. 339 Each metric will require a relationship to determine the aggregated 340 or composed metric. The relationships may involve conjecture, and 341 [RFC2330] lists four points that the metric definitions should 342 include: 344 o the specific conjecture applied to the metric, 346 o a justification of the practical utility of the composition, in 347 terms of making accurate measurements of the metric on the path, 349 o a justification of the usefulness of the aggregation or 350 composition in terms of making analysis of the path using A-frame 351 concepts more effective, and 353 o an analysis of how the conjecture could be incorrect. 355 For each metric, the applicable circumstances are defined, in terms 356 of whether the composition or aggregation: 358 o Requires homogeneity of measurement methodologies, or can allow a 359 degree of flexibility (e.g., active or passive methods produce the 360 "same" metric). Also, the applicable sending streams will be 361 specified, such as Poisson, Periodic, or both. 363 o Needs information or access that will only be available within an 364 operator's domain, or is applicable to Inter-domain composition. 366 o Requires precisely synchronized measurement time intervals in all 367 component metrics, or loosely synchronized, or no timing 368 requirements. 370 o Requires assumption of component metric independence w.r.t. the 371 metric being defined/composed, or other assumptions. 373 o Has known sources of inaccuracy/error, and identifies the sources. 375 5. Guidelines for Defining Composed Metrics 377 5.1. Ground Truth: Comparison with other IPPM Metrics 379 Figure 1 illustrates the process to derive a metric using spatial 380 composition, and compares the composed metric to other IPPM metrics. 382 Metrics describe the performance of sub-paths between 383 the Source and Destination of interest during time interval . 384 These metrics are the inputs for a Composition Function that produces 385 a Composed Metric. 387 Sub-Path Metrics 388 ++ M1 ++ ++ M2 ++ ++ M3 ++ 389 Src ||.......|| ||.......|| ||.......|| Dst 390 ++ `. ++ ++ | ++ ++ .' ++ 391 `. | .-' 392 `-. | .' 393 `._..|.._.' 394 ,-' `-. 395 ,' `. 396 | Composition | 397 \ Function ' 398 `._ _,' 399 `--.....--' 400 | 401 ++ | ++ 402 Src ||...............................|| Dst 403 ++ Composed Metric ++ 405 ++ Complete Path Metric ++ 406 Src ||...............................|| Dst 407 ++ ++ 408 Spatial Metric 409 ++ S1 ++ S2 ++ S3 ++ 410 Src ||........||.........||..........|| Dst 411 ++ ++ ++ ++ 412 Figure 1 Comparison with other IPPM metrics 414 The Composed Metric is an estimate of an actual metric collected over 415 the complete Source to Destination path. We say that the Complete 416 Path Metric represents the "Ground Truth" for the Composed Metric. 417 In other words, Composed Metrics seek to minimize error w.r.t. the 418 Complete Path Metric. 420 Further, we observe that a Spatial Metric I-D.ietf-ippm-multimetrics 421 [I-D.ietf-ippm-multimetrics]collected for packets traveling over the 422 same set of sub-paths provide a basis for the Ground Truth of the 423 individual Sub-Path metrics. We note that mathematical operations 424 may be necessary to isolate the performance of each sub-path. 426 Next, we consider multiparty metrics as defined in [I-D.ietf-ippm- 427 multimetrics], and their spatial composition. Measurements to each 428 of the Receivers produce an element of the one-to-group metric. 429 These elements can be composed from sub-path metrics and the composed 430 metrics can be combined to create a composed one-to-group metric. 431 Figure 2 illustrates this process. 433 Sub-Path Metrics 434 ++ M1 ++ ++ M2 ++ ++ M3 ++ 435 Src ||.......|| ||.......|| ||.......||Rcvr1 436 ++ ++ ++`. ++ ++ ++ 437 `-. 438 M4`.++ ++ M5 ++ 439 || ||.......||Rcvr2 440 ++ ++`. ++ 441 `-. 442 M6`.++ 443 ||Rcvr3 444 ++ 446 One-to-Group Metric 447 ++ ++ ++ ++ 448 Src ||........||.........||..........||Rcvr1 449 ++ ++. ++ ++ 450 `-. 451 `-. ++ ++ 452 `-||..........||Rcvr2 453 ++. ++ 454 `-. 455 `-. ++ 456 `-.||Rcvr3 457 ++ 458 Figure 2 Composition of One-to-Group Metrics 460 Here, Sub-path Metrics M1, M2, and M3 are combined using a 461 relationship to compose the metric applicable to the Src-Rcvr1 path. 462 Similarly, M1, M4, and M5 are used to compose the Src-Rcvr2 metric 463 and M1, M4, and M6 compose the Src-Rcvr3 metric. 465 The Composed One-to-Group Metric would list the Src-Rcvr metrics for 466 each Receiver in the Group: 468 (Composed-Rcvr1, Composed-Rcvr2, Composed-Rcvr3) 470 The "Ground Truth" for this composed metric is of course an actual 471 One-to-Group metric, where a single source packet has been measured 472 after traversing the Complete Paths to the various receivers. 474 5.2. Deviation from the Ground Truth 476 A metric composition can deviate from the ground truth for several 477 reasons. Two main aspects are: 479 o The propagation of the inaccuracies of the underlying measurements 480 when composing the metric. As part of the composition function, 481 errors of measurements might propagate. Where possible, this 482 analysis should be made and included with the description of each 483 metric. 485 o A difference in scope. When concatenating hop-by-hop active 486 measurement results to obtain the end-to-end metric, the actual 487 measured path will not be identical to the end-to-end path. It is 488 in general difficult to quantify this deviation, but a metric 489 definition might identify guidelines for keeping the deviation as 490 small as possible. 492 The description of the metric composition MUST include an section 493 identifying the deviation from the ground truth. 495 6. IANA Considerations 497 This document makes no request of IANA. 499 Note to RFC Editor: this section may be removed on publication as an 500 RFC. 502 7. Security Considerations 504 8. Acknowledgements 506 The authors would like to thank Maurizio Molina, Andy Van Maele, 507 Andreas Haneman, Igor Velimirovic, Andreas Solberg, Athanassios 508 Liakopulos, David Schitz, Nicolas Simar and the Geant2 Project. We 509 also acknowledge comments and suggestions from Phil Chimento, Emile 510 Stephan and Lei Liang. 512 9. References 514 9.1. Normative References 516 [I-D.ietf-ippm-multimetrics] 517 Stephan, E., "IP Performance Metrics (IPPM) for spatial 518 and multicast", draft-ietf-ippm-multimetrics-00 (work in 519 progress), January 2006. 521 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 522 Requirement Levels", BCP 14, RFC 2119, March 1997. 524 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, 525 "Framework for IP Performance Metrics", RFC 2330, 526 May 1998. 528 9.2. Informative References 529 Authors' Addresses 531 Al Morton (editor) 532 AT&T Labs 533 200 Laurel Avenue South 534 Middletown,, NJ 07748 535 USA 537 Phone: +1 732 420 1571 538 Fax: +1 732 368 1192 539 Email: acmorton@att.com 540 URI: http://home.comcast.net/~acmacm/ 542 Steven Van den Berghe (editor) 543 Ghent University - IBBT 544 G. Crommenlaan 8 bus 201 545 Gent 9050 546 Belgium 548 Phone: +32 9 331 49 73 549 Email: steven.vandenberghe@intec.ugent.be 550 URI: http://www.ibcn.intec.ugent.be 552 Intellectual Property Statement 554 The IETF takes no position regarding the validity or scope of any 555 Intellectual Property Rights or other rights that might be claimed to 556 pertain to the implementation or use of the technology described in 557 this document or the extent to which any license under such rights 558 might or might not be available; nor does it represent that it has 559 made any independent effort to identify any such rights. Information 560 on the procedures with respect to rights in RFC documents can be 561 found in BCP 78 and BCP 79. 563 Copies of IPR disclosures made to the IETF Secretariat and any 564 assurances of licenses to be made available, or the result of an 565 attempt made to obtain a general license or permission for the use of 566 such proprietary rights by implementers or users of this 567 specification can be obtained from the IETF on-line IPR repository at 568 http://www.ietf.org/ipr. 570 The IETF invites any interested party to bring to its attention any 571 copyrights, patents or patent applications, or other proprietary 572 rights that may cover technology that may be required to implement 573 this standard. Please address the information to the IETF at 574 ietf-ipr@ietf.org. 576 Disclaimer of Validity 578 This document and the information contained herein are provided on an 579 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 580 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 581 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 582 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 583 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 584 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 586 Copyright Statement 588 Copyright (C) The Internet Society (2006). This document is subject 589 to the rights, licenses and restrictions contained in BCP 78, and 590 except as set forth therein, the authors retain all their rights. 592 Acknowledgment 594 Funding for the RFC Editor function is currently provided by the 595 Internet Society.