idnits 2.17.1 draft-arkko-roamops-rfc2486bis-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.5 on line 596. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 586. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 602), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 17, 2004) is 7217 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '8' is defined on line 459, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3490 (ref. '4') (Obsoleted by RFC 5890, RFC 5891) == Outdated reference: A later version (-10) exists of draft-ietf-sasl-saslprep-04 -- Obsolete informational reference (is this intentional?): RFC 821 (ref. '6') (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2486 (ref. '8') (Obsoleted by RFC 4282) -- Obsolete informational reference (is this intentional?): RFC 3588 (ref. '12') (Obsoleted by RFC 6733) == Outdated reference: A later version (-09) exists of draft-ietf-eap-netsel-problem-00 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Aboba 2 Internet-Draft Microsoft 3 Expires: January 15, 2005 M. Beadles 4 SmartPipes 5 J. Arkko 6 Ericsson 7 P. Eronen 8 Nokia 9 July 17, 2004 11 The Network Access Identifier 12 draft-arkko-roamops-rfc2486bis-02 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3667. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 15, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 In order to provide roaming services, it is necessary to have a 45 standardized method for identifying users. This document defines the 46 syntax for the Network Access Identifier (NAI), the user identity 47 submitted by the client during network authentication. "Roaming" may 48 be loosely defined as the ability to use any one of multiple Internet 49 service providers (ISPs), while maintaining a formal, customer-vendor 50 relationship with only one. Examples of where roaming capabilities 51 might be required include ISP "confederations" and ISP-provided 52 corporate network access support. This document is a revised version 53 of RFC 2486 which originally defined NAIs. Enhancements include 54 international character set and privacy support, as well as a number 55 of corrections to the original RFC. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2 Requirements language . . . . . . . . . . . . . . . . . . 4 62 1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. NAI Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1 Formal Syntax . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2 NAI Length Considerations . . . . . . . . . . . . . . . . 6 66 2.3 Support for Username Privacy . . . . . . . . . . . . . . . 6 67 2.4 International Character Sets . . . . . . . . . . . . . . . 7 68 2.5 Compatibility with E-Mail Usernames . . . . . . . . . . . 7 69 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . . . 7 70 2.7 Realm Construction . . . . . . . . . . . . . . . . . . . . 7 71 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 72 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 74 Normative References . . . . . . . . . . . . . . . . . . . . . 12 75 Informative References . . . . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 77 A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 15 78 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 79 Intellectual Property and Copyright Statements . . . . . . . . 17 81 1. Introduction 83 Considerable interest exists for a set of features that fit within 84 the general category of "roaming capability" for network access, 85 including dialup Internet users, VPN usage, wireless LAN 86 authentication, and other applications. Interested parties have 87 included: 89 o Regional Internet Service Providers (ISPs) operating within a 90 particular state or province, looking to combine their efforts 91 with those of other regional providers to offer dialup service 92 over a wider area. 94 o National ISPs wishing to combine their operations with those of 95 one or more ISPs in another nation to offer more comprehensive 96 dialup service in a group of countries or on a continent. 98 o Wireless LAN hotspots providing service to one or more ISPs. 100 o Businesses desiring to offer their employees a comprehensive 101 package of dialup services on a global basis. Those services may 102 include Internet access as well as secure access to corporate 103 intranets via a Virtual Private Network (VPN), enabled by 104 tunneling protocols such as PPTP, L2F, L2TP, and IPsec tunnel 105 mode. 107 In order to enhance the interoperability of roaming services, it is 108 necessary to have a standardized method for identifying users. This 109 document defines syntax for the Network Access Identifier (NAI). 110 Examples of implementations that use the NAI, and descriptions of its 111 semantics, can be found in [7]. 113 This document is a revised version of RFC 2486 which originally 114 defined NAIs. Differences and enhancements compared to RFC 2486 are 115 listed in Appendix A. 117 1.1 Terminology 119 This document frequently uses the following terms: 121 Network Access Identifier 123 The Network Access Identifier (NAI) is the user identity submitted 124 by the client during network access authentication. In roaming, 125 the purpose of the NAI is to identify the user as well as to 126 assist in the routing of the authentication request. Please note 127 that the NAI may not necessarily be the same as the user's e-mail 128 address or the user identity submitted in an application layer 129 authentication. 131 Network Access Server 133 The Network Access Server (NAS) is the device that clients connect 134 to in order to get access to the network. In PPTP terminology this 135 is referred to as the PPTP Access Concentrator (PAC), and in L2TP 136 terminology, it is referred to as the L2TP Access Concentrator 137 (LAC). In IEEE 802.11, it is referred to as an Access Point. 139 Roaming Capability 141 Roaming capability can be loosely defined as the ability to use 142 any one of multiple Internet service providers (ISPs), while 143 maintaining a formal, customer-vendor relationship with only one. 144 Examples of cases where roaming capability might be required 145 include ISP "confederations" and ISP- provided corporate network 146 access support. 148 Tunneling Service 150 A tunneling service is any network service enabled by tunneling 151 protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One 152 example of a tunneling service is secure access to corporate 153 intranets via a Virtual Private Network (VPN). 155 1.2 Requirements language 157 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 158 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 159 described in [2]. 161 1.3 Purpose 163 As described in [7], there are a number of providers offering network 164 access services, and the number of Internet Service Providers 165 involved in roaming consortia is increasing rapidly. 167 In order to be able to offer roaming capability, one of the 168 requirements is to be able to identify the user's home authentication 169 server. For use in roaming, this function is accomplished via the 170 Network Access Identifier (NAI) submitted by the user to the NAS in 171 the initial network authentication. It is also expected that NASes 172 will use the NAI as part of the process of opening a new tunnel, in 173 order to determine the tunnel endpoint. 175 2. NAI Definition 177 2.1 Formal Syntax 179 The grammar for the NAI is given below, described in ABNF as 180 documented in [3]. The grammar for the username is based on [6], and 181 the grammar for the realm is an updated version of [1]. 183 nai = username 184 nai =/ "@" realm 185 nai =/ username "@" realm 187 username = dot-string 188 dot-string = string 189 dot-string =/ dot-string "." string 190 string = char 191 string =/ string char 192 char = c 193 char =/ "\" x 195 c = %x21 ; '!' allowed 196 ; '"' not allowed 197 c =/ %x23 ; '#' allowed 198 c =/ %x24 ; '$' allowed 199 c =/ %x25 ; '%' allowed 200 c =/ %x26 ; '&et;' allowed 201 c =/ %x27 ; ''' allowed 202 ; '(', ')' not allowed 203 c =/ %x2a ; '*' allowed 204 c =/ %x2b ; '*' allowed 205 ; ',' not allowed 206 c =/ %x2d ; '-' allowed 207 ; '.' not allowed 208 c =/ %x2f ; '/' allowed 209 c =/ %x30-39 ; '0'-'9' allowed 210 ; ';', ':', '<' not allowed 211 c =/ %x3d ; '=' allowed 212 ; '>' not allowed 213 c =/ %x3f ; '?' allowed 214 ; '@' not allowed 215 c =/ %x41-5a ; 'A'-'Z' allowed 216 ; '[', '\', ']' not allowed 217 c =/ %x5e-7e ; '^' - ' allowed 218 ; DEL not allowed 219 c =/ %x80-ff ; UTF-8 allowed (changed) 220 ; Must also satisfy rules in Section 2.4 221 x = %x00-7F ; all 128 ASCII characters, no exception 222 realm = 1*( label "." ) label 223 label = let-dig * (ldh-str) 224 ldh-str = *( alpha / digit / "-" ) let-dig 225 let-dig = alpha / digit 226 alpha = %x41-5A ; 'A'-'Z' 227 alpha =/ %x61-7A ; 'a'-'z' 228 digit = %x30-39 ; '0'-'9' 230 2.2 NAI Length Considerations 232 Devices handling NAIs MUST support an NAI length of at least 72 233 octets. Support for an NAI length of 253 octets is RECOMMENDED. 234 However, the following implementation issues should be considered: 236 o NAIs are often transported in the User-Name attribute of RADIUS. 237 Unfortunately, RFC 2865 [9] Section 5.1 states that "the ability 238 to handle at least 63 octets is recommended." As a result, it may 239 not be possible to transfer NAIs beyond 63 octets through all 240 devices. In addition, since only a single User-Name attribute may 241 be included in a RADIUS message and the maximum attribute length 242 is 253 octets, RADIUS is unable to support NAI lengths beyond 253 243 octets. 245 o NAIs can also be transported in the User-Name attribute of 246 Diameter [12], which supports content lengths up to 2^24 - 9 247 octets. As a result, NAIs processed only by Diameter nodes can be 248 very long. Unfortunately, an NAI transported over Diameter may 249 eventually be translated to RADIUS, in which case the above 250 limitations apply. 252 2.3 Support for Username Privacy 254 Interpretation of the "username" part of the NAI depends on the realm 255 in question. Therefore, the "username" part SHOULD be treated as 256 opaque data when processed by nodes that are not a part of the 257 authoritative domain (in the sense of Section 4) for that realm. 259 Where privacy is a concern, NAIs MAY be provided in an abbreviated 260 form by omitting the username portion. This is possible only when 261 NAIs are used together with a separate authentication method that can 262 transfer the username in a secure manner. 264 For roaming purposes it is typically necessary to locate the 265 appropriate backend authentication server for the given NAI before 266 the authentication conversation can proceed. As a result, the realm 267 portion is typically required in order for the authentication 268 exchange to be routed to the appropriate server. 270 2.4 International Character Sets 272 This specification allows both international usernames and realms. 273 International usernames are based on the use of Unicode characters, 274 encoded as UTF-8 and processed with a certain algorithm to ensure a 275 canonical representation. The realm part internationalization is 276 based on International Domain Name (IDN) [4]. 278 In order to ensure a canonical representation, characters of the 279 username portion in an NAI MUST fulfill the requirements specified in 280 [5]. In addition, the use of certain special characters (see grammar 281 rule c) are prohibited as well in order to retain compatibility with 282 the previous version of this RFC. 284 The realm name is an "IDN-unaware domain name slot" as defined in 285 [4]. That is, it can contain only ASCII characters. An 286 implementation MAY support internationalized domain names (IDNs) 287 using the ToASCII operation; see [4] for more information. 289 2.5 Compatibility with E-Mail Usernames 291 As proposed in this document, the Network Access Identifier is of the 292 form user@realm. Please note that while the user portion of the NAI 293 is based on the BNF described in [6], it has been extended for 294 internationalization support as well as for purposes of Section 2.7, 295 and is not necessarily compatible with the usernames used in e-mail. 296 Note also that the internationalization requirements for NAIs and 297 e-mail addresses are different, since the former need to be typed in 298 only by the user himself and his own operator, not by others. 300 2.6 Compatibility with DNS 302 The BNF of the realm portion allows the realm to begin with a digit, 303 which is not permitted by the BNF described in [1]. This change was 304 made to reflect current practice; although not permitted by the BNF 305 described in [1], FQDNs such as 3com.com are commonly used, and 306 accepted by current software. 308 2.7 Realm Construction 310 NAIs are used, among other purposes, for routing AAA transactions to 311 the user's home realm. Usually, the home realm appears in the realm 312 portion of the NAI, but in some cases a different realm can be used. 313 This may be useful, for instance, when the home realm is only 314 reachable via another mediating realm. 316 Such usage may prevent interoperability unless the parties involved 317 have a mutual agreement that the usage is allowed. In particular, 318 NAIs MUST NOT use a different realm than the home realm unless the 319 sender has explicit knowledge that (a) the specified other realm is 320 available and (b) the other realm supports such usage. The sender may 321 determine the fulfillment of these conditions through a database, 322 dynamic discovery, or other means not specified here. Note that the 323 first condition is affected by roaming, as the availability of the 324 other realm may depend on the user's location or the desired 325 application. 327 The use of the home realm MUST be the default unless otherwise 328 configured. 330 Where these conditions are fulfilled, an NAI such as 332 user@homerealm.example.net 334 MAY be represented as in 336 homerealm.example.net!user@otherrealm.example.net 338 In this case, the part before the (non-escaped) '!' MUST be a realm 339 name as defined in the ABNF in Section 2.1. When receiving such an 340 NAI, the other realm MUST convert the format back to 341 "user@homerealm.example.net" when passing the NAI forward, as well as 342 applying appropriate AAA routing for the transaction. 344 The conversion process may apply also recursively. That is, after the 345 conversion the result may still have one or more '!' characters in 346 the username. For instance, the NAI 348 other2.example.net!home.example.net!user@other1.example.net 350 would first be converted in other1.example net to 352 home.example.net!user@other2.example.net 354 and then at other2.example.net finally to 356 user@homerealm.example.net 358 2.8 Examples 360 Examples of valid Network Access Identifiers include: 362 bob 363 joe@example.com 364 fred@foo-9.example.com 365 jack@3rd.depts.example.com 366 fred_smith@example.com 367 fred=?#$&*+-/^smith@example.com 368 nancy@eng.example.net 369 eng.example.net!nancy@example.net 370 eng%nancy@example.net 371 @privatecorp.example.net 372 alice@xn--tmonesimerkki-bfbb.example.net 374 The last example uses an IDN converted into an ASCII representation. 376 Examples of invalid Network Access Identifiers include: 378 fred@foo 379 fred@foo_9.com 380 fred@bigco.com@example.net 381 eng:nancy@example.net 382 eng;nancy@example.net 383 @example.net 385 3. Security Considerations 387 Since an NAI reveals the home affiliation of a user, it may assist an 388 attacker in further probing the username space. Typically this 389 problem is of most concern in protocols which transmit the user name 390 in clear-text across the Internet, such as in RADIUS, described in 391 [9] and [10]. In order to prevent snooping of the user name, 392 protocols may use confidentiality services provided by protocols 393 transporting them, such RADIUS protected by IPsec [11] or Diameter 394 protected by TLS [12]. 396 This specification adds the possibility of hiding the username part 397 in the NAI, by omitting it. As discussed in Section 2.3, this is 398 possible only when NAIs are used together with a separate 399 authentication method that can transfer the username in a secure 400 manner. In some cases application-specific privacy mechanism have 401 also been used with NAIs. For instance, some EAP methods apply a 402 method-specific pseudonyms in the username part of the NAI. While 403 neither of these approaches can protect the realm part, their 404 advantage over transport protection is that privacy of the username 405 is protected even through intermediate nodes such as NASes. 407 4. IANA Considerations 409 In order to to avoid creating any new administrative procedures, 410 administration of the NAI realm namespace piggybacks on the 411 administration of the DNS namespace. 413 NAI realm names are required to be unique and the rights to use a 414 given NAI realm for roaming purposes are obtained coincident with 415 acquiring the rights to use a particular fully qualified domain name 416 (FQDN). Those wishing to use an NAI realm name should first acquire 417 the rights to use the corresponding FQDN. Using an NAI realm without 418 ownership of the corresponding FQDN creates the possibility of 419 conflict and therefore is to be discouraged. 421 Note that the use of an FQDN as the realm name does not require use 422 of the DNS for location of the authentication server. While Diameter 423 [12] supports the use of DNS for location of authentication servers, 424 existing RADIUS implementations typically use proxy configuration 425 files in order to locate authentication servers within a domain and 426 perform authentication routing. The implementations described in [7] 427 did not use DNS for location of the authentication server within a 428 domain. Similarly, existing implementations have not found a need 429 for dynamic routing protocols, or propagation of global routing 430 information. Note also that there is no requirement that that the 431 NAI represent a valid email address. 433 Normative References 435 [1] Mockapetris, P., "Domain names - implementation and 436 specification", STD 13, RFC 1035, November 1987. 438 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 439 Levels", BCP 14, RFC 2119, March 1997. 441 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 442 Specifications: ABNF", RFC 2234, November 1997. 444 [4] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 445 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 447 [5] Zeilenga, K., "SASLprep: Stringprep profile for user names and 448 passwords", draft-ietf-sasl-saslprep-04 (work in progress), 449 October 2003. 451 Informative References 453 [6] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 454 August 1982. 456 [7] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of 457 Roaming Implementations", RFC 2194, September 1997. 459 [8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 460 2486, January 1999. 462 [9] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 463 Authentication Dial In User Service (RADIUS)", RFC 2865, June 464 2000. 466 [10] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 468 [11] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 469 In User Service) Support For Extensible Authentication Protocol 470 (EAP)", RFC 3579, September 2003. 472 [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 473 "Diameter Base Protocol", RFC 3588, September 2003. 475 [13] Arkko, J. and B. Aboba, "Network Discovery and Selection within 476 the EAP Framework", draft-ietf-eap-netsel-problem-00 (work in 477 progress), January 2004. 479 Authors' Addresses 481 Bernard Aboba 482 Microsoft 483 One Microsoft Way 484 Redmond, WA 98052 485 USA 487 EMail: bernarda@microsoft.com 489 Mark A. Beadles 490 SmartPipes 491 565 Metro Place South Suite 300 492 Dublin OH 43017 493 USA 495 EMail: mbeadles@smartpipes.com 496 Jari Arkko 497 Ericsson 499 Jorvas 02420 500 Finland 502 EMail: jari.arkko@ericsson.com 504 Pasi Eronen 505 Nokia Research Center 506 P.O. Box 407 507 FIN-00045 Nokia Group 508 Finland 510 EMail: pasi.eronen@nokia.com 512 Appendix A. Changes from RFC 2486 514 This draft contains the following updates with respect to the 515 original NAI definition in RFC 2486: 517 o International character set support has been added for both 518 usernames and realms. Note that this implies character codes 128 - 519 255 may be used in the username portion, which may be unacceptable 520 to nodes that only support RFC 2486. Many devices already allow 521 this behaviour, however. 523 o Username privacy support has been added. Note that NAIs without a 524 username (for privacy) may not be acceptable to RFC 2486 compliant 525 nodes. Many devices already allow this behaviour, however. 527 o A recommendation to support NAI length of at least 253 octets has 528 been added, and compatibility considerations among NAI lengths in 529 this specification and various AAA protocols are discussed. Note 530 that long NAIs may not be acceptable to RFC 2486 compliant nodes. 532 o The mediating network syntax and its implications have been fully 533 described and not given only as an example. Note that this syntax 534 is not intended to be a full solution to network discovery and 535 selection needs as defined in [13]. Rather, it is intended as a 536 clarification of RFC 2486. 538 Note that this specification puts stricter requirements to the 539 part preceding the '!' sign: it is required to be a realm name. 540 This may make it unacceptable to nodes that only support RFC 2486. 541 However, as discussed in Section 2.7, this specification requires 542 that this syntax be applied only when there is explicit knowledge 543 that the peer system supports such syntax. 545 o The realm BNF entry definition has been changed to avoid an error 546 (infinite recursion) in the original specification. 548 o Several clarifications and improvements have been incorporated to 549 the ABNF specification for NAIs. 551 Appendix B. Acknowledgements 553 Thanks to Glen Zorn for many useful discussions of this problem 554 space, and for Farid Adrangi and others for suggesting mediating 555 network representation in NAIs. Jonathan Rosenberg reported the BNF 556 error. Dale Worley suggested clarifications of the x and special BNF 557 entries. Arne Norefors reported the length differences between RFC 558 2486 and RFC 2865. Kalle Tammela, Stefaan De Cnodder, Nagi Jonnala, 559 Bert Wijnen, Blair Bullock, and Richard Perlman, provided many useful 560 comments on the -00 draft. The ABNF validator at http:// 561 www.apps.ietf.org/abnf.html was used to verify the syntactic 562 correctness of the ABNF in Section 2.1. 564 Intellectual Property Statement 566 The IETF takes no position regarding the validity or scope of any 567 Intellectual Property Rights or other rights that might be claimed to 568 pertain to the implementation or use of the technology described in 569 this document or the extent to which any license under such rights 570 might or might not be available; nor does it represent that it has 571 made any independent effort to identify any such rights. Information 572 on the IETF's procedures with respect to rights in IETF Documents can 573 be found in BCP 78 and BCP 79. 575 Copies of IPR disclosures made to the IETF Secretariat and any 576 assurances of licenses to be made available, or the result of an 577 attempt made to obtain a general license or permission for the use of 578 such proprietary rights by implementers or users of this 579 specification can be obtained from the IETF on-line IPR repository at 580 http://www.ietf.org/ipr. 582 The IETF invites any interested party to bring to its attention any 583 copyrights, patents or patent applications, or other proprietary 584 rights that may cover technology that may be required to implement 585 this standard. Please address the information to the IETF at 586 ietf-ipr@ietf.org. 588 Disclaimer of Validity 590 This document and the information contained herein are provided on an 591 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 592 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 593 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 594 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 595 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 596 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 598 Copyright Statement 600 Copyright (C) The Internet Society (2004). This document is subject 601 to the rights, licenses and restrictions contained in BCP 78, and 602 except as set forth therein, the authors retain all their rights. 604 Acknowledgment 606 Funding for the RFC Editor function is currently provided by the 607 Internet Society.