Subject: [p2p-sip] IMPORTANT!!! Updated Charter

From: bryan at ethernot.org (David A. Bryan)
Date: Fri, 27 Oct 2006 17:20:59 -0400

Folks,

I have reviewed the (thankfully fairly few) comments from late
September on the charter, and made a few changes, reflecting concensus
of those discussions and/or changes in terms used in the terminology
draft (for example removing the leading "overlay" from "P2P overlay
peer" and "P2P overlay client" in about 20 places to reflect the
change in the terminology draft).

The changes are minor overall and few, since the list seemed generally
happy about the charter, but please look and make sure nothing that
changed raises concerns.

You can view the new version at the end of this message. I've also put
it, along with the old version and .pdf showing the differences marked
(just so folks can see exactly what changed) on p2psip.org:
http://www.p2psip.org/ietf.php

PLEASE take a look and make sure this charter is something that folks
can get behind and hum approval to the question "Should a WG with
substantially this charter be formed..." when we have the BOF, one
week from Monday. If there are issues, now is the last chance to raise
them!

Thanks!

David

---

Peer-to-Peer Session Initiation Protocol (P2PSIP)

Chairs: TBD

RAI Area Director(s): Cullen Jennings Jon Peterson

RAI Area Advisor: Cullen Jennings

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 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, or P2PSIP peers,
rather than centralized servers as in client-server SIP as currently
deployed. A number of cases where such an architecture is desirable
have been documented in [1].

The terminology and concepts draft [2] explains the terms and concepts
used here. The work focuses on collections of nodes called "P2PSIP
peers" and "P2PSIP clients". P2PSIP opeers
manifest a distributed namespace in which overlay users are identified
and provides mechanisms for locating users or resources within the
P2PSIP overlay. P2PSIP clients and peers use the resolution
services of the peers as an alternative to the SIP correspondent
discovery process of RFC 3263. Session management, messaging, and
presence functions are performed using traditional 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 serves. 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. 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
   client protocol is a syntactic subset of the peer protocol, and
   whether the client protocol has SIP based syntax.

4. An applicability statement. This document will address how the
   protocols defined above, along with existing IETF protocols, can be
   used to produce systems to locate a user, identify appropriate
   resources to facilitate communications (for example media relays),
   and establish communications between the users, without relying on
   centralized servers.

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 created in these groups.

The working group takes it as a fact 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
group will attempt not to make design decisions that preclude
anonymous communications systems from being crafted using the
protocols defined by this WG.

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.

4. Multicast and dynamic DNS based approaches as the core lookup
   mechanism locating users and resources. These techniques may be
   in-scope for locating bootstrap peers/servers or for interoperation
   with traditional SIP.

Goals and Milestones

Sep 2007 Submit P2PSIP overview document to the IESG (Informational)

Sep 2008 Submit P2PSIP overlay client protocol document to the IESG
(Standards track)

Sep 2008 Submit P2PSIP overlay peer protocol document to the IESG
(Standards track)

May 2009 Submit P2PSIP applicability statement to the IESG (Standards
track)

References

[1] D. Bryan, E. Shim, B. B. Lowekamp, "Use Cases for Peer-to-Peer
    Session Initiation Protocol (P2PSIP)",
    draft-bryan-sipping-p2p-usecases (work-in-progress)

[2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and
    Terminology for Peer to Peer SIP,"
    draft-willis-p2psip-concepts (work-in-progress)

---

From: hsinnrei at adobe.com (Henry Sinnreich)
Date: Fri, 27 Oct 2006 14:59:16 -0700

>   resources based on their URIs is in scope.

Add the sentence (or something like it): Using URIs may or may not imply
using the DNS or having a record in the DNS for the URI.

My apology for the late nit.

Thanks, Henry

-----Original Message-----
From: p2p-sip-bounces at cs.columbia.edu
[mailto:p2p-sip-bounces at cs.columbia.edu] On Behalf Of David A. Bryan
Sent: Friday, October 27, 2006 4:21 PM
To: P2P-SIP
Subject: [p2p-sip] IMPORTANT!!! Updated Charter

Folks,

Thanks!

David

---

Chairs: TBD

Goals and Milestones

References

[2] D. Willis, D. Bryan, P. Matthews, E. Shim, "Concepts and
    Terminology for Peer to Peer SIP,"
    draft-willis-p2psip-concepts (work-in-progress)
_______________________________________________
p2p-sip mailing list
p2p-sip at cs.columbia.edu
https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip

---

From: fwmiller at cornfed.com (Frank W. Miller)
Date: Fri, 27 Oct 2006 23:00:40 -0600

Greetings,

I know this isn't SIP but it seems like the people here would have good
opinions on the work.

I've been working on a new VoIP protocol for quite some time now.  It has
come from many frustrations both in implementing and operating SIP clients.
The work is not anywhere near completed but I feel like there is enough
material now to give a reader a good sketch of what its about.  A draft
describing the protocol can be found at:

http://www.cornfed.com/msp.txt

I would be interested in any comments from anyone on it.  I'm in the process
of implementing as well.  From the abstract:

   The Media Sessions Protocol unifies many of the best ideas associated
   with the current crop of Voice-over-IP (VoIP) and media protocols
   used in the Internet.  MSP uses peer-to-peer location discovery and
   signaling and a centralized user identifcation authority similar to
   Skype.  MSP uses encryption of all message traffic similar to Skype
   using key exchanges similar to ZRTP.  MSP uses a NAT-friendly design
   based on a single transport address similar to IAX2.  MSP uses a
   simplified text-based signaling protocol similar to SIP.  MSP uses
   standard RTP for media transport.

One comment I'd like to head off immediately is that there are very
substantial differences in the way signaling message are formatted and
passed than SIP.  It is not intended to be backward compatible with SIP.

Thanks
FM

---

From: swb at employees.org (Scott W Brim)
Date: Sat, 28 Oct 2006 08:12:09 +0200

First, you missed an "o" -- search for "opeer".

Second, 

> by a collection of intelligent endpoints, or P2PSIP peers,

I think you want to take "and managing" out of the first line.
Compare you have below ...

> presence functions are performed using traditional SIP.

Thanks.

Scott

---

From: swb at employees.org (Scott W Brim)
Date: Sat, 28 Oct 2006 08:13:17 +0200

> using the DNS or having a record in the DNS for the URI.

I like it, but "need not" is easier.

---

From: slavitch at gmail.com (Michael Slavitch)
Date: Sat, 28 Oct 2006 11:16:14 -0400

The charter doc is excellent.

Scott's editing perfects Henry's subtle but vital distinction.

Great work, folks, and good luck in San Diego.

Let's finally bag a Working Group and then some strong standards.  The
world is waiting.

M

PS:

This landlocked sailor recommends some time on blue water while you're
out there.
The daysail charters on either side of the border are great.  Green with envy.

---

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Sat, 28 Oct 2006 11:35:01 -0400

>>by a collection of intelligent endpoints, or P2PSIP peers,
Since 'P2PSIP Peer' has a certain meaning, narrower than 'intelligent
endpoint',
For example, P2PSIP Clients are also such intelligent endpoints.
One remedy may be just removing 'or P2PSIP peers' from the sentence.

Thanks.

Eunsoo