idnits 2.17.00 (12 Aug 2021) /tmp/idnits51712/draft-morton-ippm-twamp-reflect-padding-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 482. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 493. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 500. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 506. 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 (July 6, 2008) is 5060 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: '0-31' is mentioned on line 378, but not defined == Unused Reference: 'RFC2434' is defined on line 432, but no explicit reference was found in the text == Outdated reference: draft-ietf-ippm-twamp has been published as RFC 5357 == Outdated reference: A later version (-02) exists of draft-morton-ippm-more-twamp-00 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Morton 3 Internet-Draft L. Ciavattone 4 Intended status: Standards Track AT&T Labs 5 Expires: January 7, 2009 July 6, 2008 7 TWAMP Reflect Padding Feature 8 draft-morton-ippm-twamp-reflect-padding-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 7, 2009. 35 Abstract 37 The IETF is completing its work on TWAMP - the Two-Way Active 38 Measurement Protocol. This memo describes a proposed feature for 39 TWAMP, intended for discussion in the IP Performance Metrics WG. The 40 feature gives the reflector the ability to return some of the packet 41 padding bits to the sender. 43 Requirements Language 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 47 document are to be interpreted as described in RFC 2119 [RFC2119]. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Purpose and Scope . . . . . . . . . . . . . . . . . . . . . . 3 53 3. TWAMP Control Extensions . . . . . . . . . . . . . . . . . . . 3 54 3.1. Connection Setup with Reflect Padding Feature . . . . . . 4 55 3.2. Request-TW-Session Packet Format . . . . . . . . . . . . . 5 56 3.3. Accept Session Packet Format . . . . . . . . . . . . . . . 5 57 3.4. Additional considerations . . . . . . . . . . . . . . . . 6 58 4. Extended TWAMP Test . . . . . . . . . . . . . . . . . . . . . 6 59 4.1. Sender Behavior . . . . . . . . . . . . . . . . . . . . . 7 60 4.1.1. Packet Timings . . . . . . . . . . . . . . . . . . . . 7 61 4.1.2. Packet Format and Content . . . . . . . . . . . . . . 7 62 4.2. Reflector Behavior . . . . . . . . . . . . . . . . . . . . 8 63 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6.1. Registry Specification . . . . . . . . . . . . . . . . . . 9 66 6.2. Registry Management . . . . . . . . . . . . . . . . . . . 9 67 6.3. Experimental Numbers . . . . . . . . . . . . . . . . . . . 9 68 6.4. Registry Contents . . . . . . . . . . . . . . . . . . . . 9 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 72 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 74 Intellectual Property and Copyright Statements . . . . . . . . . . 12 76 1. Introduction 78 The IETF is completing its work on TWAMP - the Two-Way Active 79 Measurement Protocol [I-D.ietf-ippm-twamp], which is an extension to 80 the One-way Active Measurement Protocol, OWAMP [RFC4656]. 82 This memo describes a new proposed feature for TWAMP, so it can be 83 discussed and interest to take-up the feature assessed. This feature 84 adds the capability for the Session-Reflector to return a limited 85 number of unassigned (padding) bits to the Server/Session-Sender. 86 With this capability, the Control-Client/Session-Sender can 87 information it deems useful and have the assurance that the 88 corresponding test packet will contain the information when it is 89 returned. 91 The relationship between this memo and TWAMP is intended to be an 92 update to the TWAMP RFC when published. 94 2. Purpose and Scope 96 The purpose of this memo is to describe an additional function and 97 feature for TWAMP [I-D.ietf-ippm-twamp]. The feature needs a clear 98 description so it can be discussed and (hopefully) adopted in the IP 99 Performance Metrics Charter. 101 The scope of the memo is currently limited to specifications of the 102 following feature: 104 1. Extension of the modes of operation through assignment of new 105 values in the Mode field (see section 3.1 of [RFC4656]), while 106 retaining backward compatibility with TWAMP [I-D.ietf-ippm-twamp] 107 implementations. These values identify the ability of the 108 Server/Session-Reflector to reflect specific octets of Packet 109 Padding back to the Client/Sender. The motivation for this 110 extension is to permit the Sender to tag packets with a index for 111 simplified identification, or other uses. 113 (other items may be added) 115 When new features are discussed and reach consensus, they may become 116 chartered work items in IETF IPPM (and may appear in a different 117 memo). 119 3. TWAMP Control Extensions 121 TWAMP-Control protocol is a derivative of the OWAMP-Control protocol, 122 and provides two-way measurement capability. TWAMP 123 [I-D.ietf-ippm-twamp] uses the Mode field to identify and select 124 specific communication capabilities, and this field is a recognized 125 extension mechanism. The following sections describe one such 126 extension. 128 3.1. Connection Setup with Reflect Padding Feature 130 TWAMP connection establishment follows the procedure defined in 131 section 3.1 of [RFC4656]. The Reflect Padding feature requires two 132 new bit positions (and values) to identify the ability of the Server/ 133 Session-Reflector to reflect specific octets of Packet Padding back 134 to the Client/Sender. With this added feature, the complete set of 135 TWAMP mode values would be as follows: 137 Value Description Reference/Explanation 138 0 Reserved 139 1 Unauthenticated RFC4656, Section 3.1 140 2 Authenticated RFC4656, Section 3.1 141 4 Encrypted RFC4656, Section 3.1 142 8 Unauth. TEST protocol, draft-...-more-twamp (3) 143 Auth. CONTROL 144 16 Unauth. TEST protocol, draft-...-more-twamp (4) 145 Encrypted CONTROL 146 32 Auth. TEST protocol, draft-...-more-twamp (5) 147 Encrypted CONTROL 148 -------------------------------------------------------- 149 xx Reflect Padding new bit position (X) 150 Capability 151 yyy Reflect & Operate new bit position (Y) 152 on Padding Bits 154 In the original OWAMP mode field, setting bit positions 0, 1 or 2 155 indicated the security mode of the Control protocol, and the Test 156 protocol inherited the same mode (see section 4 of [RFC4656]). In 157 the [I-D.morton-ippm-more-twamp] bit positions (3, 4 or 5) 158 discontinue the inheritance of the security mode in the Test 159 protocol. 161 The Server sets one or both of the new bit positions (possibly 6 162 and/or 7) in the Server Greeting message to indicate its capabilities 163 and willingness to operate in these modes if desired. 165 If the Control-Client intends to operate all test sessions under this 166 control connection using one of the new modes, it MUST set one of 167 mode bits corresponding to that mode in the Setup Response message. 169 3.2. Request-TW-Session Packet Format 171 The bits designated for the Reflect Padding feature in the Request- 172 TW-Session command are as shown in the packet format below. 174 0 1 2 3 175 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | 5 | MBZ | IPVN | Conf-Sender | Conf-Receiver | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Number of Schedule Slots | 180 . 181 . ... Many fields not shown ... 182 . 183 | | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Type-P Descriptor | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Padding (to be reflected) | MBZ (2 octets) | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | MBZ (4 octets) | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | | 192 | HMAC (16 octets) | 193 | | 194 | | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 The "Packet Padding (to be reflected)" field SHALL be 2 octets long, 198 as shown. 200 3.3. Accept Session Packet Format 202 The bits designated for the Reflect Padding feature in the Accept 203 Session command are as shown in the packet format below. 205 0 1 2 3 206 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Accept | MBZ | Port | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| 210 | | 211 | SID (16 octets) | 212 | | 213 | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Padding (to be reflected) | MBZ (2 octets) | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | MBZ (8 octets) | 218 | | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | | 221 | HMAC (16 octets) | 222 | | 223 | | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 The "Packet Padding (to be reflected)" field SHALL be 2 octets long, 227 as shown. 229 3.4. Additional considerations 231 The value of the Modes field sent by the Server (in the Server 232 Greeting message) is the bit-wise OR of the mode values that it is 233 willing to support during this session. 235 If BOTH the above modes are adopted, the last eight bits of the Modes 236 32-bit field are used. The first 24 bits MUST be zero. A client 237 conforming to this version of the specification MUST ignore the 238 values in the first 24 bits of the Modes value. (This way, the bits 239 are available for future protocol extensions.) 241 Other ways in which TWAMP extends OWAMP are described in 242 [I-D.ietf-ippm-twamp]. 244 4. Extended TWAMP Test 246 The TWAMP test protocol is similar to the OWAMP [RFC4656] test 247 protocol with the exception that the Session-Reflector transmits test 248 packets to the Session-Sender in response to each test packet it 249 receives. TWAMP [I-D.ietf-ippm-twamp] section 4 defines two 250 additional test packet formats for packets transmitted by the 251 Session-Reflector. The appropriate format depends on the security 252 mode chosen. This feature utilizes some of the bits within each test 253 packet format. 255 4.1. Sender Behavior 257 This section describes extensions to the behavior of the TWAMP 258 Session-Sender. 260 4.1.1. Packet Timings 262 The Send Schedule is not utilized in TWAMP, and this is unchanged in 263 this memo. 265 4.1.2. Packet Format and Content 267 The Session-Sender packet format and content follow the same 268 procedure and guidelines as defined in section 4.1.2 of [RFC4656] (as 269 indicated in section 4.1.2 of TWAMP [I-D.ietf-ippm-twamp]). 271 The Reflect Padding feature re-designates the packet padding field, 272 as shown below for unauthenticated mode: 274 0 1 2 3 275 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Sequence Number | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Timestamp | 280 | | 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | Error Estimate | MBZ | 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 | MBZ | Length (2 oct) | Ext ID | 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | | 287 | Packet Padding (to be reflected) | 288 | | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Additional Packet Padding | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 The "Packet Padding (to be reflected)" field MAY be as long as 12 294 octets, as shown. IF the test packet length is truncated within this 295 field, THEN ALL packet padding MUST be reflected by Session- 296 Reflectors using this feature. 298 4.2. Reflector Behavior 300 The TWAMP Reflector follows the procedures and guidelines in section 301 4.2 of [I-D.ietf-ippm-twamp], with the following additional 302 functions: 304 o bits in the packet padding field of the Session-Sender's test 305 packet MUST be inserted in the Session-Reflector's test packet. 307 The Reflect Padding feature re-designates the packet padding field, 308 as shown below for unauthenticated mode: 310 0 1 2 3 311 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Sequence Number | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Timestamp | 316 | | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Error Estimate | MBZ | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Receive Timestamp | 321 | | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Sender Sequence Number | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Sender Timestamp | 326 | | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Sender Error Estimate | MBZ | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Sender TTL | Length (2 oct) | Ext ID | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 | Packet Padding (from Session-Sender) | 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Additional Packet Padding | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 The "Packet Padding (to be reflected)" field MAY be as long as 12 340 octets, as shown. IF the test packet length is truncated within this 341 field, THEN ALL packet padding MUST be reflected by Session- 342 Reflectors using this feature. 344 5. Security Considerations 346 These extended modes of operation permit stronger integrity 347 protection on the TWAMP-Control protocol while simultaneously 348 emphasizing accuracy or efficiency on the TWAMP-Test protocol, thus 349 enhancing overall security when compared to the previous options. 351 The security considerations that apply to any active measurement of 352 live networks are relevant here as well. See [RFC4656] and 353 [I-D.ietf-ippm-twamp]. 355 6. IANA Considerations 357 This memo adds two mode combinations to the IANA registry for the 358 TWAMP Mode field, and describes behavior when the new modes are used. 359 This field is a recognized extension mechanism for TWAMP. 361 6.1. Registry Specification 363 IANA has created a TWAMP-Modes registry (as requested in 364 [I-D.morton-ippm-more-twamp]). TWAMP-Modes are specified in TWAMP 365 Server Greeting messages and Set-up Response messages, as described 366 in section 3.1 of [I-D.ietf-ippm-twamp], consistent with section 3.1 367 of [RFC4656], and extended by this memo. Modes are indicated by 368 setting bits in the 32-bit Modes field. Thus, this registry can 369 contain a total of 32 possible values. 371 6.2. Registry Management 373 Because the Modes registry can contain only thirty-two values, and 374 because TWAMP is an IETF protocol, this registry must be updated only 375 by "IETF Consensus" as specified in [RFC2434](an RFC documenting 376 registry use that is approved by the IESG). For the Modes registry, 377 we expect that new features will be assigned using monotonically 378 increasing bit positions and in the range [0-31] and the 379 corresponding values, unless there is a good reason to do otherwise. 381 6.3. Experimental Numbers 383 No experimental values are currently assigned for the Modes Registry. 385 6.4. Registry Contents 387 TWAMP Modes Registry is recommended to be augmented as follows: 389 Value Description Semantics Definition 390 0 Reserved 392 1 Unauthenticated RFC4656, Section 3.1 394 2 Authenticated RFC4656, Section 3.1 396 4 Encrypted RFC4656, Section 3.1 398 8 Unauth. TEST protocol, draft-...-more-twamp (3) 399 Auth. CONTROL 400 16 Unauth. TEST protocol, draft-...-more-twamp (4) 401 Encrypted CONTROL 402 32 Auth. TEST protocol, draft-...-more-twamp (5) 403 Encrypted CONTROL 404 -------------------------------------------------------- 405 xx Reflect Padding this memo, section 3.1 406 Capability new bit position (X) 407 yyy Reflect & Operate this memo, section 3.1 408 on Padding Bits new bit position (Y) 410 7. Acknowledgements 412 The authors would like to thank future readers for helpful review and 413 comments. 415 8. References 417 8.1. Normative References 419 [I-D.ietf-ippm-twamp] 420 Babiarz, J., "A Two-way Active Measurement Protocol 421 (TWAMP)", draft-ietf-ippm-twamp-08 (work in progress), 422 June 2008. 424 [I-D.morton-ippm-more-twamp] 425 Morton, A. and K. Hedayat, "More Features for TWAMP", 426 draft-morton-ippm-more-twamp-00 (work in progress), 427 February 2008. 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, March 1997. 432 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 433 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 434 October 1998. 436 [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. 437 Zekauskas, "A One-way Active Measurement Protocol 438 (OWAMP)", RFC 4656, September 2006. 440 8.2. Informative References 442 [x] "". 444 Authors' Addresses 446 Al Morton 447 AT&T Labs 448 200 Laurel Avenue South 449 Middletown,, NJ 07748 450 USA 452 Phone: +1 732 420 1571 453 Fax: +1 732 368 1192 454 Email: acmorton@att.com 455 URI: http://home.comcast.net/~acmacm/ 457 Len Ciavattone 458 AT&T Labs 459 200 Laurel Avenue South 460 Middletown,, NJ 07748 461 USA 463 Phone: +1 732 420 1239 464 Fax: 465 Email: lencia@att.com 466 URI: 468 Full Copyright Statement 470 Copyright (C) The IETF Trust (2008). 472 This document is subject to the rights, licenses and restrictions 473 contained in BCP 78, and except as set forth therein, the authors 474 retain all their rights. 476 This document and the information contained herein are provided on an 477 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 478 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 479 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 480 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 481 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 482 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 484 Intellectual Property 486 The IETF takes no position regarding the validity or scope of any 487 Intellectual Property Rights or other rights that might be claimed to 488 pertain to the implementation or use of the technology described in 489 this document or the extent to which any license under such rights 490 might or might not be available; nor does it represent that it has 491 made any independent effort to identify any such rights. Information 492 on the procedures with respect to rights in RFC documents can be 493 found in BCP 78 and BCP 79. 495 Copies of IPR disclosures made to the IETF Secretariat and any 496 assurances of licenses to be made available, or the result of an 497 attempt made to obtain a general license or permission for the use of 498 such proprietary rights by implementers or users of this 499 specification can be obtained from the IETF on-line IPR repository at 500 http://www.ietf.org/ipr. 502 The IETF invites any interested party to bring to its attention any 503 copyrights, patents or patent applications, or other proprietary 504 rights that may cover technology that may be required to implement 505 this standard. Please address the information to the IETF at 506 ietf-ipr@ietf.org.