6.  Framework Data Model Objects

   This section provides a description of the specification of each
   supported data model object (the nouns) and identifies the commands
   (the verbs) that MUST be supported for each data model object.
   However, the specification of the data structures necessary to
   support each command is delegated to an SPPF-conforming substrate
   "protocol" specification.

6.1.  Destination Group

   A Destination Group represents a logical grouping of Public
   Identifiers with common SED.  The substrate protocol MUST support the
   ability to Add, Get, and Delete Destination Groups (refer to
   Section 7 for a generic description of various operations).

   A Destination Group object MUST be uniquely identified by attributes
   as defined in the description of "ObjKeyType" in "Generic Object Key
   Type" (Section 5.2.1 of this document).

   The DestGrpType object structure is defined as follows:

   <complexType name="DestGrpType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="dgName" type="sppfb:ObjNameType"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   The DestGrpType object is composed of the following elements:

   o  base: All first-class objects extend BasicObjType (see
      Section 5.1).

   o  dgName: The character string that contains the name of the
      Destination Group.

   o  ext: Point of extensibility described in Section 3.3.

6.2.  Public Identifier

   A Public Identifier is the search key used for locating the SED.  In
   many cases, a Public Identifier is attributed to the end user who has
   a retail relationship with the SP or Registrant organization.  SPPF
   supports the notion of the carrier-of-record as defined in [RFC5067].
   Therefore, the Registrant under which the Public Identifier is being
   created can optionally claim to be a carrier-of-record.

   SPPF identifies three types of Public Identifiers: TNs, RNs, and
   URIs.  SPPF provides structures to manage a single TN, a contiguous
   range of TNs, and a TN prefix.  The substrate protocol MUST support
   the ability to Add, Get, and Delete Public Identifiers (refer to
   Section 7 for a generic description of various operations).

   A Public Identity object MUST be uniquely identified by attributes as
   defined in the description of "PubIdKeyType" in Section 5.2.2.

   The abstract XSD type PubIdType is a generalization for the concrete
   Public Identifier schema types.  The PubIdType element "dgName"
   represents the name of a Destination Group of which a given Public
   Identifier may be a member.  Note that this element may be present
   multiple times so that a given Public Identifier may be a member of
   multiple Destination Groups.  The PubIdType object structure is
   defined as follows:

   <complexType name="PubIdType" abstract="true">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="dgName" type="sppfb:ObjNameType"
                minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   A Public Identifier may be a member of zero or more Destination
   Groups.  When a Public Identifier is a member of a Destination Group,
   it is intended to be associated with SED through the SED Group(s)
   that is associated with the Destination Group.  When a Public
   Identifier is not member of any Destination Group, it is intended to
   be associated with SED through the SED Records that are directly
   associated with the Public Identifier.

   A TN is provisioned using the TNType, an extension of PubIdType.
   Each TNType object is uniquely identified by the combination of its
   value contained within the <tn> element and its Registrant ID.
   TNType is defined as follows:

   <complexType name="TNType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="tn" type="sppfb:NumberValType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
       <element name="sedRecRef" type="sppfb:SedRecRefType"
                minOccurs="0" maxOccurs="unbounded"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <complexType name="CORInfoType">
    <sequence>
      <element name="corClaim" type="boolean" default="true"/>
      <element name="cor" type="boolean" default="false" minOccurs="0"/>
      <element name="corDate" type="dateTime" minOccurs="0"/>
    </sequence>
   </complexType>

   <simpleType name="NumberValType">
    <restriction base="token">
     <maxLength value="20"/>
     <pattern value="\+?\d\d*"/>
    </restriction>
   </simpleType>

   TNType consists of the following attributes:

   o  tn: Telephone number to be added to the Registry.

   o  sedRecRef: Optional reference to SED Records that are directly
      associated with the TN Public Identifier.  Following the SPPF data
      model, the SED Record could be a protocol-agnostic URIType or
      another type.

   o  corInfo: corInfo is an optional parameter of type CORInfoType that
      allows the Registrant organization to set forth a claim to be the
      carrier-of-record (see [RFC5067]).  This is done by setting the
      value of the <corClaim> element of the CORInfoType object
      structure to "true".  The other two parameters of the CORInfoType,
      <cor> and <corDate>, are set by the Registry to describe the

      outcome of the carrier-of-record claim by the Registrant.  In
      general, inclusion of the <corInfo> parameter is useful if the
      Registry has the authority information, such as the number
      portability data, etc., in order to qualify whether the Registrant
      claim can be satisfied.  If the carrier-of-record claim disagrees
      with the authority data in the Registry, whether or not a TN Add
      operation fails is a matter of policy and is beyond the scope of
      this document.

   An RN is provisioned using the RNType, an extension of PubIDType.
   The Registrant organization can add the RN and associate it with the
   appropriate Destination Group(s) to share the route information.
   This allows SSPs to use the RN search key to derive the Ingress
   Routes for session establishment at the runtime resolution process
   (see [RFC6116]).  Each RNType object is uniquely identified by the
   combination of its value inside the <rn> element and its Registrant
   ID.  RNType is defined as follows:

   <complexType name="RNType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="rn" type="sppfb:NumberValType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   RNType has the following attributes:

   o  rn: The RN used as the search key.

   o  corInfo: corInfo is an optional parameter of type CORInfoType that
      allows the Registrant organization to set forth a claim to be the
      carrier-of-record (see [RFC5067]).

   TNRType structure is used to provision a contiguous range of TNs.
   The object definition requires a starting TN and an ending TN that
   together define the span of the TN range, including the starting and
   ending TN.  Use of TNRType is particularly useful when expressing a
   TN range that does not include all the TNs within a TN block or
   prefix.  The TNRType definition accommodates the open number plan as
   well such that the TNs that fall in the range between the start and
   end TN may include TNs with different length variance.  Whether the
   Registry can accommodate the open number plan semantics is a matter
   of policy and is beyond the scope of this document.  Each TNRType
   object is uniquely identified by the combination of its value that,

   in turn, is a combination of the <startTn> and <endTn> elements and
   its Registrant ID.  The TNRType object structure definition is as
   follows:

   <complexType name="TNRType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="range" type="sppfb:NumberRangeType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <complexType name="NumberRangeType">
    <sequence>
     <element name="startTn" type="sppfb:NumberValType"/>
     <element name="endTn" type="sppfb:NumberValType"/>
    </sequence>
   </complexType>

   TNRType has the following attributes:

   o  startTn: The starting TN in the TN range.

   o  endTn: The last TN in the TN range.

   o  corInfo: corInfo is an optional parameter of type CORInfoType that
      allows the Registrant organization to set forth a claim to be the
      carrier-of-record (see [RFC5067]).

   In some cases, it is useful to describe a set of TNs with the help of
   the first few digits of the TN, also referred to as the TN prefix or
   a block.  A given TN prefix may include TNs with different length
   variance in support of the open number plan.  Once again, whether the
   Registry supports the open number plan semantics is a matter of
   policy, and it is beyond the scope of this document.  The TNPType
   data structure is used to provision a TN prefix.  Each TNPType object
   is uniquely identified by the combination of its value in the
   <tnPrefix> element and its Registrant ID.  TNPType is defined as
   follows:

   <complexType name="TNPType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="tnPrefix" type="sppfb:NumberValType"/>
       <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   TNPType consists of the following attributes:

   o  tnPrefix: The TN prefix.

   o  corInfo: corInfo is an optional parameter of type CORInfoType that
      allows the Registrant organization to set forth a claim to be the
      carrier-of-record (see [RFC5067]).

   In some cases, a Public Identifier may be a URI, such as an email
   address.  The URIPubIdType object is comprised of the data element
   necessary to house such Public Identifiers.  Each URIPubIdType object
   is uniquely identified by the combination of its value in the <uri>
   element and its Registrant ID.  URIPubIdType is defined as follows:

   <complexType name="URIPubIdType">
    <complexContent>
     <extension base="sppfb:PubIdType">
      <sequence>
       <element name="uri" type="anyURI"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   URIPubIdType consists of the following attributes:

   o  uri: The value that acts as the Public Identifier.

   o  ext: Point of extensibility described in Section 3.3.

6.3.  SED Group

   SED Group is a grouping of one or more Destination Groups, the common
   SED Records, and the list of peer organizations with access to the
   SED Records associated with a given SED Group.  It is this indirect
   linking of Public Identifiers to their SED that significantly
   improves the scalability and manageability of the peering data.
   Additions and changes to SED information are reduced to a single
   operation on a SED Group or SED Record rather than millions of data
   updates to individual Public Identifier records that individually
   contain their peering data.  The substrate protocol MUST support the
   ability to Add, Get, and Delete SED Groups (refer to Section 7 for a
   generic description of various operations).

   A SED Group object MUST be uniquely identified by attributes as
   defined in the description of "ObjKeyType" in "Generic Object Key
   Type" (Section 5.2.1 of this document).

   The SedGrpType object structure is defined as follows:

   <complexType name="SedGrpType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="sedGrpName" type="sppfb:ObjNameType"/>
       <element name="sedRecRef" type="sppfb:SedRecRefType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="dgName" type="sppfb:ObjNameType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="peeringOrg" type="sppfb:OrgIdType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="sourceIdent" type="sppfb:SourceIdentType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="isInSvc" type="boolean"/>
       <element name="priority" type="unsignedShort"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <complexType name="SedRecRefType">
    <sequence>
     <element name="sedKey" type="sppfb:ObjKeyType"/>
     <element name="priority" type="unsignedShort"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
   </complexType>

   The SedGrpType object is composed of the following elements:

   o  base: All first-class objects extend BasicObjType (see
      Section 5.1).

   o  sedGrpName: The character string that contains the name of the SED
      Group.  It uniquely identifies this object within the context of
      the Registrant ID (a child element of the base element as
      described above).

   o  sedRecRef: Set of zero or more objects of type SedRecRefType that
      house the unique keys of the SED Records (containing the SED) that
      the SedGrpType object refers to and their relative priority within
      the context of this SED Group.

   o  dgName: Set of zero or more names of DestGrpType object instances.
      Each dgName name, in association with this SED Group's Registrant
      ID, uniquely identifies a DestGrpType object instance whose
      associated Public Identifiers are reachable using the SED housed
      in this SED Group.  An intended side effect of this is that a SED
      Group cannot provide session establishment information for a
      Destination Group belonging to another Registrant.

   o  peeringOrg: Set of zero or more peering organization IDs that have
      accepted an offer to receive this SED Group's information.  Note
      that this identifier "peeringOrg" is an instance of OrgIdType.
      The set of peering organizations in this list is not directly
      settable or modifiable using the addSedGrpsRqst operation.  This
      set is instead controlled using the SED Offer and Accept
      operations.

   o  sourceIdent: Set of zero or more SourceIdentType object instances.
      These objects, described further below, house the source
      identification schemes and identifiers that are applied at
      resolution time as part of source-based routing algorithms for the
      SED Group.

   o  isInSvc: A boolean element that defines whether this SED Group is
      in service.  The SED contained in a SED Group that is in service
      is a candidate for inclusion in resolution responses for Public
      Identities residing in the Destination Group associated with this
      SED Group.  The session establishment information contained in a
      SED Group that is not in service is not a candidate for inclusion
      in resolution responses.

   o  priority: Priority value that can be used to provide a relative
      value weighting of one SED Group over another.  The manner in
      which this value is used, perhaps in conjunction with other
      factors, is a matter of policy.

   o  ext: Point of extensibility described in Section 3.3.

   As described above, the SED Group contains a set of references to SED
   Record objects.  A SED Record object is based on an abstract type:
   SedRecType.  The concrete types that use SedRecType as an extension
   base are NAPTRType, NSType, and URIType.  The definitions of these
   types are included in "SED Record" (Section 6.4 of this document).

   The SedGrpType object provides support for source-based routing via
   the peeringOrg data element and more granular source-based routing
   via the source identity element.  The source identity element
   provides the ability to specify zero or more of the following in
   association with a given SED Group: a regular expression that is

   matched against the resolution client IP address, a regular
   expression that is matched against the root domain name(s), and/or a
   regular expression that is matched against the calling party URI(s).
   The result will be that, after identifying the visible SED Groups
   whose associated Destination Group(s) contains the lookup key being
   queried and whose peeringOrg list contains the querying
   organization's organization ID, the resolution server will evaluate
   the characteristics of the Source URI, Source IP address, and root
   domain of the lookup key being queried.  The resolution server then
   compares these criteria against the source identity criteria
   associated with the SED Groups.  The SED contained in SED Groups that
   have source-based routing criteria will only be included in the
   resolution response if one or more of the criteria matches the source
   criteria from the resolution request.  The source identity data
   element is of type SourceIdentType, whose structure is defined as
   follows:

   <complexType name="SourceIdentType">
    <sequence>
     <element name="sourceIdentRegex" type="sppfb:RegexType"/>
     <element name="sourceIdentScheme"
              type="sppfb:SourceIdentSchemeType"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
   </complexType>

   <simpleType name="SourceIdentSchemeType">
    <restriction base="token">
     <enumeration value="uri"/>
     <enumeration value="ip"/>
     <enumeration value="rootDomain"/>
    </restriction>
   </simpleType>

   The SourceIdentType object is composed of the following data
   elements:

   o  sourceIdentScheme: The source identification scheme that this
      source identification criteria applies to and that the associated
      sourceIdentRegex should be matched against.

   o  sourceIdentRegex: The regular expression that should be used to
      test for a match against the portion of the resolution request
      that is dictated by the associated sourceIdentScheme.

   o  ext: Point of extensibility described in Section 3.3.

6.4.  SED Record

   SED Group represents a combined grouping of SED Records that define
   SED.  However, SED Records need not be created to just serve a single
   SED Group.  SED Records can be created and managed to serve multiple
   SED Groups.  As a result, a change, for example, to the properties of
   a network node used for multiple routes would necessitate just a
   single update operation to change the properties of that node.  The
   change would then be reflected in all the SED Groups whose SED Record
   set contains a reference to that node.  The substrate protocol MUST
   support the ability to Add, Get, and Delete SED Records (refer to
   Section 7 for a generic description of various operations).

   A SED Record object MUST be uniquely identified by attributes as
   defined in the description of "ObjKeyType" in "Generic Object Key
   Type" (Section 5.2.1 of this document).

   The SedRecType object structure is defined as follows:

   <complexType name="SedRecType" abstract="true">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="sedName" type="sppfb:ObjNameType"/>
       <element name="sedFunction" type="sppfb:SedFunctionType"
                minOccurs="0"/>
       <element name="isInSvc" type="boolean"/>
       <element name="ttl" type="positiveInteger" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <simpleType name="SedFunctionType">
    <restriction base="token">
     <enumeration value="routing"/>
     <enumeration value="lookup"/>
    </restriction>
   </simpleType>

   The SedRecType object is composed of the following elements:

   o  base: All first-class objects extend BasicObjType (see
      Section 5.1).

   o  sedName: The character string that contains the name of the SED
      Record.  It uniquely identifies this object within the context of
      the Registrant ID (a child element of the base element as
      described above).

   o  sedFunction: As described in [RFC6461], SED falls primarily into
      one of two categories or functions: LUF and LRF.  To remove any
      ambiguity as to the function a SED Record is intended to provide,
      this optional element allows the provisioning party to make its
      intentions explicit.

   o  isInSvc: A boolean element that defines whether or not this SED
      Record is in service.  The session establishment information
      contained in a SED Record that is in service is a candidate for
      inclusion in resolution responses for TNs that are either directly
      associated to this SED Record or for Public Identities residing in
      a Destination Group that is associated to a SED Group, which, in
      turn, has an association to this SED Record.

   o  ttl: Number of seconds that an addressing server may cache a
      particular SED Record.

   As described above, SED Records are based on abstract type
   SedRecType.  The concrete types that use SedRecType as an extension
   base are NAPTRType, NSType, and URIType.  The definitions of these
   types are included below.  The NAPTRType object is comprised of the
   data elements necessary for a Naming Authority Pointer (NAPTR) (see
   [RFC3403]) that contains routing information for a SED Group.  The
   NSType object is comprised of the data elements necessary for a DNS
   name server that points to another DNS server that contains the
   desired routing information.  The NSType is relevant only when the
   resolution protocol is ENUM (see [RFC6116]).  The URIType object is
   comprised of the data elements necessary to house a URI.

   The data provisioned in a Registry can be leveraged for many purposes
   and queried using various protocols including SIP, ENUM, and others.
   As such, the resolution data represented by the SED Records must be
   in a form suitable for transport using one of these protocols.  In
   the NAPTRType, for example, if the URI is associated with a
   Destination Group, the user part of the replacement string <uri> that
   may require the Public Identifier cannot be preset.  As a SIP
   Redirect, the resolution server will apply <ere> pattern on the input
   Public Identifier in the query and process the replacement string by
   substituting any back references in the <uri> to arrive at the final
   URI that is returned in the SIP Contact header.  For an ENUM query,
   the resolution server will simply return the values of the <ere> and
   <uri> members of the URI.

   <complexType name="NAPTRType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="order" type="unsignedShort"/>
       <element name="flags" type="sppfb:FlagsType" minOccurs="0"/>
       <element name="svcs" type="sppfb:SvcType"/>
       <element name="regx" type="sppfb:RegexParamType" minOccurs="0"/>
       <element name="repl" type="sppfb:ReplType" minOccurs="0"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <complexType name="NSType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="hostName" type="token"/>
       <element name="ipAddr" type="sppfb:IPAddrType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <complexType name="IPAddrType">
    <sequence>
     <element name="addr" type="sppfb:AddrStringType"/>
     <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
    </sequence>
    <attribute name="type" type="sppfb:IPType" default="IPv4"/>
   </complexType>

   <simpleType name="IPType">
    <restriction base="token">
     <enumeration value="IPv4"/>
     <enumeration value="IPv6"/>
    </restriction>
   </simpleType>

   <complexType name="URIType">
    <complexContent>
     <extension base="sppfb:SedRecType">
      <sequence>
       <element name="ere" type="token" default="^(.*)$"/>

       <element name="uri" type="anyURI"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <simpleType name="flagsType">
    <restriction base="token">
     <length value="1"/>
     <pattern value="[A-Z]|[a-z]|[0-9]"/>
    </restriction>
   </simpleType>

   The NAPTRType object is composed of the following elements:

   o  order: Order value in an ENUM NAPTR, relative to other NAPTRType
      objects in the same SED Group.

   o  svcs: ENUM service(s) that is served by the SBE.  This field's
      value must be of the form specified in [RFC6116] (e.g.,
      E2U+pstn:sip+sip).  The allowable values are a matter of policy
      and are not limited by this protocol.

   o  regx: NAPTR's regular expression field.  If this is not included,
      then the repl field must be included.

   o  repl: NAPTR replacement field; it should only be provided if the
      regx field is not provided; otherwise, the server will ignore it.

   o  ext: Point of extensibility described in Section 3.3.

   The NSType object is composed of the following elements:

   o  hostName: Root-relative host name of the name server.

   o  ipAddr: Zero or more objects of type IpAddrType.  Each object
      holds an IP Address and the IP Address type ("IPv4" or "IPv6").

   o  ext: Point of extensibility described in Section 3.3.

   The URIType object is composed of the following elements:

   o  ere: The POSIX Extended Regular Expression (ere) as defined in
      [RFC3986].

   o  uri: the URI as defined in [RFC3986].  In some cases, this will
      serve as the replacement string, and it will be left to the
      resolution server to arrive at the final usable URI.

6.5.  SED Group Offer

   The list of peer organizations whose resolution responses can include
   the SED contained in a given SED Group is controlled by the
   organization to which a SED Group object belongs (its Registrant) and
   the peer organization that submits resolution requests (a data
   recipient, also known as a peering organization).  The Registrant
   offers access to a SED Group by submitting a SED Group Offer.  The
   data recipient can then accept or reject that offer.  Not until
   access to a SED Group has been offered and accepted will the data
   recipient's organization ID be included in the peeringOrg list in a
   SED Group object, and that SED Group's peering information becomes a
   candidate for inclusion in the responses to the resolution requests
   submitted by that data recipient.  The substrate protocol MUST
   support the ability to Add, Get, Delete, Accept, and Reject SED Group
   Offers (refer to Section 7 for a generic description of various
   operations).

   A SED Group Offer object MUST be uniquely identified by attributes as
   defined in the description of "SedGrpOfferKeyType" in "Derived Object
   Key Types" (Section 5.2.2 of this document).

   The SedGrpOfferType object structure is defined as follows:

   <complexType name="SedGrpOfferType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="sedGrpOfferKey" type="sppfb:SedGrpOfferKeyType"/>
       <element name="status" type="sppfb:SedGrpOfferStatusType"/>
       <element name="offerDateTime" type="dateTime"/>
       <element name="acceptDateTime" type="dateTime" minOccurs="0"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   <complexType name="SedGrpOfferKeyType" abstract="true">
    <annotation>
     <documentation>
     -- Generic type that represents the key for a SED Group Offer. Must
        be defined in concrete form in a substrate "protocol"
        specification. --
     </documentation>
    </annotation>
   </complexType>

   <simpleType name="SedGrpOfferStatusType">
    <restriction base="token">
     <enumeration value="offered"/>
     <enumeration value="accepted"/>
    </restriction>
   </simpleType>

   The SedGrpOfferType object is composed of the following elements:

   o  base: All first-class objects extend BasicObjType (see
      Section 5.1).

   o  sedGrpOfferKey: The object that identifies the SED that is or has
      been offered and the organization to which it is or has been
      offered.

   o  status: The status of the offer, offered or accepted.  The server
      controls the status.  It is automatically set to "offered"
      whenever a new SED Group Offer is added and is automatically set
      to "accepted" if and when that offer is accepted.  The value of
      the element is ignored when passed in by the client.

   o  offerDateTime: Date and time in UTC when the SED Group Offer was
      added.

   o  acceptDateTime: Date and time in UTC when the SED Group Offer was
      accepted.

6.6.  Egress Route

   In a high-availability environment, the originating SSP likely has
   more than one egress path to the ingress SBE of the target SSP.  If
   the originating SSP wants to exercise greater control and choose a
   specific egress SBE to be associated to the target ingress SBE, it
   can do so using the EgrRteType object.

   An Egress Route object MUST be uniquely identified by attributes as
   defined in the description of "ObjKeyType" in "Generic Object Key
   Type" (Section 5.2.1 of this document).

   Assume that the target SSP has offered, as part of its SED, to share
   one or more Ingress Routes and that the originating SSP has accepted
   the offer.  In order to add the Egress Route to the Registry, the
   originating SSP uses a valid regular expression to rewrite the
   Ingress Route in order to include the egress SBE information.  Also,
   more than one Egress Route can be associated with a given Ingress
   Route in support of fault-tolerant configurations.  The supporting
   SPPF structure provides a way to include route precedence information
   to help manage traffic to more than one outbound egress SBE.

   The substrate protocol MUST support the ability to Add, Get, and
   Delete Egress Routes (refer to Section 7 for a generic description of
   various operations).  The EgrRteType object structure is defined as
   follows:

   <complexType name="EgrRteType">
    <complexContent>
     <extension base="sppfb:BasicObjType">
      <sequence>
       <element name="egrRteName" type="sppfb:ObjNameType"/>
       <element name="pref" type="unsignedShort"/>
       <element name="regxRewriteRule" type="sppfb:RegexParamType"/>
       <element name="ingrSedGrp" type="sppfb:ObjKeyType"
                minOccurs="0" maxOccurs="unbounded"/>
       <element name="svcs" type="sppfb:SvcType" minOccurs="0"/>
       <element name="ext" type="sppfb:ExtAnyType" minOccurs="0"/>
      </sequence>
     </extension>
    </complexContent>
   </complexType>

   The EgrRteType object is composed of the following elements:

   o  base: All first-class objects extend BasicObjType (see
      Section 5.1).

   o  egrRteName: The name of the Egress Route.

   o  pref: The preference of this Egress Route relative to other Egress
      Routes that may get selected when responding to a resolution
      request.

   o  regxRewriteRule: The regular expression rewrite rule that should
      be applied to the regular expression of the ingress NAPTR(s) that
      belongs to the Ingress Route.

   o  ingrSedGrp: The ingress SED Group that the Egress Route should be
      used for.

   o  svcs: ENUM service(s) that is served by an Egress Route.  This
      element is used to identify the ingress NAPTRs associated with the
      SED Group to which an Egress Route's regxRewriteRule should be
      applied.  If no ENUM service(s) is associated with an Egress
      Route, then the Egress Route's regxRewriteRule should be applied
      to all the NAPTRs associated with the SED Group.  This field's
      value must be of the form specified in [RFC6116] (e.g.,
      E2U+pstn:sip+sip).  The allowable values are a matter of policy
      and are not limited by this protocol.

   o  ext: Point of extensibility described in Section 3.3.

7.  Framework Operations

   In addition to the operation-specific object types, all operations
   MAY specify the minor version of the protocol that when used in
   conjunction with the major version (which can be, for instance,
   specified in the protocol Namespace) can serve to identify the
   version of the SPPF protocol that the client is using.  If the minor
   version is not specified, the latest minor version supported by the
   SPPF server for the given major version will be used.  Additionally,
   operations that may potentially modify persistent protocol objects
   SHOULD include a transaction ID as well.

7.1.  Add Operation

   Any conforming substrate "protocol" specification MUST provide a
   definition for the operation that adds one or more SPPF objects into
   the Registry.  If the object, as identified by the request attributes
   that form part of the object's key, does not exist, then the Registry
   MUST create the object.  If the object does exist, then the Registry
   MUST replace the current properties of the object with the properties
   passed in as part of the Add operation.

   Note that this effectively allows modification of a preexisting
   object.

   If the entity that issued the command is not authorized to perform
   this operation, an appropriate error message MUST be returned from
   amongst the response messages defined in "Response Message Types"
   (Section 5.3 of this document).

7.2.  Delete Operation

   Any conforming substrate "protocol" specification MUST provide a
   definition for the operation that deletes one or more SPPF objects
   from the Registry using the object's key.

   If the entity that issued the command is not authorized to perform
   this operation, an appropriate error message MUST be returned from
   amongst the response messages defined in "Response Message Types"
   (Section 5.3 of this document).

   When an object is deleted, any references to that object must of
   course also be removed as the SPPF server implementation fulfills the
   deletion request.  Furthermore, the deletion of a composite object
   must also result in the deletion of the objects it contains.  As a
   result, the following rules apply to the deletion of SPPF object
   types:

   o  Destination Groups: When a Destination Group is deleted, any
      cross-references between that destination group and any SED Group
      must be automatically removed by the SPPF implementation as part
      of fulfilling the deletion request.  Similarly, any cross-
      references between that Destination Group and any Public
      Identifier must be removed by the SPPF implementation.

   o  SED Groups: When a SED Group is deleted, any references between
      that SED Group and any Destination Group must be automatically
      removed by the SPPF implementation as part of fulfilling the
      deletion request.  Similarly, any cross-references between that
      SED Group and any SED Records must be removed by the SPPF

      implementation as part of fulfilling the deletion request.
      Furthermore, SED Group Offers relating to that SED Group must also
      be deleted.

   o  SED Records: When a SED Record is deleted, any cross-references
      between that SED Record and any SED Group must be removed by the
      SPPF implementation as part of fulfilling the deletion request.
      Similarly, any reference between that SED Record and any Public
      Identifier must be removed by the SPPF implementation.

   o  Public Identifiers: When a Public Identifier is deleted, any
      cross-references between that Public Identifier and any referenced
      Destination Group must be removed by the SPPF implementation as
      part of fulfilling the deletion request.  Any references to SED
      Records associated directly to that Public Identifier must also be
      deleted by the SPPF implementation.

   Deletes MUST be atomic.

7.3.  Get Operations

   At times, on behalf of the Registrant, the Registrar may need to get
   information about SPPF objects that were previously provisioned in
   the Registry.  A few examples include logging, auditing, and pre-
   provisioning dependency checking.  This query mechanism is limited to
   aid provisioning scenarios and should not be confused with query
   protocols provided as part of the resolution system (e.g., ENUM and
   SIP).

   Any conforming "protocol" specification MUST provide a definition for
   the operation that queries the details of one or more SPPF objects
   from the Registry using the object's key.  If the entity that issued
   the command is not authorized to perform this operation, an
   appropriate error message MUST be returned from among the response
   messages defined in Section 5.3.

   If the response to the Get operation includes an object(s) that
   extends the BasicObjType, the Registry MUST include the "cDate" and
   "mDate", if applicable.

7.4.  Accept Operations

   In SPPF, a SED Group Offer can be accepted or rejected by, or on
   behalf of, the Registrant to which the SED Group has been offered
   (refer to Section 6.5 of this document for a description of the SED
   Group Offer object).  The Accept operation is used to accept the SED
   Group Offers.  Any conforming substrate "protocol" specification MUST
   provide a definition for the operation to accept SED Group Offers by,

   or on behalf of, the Registrant, using the SED Group Offer object
   key.

   Not until access to a SED Group has been offered and accepted will
   the Registrant's organization ID be included in the peeringOrg list
   in that SED Group object, and that SED Group's peering information
   becomes a candidate for inclusion in the responses to the resolution
   requests submitted by that Registrant.  A SED Group Offer that is in
   the "offered" status is accepted by, or on behalf of, the Registrant
   to which it has been offered.  When the SED Group Offer is accepted,
   the SED Group Offer is moved to the "accepted" status and the data
   recipient's organization ID is added into the list of peerOrgIds for
   that SED Group.

   If the entity that issued the command is not authorized to perform
   this operation, an appropriate error message MUST be returned from
   amongst the response messages defined in "Response Message Types"
   (Section 5.3 of this document).

7.5.  Reject Operations

   In SPPF, a SED Group Offer object can be accepted or rejected by, or
   on behalf of, the Registrant to which the SED Group has been offered
   (refer to "Framework Data Model Objects", Section 6 of this document,
   for a description of the SED Group Offer object).  Furthermore, that
   offer may be rejected, regardless of whether or not it has been
   previously accepted.  The Reject operation is used to reject the SED
   Group Offer.  When the SED Group Offer is rejected, that SED Group
   Offer is deleted, and, if appropriate, the data recipient's
   organization ID is removed from the list of peeringOrg IDs for that
   SED Group.  Any conforming substrate "protocol" specification MUST
   provide a definition for the operation to reject SED Group Offers by,
   or on behalf of, the Registrant, using the SED Group Offer object
   key.

   If the entity that issued the command is not authorized to perform
   this operation, an appropriate error message MUST be returned from
   among the response messages defined in "Response Message Types"
   (Section 5.3 of this document).

7.6.  Get Server Details Operation

   In SPPF, the Get Server Details operation can be used to request
   certain details about the SPPF server that include the SPPF server's
   current status and the major/minor version of the SPPF protocol
   supported by the SPPF server.

   Any conforming substrate "protocol" specification MUST provide a
   definition for the operation to request such details from the SPPF
   server.  If the entity that issued the command is not authorized to
   perform this operation, an appropriate error message MUST be returned
   from among the response messages defined in "Response Message Types"
   (Section 5.3 of this document).