doc: Add RFC documents

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]
+