idnits 2.17.1 draft-eastlake-trill-rbridge-options-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 and authors 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 28, 2009) is 5323 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) == Outdated reference: A later version (-16) exists of draft-ietf-trill-rbridge-protocol-13 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 TRILL Working Group Donald Eastlake 3rd 2 INTERNET-DRAFT Stellar Switches 3 Intended status: Proposed Standard Anoop Ghanwani 4 Brocade 5 Caitlin Bestler 6 Consultant 7 Expires: March 27, 2009 September 28, 2009 9 RBridges: TRILL Header Options 11 13 Status of This Document 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Distribution of this document is unlimited. Comments should be sent 19 to the TRILL working group mailing list . 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/1id-abstracts.html 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 The TRILL base protocol specification, draft-ietf-trill-rbridge- 40 protocol-13.txt, specifies minimal hooks for options. This draft 41 specifies the format for options and an initial set of options. 43 Table of Contents 45 Status of This Document....................................1 46 Abstract...................................................1 48 1. Introduction............................................3 49 1.1 Conventions used in this document......................3 51 2. TRILL Header Options....................................4 52 2.1 RBridge Option Handling Requirements...................4 53 2.2 No Surprises...........................................5 54 2.3 Options Format.........................................5 55 2.3.1 Bit Options and Summary Bits.........................6 56 2.3.2 TLV Option Format....................................7 57 2.3.3 Marshalling of Options...............................8 59 3. Specific Bit Option.....................................9 60 3.1 ECN Bit Option.........................................9 62 4. Specific TLV Options...................................11 63 4.1 Flow ID TLV Option....................................11 64 4.2 Additional Flags TLV Option...........................12 66 5. Additions to IS-IS.....................................13 67 5.1 Additions to Link State...............................13 68 5.2 Additions to Port Capabilities........................13 70 6. IANA Considerations....................................14 71 7. Security Considerations................................14 73 8. References.............................................15 74 8.1 Normative References..................................15 75 8.2 Informative References................................15 77 Authors' Addresses........................................16 78 Copyright and IPR Provisions..............................17 80 1. Introduction 82 The base TRILL protocol specification, which appears in [Protocol], 83 provides an options feature and describes minimal hooks to safely 84 support that feature. But it does not specify the structure of 85 options nor the details of any particular options. This draft 86 specifies that format and some initial options 88 Section 2 below describes the general principles of operation, 89 format, and ordering of TRILL Header Options. Such options are of two 90 kinds: bit options, and TLV (Type, Length, Value) encoded options. 92 Section 3 describes a specific bit option while Section 4 describes 93 specific TLV encoded options. 95 1.1 Conventions used in this document 97 The terminology and acronyms for [Protocol] are used herein with the 98 same meaning. 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 2. TRILL Header Options 106 The TRILL Protocol includes an option capability in the TRILL Header 107 (see [Protocol] Section 3.5). The 5-bit Op-Length header field gives 108 the length of the options in units of 4 octets, which allows up to 109 124 octets of options area. If Op-Length is zero there are no options 110 present; else, the options follow immediately after the Ingress 111 Rbridge Nickname field in the TRILL Header and each option is 32-bit 112 aligned. 114 As described below, provision is made for both hop-by-hop options, 115 which could affect any RBridge which received a TRILL frame, and 116 ingress-to-egress options, which would only necessarily affect the 117 RBridge(s) where a TRILL frame is decapsulated. Provision is also 118 made for both "critical" and "non-critical" options. An RBridge 119 receiving a frame with a critical option that might affect it and 120 that it does not understand MUST discard the frame as it is unsafe to 121 process the frame without understanding the option. Non-critical 122 options can be safely ignored. 124 Options also indicate whether the value associated with them can 125 change (mutable options) or not (immutable options). For example, an 126 ingress-to-egress security option could protect the value of an 127 immutable ingress-to-egress option. But such a security option 128 generally could not protect a mutable value as a transit RBridge 129 could change that value but would not, in general, have the keys to 130 recompute a signature or authentication code to take a changed value 131 into account. 133 Note: Most RBridges implementations are expected to be optimized 134 for simple and common cases of frame forwarding and processing. 135 Although the hard limit on options length, their 32-bit alignment, 136 and the presence of critical option summary bits as described 137 below, are intended assist in options processing, nevertheless the 138 inclusion of options may cause frame processing using a "slow 139 path" with inferior performance to "fast path" processing. Limited 140 slow path throughput of such frames could cause them to be 141 discarded. 143 2.1 RBridge Option Handling Requirements 145 The requirements given in this section are in addition to all option 146 handling requirements in [Protocol]. 148 All Rbridges MUST be able to detect whether there are any critical 149 options present that are applicable to their processing of the frame 150 as detailed below. If they do not implement all such options 151 present, they MUST discard the frame. 153 Transit RBridges MUST transparently forward all immutable ingress-to- 154 egress options in frames that they forward. Any changes made by a 155 transit RBridge to a mutable ingress-to-egress option value MUST be a 156 change permitted by the specification of that option. 158 In addition, a transit RBridge: 160 o MAY add, if space is available, or remove, hop-by-hop options as 161 specified for that option; 162 o MAY change the value and/or length of a mutable option as 163 permitted by that option's specification (provided there is enough 164 room if lengthening the option); 165 o MUST adjust the length of the options area, including changing Op- 166 Length in the TRILL header as appropriate for any changes it has 167 made in the options; 168 o MUST NOT add or remove an ingress-to-egress option. 169 o with regard to any non-critical hop-by-hop options that the 170 transit RBridge does not understand, it MAY remove them if they 171 are mutable but MUST transparently copy them when forwarding a 172 frame if they are immutable. 174 2.2 No Surprises 176 RBridges advertise the ingress-to-egress options that they support in 177 the core TRILL IS-IS instance and advertise the hop-by-hop options 178 they support in Hellos they send. An RBridge is not required to 179 support any options. 181 Unless an RBridge advertises support for a critical option, it would 182 not normally receive frames with that option except due to errors or 183 transient conditions. 185 An RBridge SHOULD NOT add a critical option to a frame unless, 186 - for a critical hop-by-hop option, it has determined that the next 187 hop RBridge or RBridges to which the frame will be sent support 188 that option, or 189 - for a critical ingress-to-egress option, it has determined that 190 the RBridge or RBridges that will receive the frame with the 191 option and egress it support that option. 193 2.3 Options Format 195 If any options are present in a TRILL header, as indicated by a non- 196 zero Op-Length field, the first four octets of the options area 197 consist of two summary bits and 30 option bits as described below. 198 The remainder of the options area consists of TLV (Type Length Value) 199 encoded options aligned on 32-bit boundaries. Section 2.3.2 specifies 200 the format of an individual TLV option. Section 2.3.3 describes the 201 marshalling of TLV options. 203 2.3.1 Bit Options and Summary Bits 205 | 0 1 2 3 4 5 6 7| 8 - 15|16 - 23|24 - 31| 206 +------+------+--+--+--+--+--+--+-------+-------+-------+ 207 | CHbH | CItE | | | | | 208 +------+------+--+--+--+--+--+--+-------+-------+-------+ 210 Figure 1: Options Area Initial Four Octets 212 The top two bits of the options area, bits 0 and 1 above, are called 213 summary bits and summarize the presence of critical options. The 214 following summary bit description text is copied from [Protocol] for 215 convenience: 217 If the CHbH (Critical Hop by Hop) bit is one, one or more critical 218 hop-by-hop options are present so transit RBridges that support no 219 options MUST drop the frame. If the CHbH bit is zero, the frame is 220 safe, from the point of view of options processing, for a transit 221 RBridge to forward, even if the forwarding RBridge doesn't 222 understand any options. A transit RBridge that supports no options 223 and forwards a frame MUST transparently forward the options area. 225 If the CItE (Critical Ingress to Egress) bit is a one, one or more 226 critical ingress-to-egress options are present. If it is zero, no 227 such options are present. If either CHbH or CItE is non-zero, 228 egress RBridges that don't support any options MUST drop the 229 frame. If both CHbH and CItE are zero, the frame is safe, from 230 the point of view of options, for any egress RBridge to process, 231 even if it doesn't understand any options. 233 The remaining 30 bits in the initial four octets of the options area 234 are available for bit-encoded options. Any RBridge adding an options 235 area to a TRILL Header must set these 30 bits to zero except when 236 permitted to set one or more by an option that RBridge understands. 237 The 30 bits are categorized as follows: 239 Bits Category 240 --------------------- 241 2- 7 Critical hop-by-hop 242 8-15 Non-critical hop-by-hop 243 16-23 Critical ingress-to-egress 244 24-31 Non-critical ingress-to-egress 246 Any transit RBridge must transparently copy bits 2-31 except as 247 permitted by an option implemented by that RBridge. Even if a transit 248 RBridge removes all TLV options from a TRILL Header, it MUST NOT 249 eliminate the options area in a forwarded frame if any of these 30 250 bits is non-zero. 252 2.3.2 TLV Option Format 254 TRILL Header options, other than bit options described above, are TLV 255 encoded, with some flag bits in the Type and Length octets, in the 256 format show in Figure 2. 258 | 0 1 2 3 4 5 6 7| 8| 9-15 | 259 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- 260 |IE|NC| Type |MT| Length | value... 261 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--- 263 Figure 2. Option TLV Structure 265 The highest order bit of the first octet (IE) is zero for hop-by-hop 266 options and one for ingress-to-egress options. Hop-by-hop options 267 are potentially applicable to every RBridge that receives the frame. 268 Ingress-to-egress options are only added at the ingress RBridge and 269 are potentially applicable only at egress RBridges. Ingress-to-egress 270 options MAY also be examined and acted upon by transit RBridges as 271 specified in the particular option. 273 The next to highest order bit of the first octet (NC) is zero for 274 critical options and one for non-critical options. 276 The highest order bit of the second octet (MT) is zero for options 277 with immutable values, that is where the value and Length will not 278 change. It is one for such options that have a mutable value. The IE, 279 NC, Type, and MT fields themselves are always immutable. 281 The bottom six bits of the first octet give the option Type code. The 282 option Type may constrain the values of the IE, NC, and MT bits. For 283 example, if the Type indicates a Flow ID option, then it MUST be 284 marked as a hop-by-hop, non-critical, mutable option. If the IE, NC, 285 or MT bits have a value not permitted by the option Type 286 specification for an option that an RBridge would otherwise act on, 287 the RBridge MUST discard the frame. 289 The Length field is an unsigned quantity giving the length of the 290 option value in octets. It gives the amount of option value data, if 291 any, beyond the initial two Type and Length octets. The Length field 292 MUST NOT be such that the option value extends beyond the end of the 293 total options area as specified by the TRILL Header Op-Length. Thus, 294 the value of Length can vary from zero to 120. The meaning of 295 "Length" values of 121 through 127 is reserved and, when such values 296 are noticed in a frame, the frame MUST be discarded. 298 2.3.3 Marshalling of Options 300 In a TRILL Header with options, those options start immediately after 301 the Ingress RBridge Nickname and completely fill the options area. 303 TLV options start immediately after the initial four octets of option 304 and summary bits and MUST appear in ascending order by the value of 305 their first octet considered as an unsigned 8-bit integer. As a 306 result, all hop-by-hop options MUST be placed before all ingress-to- 307 egress options and, within each of those two categories, all critical 308 options MUST appear before all non-critical options. A particular 309 option first octet value MUST NOT appear more than once in a TRILL 310 Header. Frames that violate this paragraph are erroneous, will 311 produce unspecified results, and MAY be discarded. ("MAY" is chosen 312 to minimize the format checking burden required of transit RBridges.) 314 Options are 32-bit aligned. Should an option not consist of a 315 multiple of four octets, the option is padded at the end up to the 316 next multiple of four octets with octets that MUST be zero. 318 If any options are present, those options, both flag and TLV, MUST be 319 correctly summarized into the CHbH and CItE bits at the top of the 320 initial two octets of the options area. 322 3. Specific Bit Option 324 The table below shows the state of TRILL Header bit option 325 assignments. See Section 6 for IANA Considerations. 327 Bit Purpose Section 328 ----------------------------------- 329 0-1 Summary 2.3 330 2-7 available for critical hop-by-hop options 331 8-9 ECN 3.1 332 10-15 available for non-critical hop-by-hop options 333 16-23 available for critical ingress-to-egress options 334 24-31 available for non-critical ingress-to-egress options 336 Table 1. Flag Options 338 3.1 ECN Bit Option 340 RBridges may implement an ECN (Explicit Congestion Notification) 341 option [RFC3168]. If implemented, it SHOULD be enabled by default but 342 can be disable on a per RBridge basis by configuration. 344 RBridges that do not implement this option or on which it is disabled 345 simply (1) set bits 8 and 9 of the bit options area zero when they 346 add an options area to a TRILL Header and (2) transparently copy 347 those bits, if an options area is present, when they forward a frame 348 with a TRILL Header. 350 An RBridge that implements the ECN option does the following when 351 that option is enabled: 353 o When ingressing an IP frame that is ECN enabled, it MUST add an 354 options area to the TRILL Header and copy the two ECN bits from 355 the IP header into option bits 8 and 9. 356 o When ingressing a frame for a non-IP protocol with a means of 357 indicating ECN that is understood by the RBridge, it MAY add an 358 options are to the TRILL Header with the ECN bits set from the 359 ingressed frame. 360 o When forwarding a frame encountering congestion at an RBridge, if 361 an options area is present with option bits 8 and 9 indicate ECN- 362 capable transport, the RBridge MUST modify them to the congestion 363 experienced value. 364 o When egressing an IP frame, if the TRILL Header has an options 365 area with option bits 8 and 9 non-zero, it copies those bits into 366 the ECN bits in the IP header. 367 o When egressing a non-IP protocol frame with a means of indicating 368 ECN that is understood by the RBridge, it MAY transfer the ECN 369 information from the ECN bits in the options area to the egressed 370 native frame. 372 The following table is modified from [RFC3168] and shows the meaning 373 of bit values in TRILL Header option bits 8 and 9, bits 6 and 7 in 374 the IPv4 TOS Byte, and bits 6 and 7 in the IPv6 Traffic Class Octet: 376 Binary Meaning 377 ------ ------- 378 00 Not-ECT (Not ECN-Capable Transport) 379 01 ECT(1) (ECN-Capable Transport(1)) 380 10 ECT(0) (ECN-Capable Transport(0)) 381 11 CE (Congestion Experienced) 383 Table 2. ECN Bit Combinations 385 An RBridge detects congestion either by monitoring its own queue 386 depths or from participation in a link-specific protocol. An RBridge 387 implementing the ECN option MAY be configured to add congestion 388 experienced marking using ECN to any frame with a TRILL Header that 389 encounters congestion even if the frame was not previously marked as 390 ECN-capable. 392 4. Specific TLV Options 394 The table below shows the state of TRILL Header TLV option Type 395 assignment. See Section 6 for IANA Considerations. 397 Type Purpose Section 398 ----------------------------------------- 399 0x00 reserved 400 0x01-0x07 available 401 0x08 Flow ID 4.1 402 0x09-0x3B available 403 0x3C Additional Flags 4.2 404 0x39-0x3E available 405 0x3F reserved 407 Table 3. TLV Option Types 409 The following subsections specify particular TRILL TLV options. 411 4.1 Flow ID TLV Option 413 In connection with multi-pathing of frames, frames that are part of 414 the same order dependent flow need to follow the same path for 415 correct performance. Methods to determine flows are beyond the scope 416 of the TRILL standard; however, it may be useful, once the flow of a 417 frame has been determined, to preserve and transmit that information 418 for use by subsequent RBridges. 420 This is a non-critical option. It is considered hop-by-hop because it 421 can be added by a transit RBridge and can be used by transit RBridges 422 to make forwarding decisions. Because the ingress RBridge may know 423 the most about a frame, it is expected that this option would most 424 commonly be added at the ingress RBridge. Once in a frame, the option 425 SHOULD NOT be removed or changed unless, for example, a campus is 426 divided into regions such that different flow IDs would make sense in 427 different regions. 429 The value length of this option is fixed for efficiency. Since 2 430 octets might be insufficient for some purposes, the length is set at 431 six, the next size fitting evenly into the 32-bit alignment of 432 options. Should there be less than 6 octets of significance to the 433 flow ID, the value SHOULD be right justified by prefixing zero 434 octets. If an RBridge is incapable of using all six octets for flow 435 ID purposes, it SHOULD use a smaller number of lower order octets 436 from the value. 438 The option fields and flags are as follows: 440 o Type is 0x08. 441 o Length is 6. The data is an unsigned integer that is the flow 442 ID. If there are less than six value octets of significance, 443 they SHOULD be right justified by prefixing zero octets. 444 o IE MUST be zero. This is a hop-by-hop option. 445 o NC and MT MUST be one. This is a non-critical mutable option. 447 4.2 Additional Flags TLV Option 449 The option provides a means of adding a variety of additional flags 450 to the TRILL Header beyond the bit options available in the first 451 four octets of the options area. 453 The value of the flags option consists of additional flags, eight per 454 octet, numbered from the high-order to the low-order bit. Thus flag 1 455 is the 0x80 bit of the first octet, flag 8 is the 0x01 bit of that 456 octet, flag 9 is the 0x80 bit of the second octet, etc. The number of 457 additional flags that can be defined is bounded only by the options 458 space that can be available. All flags not present, because they 459 would be in value octets beyond those specified by the option Length, 460 are considered zero. 462 This option can appear up to four times in a frame to provide 463 independent sets of all combinations of ingress-to-egress, hop-by- 464 hop, non-critical, and critical flags. To simplify canonicalization 465 for security, this option MUST NOT be included if all of the flag 466 bits would be zero and the value MUST NOT have any trailing zero 467 octets. Thus its Length MUST be at least 1 and at least the last 468 octet of the value present MUST be non-zero. 470 The option fields and flags are as follows: 472 o Type is 0x3C. 473 o Length is variable with a minimum value of 1. 474 o IE and NC are variable producing, in effect, four versions of 475 this option. 476 o MT MUST be zero. This is an immutable option. 478 5. Additions to IS-IS 480 RBridges use IS-IS PDUs to inform other RBridges which options they 481 support. The specific IS-IS TLVs or sub-TLVs used to encode this 482 information are specified in a separate document. 484 5.1 Additions to Link State 486 Rbridges indicate in their link state which ingress-to-egress TLV and 487 bit options they support. In addition, if they support the ingress- 488 to-egress Additional Flags TLV option, they indicate which critical 489 ingress-to-egress Additional Flags TLV option flags they support, if 490 any. 492 5.2 Additions to Port Capabilities 494 Rbridges indicate in their Hellos which hop-by-hop TLV and bit 495 options they support. In addition, if they support the Additional 496 Flags TLV option, they indicate which critical hop-by-hop Additional 497 Flags TLV option flags they support. 499 6. IANA Considerations 501 IANA will create two subregistries within the TRILL registry. A 502 "TRILL Header Bit Options" subregistry that is initially populated as 503 specified in Table 1 in Section 3. And a "TRILL TLV Option Types" 504 subregistry that is initially populated as specified in Table 3 in 505 Section 4. References in both of those tables to sections of this 506 document are to be replaced in the IANA subregistries by references 507 to this document as an RFC. 509 New TRILL bit options and TLV option types are allocated by IETF 510 Review [RFC5226]. 512 IANA will create a third subregistry within the TRILL registry for 513 flags in the four variations of the Additional Flags TLV option (the 514 four combinations of critical and non-critical, ingress-to-egress and 515 hop-by-hop) which is initially empty. Such flags are allocated by RFC 516 Publication if the RFC allocates no more than three bits, which may 517 be a mixture of the four types, or by IETF Review for any number of 518 bits [RFC5226]. 520 7. Security Considerations 522 For general TRILL protocol security considerations, see [Protocol]. 524 RBridges should not trust that the options that appear in a TRILL 525 header reflect the intent of the previous or earlier hop RBridges, 526 including the ingress RBridge, unless the option is appropriately 527 secured. For example, through inclusion of a TRILL authentication 528 option, which may be specified in another document. 530 In order to facilitate authentication, options SHOULD be specified so 531 they do not have alternative equivalent forms. Authentication of 532 anything with alternative equivalent forms almost always requires 533 canonicalization which an authenticating RBridge ignorant of the 534 option would be unable to do. 536 8. References 538 8.1 Normative References 540 [Protocol] - Perlman, R., D. Eastlake, D. Dutt, S. Gai, and A. 541 Ghanwani, "RBridges: Base Protocol Specification", draft-ietf- 542 trill-rbridge-protocol-13.txt, work in progress. 544 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 545 Requirement Levels", BCP 14, RFC 2119, March 1997. 547 [RFC3168] - Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 548 of Explicit Congestion Notification (ECN) to IP", RFC 3168, 549 September 2001. 551 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 552 IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 554 8.2 Informative References 556 None at this time. 558 Authors' Addresses 560 Donald E. Eastlake 3rd 561 Stellar Switches 562 155 Beaver Street 563 Milford, MA 01757 565 tel: +1-508-634-2066 566 email: d3e3e3@gmail.com 568 Anoop Ghanwani 569 Brocade Communications Systems 570 1745 Technology Drive 571 San Jose, CA 95110 USA 573 Phone: +1-408-333-7149 574 Email: anoop@brocade.com 576 Caitlin Bestler 577 Consultant 578 555 E. El Camino Real #104 579 Sunnyvale, CA 94087 581 tel: +1-949-528-3085 582 email: cait@asomi.com 584 Copyright and IPR Provisions 586 Copyright (c) 2009 IETF Trust and the persons identified as the 587 document authors. All rights reserved. 589 This document is subject to BCP 78 and the IETF Trust's Legal 590 Provisions Relating to IETF Documents in effect on the date of 591 publication of this document (http://trustee.ietf.org/license-info). 592 Please review these documents carefully, as they describe your rights 593 and restrictions with respect to this document. 595 The definitive version of an IETF Document is that published by, or 596 under the auspices of, the IETF. Versions of IETF Documents that are 597 published by third parties, including those that are translated into 598 other languages, should not be considered to be definitive versions 599 of IETF Documents. The definitive version of these Legal Provisions 600 is that published by, or under the auspices of, the IETF. Versions of 601 these Legal Provisions that are published by third parties, including 602 those that are translated into other languages, should not be 603 considered to be definitive versions of these Legal Provisions. For 604 the avoidance of doubt, each Contributor to the IETF Standards 605 Process licenses each Contribution that he or she makes as part of 606 the IETF Standards Process to the IETF Trust pursuant to the 607 provisions of RFC 5378. No language to the contrary, or terms, 608 conditions or rights that differ from or are inconsistent with the 609 rights and licenses granted under RFC 5378, shall have any effect and 610 shall be null and void, whether published or posted by such 611 Contributor, or included with or in such Contribution.