idnits 2.17.1 draft-eastlake-trill-ia-appsubtlv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (July 15, 2013) is 3935 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) ** Obsolete normative reference: RFC 5342 (Obsoleted by RFC 7042) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Donald Eastlake 2 Intended status: Proposed Standard Yizhou Li 3 Huawei 4 Radia Perlman 5 Intel 6 Expires: January 14, 2014 July 15, 2013 8 TRILL: Interface Addresses APPsub-TLV 9 11 Abstract 12 This document specifies a TRILL (Transparent Interconnection of Lots 13 of Links) IS-IS application sub-TLV that enables the reporting by a 14 TRILL switch sets of addresses such that all of the addresses in each 15 set designate the same interface (port). For example, an EUI-48 MAC 16 (Extended Unique Identifier 48-bit, Media Access Control) address, 17 IPv4 address, and IPv6 address can be reported as all corresponding 18 to the same interface. Such information could be used, for example, 19 to synthesize responses to or by-pass the need for the Address 20 Resolution Protocol (ARP), the IPv6 Neighbor Discovery (ND) protocol, 21 of the flooding of unknown MAC addresses, in some cases. 23 Status of This Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Distribution of this document is unlimited. Comments should be sent 29 to the TRILL working group mailing list. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/1id-abstracts.html. The list of Internet-Draft 43 Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Table of Contents 48 1. Introduction............................................3 49 1.1 Conventions Used in This Document......................3 51 2. Format of the Interface Addresses APPsub-TLV............4 53 3. IA-APPsub-TLV sub-sub-TLVs..............................8 54 3.1 AFN Size sub-sub-TLV...................................8 55 3.2 Fixed Address sub-sub-TLV..............................9 56 3.3 Data Label sub-sub-TLV.................................9 57 3.4 Topology sub-sub-TLV..................................10 59 4. Security Considerations................................11 61 5. IANA Considerations....................................11 62 5.1 Additional AFN Number Allocation......................11 63 5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry................11 65 Acknowledgments...........................................13 66 Normative References......................................13 67 Informational References..................................14 68 Authors' Addresses........................................15 70 1. Introduction 72 This document specifies a TRILL (Transparent Interconnection of Lots 73 of Links) [RFC6325] IS-IS application sub-TLV (APPsub-TLV [RFC6823]) 74 that enables the convenient representation of sets of addresses such 75 that all of the addresses in each set designate the same end station 76 interface (port). For example, an EUI-48 MAC (Extended Unique 77 Identifier 48-bit, Media Access Control [RFC5342bis]) address, IPv4 78 address, and IPv6 address can be reported as all three corresponding 79 to the same interface. 81 This APPsub-TLV is used inside the TRILL GENINFO TLV as specified in 82 [ESADI]. It is expected to be used in Directory Assisted TRILL Edge 83 services [DirectoryFramework]. 85 Although, in some IETF protocols, address field types are represented 86 by EtherType [RFC5342bis] or Hardware Type [RFC5494] only Address 87 Family Number is used in this APPsub-TLV. 89 1.1 Conventions Used in This Document 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Format of the Interface Addresses APPsub-TLV 97 The Interface Addresses APPsub-TLV is used to indicate that a set of 98 addresses indicate the same end-station interface and to associate 99 that interface with the TRILL switch by which the interface is 100 reachable. These addresses can be in different address families. For 101 example, it can be used to declare that an end-station interface with 102 a particular IPv4 address, IPv6 address, and EUI-48 MAC address is 103 reachable from a particular TRILL switch. 105 The Template field indicates certain well known sets of addresses or 106 gives a number of AFNs. When AFNs are listed, the set of AFNs 107 provides an explicit template for the type and order of addresses in 108 each Address Set. 110 +-+-+-+-+-+-+-+-+ 111 | Type = TBD | (1 byte) 112 +-+-+-+-+-+-+-+-+ 113 | Length | (1 byte) 114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 115 | Nickname | (2 bytes) 116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 117 | Flags | (1 byte) 118 +-+-+-+-+-+-+-+-+ 119 | Confidence | (1 byte) 120 +-+-+-+-+-+-+-+-+ 121 | Addr Set End | (1 byte) 122 +-+-+-+-+-+-+-+-+-+- 123 | Template ... (variable) 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 125 | Address Set 1 (size determined by Template) | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 127 | Address Set 2 (size determined by Template) | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 129 | ... 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 131 | Address Set N (size determined by Template) | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+ 133 | optional sub-sub-TLVs ... 134 +-+-+-+-+-+-+-+-+-+-+-+-... 136 Figure 1. The Interface Addresses APPsub-TLV 138 o Type: Interface Addresses TRILL APPsub-TLV type, set to TBD[#2 139 suggested] (IA-SUBTLV). 141 o Length: Variable, minimum 5. If length is 4 or less, the APPsub- 142 TLV MUST be ignored. 144 o Nickname: The nickname of the RBridge by which the address sets 145 are reachable. 147 o Flags: A byte of flags as follows: 149 0 1 2 3 4 5 6 7 150 +-+-+-+-+-+-+-+-+ 151 |D|L| Resv | 152 +-+-+-+-+-+-+-+-+ 154 D: If D is one, the APPsub-TLV contains Push Directory 155 information. 157 L: If L is one, the APPsub-TLV contains information learned 158 locally be observing ingressed frames. (Both D and L can one 159 in the same APPsub-TLV.) 161 Resv: Additional reserved flag bits that MUST be sent as zero 162 and ignored on receipt. 164 o Confidence: This 8-bit quantity indicates the confidence level in 165 the addresses being transported [RFC6325]. 167 o Addr Set End: The unsigned offset of the byte, within the TLV 168 value part, of the last byte of the last Address Set. This will be 169 the byte just before the first sub-TLV if any sub-TLVs are 170 present. [RFC5305] 172 o Template: The initial byte of this field is the unsigned integer 173 K. It K has a value from 1 to 63, it indicates that this initial 174 byte is followed by a list of K AFNs (Address Family Numbers) in 175 the template specifying the structure and order of each Address 176 Set occurring later in the TLV. The minimum valid value is 1. If K 177 is 64 to 255, it indicates that the Template for each Address Set 178 is a specific well known Template. If the Template includes 179 explicit AFNs, they look like the following. 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | AFN 1 | (2 bytes) 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | AFN 2 | (2 bytes) 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | ... 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | AFN K | (2 bytes) 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 For K in the 64 to 255 range, some values indicate combinations of 192 a specific number of 48-bit MAC addresses, IPv4 addresses, and 193 IPv6 addresses in that order. If M is the number of MAC addresses 194 (limited to 1 or 2), v4 is the number of IPv4 addresses (limited 195 to 0, 1, or 2) and v6 is the number of IPv6 addresses (limited to 196 0 through 4 inclusive), the value of K is 198 K = 63 + M + 2*v4 + 6*v6 200 That equation specifies values of K from 64 through 93. Values 201 from 94 through 255 are available for assignment by IETF Review. 203 o AFN: A two-byte Address Family Number. The number of AFNs present 204 is given in first byte of the Template field if that value is less 205 than 64. This sequence specifies the structure of the Address Sets 206 occurring later in the TLV. For example, if Template Size is 2 and 207 the two AFNs present are the AFNs for EUI-48 and IPv4, in that 208 order, then each Address set present will consist of a 6-byte MAC 209 address followed by a 4-byte IPv4 address. If any AFNs are present 210 that are unknown to the receiving IS and the length of the 211 corresponding address is not provided by a sub-TLV as specified 212 below, the receiving IS will be unable to parse the Address Sets 213 and MUST ignore the enclosing TLV. 215 o Address Set: Each address set consists of a sequence of addresses 216 of the types given by the Template earlier in the TLV. No 217 alignment, other than to a byte boundary, is guaranteed. The 218 addresses in each Address Set are contiguous with no unused bytes 219 between them and the Address Sets are contiguous with no unused 220 bytes between Address Sets. The Address Sets must fit within the 221 TLV. If the product of the size of an Address Set and the number 222 of Address Sets is so large that this is not true, the APPsub-TLV 223 is ignored. 225 o sub-sub-TLVs: If the Address Sets indicated by Addr Sets End do not 226 completely fill the Length of the TLV, the remaining bytes are 227 parsed as sub-sub-TLVs [RFC5305]. Any such sub-sub-TLVs that are 228 not known to the receiving RBridge are ignored. Should this not be 229 possible, for example there is only one remaining byte or an 230 apparent sub-sub-TLV extends beyond the end of the TLV, the 231 containing IA-APPsub-TLV is considered corrupt and is ignored. 232 Several sub-sub-TLV types are specified in Section 3. 234 Different IA-APPsub-TLVs within the same or different ESADI-LSPs or 235 Pull Directory responses from the same RBridge may have different 236 Templates. The same AFN may occur more than once in a Template and 237 the same address may occur in more than one address set. For example, 238 an EUI-48 MAC address interface might have three IPv6 addresses. This 239 could be represented by an IA-APPsub-TLV whose Template specifically 240 provided for one EUI-48 address and three IPv6 addresses, which might 241 be an efficient format if there were multiple interfaces with that 242 pattern. Alternatively, a Template with one EUI-48 and one IPv6 243 address could be used in an IA-APPsub-TLV with three address sets 244 each having the same EUI-48 address but different IPv6 addresses, 245 which might be the most efficient format if only one interface had 246 multiple IPv6 addresses and other interfaces had only one IPv6 247 address. 249 In order to be able to parse the Address Sets, a receiving RBridge 250 must know at least the size of the address each AFN in the Template 251 specifies; however, the presence of the Addr Set End field means that 252 the sub-TLVs, if any, can always be located by a receiving IS. An 253 RBridge can be assumed to know the size of EUI-48, IPv4, and IPv6 254 addresses (AFNs 16389, 1, and 2) and the size of the additional AFNs 255 allocated by the IANA Considerations below. Should an RBridge wish to 256 include an AFN that some receiving RBridge in the campus may not 257 know, it SHOULD include an AFN-Size sub-sub-TLV as described below. 258 If an IA-APPsub-TLV is received with one or more AFNs in its template 259 for which the receiving RBridge does not know the length and for 260 which an AFN-Size sub-sub-TLV is not present, that IA-APPsub-TLV will 261 be ignored. 263 3. IA-APPsub-TLV sub-sub-TLVs 265 IA-APPsub-TLVs may have trailing sub-sub-TLVs [RFC5305] as specified 266 below. These sub-sub-TLVs occur after the Address Sets and the 267 amount of space available for sub-sub-TLVs is determined from the 268 overall IA-APPsub-TLV length and the value of the Addr Set End byte. 270 There is no ordering restriction on sub-sub-TLVs. Unless otherwise 271 specified each sub-sub-TLV type can occur zero, one, or many times in 272 an IA-APPsub-TLV. 274 3.1 AFN Size sub-sub-TLV 276 Using this sub-TLV, the originating RBridge can specify the size of 277 an address type. This is useful under two circumstances: 279 1. One or more AFNs that are unknown to the receiving RBridge appears 280 in the template. If an AFN Size sub-sub-TLV is present for each 281 such AFN, then at least the IA-APPsub-TLV can be parsed. 283 2. If an AFN occurs in the Template that represents a variable length 284 address, this sub-sub-TLV gives its size for all occurrences in 285 that IA-APPsubTLV. 287 +-+-+-+-+-+-+-+-+ 288 | Type = AFNsz | (1 byte) 289 +-+-+-+-+-+-+-+-+ 290 | Length | (1 byte) 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | AFN Size Record(s) | (3 bytes) 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Where each AFN Size Record is structured as follows: 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | AFN | (2 bytes) 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | AdrSize | (1 byte) 301 +-+-+-+-+-+-+-+-+ 303 o Type: AFN-Size sub-sub-TLV type, set to 1 (AFNsz). 305 o Length: 3*n where n is the number of AFN Size Records present. If 306 n is not a multiple of 3, the sub-sub-TLV MUST be ignored. 308 o AFN Size Record(s): Zero or more 3-byte records, each giving the 309 size of an address type identified by an AFN, 311 o AFN: The AFN whose length is being specified by the AFN Size 312 Record. 314 o AdrSize: The length of the address specified by the AFN field. 316 This sub-sub-TLV may occur multiple times in an enclosing IA-APPsub- 317 TLV. 319 An AFN Size sub-sub-TLV for any AFN known to the receiving RBridge 320 (which always includes AFN 1, 2, and 16389 and the AFNs specified in 321 xxx) is compared with the size known to the RBridge and if they 322 differ, the IA-APPsub-TLV is ignored. 324 3.2 Fixed Address sub-sub-TLV 326 There may be cases where, in an Interface Addresses TLV, the same 327 address would appear across every address set in the TLV. To avoid 328 having a larger template and wasted space in all Address Sets, this 329 sub-sub-TLV can be used to indicate such a fixed address 331 +-+-+-+-+-+-+-+-+ 332 |Type=FIXEDADR | (1 byte) 333 +-+-+-+-+-+-+-+-+ 334 | Length | (1 byte) 335 +-+-+-+-+-+-+-+-+ 336 | AFN | (2 bytes) 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 338 | Fixed Address (variable) 339 +-+-+-+-+-+-+-+-+-+-+-+-+-... 341 o Type: Data Label sub-sub-TLV type, set to 2 (FIXEDADR). 343 o Length: variable, minimum 3. If Length is 2 or less, the sub-sub- 344 TLV MUST be ignored. 346 o AFN: Address Family Number of the Fixed Address. 348 o Fixed Address: The address of the type indicated by the preceding 349 AFN field that is considered to be part of every Address Set in 350 the IA-APPsub-TLV. 352 3.3 Data Label sub-sub-TLV 354 When used with Push or Pull Directories, the Data Label is indicated 355 by the Data Label of the ESADI instance (Push) or RBridge Channel 356 message (Pull) in which the IA APPsub-TLV appears and any occurrence 357 of this sub-sub-TLV is ignored. However, the IA APPsub-TLV might be 358 used in other contexts where this sub-sub-TLV indicates the Data 359 Label of the Address Sets and multiple occurrences of this sub-sub- 360 TLV indicate that the Address Sets exist in all of the Data Labels. 362 +-+-+-+-+-+-+-+-+ 363 |Type=DATALEN | (1 byte) 364 +-+-+-+-+-+-+-+-+ 365 | Length | (1 byte) 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-... 367 | Data Label (variable) 368 +-+-+-+-+-+-+-+-+-+-+-+-+-... 370 o Type: Data Label sub-TLV type, set to 3 (DATALEN). 372 o Length: 2 or 3 374 o Data Label: If length is 2, the bottom 12 bits of the Data 375 Label are a VLAN ID and the top 4 bits are reserved (MUST be 376 sent as zero and ignored on receipt). If the length is 3, the 377 three Data Label bytes contain an FGL [RFCfgl]. 379 3.4 Topology sub-sub-TLV 381 The presence of this sub-sub-TLV indicates that the Address Sets are 382 in the topology give. If it occurs multiple times, then the Address 383 Sets are in all of the topologies listed. 385 +-+-+-+-+-+-+-+-+ 386 |Type=DATALEN | (1 byte) 387 +-+-+-+-+-+-+-+-+ 388 | Length | (1 byte) 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | RESV | Topology | (2 bytes) 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 o Type: Data Label sub-TLV type, set to 3 (DATALEN). 395 o Length: 2. 397 RESV: Four reserved bits. MUST be sent as zero and ignored on 398 receipt. 400 o Topology: The 12-bit topology number [RFC5120]. 402 4. Security Considerations 404 TBD... 406 5. IANA Considerations 408 5.1 Additional AFN Number Allocation 410 IANA is requested to allocate three new AFN numbers as follows: 412 Number Description References 413 ------ ----------- ---------- 415 TBD(29) OUI [RFC5342bis], this document 416 TBD(30) MAC/24 This document. 417 TBD(31) IPv6/64 This document. 419 The OUI AFN is provided so that MAC addresses can be abbreviated if 420 they have the same upper 24 bits. In particular, if there is an OUI 421 provided as a Fixed Address sub-sub-TLV (see Section 5.2.2) then, 422 whenever a MAC/24 address appears within an Address Set (as indicated 423 by the Template), the OUI is used as the first 24 bits of the actual 424 MAC address for the Address Set. 426 MAC/24 is a 24-bit suffix intended to be pre-fixed by an OUI as in 427 the previous paragraph. In absence of an OUI specified as a Fixed 428 Address in the same APPsub-TLV, an Address Set containing an MAC/24 429 address cannot be used. 431 IPv6/64 is an 8-byte quantity that is the first 64 bits of an IPv6 432 address. If present, there will normally be an EUI-48 or EUI-64 433 address in the address set to provide the lower 64 bits of the IPv6 434 address. For this purpose, an EUI-48 is expanded to 64 bits as 435 described in [RFC5342bis]. 437 5.2 IA APPsub-TLV Sub-Sub-TLVs SubRegistry 439 IANA is requested to establish a new subregistry for sub-sub-TLVs of 440 the Interface Addresses APPsub-TLV with initial contents as shown 441 below. 443 Name: Interface Addresses APPsub-TLV Sub-Sub-TLVs 445 Procedure: IETF Review 447 Reference: This document 449 Type Description Reference 450 ---- ----------- --------- 451 0 Reserved 452 1 AFN Size This document 453 2 Fixed Address This document 454 3 Data Label This document 455 4 Topology This document 456 5-254 Available This document 457 255 Reserved 459 Acknowledgments 461 The authors gratefully acknowledge the contributions and review by 462 the following: 464 Linda Dunbar 466 The document was prepared in raw nroff. All macros used were defined 467 within the source file. 469 Normative References 471 [RFC2119] - Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997 474 [RFC5120] - Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 475 Topology (MT) Routing in Intermediate System to Intermediate 476 Systems (IS-ISs)", RFC 5120, February 2008. 478 [RFC5305] - Li, T. and H. Smit, "IS-IS Extensions for Traffic 479 Engineering", RFC 5305, October 2008. 481 [RFC5342bis] - Eastlake 3rd, D., "IANA Considerations and IETF 482 Protocol Usage for IEEE 802 Parameters", BCP 141, RFC 5342, 483 September 2008. 485 [RFC5494] - Arkko, J. and C. Pignataro, "IANA Allocation Guidelines 486 for the Address Resolution Protocol (ARP)", RFC 5494, April 487 2009. 489 [RFC6325] - Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A. 490 Ghanwani, "Routing Bridges (RBridges): Base Protocol 491 Specification", RFC 6325, July 2011. 493 [RFC6823] - Ginsberg, L., Previdi, S., and M. Shand, "Advertising 494 Generic Information in IS-IS", RFC 6823, December 2012. 496 [RFCfgl] - D. Eastlake, M. Zhang, P. Agarwal, R. Perlman, D. Dutt, 497 "TRILL: Fine-Grained Labeling", draft-ietf-trill-fine- 498 labeling-07.txt, in RFC Editor's queue. 500 [ESADI] - Zhai, H., F. Hu, R. Perlman, D. Eastlake, O. Stokes, "TRILL 501 (Transparent Interconnection of Lots of Links): The ESADI (End 502 Station Address Distribution Information) Protocol", draft- 503 ietf-trill-esadi, work in progress. 505 Informational References 507 [DirectoryFramework] - Dunbar, L., D. Eastlkae, R. Perlman, I. 508 Gashinsky, "TRILL Edge Directory Assistance Framework", draft- 509 ietf-trill-directory-framework, work in progress. 511 [ARP reduction] - Shah, et. al., "ARP Broadcast Reduction for Large 512 Data Centers", Oct 2010. 514 Authors' Addresses 516 Donald Eastlake 517 Huawei Technologies 518 155 Beaver Street 519 Milford, MA 01757 USA 521 Phone: 1-508-333-2270 522 Email: d3e3e3@gmail.com 524 Yizhou Li 525 Huawei Technologies 526 101 Software Avenue, 527 Nanjing 210012 China 529 Phone: +86-25-56622310 530 Email: liyizhou@huawei.com 532 Radia Perlman 533 Intel Labs 534 2200 Mission College Blvd. 535 Santa Clara, CA 95054-1549 USA 537 Phone: +1-408-765-8080 538 Email: Radia@alum.mit.edu 540 Copyright, Disclaimer, and Additional IPR Provisions 542 Copyright (c) 2013 IETF Trust and the persons identified as the 543 document authors. All rights reserved. 545 This document is subject to BCP 78 and the IETF Trust's Legal 546 Provisions Relating to IETF Documents 547 (http://trustee.ietf.org/license-info) in effect on the date of 548 publication of this document. Please review these documents 549 carefully, as they describe your rights and restrictions with respect 550 to this document. Code Components extracted from this document must 551 include Simplified BSD License text as described in Section 4.e of 552 the Trust Legal Provisions and are provided without warranty as 553 described in the Simplified BSD License. The definitive version of 554 an IETF Document is that published by, or under the auspices of, the 555 IETF. Versions of IETF Documents that are published by third parties, 556 including those that are translated into other languages, should not 557 be considered to be definitive versions of IETF Documents. The 558 definitive version of these Legal Provisions is that published by, or 559 under the auspices of, the IETF. Versions of these Legal Provisions 560 that are published by third parties, including those that are 561 translated into other languages, should not be considered to be 562 definitive versions of these Legal Provisions. For the avoidance of 563 doubt, each Contributor to the IETF Standards Process licenses each 564 Contribution that he or she makes as part of the IETF Standards 565 Process to the IETF Trust pursuant to the provisions of RFC 5378. No 566 language to the contrary, or terms, conditions or rights that differ 567 from or are inconsistent with the rights and licenses granted under 568 RFC 5378, shall have any effect and shall be null and void, whether 569 published or posted by such Contributor, or included with or in such 570 Contribution.