Subject: [p2p-sip] Newest iteration of the Draft Charter

From: bryan at ethernot.org (David A. Bryan)
Date: Sun, 12 Feb 2006 15:41:09 -0500

As requested earlier in the week, here is the charter with a few
changes suggested that seemed to have broad support:

* Removal of explicit reference to zeroconf work

* Reworded scenario 2 to be a bit more readable and to make it clear
one covered enterprise networks

* Changed bit about names generally mapping to domain-level
identifiers to be may may to domain-level identifiers since a number
of people seemed troubled by wording.

Otherwise there isn't much changed. There were a few other things
mentioned, but I think subsequent emails had cleared them up, so I
think this reflects the current state.

As always, comments welcome.

David Bryan

------------------

Peer-to-Peer Session Initiation Protocol (P2PSIP)

Chairs:
TBD

RAI Area Director(s):
TBD

RAI Area Advisor:
Allison Mankin

Mailing Lists:
General Discussion: p2p-sip at cs.columbia.edu
Subscribe at: http://lists.cs.columbia.edu/mailman/listinfo/p2p-sip
Archive at: http://lists.cs.columbia.edu/pipermail/p2p-sip/

Description of the Working Group

The purpose of the Peer-to-Peer (P2P) Session Initiation Protocol
working group (P2PSIP WG) is to develop guidelines and mechanisms for
the use of the Session Initiation Protocol (SIP) in settings where
establishing and managing sessions is either partially or entirely
handled by a collection of endpoints (peers) rather than centralized
servers. This is an alternative to the conventional SIP approach which
relies on service provider hosted proxies to which users get assigned
by out-of-band means, usually based on geography, association, or
business reasons.

This is motivated by scenarios where a reduction in cost of equipment
and operation for non-end users is desired, and in situations where
such servers are not available. Some of the scenarios identified
include:

1. Self-organizing and highly available proxy farms, as opposed to the
   fixed hierarchy of IMS-like systems.

2. Topologies with ephemeral relationships such as small office
   systems (with little or no central equipment) mesh networks,
   emergency response, and battlefield environments. These systems may
   have limited or no connectivity to the Internet.

3. Recovery functions to allow endpoints to communicate in the event a
   central server fails or the endpoints are isolated by a network
   partitioning event.

The working group starts with the following general assumptions:

1. Peer associations groups, which may be called "P2P networks". 'P2P
   overlays", or "P2P federations" will provide namespaces within
   which P2P-SIP resources are identified. These namespaces are
   bounded by the identifier(s) of the peer association group, which
   may map to domain-level identifiers in the DNS.

2. Session establishment, capabilities negotiation, session
   termination, subscription, notification, messaging, and related
   functions traditionally performed using SIP will continue to be
   performed using SIP. This working group is interested only in the
   mechanisms for locating resources within peer association
   groups. We generally refer to this as the "rendezvous problem".

3. Some elements of each peer association group MAY be rooted in the
   DNS such that they can be used for bootstrapping operations.
   However, a peer association group that is operating entirely in an
   isolated (or disconnected, or autonomous) mode will rely on
   alternate means of bootstrapping the peer association group.

4. Interactions between peer association groups (or members thereof)
   and other peer association groups or conventional SIP installations
   will be resolved using the resource location model of RFC 3263:
   "Locating SIP Servers".

5. The level of authenticity of identity will vary by the peer
   association group. However, the working group will define at least
   one mechanism that will provide assertion of identity having
   strength equivalent to that provided by the "SIP Identity
   Mechanism" RFC, perhaps by reusing some or all of the mechanism of
   that RFC.

Specifically, the working group will:

1. Document scenarios in which a P2P architecture is appropriate for
   SIP based solutions ("use-cases" document).

2. Develop a general architecture or framework for P2P-based SIP
   applications. This will require evaluating the existing deployed
   and proposed P2P-based SIP solutions for possible incorporation
   into this work.

3. Define a distributed location mechanism for locating users in the
   absence of a central server, including the protocols and algorithms
   needed do establish, maintain, and query the distributed
   information.

4. If SIP extensions are needed to support the peer-to-peer model,
   define requirements for those extensions to be acted on by the SIP
   working group.

5. Select firewall/NAT traversal technique(s) for P2P SIP and integrate
   them into the P2P SIP architecture or framework.  If necessary,
   define requirements for enhancements of existing techniques to be
   acted on by other working groups.

While ensuring:

1. Security is addressed in these systems.

2. Interoperability with existing client-server (CS) SIP and the PSTN.

3. The solutions proposed will function even with some or many nodes
   located behind NATs or firewalls.

4. Existing protocols are reused whenever possible.

The following topics are initially out of the Working Group's scope,
but may be considered in possible future charters:

1. Using P2P mechanisms to manage groups of distributed media relays.

2. Using distributed relays to enable anonymous communications.

3. Creating distributed voice mail systems.

4. Performing distributed search for users based on something other
   than user id.

The following topics are explicitly excluded from the Working Group's
scope:

1. Issues specific to applications other than locating users and
   resources for the full range of SIP-based communications offered
   in a conventional client-server SIP system, including but not
   limited to real-time media, messaging, and presence.

2. Discussion of this technology as a replacement for conventional
   (client-server) SIP.

3. Solving "research" type open questions related to P2P SIP. The
   working group will instead forward such work to the IRTF. A few
   such topics include:
   o Fully distributed schemes for assuring unique user identities.
   o Development of new structured P2P algorithms, such as DHTs.
   o Developing a P2P-based replacements for DNS.

The working group will operate in close cooperation with the SIP,
SIPPING, SIMPLE, MMUSIC and BEHAVE working groups, as well as the
IRTF. Respecting the IETF specification change policy, the working
group will refer any possible changes or extensions as suggestions to
the appropriate WGs as needed. A guiding principal of the WG will be
to avoid extensions or change wherever possible.

Goals and Milestones
Aug 2006        Submit use-cases document to the IESG (Informational)
Jan 2007        Submit architecture document to the IESG (Informational)
Jul 2007        Submit protocol and/or protocol extension documents to
                the IESG (Standards-track)

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Sun, 12 Feb 2006 17:57:26 -0500

This looks good.

It gives enough scope to allow for broad and innovative practical use-cases.

It also places within scope the basic mechanisms needed to succeed in
fundamental areas of concern, including identity, SIP signalling and NAT
traversal.

For this I am very appreciative.

Unless anyone can see any problems that have been missed I think we can go
forward with this draft charter.

Regards,

Michael

On 12/02/06, David A. Bryan <bryan at ethernot.org> wrote:
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

--
Michael Slavitch
Ottawa, Ontario Canada
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.cs.columbia.edu/pipermail/p2p-sip/attachments/20060212/97d3404c/attachment.html

---

From: edpimentl at gmail.com (Edpimentl)
Date: Sun, 12 Feb 2006 18:06:21 -0500

Hello David,

Excellent draft,
What would be your reaction on adding one or two regarding how Trust,
Privacy, Presence and Preference would
be supported when initiating a P2P session or how P2P-SIP would supported.

Best,
-E
http://GooGaYa.com

---

From: bryan at ethernot.org (David A. Bryan)
Date: Sun, 12 Feb 2006 22:16:42 -0500

I think that presence is in there already (in that item 1 of what is
out of scope says

1. Issues specific to applications other than locating users and resources for
   the full range of SIP-based communications offered
   in a conventional client-server SIP system, including but not
   limited to real-time media, messaging, and presence.

So I think that gets presence in there. I think most of the rest is
likely to be either 1) able to be done in the same way as for CS SIP
or would likely be things we can look at later -- I want to try to
keep the initial scope narrow, so we can actually get the basic
signaling done -- hopefully something we  can extend later.

I worry that distributed trust and privacy also tread close to what I
think may be too close to the general distributed identity problem
listed as out of scope for comfort -- they may very well be difficult
research problems unless some more traditional methods from CS SIP
(such as certificates from a central server) are used.

David