[802SEC] FW: [New-work] WG Review: Peer-to-Peer Session Initiation Protocol(p2psip)
WG Chairs,
The following announcement from the IETF may be of interest to your WG
members.
Paul
-----Original Message-----
From: IESG Secretary [mailto:iesg-secretary@ietf.org]
Sent: Monday, January 15, 2007 3:50 PM
To: new-work@ietf.org
Subject: [New-work] WG Review: Peer-to-Peer Session Initiation
Protocol(p2psip)
A new IETF working group has been proposed in the Real-time Applications
and Infrastructure Area Area. The IESG has not made any determination as
yet. The following draft charter was submitted, and is provided for
informational purposes only. Please send your comments to the IESG
mailing list (iesg@ietf.org) by January 22nd.
+++
Peer-to-Peer Session Initiation Protocol (p2psip)
=================================================
Current Status: Proposed Working Group
Chairs: TBD
RAI Area Director(s): Cullen Jennings and Jon Peterson
RAI Area Advisor: Cullen Jennings
Mailing Lists: General Discussion: p2p-sip@cs.columbia.edu Subscribe at:
http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/
(Note: mailing list will be moving to ietf)
Description of the Working Group:
The Peer-to-Peer (P2P) Session Initiation Protocol working group (P2PSIP
WG) is chartered to develop protocols and mechanisms for the use of the
Session Initiation Protocol (SIP) in settings where the service of
establishing and managing sessions is principally handled by a
collection of intelligent endpoints, rather than centralized servers as
in SIP as currently deployed. A number of cases where such an
architecture is desirable have been documented.
The work focuses on collections of nodes called "P2PSIP peers" and
"P2PSIP clients". P2PSIP peers manifest a distributed namespace in which
overlay users are identified and provides mechanisms for locating users
or resources within the P2PSIP overlay. P2PSIP clients differ from
P2PSIP peers primarily in that they do not store information in the
overlay, but only use it to locate users and resources. P2PSIP clients
and peers use the resolution services of the peers as an alternative to
the SIP discovery process of RFC 3263. In this way, P2PSIP offers an
alternative mechanism for determining the correct destination for SIP
requests. The working group's initial charter scope will be to produce
protocols to enable this alternate mechanism for RFC 3263 functionality.
Session management, messaging, and presence functions are performed
using conventional SIP.
This group's primary tasks are to produce:
1. An overview document explaining concepts, terminology, rationale, and
illustrative use cases for the remaining work.
2. A proposed standard defining a P2PSIP Peer Protocol. This protocol is
used between P2PSIP overlay peers, some of which may be behind NATs.
This protocol will define how the P2PSIP peers collectively provide for
user and resource location in a SIP environment with no or minimal
centralized servers. This protocol may or may not be syntactically based
on SIP, a decision to be made by the WG. The group will identify and
require one base P2P algorithm (likely a particular Distributed Hash
Table (DHT) algorithm), while allowing for additional optional
algorithms in the future.
3. Optionally, a proposed standard defining a P2PSIP Client Protocol for
use by P2PSIP clients, some of which may be behind NATs. This protocol
will define how the P2PSIP clients query and/or modify, the resource
location information of the overlay. While clearly a logical subset of
the P2PSIP Protocol, the WG will determine if the P2PSIP Client Protocol
is a syntactic subset of the P2PSIP Peer Protocol, and whether the
P2PSIP Client Protocol builds on the SIP protocol.
4. A usage document. This document will address how the protocols
defined above, along with existing IETF protocols, can be used to
produce systems to locate a P2PSIP peer or client, identify appropriate
resources to facilitate communications (for example media relays), and
establish communications between the users of these P2PSIP peers or
clients, without relying on centralized servers. Additionally, the
document will explain how P2PSIP and conventional SIP entities can
interoperate.
The initial work will assume the existence of some enrollment process
that provides a unique user name, credentials, and an initial set of
bootstrap nodes if that is required by the protocols. Developing a
non-centralized enrollment process is not in scope.
The work planned for the P2PSIP working group is distinct from, but
requires close participation with other IETF WGs, particularly SIP,
SIPPING, SIMPLE, BEHAVE and MMUSIC. The group cannot modify the baseline
SIP behavior, define a new version of SIP, or attempt to produce a
parallel protocol for session establishment. If the group determines
that any capabilities requiring an extension to SIP are needed, the
group will seek to define such extensions within the SIP working group
using the SIP change process (RFC 3427). Similarly, existing tools
developed in the BEHAVE and MMUSIC groups will be used for NAT
traversal, with extensions or changes desired to support P2PSIP
presented to the BEHAVE or MMUSIC working groups.
The working group will assume that NATs and firewalls exist in the
Internet, and will ensure that the protocols produced work in their
presence as much as possible. "Similarly, the WG will avoid making
protocol design decisions that would preclude the creation of anonymous
communications systems using techniques such as onion routing to conceal
the IP addresses of P2PSIP peers.
The following topics are excluded from the Working Group's scope:
1. Issues specific to applications other than locating users and
resources for SIP-based communications and presence.
2. Solving "research" type questions related to P2PSIP or P2P in
general. The WG will instead forward such work to the IRTF P2PRG or
other RG as appropriate. Examples include fully distributed schemes for
assuring unique user identities and the development of P2P-based
replacements for DNS.
3. Locating resources based on something other than URIs. In other
words, arbitrary search of attributes is out of scope, but locating
resources based on their URIs is in scope. Using URIs need not imply
using the DNS or having a record in the DNS for the URI.
4. Multicast and dynamic DNS based approaches as the core lookup
mechanism for locating users and resources. Approaches based on these
technologies may be reasonable ways to solve similar problems but that
is not the focus of this WG. These techniques may be in-scope for
locating bootstrap peers/servers or for interoperation with conventional
SIP.
Goals and Milestones:
(Note: dates are very draft)
Jul 2007 WGLC of P2PSIP overview document Sep 2007 Submit P2PSIP
overview document to the IESG (Informational)
Jan 2008 WGLC of P2PSIP Peer Protocol document Mar 2008 Submit P2PSIP
Peer Protocol document to the IESG (PS)
Jul 2008 WGLC of P2PSIP Client Protocol document Aug 2008 Submit P2PSIP
Client Protocol document to the IESG (PS)
Apr 2009 WGLC of P2PSIP usage document
May 2009 Submit P2PSIP usage document to the IESG (BCP)
_______________________________________________
New-work mailing list
New-work@ietf.org
https://www1.ietf.org/mailman/listinfo/new-work
----------
This email is sent from the 802 Executive Committee email reflector. This list is maintained by Listserv.