summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4698.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4698.txt')
-rw-r--r--doc/rfc/rfc4698.txt2691
1 files changed, 2691 insertions, 0 deletions
diff --git a/doc/rfc/rfc4698.txt b/doc/rfc/rfc4698.txt
new file mode 100644
index 0000000..78579d7
--- /dev/null
+++ b/doc/rfc/rfc4698.txt
@@ -0,0 +1,2691 @@
+
+
+
+
+
+
+Network Working Group E. Gunduz
+Request for Comments: 4698 RIPE NCC
+Category: Standards Track A. Newton
+ VeriSign, Inc.
+ S. Kerr
+ RIPE NCC
+ October 2006
+
+
+ IRIS: An Address Registry (areg) Type
+ for the Internet Registry Information Service
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2006).
+
+Abstract
+
+ This document describes an IRIS registry schema for IP address and
+ Autonomous System Number information. The schema extends the
+ necessary query and result operations of IRIS to provide the
+ functional information service needs for syntaxes and results used by
+ Internet Protocol address registries.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 1]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Document Terminology ............................................3
+ 3. Schema Description ..............................................3
+ 3.1. Query Derivatives ..........................................4
+ 3.1.1. <findContacts> Query ................................4
+ 3.1.2. <findOrganizations> .................................4
+ 3.1.3. <findAutonomousSystemsByName> and
+ <findNetworksByName> ................................5
+ 3.1.4. <findNetworksByAddress> .............................5
+ 3.1.5. <findNetworksByHandle> ..............................6
+ 3.1.6. <findASByNumber> ....................................6
+ 3.1.7. <findByContact> .....................................7
+ 3.1.8. <findNetworksByNameServer> ..........................7
+ 3.1.9. Contact Search Group ................................8
+ 3.1.10. Common Search Group ................................8
+ 3.1.11. Match Parameters ...................................8
+ 3.2. Result Derivatives .........................................9
+ 3.2.1. <ipv4Network> and <ipv6Network> Results .............9
+ 3.2.2. <autonomousSystem> Result ..........................10
+ 3.2.3. <contact> Result ...................................11
+ 3.2.4. <organization> Result ..............................12
+ 3.2.5. Contact References .................................12
+ 3.2.6. Common Result Child Elements .......................13
+ 3.3. Support for <iris:lookupEntity> ...........................13
+ 4. Terminology for Nesting of Networks ............................14
+ 5. Formal XML Syntax ..............................................18
+ 6. BEEP Transport Compliance ......................................31
+ 6.1. Message Pattern ...........................................31
+ 6.2. Server Authentication .....................................31
+ 7. URI Resolution .................................................31
+ 7.1. Application Service Label .................................31
+ 7.2. Operational Considerations ................................31
+ 7.3. Top-Down Resolution .......................................31
+ 8. Internationalization Considerations ............................32
+ 9. IANA Considerations ............................................32
+ 10. Security Considerations .......................................32
+ 11. References ....................................................33
+ 11.1. Normative References .....................................33
+ 11.2. Informative References ...................................33
+ Appendix A. Privacy Considerations ................................34
+ Appendix B. Example Requests and Responses ........................34
+ B.1. Example 1 .................................................34
+ B.2. Example 2 .................................................36
+ Appendix C. Specificity Examples ..................................39
+ Appendix D. Contributors ..........................................46
+ Appendix E. Acknowledgements ......................................46
+
+
+
+Gunduz, et al. Standards Track [Page 2]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+1. Introduction
+
+ An Internet address registry stores information about:
+
+ o address ranges
+
+ o autonomous system number ranges
+
+ o associated contacts and organizations
+
+ o name servers
+
+ This information is interrelated, and Internet address registries
+ store this information and the information's interrelationships in a
+ manner befitting the needs of each Internet address registry and its
+ constituents. This document specifies a method for accessing and
+ retrieving this information in a common XML format.
+
+ This document describes an IRIS namespace for Internet address
+ registries using an XML Schema [8] derived from and using the IRIS
+ [2] schema. This schema and registry type are provided to
+ demonstrate the extensibility of the IRIS framework beyond the use of
+ domains, a criteria defined in CRISP [4].
+
+ The schema given is this document is specified using the Extensible
+ Markup Language (XML) 1.0 as described in XML [5], XML Schema
+ notation as described in XML_SD [7] and XML_SS [8], and XML
+ Namespaces as described in XML_NS [6].
+
+ Examples of client/server XML exchanges with this registry type are
+ available in Appendix B.
+
+2. Document Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [1].
+
+3. Schema Description
+
+ IRIS requires the derivation of both query and result elements by a
+ registry schema. Descriptions for these follow.
+
+ The descriptions contained within this section refer to XML elements
+ and attributes and their relation to the exchange of data within the
+ protocol. These descriptions also contain specifications outside the
+ scope of the formal XML syntax. Therefore, this section will use
+ terms defined by RFC 2119 [1] to describe the specification outside
+
+
+
+Gunduz, et al. Standards Track [Page 3]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ the scope of the formal XML syntax. While reading this section,
+ please reference Section 5 for needed details on the formal XML
+ syntax.
+
+3.1. Query Derivatives
+
+3.1.1. <findContacts> Query
+
+ <findContacts> searches for contacts given search constraints.
+
+ The allowable search fields are handled by one of the elements in the
+ "contactSearchGroup" (see Section 3.1.9) or the element
+ <organizationId>. The <organizationId> element constrains the query
+ based on the organization ID (handle) associated with contacts. This
+ element is an "exactMatchParameter" (see Section 3.1.11).
+
+ This query also provides optional <language> elements containing
+ language tags. Clients MAY use these elements to give a hint about
+ the natural language(s) of the affected element. Servers MAY use
+ this information in processing the query, such as tailoring
+ normalization routines to aid in more effective searches.
+
+ The client SHOULD pass the names unchanged to the server, and the
+ implementation of the server decides if the search is case sensitive
+ or not.
+
+3.1.2. <findOrganizations>
+
+ <findOrganizations> searches for organizations given search
+ constraints.
+
+ The allowable search fields are handled by one of the elements in the
+ "commonSearchGroup" (see Section 3.1.10) or the element
+ <organizationName>. This element is an
+ "exactOrPartialMatchParameter" (see Section 3.1.11).
+
+ This query also provides optional <language> elements containing
+ language tags. Clients MAY use these elements to give a hint about
+ the natural language(s) of the affected element. Servers MAY use
+ this information in processing the query, such as tailoring
+ normalization routines to aid in more effective searches.
+
+ The client SHOULD pass the names unchanged to the server, and the
+ implementation of the server decides if the search is case sensitive
+ or not.
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 4]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+3.1.3. <findAutonomousSystemsByName> and <findNetworksByName>
+
+ The <findAutonomousSystemsByName> and <findNetworksByName> elements
+ allow searches by name of autonomous systems and networks,
+ respectively. Both have the same format.
+
+ The child element <name> is an "exactOrPartialMatchParameter" (see
+ Section 3.1.11).
+
+ This query also provides optional <language> elements containing
+ language tags. Clients MAY use these elements to give a hint about
+ the natural language(s) of the affected element. Servers MAY use
+ this information in processing the query, such as tailoring
+ normalization routines to aid in more effective searches.
+
+ The client SHOULD pass the names unchanged to the server, and the
+ implementation of the server decides if the search is case sensitive
+ or not.
+
+3.1.4. <findNetworksByAddress>
+
+ The <findNetworksByAddress> element is a query for a network given a
+ related IP address or IP address range. It has the following child
+ elements:
+
+ o <ipv4Address> - has a child <start> element containing the
+ starting IPv4 address of the network and an optional child of
+ <end> containing the ending IPv4 address of the network. Clients
+ MUST convert any short-form notation to the fully-qualified
+ notation.
+
+ o <ipv6Address> - same as <ipv4Address>, but the child addresses
+ contain IPv6 addresses. Clients MUST convert any short-form
+ notation to the fully-qualified notation.
+
+ o <specificity> - determines the network specificity for the search
+ (see Section 4). Valid values are "exact-match", "all-less-
+ specific", "one-level-less-specific", "all-more-specific", and
+ "one-level-more-specific". This element may have the optional
+ attribute 'allowEquivalences'. When it is set to "true", the
+ result set should include networks with equivalent starting and
+ ending addresses. The default value for 'allowEquivalences' is
+ "false".
+
+ The results from this query MUST be either <ipv4Network> or
+ <ipv6Network> results. More than one network result MAY be returned.
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 5]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+3.1.5. <findNetworksByHandle>
+
+ The <findNetworksByHandle> element is a query for a network given a
+ the handle of a related network. It has the following child
+ elements:
+
+ o <networkHandle> - specifies the network handle.
+
+ o <specificity> - determines the network specificity for the search
+ (see Section 4). Valid values are "all-less-specifics", "one-
+ level-less-specifics", "all-more-specifics", and "one-level-more-
+ specifics".
+
+ The results from this query MUST be either <ipv4Network> or
+ <ipv6Network> results. More than one network result MAY be returned.
+
+ This query could be used to discover the parentage relationships
+ between networks that have the same starting and ending addresses.
+
+ The client SHOULD pass handles unchanged to the server, and the
+ implementation of the server decides if the search is case sensitive
+ or not.
+
+3.1.6. <findASByNumber>
+
+ The <findASByNumber> element allows a search for autonomous systems
+ given an autonomous system number (ASN) range. It has the following
+ child elements:
+
+ o <asNumberStart> - specifies the start of the ASN range.
+
+ o <asNumberEnd> - specifies the end of the ASN range.
+
+ o <specificity> - determines the range specificity for the search
+ (see Section 4). Valid values are "exact-match", "all-less-
+ specific", "one-level-less-specific", "all-more-specific", and
+ "one-level-more-specific". This element may have the optional
+ attribute 'allowEquivalences'. When it is set to "true", the
+ result set should include ranges with equivalent starting and
+ ending numbers. The default value for 'allowEquivalences' is
+ "false".
+
+ The results from this query MUST be <autonomousSystem> results. More
+ than one result MAY be returned.
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 6]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+3.1.7. <findByContact>
+
+ The <findByContact> element allows a search for autonomous systems,
+ IP networks, and organizations on fields associated with that
+ entity's contact. The optional search element <returnedResultType>
+ MUST restrict the results to autonomous systems, IPv4 networks, IPv6
+ networks, or organizations using the values 'returnASs',
+ 'returnIPv4Networks', 'returnIPv6Networks', and
+ 'returnOrganizations', respectively.
+
+ The allowable search fields are handled with either the
+ <contactHandle> element or one of the elements in the
+ "contactSearchGroup" (see Section 3.1.9). The <contactHandle>
+ element allows for the entities to be selected based on the contact
+ having the specified contact handle, and it is an
+ "exactMatchParameter" type (see Section 3.1.11). The client SHOULD
+ pass these search fields unchanged to the server, and the
+ implementation of the server decides if the search is case sensitive
+ or not.
+
+ The query MAY also be constrained further using the optional <role>
+ element. The contents of this element signify the role the contact
+ has with the entity. The allowable values for this element are
+ "adminContact", "nocContact", "techContact", "abuseContact", and
+ "otherContact".
+
+ This query also provides optional <language> elements containing
+ language tags. Clients MAY use these elements to give a hint about
+ the natural language(s) of the affected element. Servers MAY use
+ this information in processing the query, such as tailoring
+ normalization routines to aid in more effective searches.
+
+ The results from this query MUST be <ipv4Network> results,
+ <ipv6Network> results, <autonomousSystem> results, or <organization>
+ results. More than one result MAY be returned, and the results MAY
+ be of mixed types.
+
+3.1.8. <findNetworksByNameServer>
+
+ The <findNetworksByNameServer> element allows a search for IP
+ networks based on their associated name servers. The <nameServer>
+ element contains the fully qualified domain name of the name server.
+ The optional search element <returnedResultType> MUST restrict the
+ results to IPv4 networks or IPv6 networks using the values
+ 'returnIPv4Networks' and 'returnIPv6Networks', respectively.
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 7]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ The results from this query MUST be <ipv4Network> or <ipv6Network>
+ results. More than one result MAY be returned, and the results MAY
+ be of mixed types.
+
+3.1.9. Contact Search Group
+
+ Some of the queries above have similar query constraints for
+ searching on contacts. This section describes those common
+ parameters.
+
+ <commonName> allows the query to be constrained based on the common
+ name of the contact. This constraint is an
+ "exactOrPartialMatchParameter" (see Section 3.1.11).
+
+ This group also contains all the members of the "commonSearchGroup"
+ (see Section 3.1.10).
+
+3.1.10. Common Search Group
+
+ Some of the queries above have similar query constraints for
+ searching on contacts. This section describes those common
+ parameters.
+
+ <eMail> constrains the query based on the e-mail address of the
+ contact. This constraint is a "domainResource" type (see
+ Section 3.1.11).
+
+ The <city>, <region>, <country>, and <postalCode> elements restrict
+ the scope of the query based on the city, region, country, or postal
+ code of the contact, respectively. These constraints are all
+ "exactMatchParameter" types (see Section 3.1.11). The contents of
+ <country> MUST be compliant with ISO 3166 [9] two-character country
+ codes.
+
+3.1.11. Match Parameters
+
+ Some of the queries above have constraints that match strings using
+ matching parameters. This section describes those matching
+ parameters.
+
+ Elements of type "exactMatchParameter" will have one child element of
+ <exactMatch>. The contents of this child element are to match
+ exactly in the use of the constraint.
+
+ Elements of type "partialMatchParameter" will have either a
+ <beginsWith> child element with an optional <endsWith> child element
+ or an <endsWith> child element. The content of the <beginsWith>
+
+
+
+
+Gunduz, et al. Standards Track [Page 8]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ element specifies the beginning character sequence for the
+ constraint. The content of the <endsWith> element specifies the
+ ending character sequence for the constraint.
+
+ Elements of type "exactOrPartialMatchParameter" can have either the
+ child element allowed with the "exactMatchParameter" type or the
+ child elements allowed with the "partialMatchParameter" type.
+
+ Elements of type "domainResource" can have either the child element
+ allowed with the "exactMatchParameter" type or a child element of
+ <inDomain>. This parameter type is meant to match email, SIP,
+ Extensible Messaging and Presence Protocol (XMPP), and other types of
+ "user@domain" addresses. When this parameter is specified with the
+ <exactMatch> child element, the constraint is based on the whole
+ email address. When this parameter is specified with the <inDomain>
+ child element, the constraint is based on any email address within
+ the domain given. The <inDomain> MUST only contain a valid domain
+ name (i.e., no '@' symbol), and the matching SHOULD take place only
+ on the domain given (i.e., no partial matches with respect to
+ substrings or parent domains).
+
+3.2. Result Derivatives
+
+3.2.1. <ipv4Network> and <ipv6Network> Results
+
+ The <ipv4Network> and <ipv6Network> share a common definition of
+ 'ipNetworkType'. It has the following child elements:
+
+ o <networkHandle> contains the registry-unique assigned handle for
+ this network.
+
+ o <name> contains a human-friendly name for the network.
+
+ o <startAddress> contains the first IP address of the network.
+
+ o <endAddress> contains the last IP address of the network.
+
+ o <networkType> contains a string denoting the type of network.
+
+ o <networkTypeInfo> is an entity reference to a definition of the
+ values explained in a plain natural language. The referent MUST
+ be a <simpleEntity> as defined by [2].
+
+ o <nameServer> contains the domain name of a nameserver responsible
+ for reverse-DNS mapping for this network.
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 9]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ o <organization> contains an entity reference to the organization
+ assigned this network. The referent MUST be an <organization>
+ (Section 3.2.4) result.
+
+ o One of the following:
+
+ * <parent> contains an entity reference to the parent network of
+ this network. The referent MUST be an <ipv4Network>
+ (Section 3.2.1) result if this reference is a child of
+ <ipv4Network>. The referent MUST be an <ipv6Network>
+ (Section 3.2.1) result if this reference is a child of
+ <ipv6Network>.
+
+ * <noParent> signifies that this network has no parent network.
+
+ o Contact references (see Section 3.2.5).
+
+ o Common child elements (see Section 3.2.6).
+
+3.2.2. <autonomousSystem> Result
+
+ The <autonomousSystem> element represents an assigned or allocated
+ autonomous system number range. It has the following children:
+
+ o <asHandle> contains a registry-unique assigned handle for this
+ autonomous system number range.
+
+ o <asNumberStart> contains an integer indicating the starting number
+ for the autonomous system number range.
+
+ o <asNumberEnd> contains an integer indicating the ending number for
+ the autonomous system number range.
+
+ o <name> contains a human-readable name for this autonomous system.
+
+ o <organization> contains an entity reference to the organization
+ assigned or allocated this autonomous system number range. The
+ referent MUST be an <organization> (Section 3.2.4) result.
+
+ o One of the following:
+
+ * <parent> contains an entity reference to the parent autonomous
+ system of this autonomous system. The referent MUST be an
+ <autonomousSystem> (Section 3.2.2) result.
+
+ * <noParent> signifies that this autonomous system has no parent
+ autonomous system.
+
+
+
+
+Gunduz, et al. Standards Track [Page 10]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ o Contact references (see Section 3.2.5).
+
+ o Common child elements (see Section 3.2.6).
+
+3.2.3. <contact> Result
+
+ The <contact> element represents the registration of a point of
+ contact. It has the following child elements:
+
+ o <contactHandle> contains the registry-unique assigned handle for
+ this contact.
+
+ o <commonName> specifies the name of the contact.
+
+ o <eMail> contains the email address for this contact.
+
+ o <sip> contains the sip address for this contact.
+
+ o <organization> contains an entity reference to the organization
+ associated with this contact. The referent MUST be an
+ <organization> (Section 3.2.4) result.
+
+ o <postalAddress> contains information for reaching the contact via
+ postal mail. It is composed of the following child elements:
+
+ * <address> contains the address for this contact.
+
+ * <city> contains the city where this contact is located.
+
+ * <region> contains the national region where this contact is
+ located.
+
+ * <postalCode> contains the postal code where this contact is
+ located.
+
+ * <country> contains the country code where this contact is
+ located. This MUST be compliant with ISO 3166 [9]
+ two-character country codes.
+
+ o <phone> contains child elements describing the phone number of the
+ contact. The child elements are <number>, <extension>, and
+ <type>.
+
+ o Common child elements (see Section 3.2.6).
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 11]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+3.2.4. <organization> Result
+
+ The <organization> element represents an organization. It has the
+ following child elements:
+
+ o <name> contains the name of the organization.
+
+ o <id> contains a registry-unique identifier for this organization.
+
+ o <eMail> contains the email address for this organization.
+
+ o <postalAddress> contains a information for reaching the
+ organization via postal mail. It is composed of the following
+ child elements:
+
+ * <address> contains the address for this organization.
+
+ * <city> contains the city where this organization is located.
+
+ * <region> contains the national region where this organization
+ is located.
+
+ * <postalCode> contains the postal code where this organization
+ is located.
+
+ * <country> contains the country code where this organization is
+ located. This MUST be compliant with ISO 3166 [9]
+ two-character country codes.
+
+ o <phone> contains child elements describing the phone number of the
+ contact. The child elements are <number>, <extension>, and
+ <type>.
+
+ o Contact references (see Section 3.2.5).
+
+ o Common child elements (see Section 3.2.6).
+
+3.2.5. Contact References
+
+ The registry schema defined in Section 5 normalizes out a group of
+ elements used to reference contacts. This group is used by many of
+ the result types for this registry. The group has the following
+ elements, each of which may appear as many times as needed. The
+ referent of each MUST be <contact> (Section 3.2.3) results.
+
+ o <adminContact>
+
+ o <techContact>
+
+
+
+Gunduz, et al. Standards Track [Page 12]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ o <nocContact>
+
+ o <abuseContact>
+
+ o <otherContact>
+
+3.2.6. Common Result Child Elements
+
+ The registry schema defined in Section 5 normalizes out a group of
+ common elements that are used most among the result types. The group
+ has the following elements:
+
+ o <numberResourceRegistry> contains an entity reference to the
+ number resource registry of record. The referent MUST be an
+ <organization> (Section 3.2.4) result.
+
+ o <registrationDate> contains the date of first registration.
+
+ o <lastUpdatedDate> contains the date when the registration was last
+ updated.
+
+ o The <iris:seeAlso> element contains an entity reference specifying
+ an entity that is indirectly associated with this result object.
+ This element can be used for comments and remarks.
+
+3.3. Support for <iris:lookupEntity>
+
+ The following types of entity classes are recognized by the
+ <lookupEntity> query of IRIS for this registry:
+
+ o ipv4-handle - a registry-unique identifier specifying an IPv4
+ network. Queries with these names will yield a <ipv4Network>
+ result.
+
+ o ipv6-handle - a registry-unique identifier specifying an IPv6
+ network. Queries with these names will yield a <ipv6Network>
+ result.
+
+ o as-handle - a registry-unique identifier specifying an autonomous
+ system. It yields a result of <autonomousSystem>.
+
+ o contact-handle - a registry-unique identifier of a contact.
+ Yields a result of <contact>.
+
+ o organization-id - a registry-unique identifier of an organization.
+ Yields a result of <organization>.
+
+ o The entity names of these entity classes are case insensitive.
+
+
+
+Gunduz, et al. Standards Track [Page 13]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+4. Terminology for Nesting of Networks
+
+ The following terms are defined for describing the nesting of IP
+ networks.
+
+ o More specific: Given two networks, A and B, A is more specific
+ than B if network B includes all space of network A, and if
+ network B is larger than network A.
+
+ o Less specific: Opposite of more specific. The network B is less
+ specific than network A if network A's space is completely
+ included in network B and if network A is smaller than network B.
+
+ o Most specific: Given a set of networks, the network or networks
+ that are more specific than zero or more specific of the other
+ networks in the set, and that are not less specific of any of the
+ networks in the set.
+
+ o Least specific: Given a set of networks, the network or networks
+ that are not more specific to any of the other networks in the
+ set.
+
+ Examples:
+
+ +-------------------------------------------------------+
+ | |
+ | Given the networks A, B, C, and D as follows: |
+ | |
+ | A |---------------------------------| |
+ | B |-----------------| |
+ | C |---------| |
+ | D |-------| |
+ | |
+ | |
+ | Network A is less specific than B, C, and D. |
+ | Network B is more specific than A. |
+ | Among these four networks, A is the least specific, |
+ | and C and D are the most specific. |
+ | |
+ +-------------------------------------------------------+
+
+ Figure 1: Nesting Example 1
+
+
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 14]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ +-------------------------------------------------------+
+ | |
+ | Given networks E, F, and G: |
+ | |
+ | E |----------| |
+ | F |--------------| |
+ | G |---| |
+ | |
+ | Networks E and F are least specific networks. |
+ | Networks F and G are most specific networks. |
+ | |
+ +-------------------------------------------------------+
+
+ Figure 2: Nesting Example 2
+
+ The following definitions assume that there are no overlapping
+ networks in the database. A network overlaps with another one when
+ they encompass each other's space partially. Examples:
+
+ A |---------------------|
+ B |----------------------------|
+
+ Figure 3: Nesting Example 3
+
+ Here, networks A and B are overlapping networks because network A
+ encompasses network B's space partially, and network B encompasses
+ network A's space partially.
+
+ C |------------------|
+ D |---------|
+
+ Figure 4: Nesting Example 4
+
+ Here, networks C and D are NOT overlapping networks because even if
+ network D encompasses a part of network C's space, network C does not
+ encompass network D's space partially (it encompasses network D
+ completely).
+
+ The address directory can contain more than one network with the same
+ range. They are said to be exact match networks.
+
+ The parent/child relationship in the internet address directory is
+ unidirectional. That is, there might also be parent/child
+ relationship with exact match networks, but a network cannot be a
+ parent and a child of its exact match network at the same time.
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 15]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ The following are nested matching searches:
+
+ (1) all less specifics search: Given a range, find all the networks
+ that contain that range (i.e., all less specifics and exact
+ matches). These networks are the networks that fulfill the
+ following condition:
+
+ (start(network) <= start(search)) AND (end(network) >= end(search))
+
+ (2) one-level less specifics search: Given a range, find only the
+ most specific network that contains that range (could be multiple
+ networks, but usually single). This is the set of networks from
+ (1), with the provision that no network in the return set is
+ contained by any other network in the set. If there are exact
+ match networks in the set from (1), they both must appear in the
+ result set. The result set may contain a network that is exact
+ match to the query range, if the search allows exact matches.
+
+ A |-------------------------------|
+ B |---------------------------|
+ C |-------|
+ Query |- - - - - - - - - -|
+
+ Figure 5: Nesting Example 5
+
+ In the above case, the query must return B.
+
+ A |-------------------------------|
+ B |---------------------------|
+ C |---------------------------|
+ D |-------|
+ Query |- - - - - - - - - -|
+
+ Figure 6: Nesting Example 6
+
+ Here, the query must return B and C (they are exact matches of
+ each other).
+
+ A |-------------------------------|
+ B |---------------------------|
+ C |---------------------------|
+ D |-------|
+ Query |- - - -|
+
+ Figure 7: Nesting Example 7
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 16]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ Here, the query must return B and C (they are exact matches of
+ each other). D must not be in the result set, as it is exact
+ match to the query if the search specifies that exact matches of
+ query range should not appear in the result set.
+
+ In Figure 7, if the search specifies that exact matches to the
+ query range are allowed in the result set, then only D must be
+ returned.
+
+ (3) all more specifics search: Given a range, find all the networks
+ that are fully within that range. The search contains a flag
+ that specifies if an exact match to the query range should appear
+ in the result set or not. Thus, the result set may or may not
+ contain the exact match to the query range, as instructed by the
+ search.
+
+ (start(network) >= start(search)) AND (end(network) <= end(search))
+
+ (4) one-level more specifics search: Given a range, find only the
+ least specific networks that are fully within that range. This
+ is the set of networks from (3), with the provision that no
+ network in the return set contains any other network in the
+ return set.
+
+ Query |- - - - - - - - - - - - - - - - - - - - - - -|
+
+ A |------------------|
+ B |-------------------------|
+ C |--------|
+ D |---------|
+
+ Figure 8: Nesting Example 8
+
+ (5) exact match search: Given a range, find the networks that begin
+ and end on the same IP addresses as the range. That is, the
+ networks that fulfill the following condition:
+
+ (start(network) = start(search)) AND (end(network) = end(search))
+
+ (6) Given a range, find the exact match network if it exists, and if
+ it does not, perform the (2) search.
+
+ The following are parent-child relationship searches:
+
+ (7) Given a network handle, find the network that is the direct (one
+ level up) parent of the network with the given handle.
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 17]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ (8) Given a network handle, find the network or networks that are
+ direct (one level down) children of the network with the handle
+ given.
+
+5. Formal XML Syntax
+
+ This IP address registry is specified in the XML Schema notation.
+ The formal syntax presented here is a complete schema representation
+ suitable for automated validation of an XML instance when combined
+ with the formal schema syntax of IRIS.
+
+
+ <?xml version="1.0"?>
+ <schema xmlns="http://www.w3.org/2001/XMLSchema"
+ xmlns:areg="urn:ietf:params:xml:ns:areg1"
+ xmlns:iris="urn:ietf:params:xml:ns:iris1"
+ targetNamespace="urn:ietf:params:xml:ns:areg1"
+ elementFormDefault="qualified" >
+
+ <import namespace="urn:ietf:params:xml:ns:iris1" />
+
+ <annotation>
+ <documentation> IP address registry schema derived from IRIS
+ schema </documentation>
+ </annotation>
+
+ <!-- ========================================= -->
+ <!-- -->
+ <!-- Query Types -->
+ <!-- -->
+
+ <!-- ========================================= -->
+ <!-- -->
+ <!-- Find Autonomous Systems By Name -->
+ <!-- Find Networks By Name -->
+ <!-- -->
+
+ <complexType name="findByNameType" >
+ <complexContent>
+ <extension base="iris:queryType">
+ <sequence>
+ <element name="name"
+ type="areg:exactOrPartialMatchParameter" />
+ <element name="language" type="language" minOccurs="0"
+ maxOccurs="unbounded"/>
+ </sequence>
+ </extension>
+ </complexContent>
+
+
+
+Gunduz, et al. Standards Track [Page 18]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ </complexType>
+
+ <element name="findNetworksByName" type="areg:findByNameType"
+ substitutionGroup="iris:query" />
+ <element name="findAutonomousSystemsByName"
+ type="areg:findByNameType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Address/Address Range type for -->
+ <!-- Find Network -->
+ <!-- -->
+
+ <complexType name="addressRangeType">
+ <sequence>
+ <element name="start" type="token" />
+ <element name="end" type="token" minOccurs="0" maxOccurs="1" />
+ </sequence>
+ </complexType>
+
+ <!-- -->
+ <!-- Find Networks By Address -->
+ <!-- -->
+
+ <complexType name="findNetworksByAddressType" >
+ <complexContent>
+ <extension base="iris:queryType">
+ <sequence>
+ <choice>
+ <element name="ipv4Address" type="areg:addressRangeType"
+ />
+ <element name="ipv6Address" type="areg:addressRangeType"
+ />
+ </choice>
+ <element name="specificity">
+ <complexType>
+ <simpleContent>
+ <extension base="areg:specificityType" >
+ <attribute name="allowEquivalences" type="boolean"
+ default="false" />
+ </extension>
+ </simpleContent>
+ </complexType>
+ </element>
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+
+
+Gunduz, et al. Standards Track [Page 19]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ <element name="findNetworksByAddress"
+ type="areg:findNetworksByAddressType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Find AS By Number -->
+ <!-- -->
+
+ <complexType name="findASByNumberType" >
+ <complexContent>
+ <extension base="iris:queryType">
+ <sequence>
+ <element name="asNumberStart" type="token" />
+ <element name="asNumberEnd" type="token" minOccurs="0"
+ maxOccurs="1" />
+ <element name="specificity">
+ <complexType>
+ <simpleContent>
+ <extension base="areg:specificityType" >
+ <attribute name="allowEquivalences" type="boolean"
+ default="false" />
+ </extension>
+ </simpleContent>
+ </complexType>
+ </element>
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element name="findASByNumber" type="areg:findASByNumberType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Specificity Type -->
+ <!-- -->
+
+ <simpleType name="specificityType">
+ <restriction base="string">
+ <enumeration value="exact-match" />
+ <enumeration value="all-less-specific" />
+ <enumeration value="one-level-less-specific" />
+ <enumeration value="all-more-specific" />
+ <enumeration value="one-level-more-specific" />
+ </restriction>
+ </simpleType>
+
+ <!-- -->
+
+
+
+Gunduz, et al. Standards Track [Page 20]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ <!-- Find By Contact -->
+ <!-- -->
+
+ <complexType name="findByContactType">
+ <complexContent>
+ <extension base="iris:queryType">
+ <sequence>
+ <choice>
+ <group ref="areg:contactSearchGroup" />
+ <element name="contactHandle"
+ type="areg:exactMatchParameter" />
+ </choice>
+ <element name="returnedResultType" minOccurs="0"
+ maxOccurs="1" >
+ <simpleType>
+ <restriction base="string" >
+ <enumeration value="returnASs" />
+ <enumeration value="returnIPv4Networks" />
+ <enumeration value="returnIPv6Networks" />
+ <enumeration value="returnOrganizations" />
+ </restriction>
+ </simpleType>
+ </element>
+ <element name="role" minOccurs="0" maxOccurs="1" >
+ <simpleType>
+ <restriction base="string" >
+ <enumeration value="adminContact" />
+ <enumeration value="techContact" />
+ <enumeration value="nocContact" />
+ <enumeration value="abuseContact" />
+ <enumeration value="otherContact" />
+ </restriction>
+ </simpleType>
+ </element>
+ <element name="language" type="language" minOccurs="0"
+ maxOccurs="unbounded"/>
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element name="findByContact" type="areg:findByContactType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Find Networks By Handle -->
+ <!-- -->
+
+
+
+
+Gunduz, et al. Standards Track [Page 21]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ <complexType name="findNetworksByHandleType" >
+ <complexContent>
+ <extension base="iris:queryType">
+ <sequence>
+ <element name="networkHandle" type="token" />
+ <element name="specificity"
+ type="areg:specificitySubsetType" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element name="findNetworksByHandle"
+ type="areg:findNetworksByHandleType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Specificity Subtype -->
+ <!-- -->
+
+ <simpleType name="specificitySubsetType">
+ <restriction base="string">
+ <enumeration value="all-less-specific" />
+ <enumeration value="one-level-less-specific" />
+ <enumeration value="all-more-specific" />
+ <enumeration value="one-level-more-specific" />
+ </restriction>
+ </simpleType>
+
+ <!-- -->
+ <!-- Find Contacts -->
+ <!-- -->
+
+ <complexType name="findContactsType">
+ <complexContent>
+ <extension base="iris:queryType">
+ <sequence>
+ <choice>
+ <group ref="areg:contactSearchGroup" />
+ <element name="organizationId"
+ type="areg:exactMatchParameter" />
+ </choice>
+ <element name="language" type="language" minOccurs="0"
+ maxOccurs="unbounded"/>
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+
+
+Gunduz, et al. Standards Track [Page 22]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ <element name="findContacts" type="areg:findContactsType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Find Organizations -->
+ <!-- -->
+
+ <complexType name="findOrganizationsType">
+ <complexContent>
+ <extension base="iris:queryType">
+ <sequence>
+ <choice>
+ <element name="organizationName"
+ type="areg:exactOrPartialMatchParameter" />
+ <group ref="areg:commonSearchGroup" />
+ </choice>
+ <element name="language" type="language" minOccurs="0"
+ maxOccurs="unbounded"/>
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element name="findOrganizations" type="areg:findOrganizationsType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Find Networks by Name Server -->
+ <!-- -->
+
+ <complexType name="findNetworksByNameServerType">
+ <complexContent>
+ <extension base="iris:queryType">
+ <sequence>
+ <element name="nameServer" type="normalizedString" />
+ <element name="returnedResultType" minOccurs="0"
+ maxOccurs="1" >
+ <simpleType>
+ <restriction base="string" >
+ <enumeration value="returnIPv4Networks" />
+ <enumeration value="returnIPv6Networks" />
+ </restriction>
+ </simpleType>
+ </element>
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+
+
+Gunduz, et al. Standards Track [Page 23]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ <element name="findNetworksByNameServer"
+ type="areg:findNetworksByNameServerType"
+ substitutionGroup="iris:query" />
+
+ <!-- -->
+ <!-- Contact Search Group -->
+ <!-- -->
+
+ <group name="contactSearchGroup">
+ <choice>
+ <element name="commonName"
+ type="areg:exactOrPartialMatchParameter" />
+ <group ref="areg:commonSearchGroup" />
+ </choice>
+ </group>
+
+ <!-- -->
+ <!-- Common Search Group -->
+ <!-- -->
+
+ <group name="commonSearchGroup">
+ <choice>
+ <element name="eMail" type="areg:domainResourceParameter" />
+ <element name="city" type="areg:exactMatchParameter" />
+ <element name="region" type="areg:exactMatchParameter" />
+ <element name="country" type="areg:exactMatchParameter" />
+ <element name="postalCode" type="areg:exactMatchParameter" />
+ </choice>
+ </group>
+
+ <!-- -->
+ <!-- Parameters for Search Groups -->
+ <!-- -->
+
+ <complexType name="exactOrPartialMatchParameter">
+ <choice>
+ <group ref="areg:partialMatchGroup" />
+ <group ref="areg:exactMatchGroup" />
+ </choice>
+ </complexType>
+
+ <complexType name="exactMatchParameter">
+ <group ref="areg:exactMatchGroup" />
+ </complexType>
+
+ <complexType name="partialMatchParameter">
+ <sequence>
+ <group ref="areg:partialMatchGroup" />
+
+
+
+Gunduz, et al. Standards Track [Page 24]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ </sequence>
+ </complexType>
+
+ <complexType name="domainResourceParameter" >
+ <choice>
+ <group ref="areg:exactMatchGroup" />
+ <element name="inDomain" type="token" />
+ </choice>
+ </complexType>
+
+ <group name="partialMatchGroup">
+ <choice>
+ <sequence>
+ <element name="beginsWith">
+ <simpleType>
+ <restriction base="token">
+ <minLength value="1"/>
+ </restriction>
+ </simpleType>
+ </element>
+ <element minOccurs="0" ref="areg:endsWith"/>
+ </sequence>
+ <element ref="areg:endsWith" />
+ </choice>
+ </group>
+
+ <element name="endsWith">
+ <simpleType>
+ <restriction base="token">
+ <minLength value="1"/>
+ </restriction>
+ </simpleType>
+ </element>
+
+ <group name="exactMatchGroup">
+ <sequence>
+ <element name="exactMatch" type="normalizedString" />
+ </sequence>
+ </group>
+
+ <!-- ========================================= -->
+ <!-- -->
+ <!-- Result Types -->
+ <!-- -->
+ <!-- ========================================= -->
+
+ <!-- -->
+ <!-- IPv4 and IPv6 Network Results -->
+
+
+
+Gunduz, et al. Standards Track [Page 25]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ <!-- -->
+
+ <complexType name="ipNetworkType">
+ <complexContent>
+ <extension base="iris:resultType">
+ <sequence>
+ <element name="networkHandle" type="token"
+ minOccurs="0" maxOccurs="1" />
+ <element name="name" minOccurs="0" maxOccurs="1"
+ type="normalizedString" />
+ <element name="startAddress" type="token" />
+ <element name="endAddress" type="token" />
+ <sequence minOccurs="0" maxOccurs="1">
+ <element name="networkType" type="normalizedString"
+ minOccurs="1" maxOccurs="1" />
+ <element name="networkTypeInfo" type="iris:entityType"
+ minOccurs="0" maxOccurs="1" />
+ </sequence>
+ <element name="nameServer" type="normalizedString"
+ minOccurs="0" maxOccurs="unbounded" />
+ <element name="organization" type="iris:entityType"
+ minOccurs="0" maxOccurs="1" />
+ <choice minOccurs="0" maxOccurs="1" >
+ <element name="parent" type="iris:entityType" />
+ <element name="noParent">
+ </element>
+ </choice>
+ <group ref="areg:contactGroup" />
+ <group ref="areg:commonGroup" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element name="ipv4Network" type="areg:ipNetworkType"
+ substitutionGroup="iris:result" />
+
+ <element name="ipv6Network" type="areg:ipNetworkType"
+ substitutionGroup="iris:result" />
+
+ <!-- -->
+ <!-- Autonomous System -->
+ <!-- -->
+
+ <complexType name="autonomousSystemType">
+ <complexContent>
+ <extension base="iris:resultType">
+ <sequence>
+
+
+
+Gunduz, et al. Standards Track [Page 26]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ <element name="asHandle" type="token"
+ minOccurs="0" maxOccurs="1" />
+ <element name="asNumberStart" type="integer" minOccurs="0"
+ maxOccurs="1" />
+ <element name="asNumberEnd" type="integer" minOccurs="0"
+ maxOccurs="1" />
+ <element name="name" type="normalizedString" minOccurs="0"
+ maxOccurs="1" />
+ <element name="organization" type="iris:entityType"
+ minOccurs="0" maxOccurs="1" />
+ <choice minOccurs="0" maxOccurs="1">
+ <element name="parent" type="iris:entityType" />
+ <element name="noParent" />
+ </choice>
+ <group ref="areg:contactGroup" />
+ <group ref="areg:commonGroup" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element name="autonomousSystem" type="areg:autonomousSystemType"
+ substitutionGroup="iris:result" />
+
+ <!-- -->
+ <!-- Contact -->
+ <!-- -->
+
+ <complexType name="contactType">
+ <complexContent>
+ <extension base="iris:resultType">
+ <sequence>
+ <element name="contactHandle" type="token"
+ minOccurs="0" maxOccurs="1" />
+ <element name="commonName" type="normalizedString"
+ minOccurs="0" maxOccurs="1" />
+ <element name="eMail" type="normalizedString" minOccurs="0"
+ maxOccurs="unbounded" />
+ <element name="sip" type="normalizedString" minOccurs="0"
+ maxOccurs="unbounded" />
+ <element name="organization" type="iris:entityType"
+ minOccurs="0" maxOccurs="unbounded" />
+ <element name="postalAddress" minOccurs="0"
+ maxOccurs="unbounded">
+ <complexType>
+ <sequence>
+ <element name="address" type="string" minOccurs="0"
+ maxOccurs="1" />
+
+
+
+Gunduz, et al. Standards Track [Page 27]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ <element name="city" type="string" minOccurs="0"
+ maxOccurs="1" />
+ <element name="region" type="string" minOccurs="0"
+ maxOccurs="1" />
+ <element name="postalCode" type="normalizedString"
+ minOccurs="0" maxOccurs="1" />
+ <element name="country" type="token" minOccurs="0"
+ maxOccurs="1" />
+ </sequence>
+ </complexType>
+ </element>
+ <element name="phone" minOccurs="0" maxOccurs="unbounded" >
+ <complexType>
+ <sequence>
+ <element name="number" type="normalizedString" />
+ <element name="extension" type="normalizedString"
+ minOccurs="0" maxOccurs="unbounded" />
+ <element name="type" type="normalizedString"
+ minOccurs="0" maxOccurs="1" />
+ </sequence>
+ </complexType>
+ </element>
+ <group ref="areg:commonGroup" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element name="contact" type="areg:contactType"
+ substitutionGroup="iris:result" />
+
+ <!-- -->
+ <!-- Organization -->
+ <!-- -->
+
+ <complexType name="organizationType">
+ <complexContent>
+ <extension base="iris:resultType">
+ <sequence>
+ <element name="name" type="normalizedString"
+ minOccurs="0" maxOccurs="1" />
+ <element name="eMail" type="normalizedString" minOccurs="0"
+ maxOccurs="unbounded" />
+ <element name="id" type="token" />
+ <element name="postalAddress" minOccurs="0"
+ maxOccurs="unbounded">
+ <complexType>
+ <sequence>
+
+
+
+Gunduz, et al. Standards Track [Page 28]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ <element name="address" type="string" minOccurs="0"
+ maxOccurs="1" />
+ <element name="city" type="string" minOccurs="0"
+ maxOccurs="1" />
+ <element name="region" type="string" minOccurs="0"
+ maxOccurs="1" />
+ <element name="postalCode" type="normalizedString"
+ minOccurs="0" maxOccurs="1" />
+ <element name="country" type="token" minOccurs="0"
+ maxOccurs="1" />
+ </sequence>
+ </complexType>
+ </element>
+ <element name="phone" minOccurs="0" maxOccurs="unbounded" >
+ <complexType>
+ <sequence>
+ <element name="number" type="normalizedString" />
+ <element name="extension" type="normalizedString"
+ minOccurs="0" maxOccurs="unbounded" />
+ <element name="type" type="normalizedString"
+ minOccurs="0" maxOccurs="1" />
+ </sequence>
+ </complexType>
+ </element>
+ <group ref="areg:contactGroup" />
+ <group ref="areg:commonGroup" />
+ </sequence>
+ </extension>
+ </complexContent>
+ </complexType>
+
+ <element name="organization" type="areg:organizationType"
+ substitutionGroup="iris:result" />
+
+ <!-- -->
+ <!-- Contact Group -->
+ <!-- -->
+
+ <group name="contactGroup">
+ <sequence>
+ <element name="adminContact" type="iris:entityType"
+ minOccurs="0" maxOccurs="unbounded" />
+ <element name="techContact" type="iris:entityType"
+ minOccurs="0" maxOccurs="unbounded" />
+ <element name="nocContact" type="iris:entityType" minOccurs="0"
+ maxOccurs="unbounded" />
+ <element name="abuseContact" type="iris:entityType"
+ minOccurs="0" maxOccurs="unbounded" />
+
+
+
+Gunduz, et al. Standards Track [Page 29]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ <element name="otherContact" type="iris:entityType"
+ minOccurs="0" maxOccurs="unbounded" />
+ </sequence>
+ </group>
+
+ <!-- -->
+ <!-- Common Group -->
+ <!-- -->
+
+ <group name="commonGroup">
+ <sequence>
+ <element name="numberResourceRegistry" type="iris:entityType"
+ minOccurs="0" maxOccurs="1" />
+ <element name="registrationDate" type="dateTime" minOccurs="0"
+ maxOccurs="1" />
+ <element name="lastUpdatedDate" type="dateTime" minOccurs="0"
+ maxOccurs="1" />
+ <element ref="iris:seeAlso" minOccurs="0" maxOccurs="unbounded"
+ />
+ </sequence>
+ </group>
+ </schema>
+
+ Figure 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 30]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+6. BEEP Transport Compliance
+
+ IRIS allows several extensions of the core capabilities. This
+ section outlines those extensions allowable by IRIS-BEEP [3].
+
+6.1. Message Pattern
+
+ This registry type uses the default message pattern as described in
+ IRIS-BEEP [3].
+
+6.2. Server Authentication
+
+ This registry type uses the default server authentication method as
+ described in IRIS-BEEP [3].
+
+7. URI Resolution
+
+7.1. Application Service Label
+
+ See Section 9 for the application service label registration.
+
+7.2. Operational Considerations
+
+ Address registries do not have natural links to DNS. Using reverse
+ DNS tree presents problems for IP address delegation (for example,
+ delegations do not fall into byte boundaries, unlike reverse DNS),
+ and DNS does not currently contain any information regarding
+ autonomous system delegation.
+
+ Therefore, in order for the top-down resolution to operate properly,
+ it is requested that the IAB instruct IANA to insert and maintain a
+ NAPTR DNS resource record for areg.iris.arpa, as described in
+ Section 9.
+
+7.3. Top-Down Resolution
+
+ The top-down alternative resolution method MUST be identified as
+ 'top' in IRIS URIs.
+
+ The process for this condition is as follows:
+
+ 1. The IRIS [2] direct-resolution process is tried against
+ areg.iris.arpa.
+
+ 2. If the direct-resolution process yields no server for which a
+ connection can be made, then a negative response is returned, and
+ no further action is taken.
+
+
+
+
+Gunduz, et al. Standards Track [Page 31]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ It is RECOMMENDED that IRIS clients issuing AREG1 requests use the
+ 'top' resolution method when no resolution method has been explicitly
+ given by a user. IRIS servers accepting AREG1 requests that seek
+ information for which they are not authoritative SHOULD refer clients
+ using the 'top' resolution method.
+
+8. Internationalization Considerations
+
+ This document lays out no new considerations for internationalization
+ beyond those specified in IRIS [2].
+
+9. IANA Considerations
+
+ The following URN has been registered with IANA according to the IANA
+ considerations defined in IRIS [2]:
+
+ urn:ietf:params:xml:ns:areg1
+
+ The following S-NAPTR application service label has been registered
+ with IANA according to the IANA considerations defined in IRIS [2]:
+
+ AREG1
+
+ Under instructions from the IAB, the IANA will create a new second
+ level domain under .arpa called iris (i.e., iris.arpa.). The
+ contents of this new domain are to be under the control of the IAB.
+ Under instructions from the IAB, the IANA will insert and maintain a
+ NAPTR DNS resource record in the iris.arpa. domain for the name
+ areg.iris.arpa. The initial contents for that record is:
+
+ areg.iris.arpa.
+ ;; order pref flags service re replacement
+ IN NAPTR 100 10 "" "AREG1:iris.xpc:iris.lwz" "" areg.nro.net
+
+10. Security Considerations
+
+ This document lays out no new considerations for security precautions
+ beyond those specified in IRIS [2].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 32]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+11. References
+
+11.1. Normative References
+
+ [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [2] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information
+ Service (IRIS) Core Protocol", RFC 3981, January 2005.
+
+ [3] Newton, A. and M. Sanz, "Using the Internet Registry Information
+ Service (IRIS) over the Blocks Extensible Exchange Protocol
+ (BEEP)", RFC 3983, January 2005.
+
+ [4] Newton, A., "Cross Registry Internet Service Protocol (CRISP)
+ Requirements", RFC 3707, February 2004.
+
+11.2. Informative References
+
+ [5] World Wide Web Consortium, "Extensible Markup Language (XML)
+ 1.0", W3C XML, February 1998,
+ <http://www.w3.org/TR/1998/REC-xml-19980210>.
+
+ [6] World Wide Web Consortium, "Namespaces in XML", W3C XML
+ Namespaces, January 1999,
+ <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
+
+ [7] World Wide Web Consortium, "XML Schema Part 2: Datatypes",
+ W3C XML Schema, October 2000,
+ <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.
+
+ [8] World Wide Web Consortium, "XML Schema Part 1: Structures",
+ W3C XML Schema, October 2000,
+ <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
+
+ [9] International Organization for Standardization, "Codes for the
+ representation of names of countries, 3rd edition", ISO Standard
+ 3166, August 1988.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 33]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+Appendix A. Privacy Considerations
+
+ Internet address registries store contact details and other
+ information that may be abused. The XML Schema defined in this
+ document purposefully makes the inclusion of any data in a response
+ an option that is dependent on the needs and policies of the Internet
+ address registry serving the data.
+
+ Combined with the authentication mechanisms of an IRIS transfer
+ protocol, Internet address registries may derive authorization
+ policies to meet their needs without compromising general privacy
+ policies. As an example, the constituents of an Internet address
+ registry may create a policy whereby NOC contact email addresses are
+ only to be available to members of the Internet address registry. To
+ institute this policy, the XML elements for NOC contacts will never
+ appear in a response to a user that has not been authenticated to be
+ a member of the Internet address registry.
+
+Appendix B. Example Requests and Responses
+
+ The examples in this section use the string "C:" to denote data sent
+ by a client to a server and the string "S:" to denote data sent by a
+ server to a client.
+
+B.1. Example 1
+
+ The following is an example of entity lookup for the contact-handle
+ of 'JN560-RIR1'.
+
+ C: <?xml version="1.0"?>
+ C: <request xmlns="urn:ietf:params:xml:ns:iris1"
+ C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ C: xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >
+ C:
+ C: <searchSet>
+ C:
+ C: <lookupEntity
+ C: registryType="urn:ietf:params:xml:ns:areg1"
+ C: entityClass="contact-handle"
+ C: entityName="JN560-RIR1" />
+ C:
+ C: </searchSet>
+ C:
+ C: </request>
+
+ S: <?xml version="1.0"?>
+ S: <iris:response
+ S: xmlns:iris="urn:ietf:params:xml:ns:iris1"
+
+
+
+Gunduz, et al. Standards Track [Page 34]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ S: xmlns="urn:ietf:params:xml:ns:areg1"
+ S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ S:
+ S: <iris:resultSet>
+ S: <iris:answer>
+ S:
+ S: <contact
+ S: authority="rir.example.net"
+ S: registryType="areg1"
+ S: entityClass="contact-handle"
+ S: entityName="JN560-RIR1">
+ S:
+ S: <contactHandle>JN560-RIR1</contactHandle>
+ S:
+ S: <commonName>Bob Smurd</commonName>
+ S:
+ S: <organization
+ S: iris:referentType="organization"
+ S: authority="rir.example.net"
+ S: registryType="areg1"
+ S: entityClass="organization-id"
+ S: entityName="ORGX">
+ S: <iris:displayName
+ S: language="en">
+ S: Organization X, Inc.
+ S: </iris:displayName>
+ S: </organization>
+ S:
+ S: <phone>
+ S: <number>+1-703-555-5555</number>
+ S: <type>office</type>
+ S: </phone>
+ S:
+ S: </contact>
+ S:
+ S: </iris:answer>
+ S: </iris:resultSet>
+ S:
+ S: </iris:response>
+
+ Figure 11: Example 1
+
+
+
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 35]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+B.2. Example 2
+
+ The following example shows a query to find the IP networks
+ containing a given address.
+
+ C: <?xml version="1.0"?>
+ C: <request xmlns="urn:ietf:params:xml:ns:iris1"
+ C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ C:
+ C: <searchSet>
+ C: <findNetworksByAddress
+ C: xmlns="urn:ietf:params:xml:ns:areg1">
+ C:
+ C: <ipv4Address>
+ C: <start>192.0.2.134</start>
+ C: </ipv4Address>
+ C:
+ C: <specificity
+ C: allowEquivalences="true"
+ C: >one-level-less-specific</specificity>
+ C:
+ C: </findNetworksByAddress>
+ C: </searchSet>
+ C:
+ C: </request>
+
+ S: <?xml version="1.0"?>
+ S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"
+ S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
+ S:
+ S: <iris:resultSet>
+ S: <iris:answer>
+ S: <areg:ipv4Network
+ S: xmlns="urn:ietf:params:xml:ns:areg1"
+ S: xmlns:areg="urn:ietf:params:xml:ns:areg1"
+ S: xsi:schemaLocation="urn:ietf:params:xml:ns:areg1 areg.xsd"
+ S: authority="rir.example.net" registryType="areg1"
+ S: entityClass="ipv4-handle" entityName="NET-192-0-2-128-1" >
+ S: <networkHandle>
+ S: NET-192-0-2-128-1
+ S: </networkHandle>
+ S: <name>
+ S: UU-192-0-2-D6
+ S: </name>
+ S: <startAddress>
+ S: 192.0.2.128
+ S: </startAddress>
+ S: <endAddress>
+
+
+
+Gunduz, et al. Standards Track [Page 36]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ S: 192.0.2.255
+ S: </endAddress>
+ S: <networkType>reassigned</networkType>
+ S: <organization
+ S: iris:referentType="areg:organization"
+ S: authority="rir.example.net" registryType="areg1"
+ S: entityClass="organization-id" entityName="ORGX">
+ S: <iris:displayName language="en">
+ S: Organization X, Inc.
+ S: </iris:displayName>
+ S: </organization>
+ S: <parent
+ S: iris:referentType="areg:ipv4Network"
+ S: authority="rir.example.net" registryType="areg1"
+ S: entityClass="ipv4-handle" entityName="NET-192-0-2-0-1"/>
+ S: <techContact
+ S: iris:referentType="areg:contact"
+ S: authority="rir.example.net" registryType="areg1"
+ S: entityClass="contact-handle" entityName="JN560-RIR1">
+ S: <iris:displayName language="en">
+ S: Smurd, Bob
+ S: </iris:displayName>
+ S: </techContact>
+ S: <registrationDate>
+ S: 2002-11-18T00:00:00-00:00
+ S: </registrationDate>
+ S: <lastUpdatedDate>
+ S: 2002-11-18T00:00:00-00:00
+ S: </lastUpdatedDate>
+ S: <iris:seeAlso
+ S: iris:referentType="ANY"
+ S: authority="rir.example.net" registryType="areg1"
+ S: entityClass="local" entityName="portability-notice"/>
+ S: </areg:ipv4Network>
+ S: <areg:ipv4Network
+ S: xmlns="urn:ietf:params:xml:ns:areg1"
+ S: xmlns:areg="urn:ietf:params:xml:ns:areg1"
+ S: xsi:schemaLocation="urn:ietf:params:xml:ns:areg1 areg.xsd"
+ S: authority="rir.example.net" registryType="areg1"
+ S: entityClass="ipv4-handle" entityName="NET-192-0-2-0-2" >
+ S: <networkHandle>
+ S: NET-192-0-2-0-2
+ S: </networkHandle>
+ S: <name>
+ S: UU-192-0-2-0-D5
+ S: </name>
+ S: <startAddress>
+ S: 192.0.2.0
+
+
+
+Gunduz, et al. Standards Track [Page 37]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ S: </startAddress>
+ S: <endAddress>
+ S: 192.0.2.255
+ S: </endAddress>
+ S: <networkType>direct allocation</networkType>
+ S: <nameServer>auth03.ns.example.org</nameServer>
+ S: <nameServer>auth00.ns.example.org</nameServer>
+ S: <organization
+ S: iris:referentType="areg:organization"
+ S: authority="rir.example.net" registryType="areg1"
+ S: entityClass="organization-id" entityName="ORGY">
+ S: <iris:displayName language="en">
+ S: Organization Y, Inc.
+ S: </iris:displayName>
+ S: </organization>
+ S: <parent
+ S: iris:referentType="areg:ipv4Network"
+ S: authority="rir.example.net" registryType="areg1"
+ S: entityClass="ipv4-handle" entityName="NET-192-0-2-0-1"/>
+ S: <techContact
+ S: iris:referentType="areg:contact"
+ S: authority="rir.example.net" registryType="areg1"
+ S: entityClass="contact-handle" entityName="OA12-RIR1" />
+ S: <registrationDate>
+ S: 2000-10-27T00:00:00-00:00
+ S: </registrationDate>
+ S: <lastUpdatedDate>
+ S: 2002-02-13T00:00:00-00:00
+ S: </lastUpdatedDate>
+ S: <iris:seeAlso
+ S: iris:referentType="ANY"
+ S: authority="rir.example.net" registryType="areg1"
+ S: entityClass="local" entityName="portability-notice"/>
+ S: </areg:ipv4Network>
+ S: </iris:answer>
+ S: <iris:additional>
+ S: <iris:simpleEntity
+ S: authority="rir.example.net" registryType="areg1"
+ S: entityClass="local" entityName="portability-notice" >
+ S: <iris:property name="portability" language="en">
+ S: Addresses within this block are non-portable.
+ S: </iris:property>
+
+
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 38]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ S: </iris:simpleEntity>
+ S: </iris:additional>
+ S: </iris:resultSet>
+ S:
+ S: </iris:response>
+
+ Figure 12: Example 2
+
+Appendix C. Specificity Examples
+
+ This section includes examples to clarify specificity options for
+ network and ASN searches.
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+
+ Contents of the DB
+
+ Figure 13: Specificity Example 1
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 39]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query|- - - - - - - | 192.0.2.0 - 192.0.2.9
+
+
+ Exact match (1)
+
+ Result: C
+
+ Figure 14: Specificity Example 2
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query|- - - - - - - - | 192.0.2.0 - 192.0.2.12
+
+
+ Exact match (2)
+
+ Result: None
+
+ Figure 15: Specificity Example 3
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 40]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15
+
+
+ All more specifics, allowEquivalences = false
+
+ Result: C, F, & G (A is not included; exact match)
+
+ Figure 16: Specificity Example 4
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15
+
+
+ All more specifics, allowEquivalences = true
+
+ Result: A, C, F, & G (A is included; exact match)
+
+ Figure 17: Specificity Example 5
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 41]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15
+
+
+ One level more specifics, allowEquivalences = false
+
+ Result: C
+
+ Figure 18: Specificity Example 6
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query|- - - - - - - - - | 192.0.2.0 - 192.0.2.15
+
+
+ One level more specifics, allowEquivalences = true
+
+ Result: A
+
+ Figure 19: Specificity Example 7
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 42]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query |- - | 192.0.2.6 - 192.0.2.9
+
+
+ All less specifics, allowEquivalences = true
+
+ Result: A, C, & G (G is included; exact match)
+
+ Figure 20: Specificity Example 8
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query |- - | 192.0.2.6 - 192.0.2.9
+
+
+ All less specifics, allowEquivalences = false
+
+ Result: A & C (G is not included; exact match)
+
+ Figure 21: Specificity Example 9
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 43]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query |- - | 192.0.2.6 - 192.0.2.9
+
+
+ One level less specifics, allowEquivalences = true
+
+ Result: G (the exact match)
+
+ Figure 22: Specificity Example 10
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query |- - | 192.0.2.6 - 192.0.2.9
+
+
+ One level less specifics, allowEquivalences = false
+
+ Result: C
+
+ Figure 23: Specificity Example 11
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 44]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query|- - - - - - | 192.0.2.0 - 192.0.2.8
+
+
+ One level less specifics, allowEquivalences = false or true
+
+ Result: C
+
+ Figure 24: Specificity Example 12
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query = E
+
+
+ Find parent (Query argument is a handle)
+
+ Result: D
+
+ Figure 25: Specificity Example 13
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 45]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+ A |------------------| 192.0.2.0 - 192.0.2.15
+
+ B |------------------| 192.0.2.16 - 192.0.2.31
+
+ C |--------------| 192.0.2.0 - 192.0.2.9
+
+ D |---------------| 192.0.2.16 - 192.0.2.30
+
+ E |---------------| 192.0.2.16 - 192.0.2.30
+
+ F |--------| 192.0.2.0 - 192.0.2.5
+
+ G |----| 192.0.2.6 - 192.0.2.9
+
+ Query = D
+
+
+ Find child (Query argument is a handle)
+
+ Result: E
+
+ Figure 26: Specificity Example 14
+
+Appendix D. Contributors
+
+ David Blacka and Tim Christensen made substantial contributions to
+ this document.
+
+Appendix E. Acknowledgements
+
+ Eric Hall, William Leibzon, April Marine, George Michaelson, Tim
+ Christensen Cathy Murphy, Andrei Robachevsky, Marcos Sanz, Frederico
+ Neves, Ted Hardie, and many others contributed constructively in the
+ mailing list discussions and IETF Meeting sessions.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 46]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+Authors' Addresses
+
+ Engin Gunduz
+ RIPE NCC
+ Singel 258
+ Amsterdam 1016AB
+ The Netherlands
+
+ Phone: +31 20 535 4444
+ EMail: e.gunduz@computer.org
+
+
+ Andrew L. Newton
+ VeriSign, Inc.
+ 21345 Ridgetop Circle
+ Sterling, VA 20166
+ USA
+
+ Phone: +1 703 948 3382
+ EMail: andy@hxr.us
+
+
+ Shane W. Kerr
+ RIPE NCC
+ Singel 258
+ Amsterdam 1016AB
+ The Netherlands
+
+ Phone: +31 20 535 4444
+ EMail: shane@time-travellers.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 47]
+
+RFC 4698 IRIS Address Registry Type October 2006
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2006).
+
+ This document is subject to the rights, licenses and restrictions
+ contained in BCP 78, and except as set forth therein, the authors
+ retain all their rights.
+
+ This document and the information contained herein are provided on an
+ "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+ OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+ The IETF takes no position regarding the validity or scope of any
+ Intellectual Property Rights or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; nor does it represent that it has
+ made any independent effort to identify any such rights. Information
+ on the procedures with respect to rights in RFC documents can be
+ found in BCP 78 and BCP 79.
+
+ Copies of IPR disclosures made to the IETF Secretariat and any
+ assurances of licenses to be made available, or the result of an
+ attempt made to obtain a general license or permission for the use of
+ such proprietary rights by implementers or users of this
+ specification can be obtained from the IETF on-line IPR repository at
+ http://www.ietf.org/ipr.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights that may cover technology that may be required to implement
+ this standard. Please address the information to the IETF at
+ ietf-ipr@ietf.org.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is provided by the IETF
+ Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Gunduz, et al. Standards Track [Page 48]
+