idnits 2.17.1 draft-ietf-radext-rfc2486bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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 uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 (September 30, 2004) is 7148 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 463, 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: 7 errors (**), 0 flaws (~~), 6 warnings (==), 10 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: March 31, 2005 M. Beadles 4 SmartPipes 5 J. Arkko 6 Ericsson 7 P. Eronen 8 Nokia 9 September 30, 2004 11 The Network Access Identifier 12 draft-ietf-radext-rfc2486bis-00 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as 26 Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on March 31, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). 45 Abstract 47 In order to provide roaming services, it is necessary to have a 48 standardized method for identifying users. This document defines the 49 syntax for the Network Access Identifier (NAI), the user identity 50 submitted by the client during network authentication. "Roaming" may 51 be loosely defined as the ability to use any one of multiple Internet 52 service providers (ISPs), while maintaining a formal, customer-vendor 53 relationship with only one. Examples of where roaming capabilities 54 might be required include ISP "confederations" and ISP-provided 55 corporate network access support. This document is a revised version 56 of RFC 2486 which originally defined NAIs. Enhancements include 57 international character set and privacy support, as well as a number 58 of corrections to the original RFC. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . 3 64 1.2 Requirements language . . . . . . . . . . . . . . . . 4 65 1.3 Purpose . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. NAI Definition . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2.1 Formal Syntax . . . . . . . . . . . . . . . . . . . . 5 68 2.2 NAI Length Considerations . . . . . . . . . . . . . . 6 69 2.3 Support for Username Privacy . . . . . . . . . . . . . 6 70 2.4 International Character Sets . . . . . . . . . . . . . 7 71 2.5 Compatibility with E-Mail Usernames . . . . . . . . . 7 72 2.6 Compatibility with DNS . . . . . . . . . . . . . . . . 7 73 2.7 Realm Construction . . . . . . . . . . . . . . . . . . 8 74 2.8 Examples . . . . . . . . . . . . . . . . . . . . . . . 9 75 3. Security Considerations . . . . . . . . . . . . . . . . . . . 10 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5.1 Normative References . . . . . . . . . . . . . . . . . . 12 79 5.2 Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 81 A. Changes from RFC 2486 . . . . . . . . . . . . . . . . . . . . 14 82 B. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 Intellectual Property and Copyright Statements . . . . . . . . 16 85 1. Introduction 87 Considerable interest exists for a set of features that fit within 88 the general category of "roaming capability" for network access, 89 including dialup Internet users, VPN usage, wireless LAN 90 authentication, and other applications. Interested parties have 91 included: 92 o Regional Internet Service Providers (ISPs) operating within a 93 particular state or province, looking to combine their efforts 94 with those of other regional providers to offer dialup service 95 over a wider area. 96 o National ISPs wishing to combine their operations with those of 97 one or more ISPs in another nation to offer more comprehensive 98 dialup service in a group of countries or on a continent. 99 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: 120 Network Access Identifier 122 The Network Access Identifier (NAI) is the user identity submitted 123 by the client during network access authentication. In roaming, 124 the purpose of the NAI is to identify the user as well as to 125 assist in the routing of the authentication request. Please note 126 that the NAI may not necessarily be the same as the user's e-mail 127 address or the user identity submitted in an application layer 128 authentication. 129 Network Access Server 131 The Network Access Server (NAS) is the device that clients connect 132 to in order to get access to the network. In PPTP terminology 133 this is referred to as the PPTP Access Concentrator (PAC), and in 134 L2TP terminology, it is referred to as the L2TP Access 135 Concentrator (LAC). In IEEE 802.11, it is referred to as an 136 Access Point. 137 Roaming Capability 139 Roaming capability can be loosely defined as the ability to use 140 any one of multiple Internet service providers (ISPs), while 141 maintaining a formal, customer-vendor relationship with only one. 142 Examples of cases where roaming capability might be required 143 include ISP "confederations" and ISP- provided corporate network 144 access support. 145 Tunneling Service 147 A tunneling service is any network service enabled by tunneling 148 protocols such as PPTP, L2F, L2TP, and IPsec tunnel mode. One 149 example of a tunneling service is secure access to corporate 150 intranets via a Virtual Private Network (VPN). 152 1.2 Requirements language 154 In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", 155 "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as 156 described in [2]. 158 1.3 Purpose 160 As described in [7], there are a number of providers offering network 161 access services, and the number of Internet Service Providers 162 involved in roaming consortia is increasing rapidly. 164 In order to be able to offer roaming capability, one of the 165 requirements is to be able to identify the user's home authentication 166 server. For use in roaming, this function is accomplished via the 167 Network Access Identifier (NAI) submitted by the user to the NAS in 168 the initial network authentication. It is also expected that NASes 169 will use the NAI as part of the process of opening a new tunnel, in 170 order to determine the tunnel endpoint. 172 2. NAI Definition 174 2.1 Formal Syntax 176 The grammar for the NAI is given below, described in ABNF as 177 documented in [3]. The grammar for the username is based on [6], and 178 the grammar for the realm is an updated version of [1]. 180 nai = username 181 nai =/ "@" realm 182 nai =/ username "@" realm 184 username = dot-string 185 dot-string = string 186 dot-string =/ dot-string "." string 187 string = char 188 string =/ string char 189 char = c 190 char =/ "\" x 192 c = %x21 ; '!' allowed 193 ; '"' not allowed 194 c =/ %x23 ; '#' allowed 195 c =/ %x24 ; '$' allowed 196 c =/ %x25 ; '%' allowed 197 c =/ %x26 ; '&' allowed 198 c =/ %x27 ; ''' allowed 199 ; '(', ')' not allowed 200 c =/ %x2a ; '*' allowed 201 c =/ %x2b ; '+' allowed 202 ; ',' not allowed 203 c =/ %x2d ; '-' allowed 204 ; '.' not allowed 205 c =/ %x2f ; '/' allowed 206 c =/ %x30-39 ; '0'-'9' allowed 207 ; ';', ':', '<' not allowed 208 c =/ %x3d ; '=' allowed 209 ; '>' not allowed 210 c =/ %x3f ; '?' allowed 211 ; '@' not allowed 212 c =/ %x41-5a ; 'A'-'Z' allowed 213 ; '[', '\', ']' not allowed 214 c =/ %x5e ; '^' allowed 215 c =/ %x5f ; '_' allowed 216 c =/ %x60 ; '`' allowed 217 c =/ %x61-7a ; 'a'-'z' allowed 218 c =/ %x7b ; '{' allowed 219 c =/ %x7c ; '|' allowed 220 c =/ %x7d ; '}' allowed 221 c =/ %x7e ; '~' allowed 222 ; DEL not allowed 223 c =/ %x80-ff ; UTF-8 allowed (not in RFC 2486) 224 ; c must also satisfy rules in Section 2.4 225 x = %x00-7F ; all 128 ASCII characters, no exception 227 realm = 1*( label "." ) label 228 label = let-dig * (ldh-str) 229 ldh-str = *( alpha / digit / "-" ) let-dig 230 let-dig = alpha / digit 231 alpha = %x41-5A ; 'A'-'Z' 232 alpha =/ %x61-7A ; 'a'-'z' 233 digit = %x30-39 ; '0'-'9' 235 2.2 NAI Length Considerations 237 Devices handling NAIs MUST support an NAI length of at least 72 238 octets. Support for an NAI length of 253 octets is RECOMMENDED. 239 However, the following implementation issues should be considered: 240 o NAIs are often transported in the User-Name attribute of RADIUS. 241 Unfortunately, RFC 2865 [9] Section 5.1 states that "the ability 242 to handle at least 63 octets is recommended." As a result, it may 243 not be possible to transfer NAIs beyond 63 octets through all 244 devices. In addition, since only a single User-Name attribute may 245 be included in a RADIUS message and the maximum attribute length 246 is 253 octets, RADIUS is unable to support NAI lengths beyond 253 247 octets. 248 o NAIs can also be transported in the User-Name attribute of 249 Diameter [12], which supports content lengths up to 2^24 - 9 250 octets. As a result, NAIs processed only by Diameter nodes can be 251 very long. Unfortunately, an NAI transported over Diameter may 252 eventually be translated to RADIUS, in which case the above 253 limitations apply. 255 2.3 Support for Username Privacy 257 Interpretation of the "username" part of the NAI depends on the realm 258 in question. Therefore, the "username" part SHOULD be treated as 259 opaque data when processed by nodes that are not a part of the 260 authoritative domain (in the sense of Section 4) for that realm. 262 Where privacy is a concern, NAIs MAY be provided in an abbreviated 263 form by omitting the username portion. This is possible only when 264 NAIs are used together with a separate authentication method that can 265 transfer the username in a secure manner. 267 For roaming purposes it is typically necessary to locate the 268 appropriate backend authentication server for the given NAI before 269 the authentication conversation can proceed. As a result, the realm 270 portion is typically required in order for the authentication 271 exchange to be routed to the appropriate server. 273 2.4 International Character Sets 275 This specification allows both international usernames and realms. 276 International usernames are based on the use of Unicode characters, 277 encoded as UTF-8 and processed with a certain algorithm to ensure a 278 canonical representation. The realm part internationalization is 279 based on International Domain Name (IDN) [4]. 281 In order to ensure a canonical representation, characters of the 282 username portion in an NAI MUST fulfill the requirements specified in 283 [5]. In addition, the use of certain special characters (see grammar 284 rule c) are prohibited as well in order to retain compatibility with 285 the previous version of this RFC. 287 The realm name is an "IDN-unaware domain name slot" as defined in 288 [4]. That is, it can contain only ASCII characters. An 289 implementation MAY support internationalized domain names (IDNs) 290 using the ToASCII operation; see [4] for more information. 292 2.5 Compatibility with E-Mail Usernames 294 As proposed in this document, the Network Access Identifier is of the 295 form user@realm. Please note that while the user portion of the NAI 296 is based on the BNF described in [6], it has been extended for 297 internationalization support as well as for purposes of Section 2.7, 298 and is not necessarily compatible with the usernames used in e-mail. 299 Note also that the internationalization requirements for NAIs and 300 e-mail addresses are different, since the former need to be typed in 301 only by the user himself and his own operator, not by others. 303 2.6 Compatibility with DNS 305 The BNF of the realm portion allows the realm to begin with a digit, 306 which is not permitted by the BNF described in [1]. This change was 307 made to reflect current practice; although not permitted by the BNF 308 described in [1], FQDNs such as 3com.com are commonly used, and 309 accepted by current software. 311 2.7 Realm Construction 313 NAIs are used, among other purposes, for routing AAA transactions to 314 the user's home realm. Usually, the home realm appears in the realm 315 portion of the NAI, but in some cases a different realm can be used. 316 This may be useful, for instance, when the home realm is only 317 reachable via another mediating realm. 319 Such usage may prevent interoperability unless the parties involved 320 have a mutual agreement that the usage is allowed. In particular, 321 NAIs MUST NOT use a different realm than the home realm unless the 322 sender has explicit knowledge that (a) the specified other realm is 323 available and (b) the other realm supports such usage. The sender 324 may determine the fulfillment of these conditions through a database, 325 dynamic discovery, or other means not specified here. Note that the 326 first condition is affected by roaming, as the availability of the 327 other realm may depend on the user's location or the desired 328 application. 330 The use of the home realm MUST be the default unless otherwise 331 configured. 333 Where these conditions are fulfilled, an NAI such as 335 user@homerealm.example.net 337 MAY be represented as in 339 homerealm.example.net!user@otherrealm.example.net 341 In this case, the part before the (non-escaped) '!' MUST be a realm 342 name as defined in the ABNF in Section 2.1. When receiving such an 343 NAI, the other realm MUST convert the format back to 344 "user@homerealm.example.net" when passing the NAI forward, as well as 345 applying appropriate AAA routing for the transaction. 347 The conversion process may apply also recursively. That is, after 348 the conversion the result may still have one or more '!' characters 349 in the username. For instance, the NAI 351 other2.example.net!home.example.net!user@other1.example.net 353 would first be converted in other1.example net to 355 home.example.net!user@other2.example.net 357 and then at other2.example.net finally to 358 user@homerealm.example.net 360 2.8 Examples 362 Examples of valid Network Access Identifiers include: 364 bob 365 joe@example.com 366 fred@foo-9.example.com 367 jack@3rd.depts.example.com 368 fred_smith@example.com 369 fred=?#$&*+-/^smith@example.com 370 nancy@eng.example.net 371 eng.example.net!nancy@example.net 372 eng%nancy@example.net 373 @privatecorp.example.net 374 alice@xn--tmonesimerkki-bfbb.example.net 376 The last example uses an IDN converted into an ASCII representation. 378 Examples of invalid Network Access Identifiers include: 380 fred@foo 381 fred@foo_9.com 382 fred@bigco.com@example.net 383 eng:nancy@example.net 384 eng;nancy@example.net 385 @example.net 387 3. Security Considerations 389 Since an NAI reveals the home affiliation of a user, it may assist an 390 attacker in further probing the username space. Typically this 391 problem is of most concern in protocols which transmit the user name 392 in clear-text across the Internet, such as in RADIUS, described in 393 [9] and [10]. In order to prevent snooping of the user name, 394 protocols may use confidentiality services provided by protocols 395 transporting them, such RADIUS protected by IPsec [11] or Diameter 396 protected by TLS [12]. 398 This specification adds the possibility of hiding the username part 399 in the NAI, by omitting it. As discussed in Section 2.3, this is 400 possible only when NAIs are used together with a separate 401 authentication method that can transfer the username in a secure 402 manner. In some cases application-specific privacy mechanism have 403 also been used with NAIs. For instance, some EAP methods apply a 404 method-specific pseudonyms in the username part of the NAI. While 405 neither of these approaches can protect the realm part, their 406 advantage over transport protection is that privacy of the username 407 is protected even through intermediate nodes such as NASes. 409 4. IANA Considerations 411 In order to to avoid creating any new administrative procedures, 412 administration of the NAI realm namespace piggybacks on the 413 administration of the DNS namespace. 415 NAI realm names are required to be unique and the rights to use a 416 given NAI realm for roaming purposes are obtained coincident with 417 acquiring the rights to use a particular fully qualified domain name 418 (FQDN). Those wishing to use an NAI realm name should first acquire 419 the rights to use the corresponding FQDN. Using an NAI realm without 420 ownership of the corresponding FQDN creates the possibility of 421 conflict and therefore is to be discouraged. 423 Note that the use of an FQDN as the realm name does not require use 424 of the DNS for location of the authentication server. While Diameter 425 [12] supports the use of DNS for location of authentication servers, 426 existing RADIUS implementations typically use proxy configuration 427 files in order to locate authentication servers within a domain and 428 perform authentication routing. The implementations described in [7] 429 did not use DNS for location of the authentication server within a 430 domain. Similarly, existing implementations have not found a need 431 for dynamic routing protocols, or propagation of global routing 432 information. Note also that there is no requirement that that the 433 NAI represent a valid email address. 435 5. References 437 5.1 Normative References 439 [1] Mockapetris, P., "Domain names - implementation and 440 specification", STD 13, RFC 1035, November 1987. 442 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 443 Levels", BCP 14, RFC 2119, March 1997. 445 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 446 Specifications: ABNF", RFC 2234, November 1997. 448 [4] Faltstrom, P., Hoffman, P. and A. Costello, "Internationalizing 449 Domain Names in Applications (IDNA)", RFC 3490, March 2003. 451 [5] Zeilenga, K., "SASLprep: Stringprep profile for user names and 452 passwords", draft-ietf-sasl-saslprep-04 (work in progress), 453 October 2003. 455 5.2 Informative References 457 [6] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 458 August 1982. 460 [7] Aboba, B., Lu, J., Alsop, J., Ding, J. and W. Wang, "Review of 461 Roaming Implementations", RFC 2194, September 1997. 463 [8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 464 2486, January 1999. 466 [9] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 467 Authentication Dial In User Service (RADIUS)", RFC 2865, June 468 2000. 470 [10] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. 472 [11] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial 473 In User Service) Support For Extensible Authentication Protocol 474 (EAP)", RFC 3579, September 2003. 476 [12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko, 477 "Diameter Base Protocol", RFC 3588, September 2003. 479 [13] Arkko, J. and B. Aboba, "Network Discovery and Selection within 480 the EAP Framework", draft-ietf-eap-netsel-problem-00 (work in 481 progress), January 2004. 483 Authors' Addresses 485 Bernard Aboba 486 Microsoft 487 One Microsoft Way 488 Redmond, WA 98052 489 USA 491 EMail: bernarda@microsoft.com 493 Mark A. Beadles 494 SmartPipes 495 565 Metro Place South Suite 300 496 Dublin OH 43017 497 USA 499 EMail: mbeadles@smartpipes.com 501 Jari Arkko 502 Ericsson 503 Jorvas 02420 504 Finland 506 EMail: jari.arkko@ericsson.com 508 Pasi Eronen 509 Nokia Research Center 510 P.O. Box 407 511 FIN-00045 Nokia Group 512 Finland 514 EMail: pasi.eronen@nokia.com 516 Appendix A. Changes from RFC 2486 518 This draft contains the following updates with respect to the 519 original NAI definition in RFC 2486: 520 o International character set support has been added for both 521 usernames and realms. Note that this implies character codes 128 522 - 255 may be used in the username portion, which may be 523 unacceptable to nodes that only support RFC 2486. Many devices 524 already allow this behaviour, however. 525 o Username privacy support has been added. Note that NAIs without a 526 username (for privacy) may not be acceptable to RFC 2486 compliant 527 nodes. Many devices already allow this behaviour, however. 528 o A recommendation to support NAI length of at least 253 octets has 529 been added, and compatibility considerations among NAI lengths in 530 this specification and various AAA protocols are discussed. Note 531 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 However, as discussed in Section 2.7, this specification requires 539 that this syntax be applied only when there is explicit knowledge 540 that the peer system supports such syntax. 541 o The realm BNF entry definition has been changed to avoid an error 542 (infinite recursion) in the original specification. 543 o Several clarifications and improvements have been incorporated to 544 the ABNF specification for NAIs. 546 Appendix B. Acknowledgements 548 Thanks to Glen Zorn for many useful discussions of this problem 549 space, and for Farid Adrangi and others for suggesting mediating 550 network representation in NAIs. Jonathan Rosenberg reported the BNF 551 error. Dale Worley suggested clarifications of the x and special BNF 552 entries. Arne Norefors reported the length differences between RFC 553 2486 and RFC 2865. Kalle Tammela, Stefaan De Cnodder, Nagi Jonnala, 554 Bert Wijnen, Blair Bullock, Yoshihiro Ohba, and Richard Perlman 555 provided many useful comments on this draft. The ABNF validator at 556 http://www.apps.ietf.org/abnf.html was used to verify the syntactic 557 correctness of the ABNF in Section 2.1. 559 Intellectual Property Statement 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Disclaimer of Validity 585 This document and the information contained herein are provided on an 586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 588 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 589 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 590 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 593 Copyright Statement 595 Copyright (C) The Internet Society (2004). This document is subject 596 to the rights, licenses and restrictions contained in BCP 78, and 597 except as set forth therein, the authors retain all their rights. 599 Acknowledgment 601 Funding for the RFC Editor function is currently provided by the 602 Internet Society.