Subject: [p2p-sip] Draft: BOF request for p2p-sip

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 18 Jan 2006 13:59:31 -0600

BOF Name: Peer to Peer support for Session Initiation Protocol [P2P-SIP]
Transport Area (Allison Mankin, sponsoring AD)
BOF Chairs: Dean Willis <dean.willis at softarmor.com> , David Bryan  
<bryan at ethernot.org>

Agenda:
-----------

Agenda Bash, 5 minutes
Discussion of Draft Charter and Scope, 30 minutes
Discussion  of  Potential Working Group Organization (volunteering of  
chairs, secretary) 25 Minutes
Discussion of Use Cases Document (draft-bryan-sipping-p2p-usecases)   
30 Minutes
Discussion of Requirements (draft-baset-sipping-p2preq) 30 minutes

Supporting documents:
	draft-johnston-sipping-p2p-ipcom
	draft-bryan-sipping-p2p

Standard "Question 4" Answers for Scheduling:
---------------------------------------------------------------

a. Working Group or BOF full name with acronym in brackets:

Peer to Peer Support for Session Initiation Protocol [P2P-SIP]

b. AREA under which Working Group or BOF appears:

Transport

c. CONFLICTS you wish to avoid, please be as specific as possible:

SIP, SIPPING, SIMPLE, BEHAVE, ECRIT, TSVWG, TSVAREA, AVT,

d. Expected Attendance

200

e. Special requests

None

f. Number of sessions:

We'd like one session during the regular IETF and would like to  
organize an additional gathering on Friday afternoon following the  
regular IETF session.

g. Length of sessions:

The "regular session" should be at least 2 hours if possible but we  
can make do with a 1 hour regular session assuming we have the  
extended "after meeting" session.

Working Group Description
-------------------------------------

The Draft Charter (see following text) contains a detailed  
description of the proposed working group as well as references to  
the mailing list and its archive. The constituency met in an ad-hoc  
fashion under the auspices of the SIPPING working group at IETF 62,  
63 64. Minutes of those discussions are posted at:

http://www.softarmor.com/sipping/meets/ietf62/notes/notes-dwillis- 
p2padhoc-sipping-62.html
http://www.softarmor.com/sipping/meets/ietf63/notes/p2p-ad-hoc- 
sipping-ietf63.txt
http://www.softarmor.com/sipping/meets/ietf64/notes/minutes-p2p- 
sipping-ietf64.txt

Historically, the level of interest in this work gas been very high,  
with more than 50 people attending the ad-hoc sessions despite their  
unusual scheduling. There are existing drafts for use cases,  
requirements, and two different solution approaches in the IETF  
repository at the time of this request. Some of these documents have  
been revised several times and are beginning to mature.

The most significant challenge the constituency has faced is  
narrowing its focus to a scope that is manageable in an IETF working  
group. We believe the following draft charter addresses that focus  
and has strong consensus in the community.

Draft Charter
------------------

Peer-to-Peer Session Initiation Protocol (P2PSIP)

Chairs:
TBD

Transport Area Director(s):
Allison Mankin <mankin at psg.com>
Jon Peterson <jon.peterson at neustar.biz>

Transport Area Advisor:
TBD

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 of
using a hierarchy of proxies where the mapping of users to proxies is
determined by a combination of out-of-band and geographic mechanisms.

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. Disconnected or partly-connected topologies with ephemeral
    relationships such as small office systems (with little or no
    central equipment), mesh networks, emergency response, and
    battlelfield environments.

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
    generally 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 based
    on the "zeroconf" work.

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.

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 SIP-based communications.

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: philip_matthews at magma.ca (Philip Matthews)
Date: Wed, 18 Jan 2006 16:23:48 -0500

Dean:

You didn't say how long we wanted the additional session on Friday  
afternoon to be.
Perhaps request a 4-hour session (1 - 5pm) like we had in Vancouver?

If more internet-drafts are better, then I can easily re-submit my  
now-expired draft from the spring.

Should we also avoid a conflict with the p2prg (if it will meet again  
in Dallas)?

- Philip

On 18-Jan-06, at 14:59 , Dean Willis wrote:

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: buford at research.panasonic.com (John Buford)
Date: Wed, 18 Jan 2006 16:29:27 -0500

Regarding p2prg, a meeting is being planned for Dallas,
though time has not been set yet.  So avoiding the conflict
would be great.

John

----------------------------------
Dean:

- Philip