One document matched: draft-petithuguenin-vipr-framework-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<rfc category="std" docName="draft-petithuguenin-vipr-framework-00" ipr="noModificationTrust200902">
<front>
<title abbrev="VIPR Framework">Verification Involving PSTN Reachability (VIPR): Framework</title>
<author fullname="Marc Petit-Huguenin" initials="M." surname="Petit-Huguenin">
<organization>Stonyfish</organization>
<address>
<email>marc@stonyfish.com</email>
</address>
</author>
<author fullname="Cullen Jennings" initials="C." surname="Jennings">
<organization>Cisco</organization>
<address>
<postal>
<street>170 West Tasman Drive</street>
<street>MS: SJC-21/2</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 421-9990</phone>
<email>fluffy@cisco.com</email>
</address>
</author>
<author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
<organization>jdrosen.net</organization>
<address>
<postal>
<street/>
<city>Monmouth</city>
<region>NJ</region>
<country>US</country>
</postal>
<email>jdrosen@jdrosen.net</email>
<uri>http://www.jdrosen.net</uri>
</address>
</author>
<date day="24" month="October" year="2011"/>
<area>RAI</area>
<workgroup>VIPR WG</workgroup>
<abstract>
<t>
This document describes the framework for Verification Involving PSTN Reachability (VIPR), a set of protocols to automatically and securely provision SIP routes between domains.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
</section>
<section title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
<t>This document uses some of the terminology defined in <xref target="RELOAD"/> and <xref target="RFC3261"/>.</t>
</section>
<section title="Security Considerations">
<t/>
</section>
<section title="IANA Considerations">
</section>
<section title="Acknowledgements">
<t>This document was written with the xml2rfc tool described in <xref target="RFC2629"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
<list>
<t>
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.
</t>
</list>
</t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT"/>
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
</reference>
<reference anchor="RFC2434">
<front>
<title abbrev="Guidelines for IANA Considerations">Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author fullname="Thomas Narten" initials="T." surname="Narten">
<organization>IBM Corporation</organization>
<address>
<postal>
<street>3039 Cornwallis Ave.</street>
<street>PO Box 12195 - BRQA/502</street>
<street>Research Triangle Park</street>
<street>NC 27709-2195</street>
</postal>
<phone>919-254-7798</phone>
<email>narten@raleigh.ibm.com</email>
</address>
</author>
<author fullname="Harald Tveit Alvestrand" initials="H.T." surname="Alvestrand">
<organization>Maxware</organization>
<address>
<postal>
<street>Pirsenteret</street>
<street>N-7005 Trondheim</street>
<country>Norway</country>
</postal>
<phone>+47 73 54 57 97</phone>
<email>Harald@Alvestrand.no</email>
</address>
</author>
<date month="October" year="1998"/>
<area>General</area>
<keyword>Internet Assigned Numbers Authority</keyword>
<keyword>IANA</keyword>
<abstract>
<t>
Many protocols make use of identifiers consisting of constants and
other well-known values. Even after a protocol has been defined and
deployment has begun, new values may need to be assigned (e.g., for a
new option type in DHCP, or a new encryption or authentication
algorithm for IPSec). To insure that such quantities have consistent
values and interpretations in different implementations, their
assignment must be administered by a central authority. For IETF
protocols, that role is provided by the Internet Assigned Numbers
Authority (IANA).
</t>
<t>
In order for the IANA to manage a given name space prudently, it
needs guidelines describing the conditions under which new values can
be assigned. If the IANA is expected to play a role in the management
of a name space, the IANA must be given clear and concise
instructions describing that role. This document discusses issues
that should be considered in formulating a policy for assigning
values to a name space and provides guidelines to document authors on
the specific text that must be included in documents that place
demands on the IANA.
</t>
</abstract>
</front>
<seriesInfo name="BCP" value="26"/>
<seriesInfo name="RFC" value="2434"/>
<format octets="25092" target="http://www.rfc-editor.org/rfc/rfc2434.txt" type="TXT"/>
<format octets="37803" target="http://xml.resource.org/public/rfc/html/rfc2434.html" type="HTML"/>
<format octets="27060" target="http://xml.resource.org/public/rfc/xml/rfc2434.xml" type="XML"/>
</reference>
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author fullname="J. Rosenberg" initials="J." surname="Rosenberg">
<organization/>
</author>
<author fullname="H. Schulzrinne" initials="H." surname="Schulzrinne">
<organization/>
</author>
<author fullname="G. Camarillo" initials="G." surname="Camarillo">
<organization/>
</author>
<author fullname="A. Johnston" initials="A." surname="Johnston">
<organization/>
</author>
<author fullname="J. Peterson" initials="J." surname="Peterson">
<organization/>
</author>
<author fullname="R. Sparks" initials="R." surname="Sparks">
<organization/>
</author>
<author fullname="M. Handley" initials="M." surname="Handley">
<organization/>
</author>
<author fullname="E. Schooler" initials="E." surname="Schooler">
<organization/>
</author>
<date month="June" year="2002"/>
<abstract>
<t>This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="3261"/>
<format octets="647976" target="http://www.rfc-editor.org/rfc/rfc3261.txt" type="TXT"/>
</reference>
<reference anchor="RELOAD">
<front>
<title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
<organization/>
</author>
<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
<organization/>
</author>
<author fullname="Salman Baset" initials="S" surname="Baset">
<organization/>
</author>
<author fullname="Henning Schulzrinne" initials="H" surname="Schulzrinne">
<organization/>
</author>
<date day="4" month="August" year="2011"/>
<abstract>
<t>This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-base-18"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-18.txt" type="TXT"/>
</reference>
<reference anchor="VIPR-PVP">
<front>
<title>The Public Switched Telephone Network (PSTN) Validation Protocol (PVP)</title>
<author fullname="Jonathan Rosenberg" initials="J" surname="Rosenberg">
<organization/>
</author>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Marc Petit-Huguenin" initials="M" surname="Petit-Huguenin">
<organization/>
</author>
<date day="14" month="June" year="2011"/>
<abstract>
<t>One of the main challenges in inter-domain federation of Session Initiation Protocol (SIP) calls is that many domains continue to utilize phone numbers, and not email-style SIP URI. Consequently, a mechanism is needed that enables secure mappings from phone numbers to domains. The main technical challenge in doing this securely is to verify that the domain in question truly is the "owner" of the phone number. This specification defines the PSTN Validation Protocol (PVP), which can be used by a domain to verify this ownership by means of a forward routability check in the PSTN.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-petithuguenin-vipr-pvp-01"/>
<format target="http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-pvp-01.txt" type="TXT"/>
</reference>
<reference anchor="VIPR-RELOAD">
<front>
<title>A Usage of Resource Location and Discovery (RELOAD) for Public Switched Telephone Network (PSTN) Verification</title>
<author fullname="Jonathan Rosenberg" initials="J" surname="Rosenberg">
<organization/>
</author>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Marc Petit-Huguenin" initials="M" surname="Petit-Huguenin">
<organization/>
</author>
<date day="10" month="July" year="2011"/>
<abstract>
<t>Verification Involving PSTN Reachability (VIPR) is a technique for inter-domain SIP federation. VIPR makes use of the RELOAD protocol to store unverified mappings from phone numbers to RELOAD nodes, with whom a validation process can be run. This document defines the usage of RELOAD for this purpose.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-petithuguenin-vipr-reload-usage-02"/>
<format target="http://www.ietf.org/internet-drafts/draft-petithuguenin-vipr-reload-usage-02.txt" type="TXT"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="RFC2629">
<front>
<title>Writing I-Ds and RFCs using XML</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country>
</postal>
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>
<date month="June" year="1999"/>
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="2629"/>
<format octets="48677" target="http://www.rfc-editor.org/rfc/rfc2629.txt" type="TXT"/>
<format octets="71741" target="http://xml.resource.org/public/rfc/html/rfc2629.html" type="HTML"/>
<format octets="53481" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml" type="XML"/>
</reference>
<reference anchor="VIPR-OVERVIEW">
<front>
<title>Verification Involving PSTN Reachability: Requirements and Architecture Overview</title>
<author fullname="Mary Barnes" initials="M" surname="Barnes">
<organization/>
</author>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Jonathan Rosenberg" initials="J" surname="Rosenberg">
<organization/>
</author>
<author fullname="Marc Petit-Huguenin" initials="M" surname="Petit-Huguenin">
<organization/>
</author>
<date day="28" month="September" year="2011"/>
<abstract>
<t>The Session Initiation Protocol (SIP) has seen widespread deployment within individual domains, typically supporting voice and video communications. Though it was designed from the outset to support inter-domain federation over the public Internet, such federation has not materialized. The primary reasons for this are the complexities of inter-domain phone number routing and concerns over security. This document reviews this problem space, outlines requirements, and then describes a new model and technique for inter-domain federation with SIP involving the Public Switched Telephone Network (PSTN), called Verification Involving PSTN Reachability (VIPR). VIPR addresses the problems that have prevented inter-domain federation over the Internet. It provides fully distributed inter-domain routing for phone numbers, authorized mappings from phone numbers to domains, a new technique for automated SIP anti-spam, and privacy of number ownership, all while preserving the trapezoidal model of SIP.</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-jennings-vipr-overview-02"/>
<format target="http://www.ietf.org/internet-drafts/draft-jennings-vipr-overview-02.txt" type="TXT"/>
</reference>
<reference anchor="VIPR-VAP">
<front>
<title>Verification Involving PSTN Reachability: The ViPR Access Protocol (VAP)</title>
<author fullname="Cullen Jennings" initials="C" surname="Jennings">
<organization/>
</author>
<author fullname="Jonathan Rosenberg" initials="J" surname="Rosenberg">
<organization/>
</author>
<author fullname="Marc Petit-Huguenin" initials="M" surname="Petit-Huguenin">
<organization/>
</author>
<date day="11" month="July" year="2011"/>
<abstract>
<t>Verification Involving PSTN Reachability (ViPR) is a technique for inter-domain SIP federation. ViPR hybridizes the PSTN, P2P networks, and SIP, and in doing so, addresses the phone number routing and VoIP spam problems that have been a barrier to federation. The ViPR architecture uses a server, the ViPR server, which performs P2P and validation services on behalf of call agents, which acts as clients to the server. Such an architecture requires a client/server protocol between call agents and the ViPR server. That protocol, defined here, is called the ViPR Access Protocol (VAP).</t>
</abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-jennings-vipr-vap-01"/>
<format target="http://www.ietf.org/internet-drafts/draft-jennings-vipr-vap-01.txt" type="TXT"/>
</reference>
</references>
<section title="Examples">
<t/>
</section>
<section title="Release notes">
<t>This section must be removed before publication as an RFC.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:16:52 |