idnits 2.17.1 draft-montemurro-gsma-imei-urn-02.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 568. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHALL not' in this paragraph: Additional security considerations are specified in 3GPP TS 22.016 [11]. Specifically the IMEI is to be incorporated in a module which is contained within the terminal. The IMEI SHALL not be chnaged after the terminal's production process. It SHALL resist tampering, i.e. manipulation and change, by any means (e.g. physical, electrical and software). -- 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 30, 2008) is 5658 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3406 (ref. '1') (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 4234 (ref. '5') (Obsoleted by RFC 5234) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-15 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Montemurro, Ed. 3 Internet-Draft A. Allen 4 Intended status: Informational Research in Motion (RIM) 5 Expires: April 3, 2009 D. McDonald 6 unaffiliated 7 P. Gosden 8 GSM Association 9 September 30, 2008 11 A Uniform Resource Name Namespace For The GSM Association (GSMA) and the 12 International Mobile station Equipment Identity(IMEI) 13 draft-montemurro-gsma-imei-urn-02 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on April 3, 2009. 40 Abstract 42 This specification defines a Uniform Resource Name namespace for the 43 GSMA and sub namespaces for the IMEI (International Mobile station 44 Equipment Identity), and for the IMEISV (International Mobile station 45 Equipment Identity and Software Version number). The IMEI is 15 46 decimal digits long and the IMEISV is 16 decimal digits long and are 47 both encoded using Binary Encoded Decimal (BCD). The IMEI and IMEISV 48 were introduced as part of the specification for Global System for 49 Mobile (GSM) and are also now incorporated by the 3rd Generation 50 Partnership Project (3GPP) as part of the 3GPP specification for GSM, 51 and the Universal Mobile Telecommunications System (UMTS). The IMEI 52 and IMEISV are used to uniquely identify Mobile Equipment within 53 these systems and are managed by the GSMA (GSM Association). 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Namespace Registration Template . . . . . . . . . . . . . . . 4 62 3.1. GSMA . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Specification . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. IMEI Format . . . . . . . . . . . . . . . . . . . . . . . 7 66 4.1.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 8 67 4.1.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 8 68 4.1.3. Spare . . . . . . . . . . . . . . . . . . . . . . . . 8 69 4.2. IMEISV Format . . . . . . . . . . . . . . . . . . . . . . 8 70 4.2.1. Type Allocation Code (TAC) . . . . . . . . . . . . . . 9 71 4.2.2. Serial Number (SNR) . . . . . . . . . . . . . . . . . 9 72 4.2.3. Software Version Number (SVN) . . . . . . . . . . . . 9 74 5. Community considerations . . . . . . . . . . . . . . . . . . . 9 76 6. Use as an Instance ID . . . . . . . . . . . . . . . . . . . . 9 78 7. Namespace considerations . . . . . . . . . . . . . . . . . . . 9 80 8. Security considerations . . . . . . . . . . . . . . . . . . . 10 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 10.1. Normative references . . . . . . . . . . . . . . . . . . . 10 86 10.2. Informative references . . . . . . . . . . . . . . . . . . 11 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 89 Intellectual Property and Copyright Statements . . . . . . . . . . 13 91 1. Introduction 93 This specification defines a Uniform Resource Name namespace for the 94 GSMA (GSM Association) and sub namespaces for the IMEI (International 95 Mobile station Equipment Identity), and for the IMEISV (International 96 Mobile station Equipment Identity and Software Version number as per 97 the namespace registration requirement found in [1]. GSMA is an 98 identifier for a namespace for identities used by Mobile Equipment 99 used in GSM and UMTS networks. The IMEI and the IMEISV are managed 100 by the GSMA, so this namespace would be managed by the GSMA. Whilst 101 this specification currently specifies only the IMEI and IMEISV sub 102 namespaces under the GSMA URN namespace additional sub namespaces 103 under the GSMA namespace may be specified in the future by the GSMA 104 through the publication of future informational RFCs. 106 The IMEI is 15 decimal digits long and includes a Type Allocation 107 Code (TAC) of 8 decimal digits and the Serial Number (SNR) of 6 108 decimal digits plus a Spare decimal digit. The TAC identifies the 109 type of the Mobile Equipment and is chosen from a range of values 110 allocated to the Mobile Equipment manufacturer in order to uniquely 111 identify the model of the Mobile Equipment. The SNR is an individual 112 serial number that uniquely identifies each Mobile Equipment within 113 the TAC. The Spare digit is used as a security check to combat 114 potential spoofing and is always set to the value 0 when transmitted 115 by the Mobile Equipment. 117 The IMEISV is 16 decimal digits long and includes the TAC and SNR 118 same as for the IMEI but also a 2 decimal digit Software Version 119 Number (SVN) which is allocated by the Mobile Equipment manufacturer 120 to identify the software version of the Mobile Equipment. 122 The IMEI is specified to be stored in a tamper proof fashion so that 123 it cannot be overwritten or otherwise reprogrammed by software. 125 The information here is meant to be a concise guide for those wishing 126 to use the IMEI and IMEISV as URNs. Nothing in this document should 127 be construed to override 3GPP TS 23.003 [2] that defines the IMEI and 128 IMEISV. 130 The GSM Association (GSMA) is a global trade association representing 131 more than 750 GSM mobile phone operators across 218 territories and 132 countries of the world. The primary goals of the GSMA are to ensure 133 mobile phones and wireless services work globally and are easily 134 accessible. Further details about the GSMA role in allocating the 135 IMEI and the IMEISV and the IMEI and IMEISV allocation guidelines can 136 be found in GSMA PRD DG.06 [3] 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in [4]. 144 3. Namespace Registration Template 146 3.1. GSMA 148 Namespace ID: "gsma" requested 150 Registration Information: 152 Registration version number: 1 154 Registration date: 2006-10-11 156 Declared registrant of the namespace: GSM Association, 1st Floor, 157 Mid City Place, 71 High Holborn, London, England 159 Declaration of syntactic structure: 160 The identifier is expressed in ASCII (UTF-8) characters and has a 161 hierarchical structure as follows: 163 urn:gsma::[]+ 164 where 165 = "imei" | "imeisv" 166 = GSMA-approved string 167 + = one or more occurences of "gsma-specifier-defined-string" 169 The GSMA namespace includes two predefined namespaces IMEI and 170 IMEISV and may be in the future extended to include other 171 identifiers used by Mobile Equipment used in GSM and UMTS networks 172 or future networks deployed by members of the GSMA. 174 A IMEI is an identifier under the GSMA namespace that uniquely 175 identifies Mobile Equipment used in GSM and UMTS networks. 177 The internal representation of a IMEI is a specific sequence of 178 bits in memory, as described in 3GPP TS 23.003 [2]. To accurately 179 represent a IMEI as a URN, it is necessary to convert the BCD bit 180 sequence to a string representation. Each field BCD bit sequence 181 has its value printed as a decimal digit string with the most 182 significant digit first. 184 The formal definition of the IMEI string representation is 185 provided by the following ABNF [5] 187 IMEI = tac "-" snr "-" spare 188 tac = 8Digit 189 snr = 6Digit 190 spare = 1Digit 191 decDigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / 192 "9" 194 For example: 195 urn:gsma:imei:90420156-025763-0 197 A IMEISV is an identifier under the GSMA namespace that uniquely 198 identifies Mobile Equipment and associated software versions used 199 in GSM and UMTS networks. The internal representation of a IMEISV 200 is a specific sequence of bits in memory, as described in 3GPP TS 201 23.003 [2]. To accurately represent a IMEISV as a URN, it is 202 necessary to convert the BCD bit sequence to a string 203 representation. Each field BCD bit sequence has its value printed 204 as a decimal digit string with the most significant digit first. 206 The formal definition of the IMEISV string representation is 207 provided by the following ABNF [5] 209 IMEISV = tac "-" snr "-" svn 210 tac = 8Digit 211 snr = 6Digit 212 svn = 2Digit 213 decDigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / 214 "9" 216 For example: 217 urn:gsma:imeisv:90420156-025763-42 219 The and can 220 comprise any ASCII characters compliant with URI syntax and must 221 not contain the ":" character (see STD 66, RFC 3986 [6]). The 222 exclusion of the colon from the list of other characters means 223 that the colon can only occur as a delimiter between string 224 values. 226 The GSMA will take responsibility for the gsma-specifier "imei" 227 and "imeisv" and manage the sub level. 229 Additional gsma-specifiers may be added in the future through 230 informational RFCs. 232 Relevant ancillary documentation: 233 See IMEI Allocation and Approval Guidelines [3] and 3GPP TS 23.003 234 [2]. 236 Identifier uniqueness considerations: 237 Identifiers in the "gsma" namespace are defined and assigned in 238 the requested namespace by the GSMA after ensuring that the URNs 239 to be assigned are unique. Uniqueness is achieved by checking 240 against the registry of previously assigned names. 242 Procedures are in place to ensure that each IMEI is uniquely 243 assigned by the Mobile Equipment manufacturer so that it is 244 guaranteed to uniquely identify that particular Mobile Equipment. 245 IMEIs are stored in the Mobile Equipment in a tamper proof non 246 modifiable fashion so they remain persistent. 247 Procedures are in place to ensure that each IMEISV is uniquely 248 assigned by the Mobile Equipment manufacturer so that it is 249 guaranteed to uniquely identify that particular Mobile Equipment 250 and the specific software version installed. 252 Identifier persistence considerations: 253 The GSMA is committed to maintaining uniqueness and persistence of 254 all resources identified by assigned URNs. 256 As the NID sought is "gsma" and GSMA is the long standing acronym 257 for the trade association that represents the mobile phone 258 operators the URN should also persist indefinitely, (at least as 259 long as there is a need for its use).The assignment process 260 guarantees that names are not reassigned. The binding between the 261 name and its resource is permanent. 263 IMEIs are stored in Mobile Equipment in a tamper proof non- 264 modifiable fashion so they remain persistent 265 The TAC and SNR portions of IMEISVs are stored in the Mobile 266 Equipment in a tamper proof non modifiable fashion so they remain 267 persistent. The SVN may be modified by software when new versions 268 are installed but should be persistent for the duration of the 269 installation of that specific version of software. 271 Process of identifier assignment: 272 GSMA will manage the and 273 including "imei" and "imeisv" identifier resources to maintain 274 uniqueness. 276 The process for IMEI and IMEISV assignment is documented in GSMA 277 PRD DG.06[3] 279 Process for identifier resolution: 280 Since the GSMA namespace is not globally resolvable, this is not 281 applicable. 283 Rules for Lexical Equivalence: 284 Consider each field of the IMEI or IMEISV to be a sequence of 285 decimial digits. Then, to compare a pair of IMEIs or IMEISVs, 286 arithmetically compare the corresponding fields from each IMEI or 287 IMEISV in order of significance and according to their data type. 288 Two IMEIs or IMEISVs are equal if and only if all the 289 corresponding fields are equal. 291 The lexical equivalence of the GSMA namespace-specific strings 292 (NSSs) is defined as an exact, but not case-sensitive, string 293 match. 295 Any identifier in GSMA namespaces can be compared using the normal 296 mechanisms for percent-encoded UTF-8 strings. 298 Conformance with URN Syntax: 299 The string representation of the GSMA URN and of the IMEI and 300 IMEISV subnamespaces is fully compatible with the URN syntax. 302 Validation Mechanism: 303 The IMEI can be validated using the mechanism defined in Annex B 304 of 3GPP TS 23.003 [2]. The TAC and SNR fields of the IMEISV can 305 be validated using the mechanism defined in Annex B of 3GPP TS 306 23.003 [2]. There is no mechanism defined to validate the SVN 307 field of the IMEISV. 309 Scope: GSMA URN is global in scope. 311 4. Specification 313 4.1. IMEI Format 315 The IMEI format is 15 decimal digits encoded in 8 octets using BCD as 316 defined in 3GPP TS 24.008 [7]. The most significant digit is coded 317 in the least significant bits of octet 1. The least significant 318 digit is coded in the least significant bits of octet 8. 320 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 321 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 322 | | | S| 323 | T | S | p| 324 | A | N | a| 325 | C | R | r| 326 | | | e| 327 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 328 1 2 3 4 5 6 7 8 Octets 330 4.1.1. Type Allocation Code (TAC) 332 The TAC is a 8 decimal digit value. The TAC identifies the type of 333 the Mobile Equipment and is chosen from a range of values allocated 334 to the Mobile Equipment manufacturer in order to uniquely identify 335 the model of the Mobile Equipment. 337 4.1.2. Serial Number (SNR) 339 The SNR is a 6 decimal digit value. The SNR is an individual serial 340 number that uniquely identifies each Mobile Equipment within the TAC 342 4.1.3. Spare 344 The Spare is a single decimal digit that is used as a security check 345 digit to combat potential spoofing. The Spare is always set to zero 346 when transmitted by the Mobile Equipment. Annex B of 3GPP TS 23.003 347 [2] defines a mechanism for computing the actual check digit in order 348 to validate the TAC and SNR. 350 4.2. IMEISV Format 352 The IMEISV format is 16 decimal digits encoded in 8 octets using BCD 353 as defined in 3GPP TS 24.008 [7]. The most significant digit is 354 coded in the most significant bits of octet 1. The least significant 355 digit is coded in the least significant bits of octet 8. 357 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 Decimal Digits 358 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 359 | | | | 360 | T | S | S | 361 | A | N | V | 362 | C | R | N | 363 | | | | 364 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 365 1 2 3 4 5 6 7 8 Octets 367 4.2.1. Type Allocation Code (TAC) 369 The TAC is the same as for the IMEI in Section 5.1.1. 371 4.2.2. Serial Number (SNR) 373 The SNR is the same as for the IMEI in Section 5.1.2. 375 4.2.3. Software Version Number (SVN) 377 The Software Version Number is allocated by the Mobile Equipment 378 manufacturer to identify the software version of the Mobile 379 Equipment. 381 5. Community considerations 383 GSM and UMTS mobile devices will be interoperating with Internet 384 devices for a variety of voice and data services. To do this, they 385 need to make use of Internet protocols that will operate end to end 386 between devices in GSM/UMTS networks and those in the general 387 internet. Many of these protocols require the use of URN's as 388 identifiers. Within the GSM/UMTS networks, mobile devices are 389 identified by their IMEI and IMEISV. Internet users will need to be 390 able to receive and include the GSMA URN in various Internet protocol 391 elements to facilitate communication between pure internet based 392 devices and GSM and UMTS mobile devices. Thus the existence and 393 syntax of these namespaces needs to be available to the general 394 internet community and the namespace needs to be reserved with IANA 395 in order to guarantee uniqueness and prevent potential namespace 396 conflicts both within the internet and within GSM/UMTS networks. 398 6. Use as an Instance ID 400 The IMEI and IMEISV URNs MAY be used as an Instance ID and included 401 in the sip.instance parameter of a Contact header field of a SIP 402 Register request as specified in draft-ietf-sip-outbound [8]. 404 7. Namespace considerations 406 A URN was considered the most appropriate URI to represent the IMEI 407 and IMEISV as these identifiers may be used and transported similarly 408 to the Universally Unique Identifier (UUID)which is defined as a URN 409 in [9]. Since specifications for protocols that are used to 410 transport device identifiers often require the device identifier to 411 be globally unique and in the URN format it is necessary that the 412 IMEI and IMEISV URN formats are defined. 414 8. Security considerations 416 IMEIs (with the Spare value set to zero) are displayable on most 417 Mobile Equipment therefore they must not be used as security 418 capabilities (identifiers whose mere possession grants access), for 419 example. 421 Revealing the specific software version of the terminal might make 422 the terminal more vulnerable to attacks against software that is 423 known to contain security holes. This is a similar concern to the 424 use of the User-Agent header in SIP as specified in RFC 3261 [10]. 425 It is therefore RECOMMENDED that the IMEISV is not delivered to 426 devices that are not trusted.Care should be taken regarding use of 427 the IMEISV as it could help a malicious device identify Mobile 428 Equipment running software that is known to be vulnerable to certain 429 attacks. 431 Additional security considerations are specified in 3GPP TS 22.016 432 [11]. Specifically the IMEI is to be incorporated in a module which 433 is contained within the terminal. The IMEI SHALL not be chnaged 434 after the terminal's production process. It SHALL resist tampering, 435 i.e. manipulation and change, by any means (e.g. physical, electrical 436 and software). 438 9. Acknowledgements 440 This document draws heavily on the 3GPP work on Numbering, Addressing 441 and Identification in 3GPP TS 23.003 [2] and also on the style and 442 structure used in RFC 4122 [9]. 444 10. References 446 10.1. Normative references 448 [1] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 449 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 450 BCP 66, RFC 3406, October 2002. 452 [2] 3GPP, "TS 23.003: Numbering, addressing and identification 453 (Release 8)", 3GPP 23.003, September 2008, 454 . 456 [3] GSMA Association, "IMEI Allocation and Approval Guidelines", 457 PRD DG.06 version 3.6, February 2008, 458 . 460 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 461 Levels", BCP 14, RFC 2119, March 1997. 463 [5] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 464 Specifications: ABNF", RFC 4234, October 2005. 466 [6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 467 Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, 468 January 2005. 470 [7] 3GPP, "TS 24.008: Mobile radio interface Layer 3 specification; 471 Core network protocols; Stage 3 (Release 8)", 3GPP 24.008, 472 September 2008, 473 . 475 10.2. Informative references 477 [8] Jennings, C. and R. Mahy, "Managing Client Initiated 478 Connections in the Session Initiation Protocol (SIP)", 479 draft-ietf-sip-outbound-15 (work in progress), June 2008. 481 [9] Leach, P., Mealling, M., and R. Salz, "A Universally Unique 482 IDentifier (UUID) URN Namespace", RFC 4122, July 2005. 484 [10] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 485 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 486 Session Initiation Protocol", RFC 3261, June 2002. 488 [11] 3GPP, "TS 22.016: International Mobile station Equipment 489 Identities (IMEI)(Release 7)", 3GPP 22.016, May 2007, 490 . 492 Authors' Addresses 494 Michael Montemurro (editor) 495 Research in Motion (RIM) 496 5090 Commerce Blvd 497 Mississauga, Ontario L4W 5W4 498 Canada 500 Phone: unlisted 501 Fax: unlisted 502 Email: mmontemurro@rim.com 503 Andrew Allen 504 Research in Motion (RIM) 505 300 Knightsbridge Parkway, Suite 360 506 Lincolnshire, Illinois 60069 507 USA 509 Phone: unlisted 510 Fax: unlisted 511 Email: aallen@rim.com 513 David McDonald 514 unaffiliated 516 Phone: unlisted 517 Fax: unlisted 518 Email: mcdonalddm@hotmail.com 520 Paul Gosden 521 GSM Association 522 1st Floor, Mid City Place, 71 High Holborn, 523 London 524 England 526 Phone: unlisted 527 Fax: unlisted 528 Email: pgosden@gsm.org 530 Full Copyright Statement 532 Copyright (C) The IETF Trust (2008). 534 This document is subject to the rights, licenses and restrictions 535 contained in BCP 78, and except as set forth therein, the authors 536 retain all their rights. 538 This document and the information contained herein are provided on an 539 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 540 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 541 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 542 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 543 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 544 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 546 Intellectual Property 548 The IETF takes no position regarding the validity or scope of any 549 Intellectual Property Rights or other rights that might be claimed to 550 pertain to the implementation or use of the technology described in 551 this document or the extent to which any license under such rights 552 might or might not be available; nor does it represent that it has 553 made any independent effort to identify any such rights. Information 554 on the procedures with respect to rights in RFC documents can be 555 found in BCP 78 and BCP 79. 557 Copies of IPR disclosures made to the IETF Secretariat and any 558 assurances of licenses to be made available, or the result of an 559 attempt made to obtain a general license or permission for the use of 560 such proprietary rights by implementers or users of this 561 specification can be obtained from the IETF on-line IPR repository at 562 http://www.ietf.org/ipr. 564 The IETF invites any interested party to bring to its attention any 565 copyrights, patents or patent applications, or other proprietary 566 rights that may cover technology that may be required to implement 567 this standard. Please address the information to the IETF at 568 ietf-ipr@ietf.org.