draft-ietf-drinks-spp-framework-08.txt   draft-ietf-drinks-spp-framework-09.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
DRINKS K. Cartwright DRINKS K. Cartwright
Internet-Draft V. Bhatia Internet-Draft V. Bhatia
Intended status: Standards Track TNS Intended status: Standards Track TNS
Expires: April 25, 2015 S. Ali Expires: April 25, 2015 S. Ali
NeuStar NeuStar
D. Schwartz D. Schwartz
XConnect XConnect
October 22, 2014 October 22, 2014
Session Peering Provisioning Framework (SPPF) Session Peering Provisioning Framework (SPPF)
draft-ietf-drinks-spp-framework-08 draft-ietf-drinks-spp-framework-09
Abstract Abstract
This document specifies the data model and the overall structure for This document specifies the data model and the overall structure for
a framework to provision session establishment data into Session Data a framework to provision session establishment data into Session Data
Registries and SIP Service Provider data stores. The framework is Registries and SIP Service Provider data stores. The framework is
called the Session Peering Provisioning Framework (SPPF). The called the Session Peering Provisioning Framework (SPPF). The
provisioned data is typically used by network elements for session provisioned data is typically used by network elements for session
establishment. establishment.
skipping to change at page 3, line 24 skipping to change at page 3, line 24
9.7. Man in the Middle . . . . . . . . . . . . . . . . . . . . 43 9.7. Man in the Middle . . . . . . . . . . . . . . . . . . . . 43
10. Internationalization Considerations . . . . . . . . . . . . . 43 10. Internationalization Considerations . . . . . . . . . . . . . 43
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11.1. URN Assignments . . . . . . . . . . . . . . . . . . . . 43 11.1. URN Assignments . . . . . . . . . . . . . . . . . . . . 43
11.2. Organization Identifier Namespace Registry . . . . . . . 44 11.2. Organization Identifier Namespace Registry . . . . . . . 44
12. Formal Specification . . . . . . . . . . . . . . . . . . . . 44 12. Formal Specification . . . . . . . . . . . . . . . . . . . . 44
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
14.1. Normative References . . . . . . . . . . . . . . . . . . 53 14.1. Normative References . . . . . . . . . . . . . . . . . . 53
14.2. Informative References . . . . . . . . . . . . . . . . . 53 14.2. Informative References . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
Service providers and enterprises use routing databases known as Service providers and enterprises use routing databases known as
registries to make session routing decisions for Voice over IP, SMS registries to make session routing decisions for Voice over IP, SMS
and MMS traffic exchanges. This document is narrowly focused on the and MMS traffic exchanges. This document is narrowly focused on the
provisioning framework for these registries. This framework provisioning framework for these registries. This framework
prescribes a way for an entity to provision session-related data into prescribes a way for an entity to provision session-related data into
a Registry. The data being provisioned can be optionally shared with a Registry. The data being provisioned can be optionally shared with
other participating peering entities. The requirements and use cases other participating peering entities. The requirements and use cases
skipping to change at page 6, line 14 skipping to change at page 6, line 14
o Sections 9 - 11 discuss security, internationalization and IANA o Sections 9 - 11 discuss security, internationalization and IANA
considerations considerations
o Section 12 normatively defines the SPPF using its XML Schema o Section 12 normatively defines the SPPF using its XML Schema
Definition. Definition.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
[RFC2119].
This document reuses terms from [RFC3261], [RFC5486], use cases and This document reuses terms from [RFC3261], [RFC5486], use cases and
requirements documented in [RFC6461] and the ENUM Validation requirements documented in [RFC6461] and the ENUM Validation
Architecture [RFC4725]. Architecture [RFC4725].
In addition, this document specifies the following additional terms: In addition, this document specifies the following additional terms:
SPPF: Session Peering Provisioning Framework, the framework used by SPPF: Session Peering Provisioning Framework, the framework used by
a transport protocol to provision data into a Registry (see arrow a transport protocol to provision data into a Registry (see arrow
labeled "1." in Figure 1 of [RFC6461]). It is the primary scope labeled "1." in Figure 1 of [RFC6461]). It is the primary scope
skipping to change at page 18, line 31 skipping to change at page 18, line 31
response message is referring to. For example, valid values for response message is referring to. For example, valid values for
"attribute name" are "dgName", "sedGrpName", "sedRec", etc. "attribute name" are "dgName", "sedGrpName", "sedRec", etc.
o The value for Attribute Value MUST be the value of the data o The value for Attribute Value MUST be the value of the data
element to which the preceding Attribute Name refers. element to which the preceding Attribute Name refers.
o Response type "Attribute value invalid" MUST be used whenever an o Response type "Attribute value invalid" MUST be used whenever an
element value does not adhere to data validation rules. element value does not adhere to data validation rules.
o Response types "Attribute value invalid" and "Object does not o Response types "Attribute value invalid" and "Object does not
exist" MUST not be used interchangeably. Response type "Object exist" MUST NOT be used interchangeably. Response type "Object
does not exist" MUST be returned by an Update/Del/Accept/Reject does not exist" MUST be returned by an Update/Del/Accept/Reject
operation when the data element(s) used to uniquely identify a operation when the data element(s) used to uniquely identify a
pre-existing object do not exist. If the data elements used to pre-existing object do not exist. If the data elements used to
uniquely identify an object are malformed, then response type uniquely identify an object are malformed, then response type
"Attribute value invalid" MUST be returned. "Attribute value invalid" MUST be returned.
6. Framework Data Model Objects 6. Framework Data Model Objects
This section provides a description of the specification of each This section provides a description of the specification of each
supported data model object (the nouns) and identifies the commands supported data model object (the nouns) and identifies the commands
skipping to change at page 22, line 13 skipping to change at page 22, line 13
to qualify whether the Registrant claim can be satisfied. If the to qualify whether the Registrant claim can be satisfied. If the
carrier-of-record claim disagrees with the authority data in the carrier-of-record claim disagrees with the authority data in the
Registry, whether the TN add operation fails or not is a matter of Registry, whether the TN add operation fails or not is a matter of
policy and it is beyond the scope of this document. policy and it is beyond the scope of this document.
A routing number is provisioned using the RNType, an extension of A routing number is provisioned using the RNType, an extension of
PubIDType. The Registrant organization can add the RN and associate PubIDType. The Registrant organization can add the RN and associate
it with the appropriate destination group(s) to share the route it with the appropriate destination group(s) to share the route
information. This allows SSPs to use the RN search key to derive the information. This allows SSPs to use the RN search key to derive the
ingress routes for session establishment at the runtime resolution ingress routes for session establishment at the runtime resolution
process (see [RFC3761]. Each RNType object is uniquely identified by process (see [RFC6116]. Each RNType object is uniquely identified by
the combination of its value inside the <rn> element, and its the combination of its value inside the <rn> element, and its
Registrant ID. RNType is defined as follows: Registrant ID. RNType is defined as follows:
<complexType name="RNType"> <complexType name="RNType">
<complexContent> <complexContent>
<extension base="sppfb:PubIdType"> <extension base="sppfb:PubIdType">
<sequence> <sequence>
<element name="rn" type="sppfb:NumberValType"/> <element name="rn" type="sppfb:NumberValType"/>
<element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/> <element name="corInfo" type="sppfb:CORInfoType" minOccurs="0"/>
</sequence> </sequence>
skipping to change at page 30, line 14 skipping to change at page 30, line 14
As described above, SED records are based on an abstract type: As described above, SED records are based on an abstract type:
SedRecType. The concrete types that use SedRecType as an extension SedRecType. The concrete types that use SedRecType as an extension
base are NAPTRType, NSType, and URIType. The definitions of these base are NAPTRType, NSType, and URIType. The definitions of these
types are included below. The NAPTRType object is comprised of the types are included below. The NAPTRType object is comprised of the
data elements necessary for a NAPTR (see [RFC3403]that contains data elements necessary for a NAPTR (see [RFC3403]that contains
routing information for a SED Group. The NSType object is comprised routing information for a SED Group. The NSType object is comprised
of the data elements necessary for a DNS name server that points to of the data elements necessary for a DNS name server that points to
another DNS server that contains the desired routing information. another DNS server that contains the desired routing information.
The NSType is relevant only when the resolution protocol is ENUM (see The NSType is relevant only when the resolution protocol is ENUM (see
[RFC3761]). The URIType object is comprised of the data elements [RFC6116]). The URIType object is comprised of the data elements
necessary to house a URI. necessary to house a URI.
The data provisioned in a Registry can be leveraged for many purposes The data provisioned in a Registry can be leveraged for many purposes
and queried using various protocols including SIP, ENUM and others. and queried using various protocols including SIP, ENUM and others.
As such, the resolution data represented by the SED records must be As such, the resolution data represented by the SED records must be
in a form suitable for transport using one of these protocols. In in a form suitable for transport using one of these protocols. In
the NAPTRType for example, if the URI is associated with a the NAPTRType for example, if the URI is associated with a
destination group, the user part of the replacement string <uri> that destination group, the user part of the replacement string <uri> that
may require the Public Identifier cannot be preset. As a SIP may require the Public Identifier cannot be preset. As a SIP
Redirect, the resolution server will apply <ere> pattern on the input Redirect, the resolution server will apply <ere> pattern on the input
skipping to change at page 41, line 20 skipping to change at page 41, line 20
exposures that are likely to be independent of lower-layer mechanism exposures that are likely to be independent of lower-layer mechanism
choices. choices.
9.3.1. DoS Issues Inherited from Transport Mechanism 9.3.1. DoS Issues Inherited from Transport Mechanism
SPPF implementation is in general dependent on the selection and SPPF implementation is in general dependent on the selection and
implementation of a lower-level transport protocol and a binding implementation of a lower-level transport protocol and a binding
between that protocol and SPPF. The archetypal SPPF implementation between that protocol and SPPF. The archetypal SPPF implementation
uses XML (http://www.w3.org/TR/xml/) representation in a SOAP uses XML (http://www.w3.org/TR/xml/) representation in a SOAP
(http://www.w3.org/TR/soap/) request/response framework over HTTP (http://www.w3.org/TR/soap/) request/response framework over HTTP
([RFC2616]), and probably also uses TLS ([RFC5246]) for on-the wire ([RFC7230]), and probably also uses TLS ([RFC5246]) for on-the wire
data integrity and participant authentication, and might use HTTP data integrity and participant authentication, and might use HTTP
Digest authentication ([RFC2609]). Digest authentication ([RFC2609]).
The typical deployment scenario for SPPF is to have servers in a The typical deployment scenario for SPPF is to have servers in a
managed facility, and therefore techniques such as Network Ingress managed facility, and therefore techniques such as Network Ingress
Filtering ([RFC2609]) are generally applicable. In short, any DoS Filtering ([RFC2609]) are generally applicable. In short, any DoS
mechanism affecting a typical HTTP implementation would affect such mechanism affecting a typical HTTP implementation would affect such
an SPPF implementation, and the mitigation tools for HTTP in general an SPPF implementation, and the mitigation tools for HTTP in general
also therefore apply to SPPF. also therefore apply to SPPF.
skipping to change at page 53, line 25 skipping to change at page 53, line 25
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM
Requirements", RFC 5067, November 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
14.2. Informative References 14.2. Informative References
[RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates [RFC2609] Guttman, E., Perkins, C., and J. Kempf, "Service Templates
and Service: Schemes", RFC 2609, June 1999. and Service: Schemes", RFC 2609, June 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO
10646", RFC 2781, February 2000. 10646", RFC 2781, February 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database", RFC Part Three: The Domain Name System (DNS) Database", RFC
3403, October 2002. 3403, October 2002.
[RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform
Resource Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation [RFC4725] Mayrhofer, A. and B. Hoeneisen, "ENUM Validation
Architecture", RFC 4725, November 2006. Architecture", RFC 4725, November 2006.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006. Service Considerations", RFC 4732, December 2006.
[RFC4949] Shirey, R., "Internet Security Glossary, Version 2", RFC
4949, August 2007.
[RFC5067] Lind, S. and P. Pfautz, "Infrastructure ENUM
Requirements", RFC 5067, November 2007.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008.
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
Interconnect (SPEERMINT) Terminology", RFC 5486, March Interconnect (SPEERMINT) Terminology", RFC 5486, March
2009. 2009.
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)", RFC 6116, Discovery System (DDDS) Application (ENUM)", RFC 6116,
March 2011. March 2011.
[RFC6461] Channabasappa, S., "Data for Reachability of Inter-/Intra- [RFC6461] Channabasappa, S., "Data for Reachability of Inter-/Intra-
NetworK SIP (DRINKS) Use Cases and Protocol Requirements", NetworK SIP (DRINKS) Use Cases and Protocol Requirements",
RFC 6461, January 2012. RFC 6461, January 2012.
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
2014.
[Unicode6.1] [Unicode6.1]
The Unicode Consortium, "The Unicode Standard - Version The Unicode Consortium, "The Unicode Standard - Version
6.1", Unicode 6.1, January 2012. 6.1", Unicode 6.1, January 2012.
Authors' Addresses Authors' Addresses
Kenneth Cartwright Kenneth Cartwright
TNS TNS
1939 Roland Clarke Place 1939 Roland Clarke Place
Reston, VA 20191 Reston, VA 20191
 End of changes. 13 change blocks. 
25 lines changed or deleted 19 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/