idnits 2.17.1 draft-ietf-crisp-iris-areg-15.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2149. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2126. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2133. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2139. ** 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. 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 : ---------------------------------------------------------------------------- == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 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 (May 25, 2006) is 6545 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: '10' is defined on line 1528, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1531, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3707 (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 1700 (ref. '10') (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 2434 (ref. '11') (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Gunduz 3 Internet-Draft RIPE NCC 4 Expires: November 26, 2006 A. Newton 5 VeriSign, Inc. 6 S. Kerr 7 RIPE NCC 8 May 25, 2006 10 IRIS - An Address Registry (areg) Type for the Internet Registry 11 Information Service 12 draft-ietf-crisp-iris-areg-15 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 26, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document describes an IRIS registry schema for IP address and 46 Autonomous System Number information. The schema extends the 47 necessary query and result operations of IRIS to provide the 48 functional information service needs for syntaxes and results used by 49 Internet Protocol address registries. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 5 55 3. Schema Description . . . . . . . . . . . . . . . . . . . . . . 6 56 3.1. Query Derivatives . . . . . . . . . . . . . . . . . . . . 6 57 3.1.1. Query . . . . . . . . . . . . . . . . . 6 58 3.1.2. . . . . . . . . . . . . . . . . . 6 59 3.1.3. and 60 . . . . . . . . . . . . . . . . . 7 61 3.1.4. . . . . . . . . . . . . . . . 7 62 3.1.5. . . . . . . . . . . . . . . . . 8 63 3.1.6. . . . . . . . . . . . . . . . . . . . 8 64 3.1.7. . . . . . . . . . . . . . . . . . . . 9 65 3.1.8. . . . . . . . . . . . . . . 9 66 3.1.9. Contact Search Group . . . . . . . . . . . . . . . . . 10 67 3.1.10. Common Search Group . . . . . . . . . . . . . . . . . 10 68 3.1.11. Match Parameters . . . . . . . . . . . . . . . . . . . 10 69 3.2. Result Derivatives . . . . . . . . . . . . . . . . . . . . 11 70 3.2.1. and Results . . . . . . . 11 71 3.2.2. Result . . . . . . . . . . . . . . 12 72 3.2.3. Result . . . . . . . . . . . . . . . . . . . 13 73 3.2.4. Result . . . . . . . . . . . . . . . . 13 74 3.2.5. Contact References . . . . . . . . . . . . . . . . . . 14 75 3.2.6. Common Result Child Elements . . . . . . . . . . . . . 15 76 3.3. Support for . . . . . . . . . . . . . 15 77 4. Terminology for Nesting of Networks . . . . . . . . . . . . . 16 78 5. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . . 20 79 6. BEEP Transport Compliance . . . . . . . . . . . . . . . . . . 33 80 6.1. Message Pattern . . . . . . . . . . . . . . . . . . . . . 33 81 6.2. Server Authentication . . . . . . . . . . . . . . . . . . 33 82 7. URI Resolution . . . . . . . . . . . . . . . . . . . . . . . . 34 83 7.1. Application Service Label . . . . . . . . . . . . . . . . 34 84 7.2. Operational Considerations . . . . . . . . . . . . . . . . 34 85 7.3. Top-Down Resolution . . . . . . . . . . . . . . . . . . . 34 86 8. Internationalization Considerations . . . . . . . . . . . . . 35 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 89 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38 90 11.1. Normative References . . . . . . . . . . . . . . . . . . . 38 91 11.2. Informative References . . . . . . . . . . . . . . . . . . 38 92 Appendix A. Privacy Considerations . . . . . . . . . . . . . . . 39 93 Appendix B. Example Requests and Responses . . . . . . . . . . . 40 94 B.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 40 95 B.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 41 97 Appendix C. Specificity Examples . . . . . . . . . . . . . . . . 45 98 Appendix D. Contributors . . . . . . . . . . . . . . . . . . . . 57 99 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 58 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 59 101 Intellectual Property and Copyright Statements . . . . . . . . . . 60 103 1. Introduction 105 An Internet address registry stores information about: 107 o address ranges 109 o autonomous system number ranges 111 o associated contacts and organizations 113 o name servers 115 This information is inter-related, and Internet address registries 116 store this information and the information's inter-relationships in a 117 manner befitting the needs of each Internet address registry and the 118 registry's constituents. This document specifies a methods for 119 accessing and retrieving this information in a common XML format. 121 This document describes an IRIS namespace for Internet address 122 registries using an XML Schema [9] derived from and using the IRIS 123 [2] schema. This schema and registry type are provided to 124 demonstrate the extensibility of the IRIS framework beyond the use of 125 domains, a criteria defined in CRISP [4]. 127 The schema given is this document is specified using the Extensible 128 Markup Language (XML) 1.0 as described in XML [6], XML Schema 129 notation as described in XML_SD [8] and XML_SS [9], and XML 130 Namespaces as described in XML_NS [7]. 132 Examples of client/server XML exchanges with this registry type are 133 available in Appendix B. 135 2. Document Terminology 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC2119 [1]. 141 3. Schema Description 143 IRIS requires the derivation of both query and result elements by a 144 registry schema. These descriptions follow. 146 The descriptions contained within this section refer to XML elements 147 and attributes and their relation to the exchange of data within the 148 protocol. These descriptions also contain specifications outside the 149 scope of the formal XML syntax. Therefore, this section will use 150 terms defined by RFC 2119 [1] to describe the specification outside 151 the scope of the formal XML syntax. While reading this section, 152 please reference Section 5 for needed details on the formal XML 153 syntax. 155 3.1. Query Derivatives 157 3.1.1. Query 159 searches for contacts given search constraints. 161 The allowable search fields are handled by one of the elements in the 162 "contactSearchGroup" (see Section 3.1.9) or the element 163 . The element constrains the query 164 based on the organization ID (handle) associated with contacts. This 165 element is an "exactMatchParameter" (see Section 3.1.11). 167 This query also provides optional elements containing 168 language tags. Clients MAY use these elements to give a hint about 169 the natural language(s) of the affected element. Servers MAY use 170 this information in processing the query, such as tailoring 171 normalization routines to aid in more effective searches. 173 The client SHOULD pass the names unchanged to the server, and the 174 implementation of the server decides if the search is case sensitive 175 or not. 177 3.1.2. 179 searches for organizations given search 180 constraints. 182 The allowable search fields are handled by one of the elements in the 183 "commonSearchGroup" (see Section 3.1.10) or the element 184 . This element is an 185 "exactOrPartialMatchParameter" (see Section 3.1.11). 187 This query also provides optional elements containing 188 language tags. Clients MAY use these elements to give a hint about 189 the natural language(s) of the affected element. Servers MAY use 190 this information in processing the query, such as tailoring 191 normalization routines to aid in more effective searches. 193 The client SHOULD pass the names unchanged to the server, and the 194 implementation of the server decides if the search is case sensitive 195 or not. 197 3.1.3. and 199 The and elements 200 allow searches by name of autonomous systems, and networks, 201 respectively. Both have the same format. 203 The child element is an "exactOrPartialMatchParameter" (see 204 Section 3.1.11). 206 This query also provides optional elements containing 207 language tags. Clients MAY use these elements to give a hint about 208 the natural language(s) of the affected element. Servers MAY use 209 this information in processing the query, such as tailoring 210 normalization routines to aid in more effective searches. 212 The client SHOULD pass the names unchanged to the server, and the 213 implementation of the server decides if the search is case sensitive 214 or not. 216 3.1.4. 218 The element is a query for a network given a 219 related IP address or IP address range. It has the following child 220 elements: 222 o - has a child element containing the 223 starting IPv4 address of the network and an optional child of 224 containing the ending IPv4 address of the network. Clients 225 MUST convert any short-form notation ot the fully-qualified 226 notation. 228 o - same as but the child addresses 229 contain IPv6 addresses. Clients MUST convert any short-form 230 notation to the fully-qualified notation. 232 o - determines the network specificity for the search 233 (see Section 4). Valid values are "exact-match", "all-less- 234 specific", "one-level-less-specific", "all-more-specific", and 235 "one-level-more-specific". This element may have the optional 236 attribute 'allowEquivalences'. When set to "true", the result set 237 should include networks with equivalent starting and ending 238 addresses. The default value for 'allowEquivalences' is "false". 240 The results from this query MUST be either the result 241 or the result. More than one network result MAY be 242 returned. 244 3.1.5. 246 The element is a query for a network given a 247 the handle of a related network. It has the following child 248 elements: 250 o - Specifies the network handle. 252 o - determines the network specificity for the search 253 (see Section 4). Valid values are "all-less-specifics", "one- 254 level-less-specifics", "all-more-specifics", and "one-level-more- 255 specifics". 257 The results from this query MUST be either the result 258 or the result. More than one network result MAY be 259 returned. 261 This query could be used to discover the parentage relationships 262 between networks that have the same starting and ending addresses. 264 The client SHOULD pass handles unchanged to the server, and the 265 implementation of the server decides if the search is case sensitive 266 or not. 268 3.1.6. 270 The element allows a search for autonomous systems 271 given an autonomous system number (ASN) range. It has the following 272 child elements: 274 o - Specifies the start of the ASN range. 276 o - Specifies the end of the ASN range. 278 o - determines the range specificity for the search 279 (see Section 4). Valid values are "exact-match", "all-less- 280 specific", "one-level-less-specific", "all-more-specific" and 281 "one-level-more-specific". This element may have the optional 282 attribute 'allowEquivalences'. When set to "true", the result set 283 should include ranges with equivalent starting and ending numbers. 284 The default value for 'allowEquivalences' is "false". 286 The results from this query MUST be result. More 287 than one result MAY be returned. 289 3.1.7. 291 The element allows a search for autonomous systems, 292 IP networks and organizations on fields associated with that entity's 293 contact. The optional search element MUST 294 restrict the results to autonomous systems, IPv4 networks, IPv6 295 networks, or organizations using the values 'returnASs', 296 'returnIPv4Networks', 'returnIPv6Networks', and 297 'returnOrganizations', respectively. 299 The allowable search fields are handled with either the 300 element or one of the elements in the 301 "contactSearchGroup" (see Section 3.1.9). The 302 element allows for the entities to be selected based on the contact 303 having the specified contact handle, and is an "exactMatchParameter" 304 type (see Section 3.1.11). The client SHOULD pass these search 305 fields unchanged to the server, and the implementation of the server 306 decides if the search is case sensitive or not. 308 The query MAY also be constrained further using the optional 309 element. The contents of this element signify the role the contact 310 has with the entity. The allowable values for this element are 311 "adminContact", "nocContact", "techContact", "abuseContact", and 312 "otherContact". 314 This query also provides optional elements containing 315 language tags. Clients MAY use these elements to give a hint about 316 the natural language(s) of the affected element. Servers MAY use 317 this information in processing the query, such as tailoring 318 normalization routines to aid in more effective searches. 320 The results from this query MUST be the results, the 321 results, the or 322 results. More than one result MAY be returned and the results MAY be 323 of mixed types. 325 3.1.8. 327 The element allows a search for IP 328 networks based on their associated name servers. The 329 element contains the fully qualified domain name of the name server. 330 The optional search element MUST restrict the 331 results to IPv4 networks or IPv6 networks using the values 332 'returnIPv4Networks' and 'returnIPv6Networks', respectively. 334 The results from this query MUST be the or the 335 results. More than one result MAY be returned and the 336 results MAY be of mixed types. 338 3.1.9. Contact Search Group 340 Some of the queries above have similar query constraints for 341 searching on contacts. This section describes those common 342 parameters. 344 allows the query to be constrained based on the common 345 name of the contact. This constraint is an 346 "exactOrPartialMatchParameter" (see Section 3.1.11). 348 This group also contains all the members of the "commonSearchGroup" 349 (see Section 3.1.10). 351 3.1.10. Common Search Group 353 Some of the queries above have similar query constraints for 354 searching on contacts. This section describes those common 355 parameters. 357 constrains the query based on the e-mail address of the 358 contact. This constraint is a "domainResource" type (see 359 Section 3.1.11). 361 The , , and elements restrict 362 the scope of the query based on the city, region, country, or postal 363 code of the contact, respectively. These constraints are all 364 "exactMatchParameter" types (see Section 3.1.11). The contents of 365 MUST be compliant with ISO 3166 [12] two-character country 366 codes. 368 3.1.11. Match Parameters 370 Some of the queries above have constraints that match strings using 371 matching parameters. This section describes those matching 372 parameters. 374 Elements of type "exactMatchParameter" will have one child element of 375 . The contents of this child element are to match 376 exactly in the use of the constraint. 378 Elements of type "partialMatchParameter" will have either a 379 child element with an optional child element 380 or an child element. The content of the 381 element specifies the beginning character sequence for the 382 constraint. The content of the element specifies the 383 ending character sequence for the constraint. 385 Elements of type "exactOrPartialMatchParameter" can have either the 386 child element allowed with the "exactMatchParameter" type or the 387 child elements allowed with the "partialMatchParameter" type. 389 Elements of type "domainResource" can have either the child element 390 allowed with the "exactMatchParameter" type or a child element of 391 . This parameter type is meant to match email, SIP, XMPP, 392 and other types of "user@domain" addresses. When this parameter is 393 specified with the child element, the constraint is 394 based on the whole email address. When this parameter is specified 395 with the child element, the constraint is based on any 396 email address within the domain given. The MUST only 397 contain a valid domain name (i.e. no '@' symbol), and the matching 398 SHOULD take place only on the domain given (i.e. no partial matches 399 with respect to substrings or parent domains). 401 3.2. Result Derivatives 403 3.2.1. and Results 405 The and share a common definition of 406 'ipNetworkType'. It has the following child elements: 408 o contains the registry unique assigned handle for 409 this network. 411 o contains a human friendly name for the network. 413 o contains the first IP address of the network. 415 o contains the last IP address of the network. 417 o contains a string denoting the type of network. 419 o is an entity reference to a definition of the 420 values explained in a plain natural language. The referent MUST 421 be a as defined by [2]. 423 o contains the domain name of a nameserver responsible 424 for reverse-DNS mapping for this network. 426 o contains an entity reference to the organization 427 assigned this network. The referent MUST be an 428 (Section 3.2.4) result. 430 o One of: 432 * contains an entity reference to the parent network of 433 this network. The referent MUST be an 434 (Section 3.2.1) result if this reference is a child of 435 . The referent MUST be an 436 (Section 3.2.1) result if this reference is a child of 437 . 439 * signifies that this network has not parent network. 441 o Contact references (see Section 3.2.5). 443 o Common child elements (see Section 3.2.6). 445 3.2.2. Result 447 The element represents an assigned or allocated 448 autonomous system number range. It has the following children: 450 o contains a registry unique assigned handle for this 451 autonomous system number range. 453 o contains an integer indicating the starting number 454 for the autonomous system number range. 456 o contains an integer indicating the ending number for 457 the autonomous system number range. 459 o contains a human readable name for this autonomous system. 461 o contains an entity reference to the organization 462 assigned or allocated this autonomous system number range. The 463 referent MUST be an (Section 3.2.4) result. 465 o One of: 467 * contains an entity reference to the parent autonomous 468 system of this autonomous system. The referent MUST be an 469 (Section 3.2.2) result. 471 * signifies that this autonomous system as no parent 472 autonomous system. 474 o Contact references (see Section 3.2.5). 476 o Common child elements (see Section 3.2.6). 478 3.2.3. Result 480 The element represents the registration of a point of 481 contact. It has the following child elements: 483 o contains the registry unique assigned handle for 484 this contact. 486 o specifies the name of the contact. 488 o contains the email address for this contact. 490 o contains the sip address for this contact. 492 o contains an entity reference to the organization 493 associated with this contact. The referent MUST be an 494 (Section 3.2.4) result. 496 o contains a information for reaching the contact 497 via postal mail. It is composed of the following child elements: 499 *
contains the address for this contact. 501 * contains the city where this contact is located. 503 * contains the national region where this contact is 504 located. 506 * contains the postal code where this contact is 507 located. 509 * contains the country code where this contact is 510 located. This MUST be compliant with ISO 3166 [12] two- 511 character country codes. 513 o contains child elements describing the phone number of the 514 contact. The child elements are , , and 515 . 517 o Common child elements (see Section 3.2.6). 519 3.2.4. Result 521 The element represents an organization. It has the 522 following child elements: 524 o contains the name of the organization. 526 o contains a registry unique identifier for this organization. 528 o contains the email address for this organization. 530 o contains a information for reaching the 531 organization via postal mail. It is composed of the following 532 child elements: 534 *
contains the address for this organization. 536 * contains the city where this organization is located. 538 * contains the national region where this organization 539 is located. 541 * contains the postal code where this organization 542 is located. 544 * contains the country code where this organization is 545 located. This MUST be compliant with ISO 3166 [12] two- 546 character country codes. 548 o contains child elements describing the phone number of the 549 contact. The child elements are , , and 550 . 552 o Contact references (see Section 3.2.5). 554 o Common child elements (see Section 3.2.6). 556 3.2.5. Contact References 558 The registry schema defined in Section 5 normalizes out a group of 559 elements used to reference contacts. This group is used by many of 560 the result types for this registry. The group has the following 561 elements, each of which may appear as many times as needed. The 562 referent of each MUST be (Section 3.2.3) results. 564 o 566 o 568 o 570 o 572 o 574 3.2.6. Common Result Child Elements 576 The registry schema defined in Section 5 normalizes out a group of 577 common elements used most of the result types. The group has the 578 following elements: 580 o contains an entity reference to the 581 number resource registry of record. The referent MUST be an 582 (Section 3.2.4) result. 584 o contains the date of first registration. 586 o contains the date when the registration was last 587 updated. 589 o The element contains an entity reference specifying 590 an entity that is indirectly associated with this result object. 591 This element can be used for comments and remarks. 593 3.3. Support for 595 The following types of entity classes are recognized by the 596 query of IRIS for this registry: 598 o ipv4-handle - a registry unique identifier specifying an IPv4 599 network. Queries with these names will yield a 600 result. 602 o ipv6-handle - a registry unique identifier specifying an IPv6 603 network. Queries with these names will yield a 604 result. 606 o as-handle - a registry unique identifier specifying an autonomous 607 system. It yields a result of . 609 o contact-handle - a registry unique identifier of a contact. 610 Yields a result of . 612 o organization-id - a registry unique identifier of an organization. 613 Yields a result of . 615 o The entity names of these entity classes are case insensitive. 617 4. Terminology for Nesting of Networks 619 The following terms are defined for describing the nesting of IP 620 networks. 622 o More specific: Given two networks, A and B, A is more specific 623 than B if network B includes all space of network A, and if 624 network B is larger than network A. 626 o Less specific: Opposite of more specific. The network B is less 627 specific than network A if network A's space is completely 628 included in network B and if network A is smaller than network B. 630 o Most specific: Given a set of networks, the network or networks 631 that are more specific than zero or more specific of the other 632 networks in the set, and that are not less specific of any of the 633 networks in the set. 635 o Least specific: Given a set of networks, the network or networks 636 that are not more specific to any of the other networks in the 637 set. 639 Examples: 641 +-------------------------------------------------------+ 642 | | 643 | Given the networks A, B, C and D as follows: | 644 | | 645 | A |---------------------------------| | 646 | B |-----------------| | 647 | C |---------| | 648 | D |-------| | 649 | | 650 | | 651 | The network A is less specific than B, C and D. | 652 | The network B is more specific than A. | 653 | Among these four networks, A is the least specific, | 654 | and C and D are the most specific networks. | 655 | | 656 +-------------------------------------------------------+ 658 Figure 1: Nesting Example 1 659 +-------------------------------------------------------+ 660 | | 661 | Given the networks E, F and G: | 662 | | 663 | E |----------| | 664 | F |--------------| | 665 | G |---| | 666 | | 667 | The networks E and F are least specific networks. | 668 | The networks F and G are most specific networks. | 669 | | 670 +-------------------------------------------------------+ 672 Figure 2: Nesting Example 2 674 The following definitions assume that there are no overlapping 675 networks in the database. A network overlaps with another one when 676 they encompass each other's space partially. Examples: 678 A |---------------------| 679 B |----------------------------| 681 Figure 3: Nesting Example 3 683 Here, the networks A and B are overlapping networks because network A 684 encompasses network B's space partially and network B encompasses 685 network A's space partially. 687 C |------------------| 688 D |---------| 690 Figure 4: Nesting Example 4 692 Here, the networks C and D are NOT overlapping networks, because even 693 if network D encompasses a part of network C's space, network C does 694 not encompass network D's space partially (it encompasses network D 695 completely). 697 The address directory can contain more than one network with the same 698 range. They are said to be exact match networks. 700 Parent/child relationship in the internet address directory is 701 unidirectional. That is, there might also be parent/child 702 relationship with exact match networks, but a network cannot be a 703 parent and a child of its exact match network at the same time. 705 Nested matching searches: 707 [1] all less specifics search: Given a range, find all the networks 708 that contain that range (ie, all less specifics and exact matches). 709 These networks are the networks that fulfill the following condition: 711 (start(network) <= start(search)) AND (end(network) >= end(search)) 713 [2] one-level less specifics search: Given a range, find only the 714 most specific network that contains that range (could be multiple 715 networks, but usually single); This is the set of networks from [1], 716 with the provision that: no network in the return set is contained by 717 any other network in the set. If there are exact match networks in 718 the set from [1], they both must appear in the result set. The 719 result set may contain a network that is exact match to the query 720 range, if the search allows exact matches. 722 A |-------------------------------| 723 B |---------------------------| 724 C |-------| 725 Query |- - - - - - - - - -| 727 Figure 5: Nesting Example 5 729 In the above case, the query must return B. 731 A |-------------------------------| 732 B |---------------------------| 733 C |---------------------------| 734 D |-------| 735 Query |- - - - - - - - - -| 737 Figure 6: Nesting Example 6 739 Here, the query must return B and C (they are exact matches of each 740 other). 742 A |-------------------------------| 743 B |---------------------------| 744 C |---------------------------| 745 D |-------| 746 Query |- - - -| 748 Figure 7: Nesting Example 7 750 Here, the query must return B and C (they are exact matches of each 751 other). D must not be in the result set, as it is exact match to the 752 query if the search specifies that exact matches of query range 753 should not appear in the result set. 755 In the example 7, if the search specifies that exact matches to the 756 query range are allowed in the result set, then only D must be 757 returned. 759 [3] all more specifics search: Given a range, find all the networks 760 that are fully within that range. The search contains a flag that 761 specifies if an exact match to the query range should appear in the 762 result set or not. Thus, the result set may or may not contain the 763 exact match to the query range, as instructed by the search. 765 (start(network) >= start(search)) AND (end(network) <= end(search)) 767 [4] one-level more specifics search: Given a range, find only the 768 least specific networks that are fully within that range. This is 769 the set of networks from [3], with the provision that: 771 no network in the return set contains any other network in the return 772 set. 774 Query |- - - - - - - - - - - - - - - - - - - - - - -| 776 A |------------------| 777 B |-------------------------| 778 C |--------| 779 D |---------| 781 Figure 8: Nesting Example 8 783 [5] exact match search: Given a range, find the networks that begin 784 and end on the same IP addresses as the range. 786 That is, the networks that fulfill the following condition: 788 (start(network) = start(search)) AND (end(network) = end(search)) 790 [6] Given a range find the exact match network if exists, and if not, 791 perform the [2] search. 793 Parent-child relationship searches: 795 [6] Given a network handle, find the network that is the direct (one 796 level up) parent of the network with the given handle. 798 [7] Given a network handle, find the network or networks that are 799 direct (one level down) children of the network with the handle 800 given. 802 5. Formal XML Syntax 804 This IP address registry is specified in the XML Schema notation. 805 The formal syntax presented here is a complete schema representation 806 suitable for automated validation of an XML instance when combined 807 with the formal schema syntax of IRIS. 809 810 816 818 819 IP address registry schema derived from IRIS 820 schema 821 823 824 825 826 828 829 830 831 832 834 835 836 837 838 840 842 843 844 845 847 850 854 855 856 857 859 860 861 862 863 864 866 867 868 870 871 872 873 874 875 877 879 880 881 882 883 884 886 887 888 889 890 891 892 893 895 899 900 901 903 904 905 906 907 908 910 911 912 913 914 916 917 918 919 920 921 922 923 925 928 929 930 932 933 934 935 936 937 938 939 940 942 943 944 946 947 948 949 950 951 952 954 955 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 979 980 981 982 984 987 988 989 991 992 993 994 995 996 998 999 1000 1001 1003 1007 1008 1009 1011 1012 1013 1014 1015 1016 1017 1018 1020 1021 1022 1024 1025 1026 1027 1028 1029 1030 1032 1033 1035 1036 1037 1038 1040 1043 1044 1045 1047 1048 1049 1050 1051 1052 1054 1055 1056 1058 1059 1060 1061 1063 1066 1067 1068 1070 1071 1072 1073 1074 1075 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1089 1093 1094 1095 1097 1098 1099 1101 1102 1103 1105 1106 1107 1109 1110 1111 1112 1113 1114 1115 1116 1117 1119 1120 1121 1123 1124 1125 1126 1127 1128 1130 1131 1132 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1162 1163 1164 1165 1166 1167 1168 1170 1171 1172 1173 1174 1176 1177 1178 1179 1180 1182 1183 1184 1186 1187 1188 1189 1190 1192 1194 1195 1196 1197 1199 1201 1202 1204 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1218 1221 1224 1225 1226 1228 1229 1230 1231 1232 1234 1236 1238 1240 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1253 1256 1257 1258 1260 1261 1262 1263 1264 1266 1268 1270 1272 1274 1276 1277 1278 1280 1282 1284 1286 1288 1289 1290 1291 1292 1293 1294 1295 1297 1299 1300 1301 1302 1303 1304 1305 1306 1308 1311 1312 1313 1315 1316 1317 1318 1319 1321 1323 1324 1326 1327 1328 1330 1332 1334 1336 1338 1339 1340 1341 1342 1343 1344 1345 1347 1349 1350 1351 1352 1353 1354 1355 1356 1357 1359 1362 1363 1364 1366 1367 1368 1370 1372 1374 1376 1378 1380 1382 1383 1384 1386 1387 1388 1390 1392 1394 1396 1397 1398 1400 Figure 9 1402 6. BEEP Transport Compliance 1404 IRIS allows several extensions of the core capabilities. This 1405 section outlines those extensions allowable by IRIS-BEEP [3]. 1407 6.1. Message Pattern 1409 This registry type uses the default message pattern as described in 1410 IRIS-BEEP [3]. 1412 6.2. Server Authentication 1414 This registry type uses the default server authentication method as 1415 described in IRIS-BEEP [3]. 1417 7. URI Resolution 1419 7.1. Application Service Label 1421 See Section 9 for the application service label registration. 1423 7.2. Operational Considerations 1425 Address registries do not have natural links to DNS. Using reverse 1426 DNS tree presents problems for IP address delegation (for example, 1427 delegations do not fall into byte boundaries, unlike reverse DNS), 1428 and DNS does not currently contain any information regarding 1429 autonomous system delegation. 1431 Therefore, in order for the top-down resolution to operate properly, 1432 it is requested that the IAB instruct IANA to insert and maintain a 1433 NAPTR DNS resource record for areg.iris.arpa, as described in 1434 Section 9. 1436 7.3. Top-Down Resolution 1438 The top-down alternative resolution method MUST be identified as 1439 'top' in IRIS URIs. 1441 The process for this condition is as follows: 1443 1. The IRIS [2] direct-resolution process is tried against 1444 areg.iris.arpa. 1446 2. If the direct-resolution process yields no server for which a 1447 connection can be made, then a negative response is returned and 1448 no further action is taken. 1450 It is RECOMMENDED that IRIS clients issuing AREG1 requests use the 1451 'top' resolution method when no resolution method has been explicitly 1452 given by a user. IRIS servers accepting AREG1 requests seeking 1453 information for which they are not authoritative SHOULD refer clients 1454 using the 'top' resolution method. 1456 8. Internationalization Considerations 1458 This document lays out no new considerations for internationalization 1459 beyond that specified in IRIS [2]. 1461 9. IANA Considerations 1463 The following URN will need to be registered with IANA according to 1464 the IANA considerations defined in IRIS [2]: 1466 urn:ietf:params:xml:ns:areg1 1468 The following S-NAPTR application service label will need to be 1469 registered with IANA according to the IANA considerations defined in 1470 IRIS [2]: 1472 AREG1 1474 Under instructions from the IAB, the IANA will create a new second 1475 level domain under .arpa called iris (i.e. iris.arpa.). The contents 1476 of this new domain are to be under the control of the IAB. Under 1477 instructions from the IAB, the IANA will insert and maintain a NAPTR 1478 DNS resource record in the iris.arpa. domain for the name 1479 areg.iris.arpa. The initial contents for that record is: 1481 areg.iris.arpa. 1482 ;; order pref flags service re replacement 1483 IN NAPTR 100 10 "" "AREG1:iris.xpc:iris.lwz" "" areg.nro.net 1485 10. Security Considerations 1487 This document lays out no new considerations for security precautions 1488 beyond that specified in IRIS [2]. 1490 11. References 1492 11.1. Normative References 1494 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1495 Levels", RFC 2119, BCP 14, March 1997. 1497 [2] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information 1498 Service (IRIS) Core Protocol", RFC 3981, January 2005. 1500 [3] Newton, A. and M. Sanz, "Using the Internet Registry Information 1501 Service (IRIS) over the Blocks Extensible Exchange Protocol 1502 (BEEP)", RFC 3983, January 2005. 1504 [4] Newton, A., "Cross Registry Internet Service Protocol (CRISP) 1505 Requirements", RFC 3707, February 2004. 1507 11.2. Informative References 1509 [5] Mockapetris, P., "Domain names - implementation and 1510 specification", STD 13, RFC 1035, November 1987. 1512 [6] World Wide Web Consortium, "Extensible Markup Language (XML) 1513 1.0", W3C XML, February 1998, 1514 . 1516 [7] World Wide Web Consortium, "Namespaces in XML", W3C XML 1517 Namespaces, January 1999, 1518 . 1520 [8] World Wide Web Consortium, "XML Schema Part 2: Datatypes", 1521 W3C XML Schema, October 2000, 1522 . 1524 [9] World Wide Web Consortium, "XML Schema Part 1: Structures", 1525 W3C XML Schema, October 2000, 1526 . 1528 [10] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", RFC 1700, 1529 STD 2, October 1994. 1531 [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 1532 Considerations Section in RFCs", RFC 2434, BCP 26, 1533 October 1998. 1535 [12] International Organization for Standardization, "Codes for the 1536 representation of names of countries, 3rd edition", 1537 ISO Standard 3166, August 1988. 1539 Appendix A. Privacy Considerations 1541 Internet address registries store contact details and other 1542 information that may be abused. The XML Schema defined in this 1543 document purposefully makes the inclusion of any data in a response 1544 an option dependent on the needs and policies of the Internet address 1545 registry serving the data. 1547 Combined with the authentication mechanisms of an IRIS transfer 1548 protocol, Internet address registries may derive authorization 1549 policies to meet their needs without compromising general privacy 1550 policies. As an example, the constituents of an Internet address 1551 registry may create a policy whereby NOC contact email addresses are 1552 only to be available to members of the Internet address registry. To 1553 institute this policy, the XML elements for NOC contacts will never 1554 appear in a response to a user that has not been authenticated to be 1555 a member of the Internet address registry. 1557 Appendix B. Example Requests and Responses 1559 The examples in this section use the string "C:" to denote data sent 1560 by a client to a server and the string "S:" to denote data sent by a 1561 server to a client. 1563 B.1. Example 1 1565 The following is an example of entity lookup for the contact-handle 1566 of 'JN560-RIR1'. 1568 C: 1569 C: 1572 C: 1573 C: 1574 C: 1575 C: 1579 C: 1580 C: 1581 C: 1582 C: 1584 S: 1585 S: 1589 S: 1590 S: 1591 S: 1592 S: 1593 S: 1598 S: 1599 S: JN560-RIR1 1600 S: 1601 S: Bob Smurd 1602 S: 1603 S: 1609 S: 1611 S: Organization X, Inc. 1612 S: 1613 S: 1614 S: 1615 S: 1616 S: +1-703-555-5555 1617 S: office 1618 S: 1619 S: 1620 S: 1621 S: 1622 S: 1623 S: 1624 S: 1625 S: 1627 Figure 11: Example 1 1629 B.2. Example 2 1631 The following example shows a query to find the IP networks 1632 containing a given address. 1634 C: 1635 C: 1637 C: 1638 C: 1639 C: 1641 C: 1642 C: 1643 C: 192.0.2.134 1644 C: 1645 C: 1646 C: one-level-less-specific 1649 C: 1650 C: 1651 C: 1652 C: 1654 C: 1656 S: 1657 S: 1659 S: 1660 S: 1661 S: 1662 S: 1668 S: 1669 S: NET-192-0-2-128-1 1670 S: 1671 S: 1672 S: UU-192-0-2-D6 1673 S: 1674 S: 1675 S: 192.0.2.128 1676 S: 1677 S: 1678 S: 192.0.2.255 1679 S: 1680 S: reassigned 1681 S: 1685 S: 1686 S: Organization X, Inc. 1687 S: 1688 S: 1689 S: 1693 S: 1697 S: 1698 S: Smurd, Bob 1699 S: 1700 S: 1701 S: 1702 S: 2002-11-18T00:00:00-00:00 1703 S: 1704 S: 1705 S: 2002-11-18T00:00:00-00:00 1706 S: 1707 S: 1711 S: 1712 S: 1718 S: 1719 S: NET-192-0-2-0-2 1720 S: 1721 S: 1722 S: UU-192-0-2-0-D5 1723 S: 1724 S: 1725 S: 192.0.2.0 1726 S: 1727 S: 1728 S: 192.0.2.255 1729 S: 1730 S: direct allocation 1731 S: auth03.ns.example.org 1732 S: auth00.ns.example.org 1733 S: 1737 S: 1738 S: Organization Y, Inc. 1739 S: 1740 S: 1741 S: 1745 S: 1749 S: 1750 S: 2000-10-27T00:00:00-00:00 1751 S: 1752 S: 1753 S: 2002-02-13T00:00:00-00:00 1754 S: 1755 S: 1759 S: 1760 S: 1761 S: 1762 S: 1765 S: 1766 S: Addresses within this block are non-portable. 1767 S: 1768 S: 1769 S: 1770 S: 1771 S: 1772 S: 1774 Figure 12: Example 2 1776 Appendix C. Specificity Examples 1778 This section includes examples to clarify specificity options for 1779 network and ASN searches. 1781 A |------------------| 192.0.2.0 - 192.0.2.15 1783 B |------------------| 192.0.2.16 - 192.0.2.31 1785 C |--------------| 192.0.2.0 - 192.0.2.9 1787 D |---------------| 192.0.2.16 - 192.0.2.30 1789 E |---------------| 192.0.2.16 - 192.0.2.30 1791 F |--------| 192.0.2.0 - 192.0.2.5 1793 G |----| 192.0.2.6 - 192.0.2.9 1795 Contents of the DB 1797 Figure 13: Specificity Example 1 1799 A |------------------| 192.0.2.0 - 192.0.2.15 1801 B |------------------| 192.0.2.16 - 192.0.2.31 1803 C |--------------| 192.0.2.0 - 192.0.2.9 1805 D |---------------| 192.0.2.16 - 192.0.2.30 1807 E |---------------| 192.0.2.16 - 192.0.2.30 1809 F |--------| 192.0.2.0 - 192.0.2.5 1811 G |----| 192.0.2.6 - 192.0.2.9 1813 Query|- - - - - - - | 192.0.2.0 - 192.0.2.9 1815 Exact match [1] 1817 Result: C 1819 Figure 14: Specificity Example 2 1821 A |------------------| 192.0.2.0 - 192.0.2.15 1823 B |------------------| 192.0.2.16 - 192.0.2.31 1825 C |--------------| 192.0.2.0 - 192.0.2.9 1827 D |---------------| 192.0.2.16 - 192.0.2.30 1829 E |---------------| 192.0.2.16 - 192.0.2.30 1831 F |--------| 192.0.2.0 - 192.0.2.5 1833 G |----| 192.0.2.6 - 192.0.2.9 1835 Query|- - - - - - - - | 192.0.2.0 - 192.0.2.12 1837 Exact match [2] 1839 Result: None 1841 Figure 15: Specificity Example 3 1842 A |------------------| 192.0.2.0 - 192.0.2.15 1844 B |------------------| 192.0.2.16 - 192.0.2.31 1846 C |--------------| 192.0.2.0 - 192.0.2.9 1848 D |---------------| 192.0.2.16 - 192.0.2.30 1850 E |---------------| 192.0.2.16 - 192.0.2.30 1852 F |--------| 192.0.2.0 - 192.0.2.5 1854 G |----| 192.0.2.6 - 192.0.2.9 1856 Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15 1858 All more specifics, allowEquivalences = false 1860 Result: C, F & G (not A, which is exact match) 1862 Figure 16: Specificity Example 4 1863 A |------------------| 192.0.2.0 - 192.0.2.15 1865 B |------------------| 192.0.2.16 - 192.0.2.31 1867 C |--------------| 192.0.2.0 - 192.0.2.9 1869 D |---------------| 192.0.2.16 - 192.0.2.30 1871 E |---------------| 192.0.2.16 - 192.0.2.30 1873 F |--------| 192.0.2.0 - 192.0.2.5 1875 G |----| 192.0.2.6 - 192.0.2.9 1877 Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15 1879 All more specifics, allowEquivalences = true 1881 Result: A, C, F & G (A included, which is exact match) 1883 Figure 17: Specificity Example 5 1884 A |------------------| 192.0.2.0 - 192.0.2.15 1886 B |------------------| 192.0.2.16 - 192.0.2.31 1888 C |--------------| 192.0.2.0 - 192.0.2.9 1890 D |---------------| 192.0.2.16 - 192.0.2.30 1892 E |---------------| 192.0.2.16 - 192.0.2.30 1894 F |--------| 192.0.2.0 - 192.0.2.5 1896 G |----| 192.0.2.6 - 192.0.2.9 1898 Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15 1900 One level more specifics, allowEquivalences = false 1902 Result: C 1904 Figure 18: Specificity Example 6 1905 A |------------------| 192.0.2.0 - 192.0.2.15 1907 B |------------------| 192.0.2.16 - 192.0.2.31 1909 C |--------------| 192.0.2.0 - 192.0.2.9 1911 D |---------------| 192.0.2.16 - 192.0.2.30 1913 E |---------------| 192.0.2.16 - 192.0.2.30 1915 F |--------| 192.0.2.0 - 192.0.2.5 1917 G |----| 192.0.2.6 - 192.0.2.9 1919 Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15 1921 One level more specifics, allowEquivalences = true 1923 Result: A 1925 Figure 19: Specificity Example 7 1926 A |------------------| 192.0.2.0 - 192.0.2.15 1928 B |------------------| 192.0.2.16 - 192.0.2.31 1930 C |--------------| 192.0.2.0 - 192.0.2.9 1932 D |---------------| 192.0.2.16 - 192.0.2.30 1934 E |---------------| 192.0.2.16 - 192.0.2.30 1936 F |--------| 192.0.2.0 - 192.0.2.5 1938 G |----| 192.0.2.6 - 192.0.2.9 1940 Query |- - | 192.0.2.6 - 192.0.2.9 1942 All less specifics, allowEquivalences = true 1944 Result: A, C & G (G is included, exact match) 1946 Figure 20: Specificity Example 8 1947 A |------------------| 192.0.2.0 - 192.0.2.15 1949 B |------------------| 192.0.2.16 - 192.0.2.31 1951 C |--------------| 192.0.2.0 - 192.0.2.9 1953 D |---------------| 192.0.2.16 - 192.0.2.30 1955 E |---------------| 192.0.2.16 - 192.0.2.30 1957 F |--------| 192.0.2.0 - 192.0.2.5 1959 G |----| 192.0.2.6 - 192.0.2.9 1961 Query |- - | 192.0.2.6 - 192.0.2.9 1963 All less specifics, allowEquivalences = false 1965 Result: A & C (G is not included, exact match) 1967 Figure 21: Specificity Example 9 1968 A |------------------| 192.0.2.0 - 192.0.2.15 1970 B |------------------| 192.0.2.16 - 192.0.2.31 1972 C |--------------| 192.0.2.0 - 192.0.2.9 1974 D |---------------| 192.0.2.16 - 192.0.2.30 1976 E |---------------| 192.0.2.16 - 192.0.2.30 1978 F |--------| 192.0.2.0 - 192.0.2.5 1980 G |----| 192.0.2.6 - 192.0.2.9 1982 Query |- - | 192.0.2.6 - 192.0.2.9 1984 One level less specifics, allowEquivalences = true 1986 Result: G (the exact match) 1988 Figure 22: Specificity Example 10 1989 A |------------------| 192.0.2.0 - 192.0.2.15 1991 B |------------------| 192.0.2.16 - 192.0.2.31 1993 C |--------------| 192.0.2.0 - 192.0.2.9 1995 D |---------------| 192.0.2.16 - 192.0.2.30 1997 E |---------------| 192.0.2.16 - 192.0.2.30 1999 F |--------| 192.0.2.0 - 192.0.2.5 2001 G |----| 192.0.2.6 - 192.0.2.9 2003 Query |- - | 192.0.2.6 - 192.0.2.9 2005 One level less specifics, allowEquivalences = false 2007 Result: C 2009 Figure 23: Specificity Example 11 2010 A |------------------| 192.0.2.0 - 192.0.2.15 2012 B |------------------| 192.0.2.16 - 192.0.2.31 2014 C |--------------| 192.0.2.0 - 192.0.2.9 2016 D |---------------| 192.0.2.16 - 192.0.2.30 2018 E |---------------| 192.0.2.16 - 192.0.2.30 2020 F |--------| 192.0.2.0 - 192.0.2.5 2022 G |----| 192.0.2.6 - 192.0.2.9 2024 Query|- - - - - - | 192.0.2.0 - 192.0.2.8 2026 One level less specifics, allowEquivalences = false or true 2028 Result: C 2030 Figure 24: Specificity Example 12 2032 A |------------------| 192.0.2.0 - 192.0.2.15 2034 B |------------------| 192.0.2.16 - 192.0.2.31 2036 C |--------------| 192.0.2.0 - 192.0.2.9 2038 D |---------------| 192.0.2.16 - 192.0.2.30 2040 E |---------------| 192.0.2.16 - 192.0.2.30 2042 F |--------| 192.0.2.0 - 192.0.2.5 2044 G |----| 192.0.2.6 - 192.0.2.9 2046 Query = E 2048 Find parent (Query argument is a handle) 2050 Result: D 2052 Figure 25: Specificity Example 13 2054 A |------------------| 192.0.2.0 - 192.0.2.15 2056 B |------------------| 192.0.2.16 - 192.0.2.31 2058 C |--------------| 192.0.2.0 - 192.0.2.9 2060 D |---------------| 192.0.2.16 - 192.0.2.30 2062 E |---------------| 192.0.2.16 - 192.0.2.30 2064 F |--------| 192.0.2.0 - 192.0.2.5 2066 G |----| 192.0.2.6 - 192.0.2.9 2068 Query = D 2070 Find child (Query argument is a handle) 2072 Result: E 2074 Figure 26: Specificity Example 14 2076 Appendix D. Contributors 2078 David Blacka and Tim Christensen made substantial contributions to 2079 this document. 2081 Appendix E. Acknowledgements 2083 Eric Hall, William Leibzon, April Marine, George Michaelson, Tim 2084 Christensen Cathy Murphy, Andrei Robachevsky, Marcos Sanz, Frederico 2085 Neves, Ted Hardie and many others contributed constructively in the 2086 mailing list discussions and IETF Meeting sessions. 2088 Authors' Addresses 2090 Engin Gunduz 2091 RIPE NCC 2092 Singel 258 2093 Amsterdam 1016AB 2094 The Netherlands 2096 Phone: +31 20 535 4444 2097 Email: e.gunduz@computer.org 2099 Andrew L. Newton 2100 VeriSign, Inc. 2101 21345 Ridgetop Circle 2102 Sterling, VA 20166 2103 USA 2105 Phone: +1 703 948 3382 2106 Email: andy@hxr.us; anewton@verisignlabs.com 2108 Shane W. Kerr 2109 RIPE NCC 2110 Singel 258 2111 Amsterdam 1016AB 2112 The Netherlands 2114 Phone: +31 20 535 4444 2115 Email: shane@ripe.net 2117 Intellectual Property Statement 2119 The IETF takes no position regarding the validity or scope of any 2120 Intellectual Property Rights or other rights that might be claimed to 2121 pertain to the implementation or use of the technology described in 2122 this document or the extent to which any license under such rights 2123 might or might not be available; nor does it represent that it has 2124 made any independent effort to identify any such rights. Information 2125 on the procedures with respect to rights in RFC documents can be 2126 found in BCP 78 and BCP 79. 2128 Copies of IPR disclosures made to the IETF Secretariat and any 2129 assurances of licenses to be made available, or the result of an 2130 attempt made to obtain a general license or permission for the use of 2131 such proprietary rights by implementers or users of this 2132 specification can be obtained from the IETF on-line IPR repository at 2133 http://www.ietf.org/ipr. 2135 The IETF invites any interested party to bring to its attention any 2136 copyrights, patents or patent applications, or other proprietary 2137 rights that may cover technology that may be required to implement 2138 this standard. Please address the information to the IETF at 2139 ietf-ipr@ietf.org. 2141 Disclaimer of Validity 2143 This document and the information contained herein are provided on an 2144 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2145 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2146 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2147 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2148 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2149 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2151 Copyright Statement 2153 Copyright (C) The Internet Society (2006). This document is subject 2154 to the rights, licenses and restrictions contained in BCP 78, and 2155 except as set forth therein, the authors retain all their rights. 2157 Acknowledgment 2159 Funding for the RFC Editor function is currently provided by the 2160 Internet Society.