UserPreferences

GssPolicies/InumberDelegation

I-Number Delegation

TableOfContents

  1. Motivation
  2. Background
  3. Community I-Number Delegation Policy
  4. Implications
    1. XDI.ORG Community I-Number Routing Tables
  5. Related Policies

1. Motivation

These policies specify the rules for delegation of I-Numbers within the XDI.ORG Community. They are motivated by the need to:

2. Background

Efficient resolution of XDI.ORG Community I-Numbers is very similar to efficient routing of IP addresses – it requires agreement by all participants in the addressing network to a common set of addressing rules. In this case these addressing rules are defined by:

  1. The XRI Specifications for overall syntax of persistent XRIs representing XRI authorities, and

  2. The XDI.ORG Community I-Number Syntax Policy (GssPolicies/InumberSyntax) for constraints that optimize addressing across the network of XRI authorities addressable via the XDI.ORG Global Registries.

The following policy expresses the need for XDI.ORG-Accredited I-Brokers and Community I-Brokers to adhere to this constraint.

3. Community I-Number Delegation Policy

All delegation of Community I-Numbers to Community I-Brokers by an XDI.ORG-Accredited I-Broker or another Community I-Broker at any delegation level MUST conform to the Community I-Number Syntax Policy.

4. Implications

4.1. XDI.ORG Community I-Number Routing Tables

The key implication of this policy is that all i-brokers and XRI resolvers dealing with XRIs in the XDI.ORG Community will be able to standardize on "nested" [WWW]IPv6-based routing tables for the XRI authority segment of all Community I-Numbers.

By "nested", this means that the base routing table is the same as the IPv6 128-bit routing table. However in order to provide for expansion of this space by authorities at every level due to the unique persistence requirements of I-Numbers, each of the eight 16-bit segments in the base routing table may be mapped to another instance of the 128-bit table ("subtable"). If necessary, a segment of a subtable can be mapped to another lower-level subtable and so on (this should be very rare and only needed by the very largest registries or i-brokers.)

5. Related Policies