Subject: [p2p-sip] Revised Draft for possible WG charter

From: karstbj at yahoo.com (Karst Bjorgson)
Date: Tue, 31 Jan 2006 23:44:26 -0800 (PST)

> 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.

Isn't the reference to the "zeroconf" working group a
bit problematic? The group is flagged on the IETF web
page as "concluded". Its only result was the
publication of RFC 3927 (rfc3927) - Dynamic
Configuration of IPv4 Link-Local Addresses. While
useful, link local addresses are certainly not
sufficient for "bootstrapping peer association". The
quick fix is probably to just say "... rely on
alternate means of bootstrapping the peer association
group." (i.e. remove the mention of zeroconf.)

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

---

From: jose at netlab.hut.fi ([email-masked])
Date: Wed, 1 Feb 2006 09:49:27 +0200

Hi David,

The proposal looks pretty good.
Rgds
Jose

> I've inlined a newer version of the charter draft (minor changes)
>
> Changes are adding the wording below about evaluating NAT
> solutions/forwarding to other groups,  changing slightly some wording
> in the very last sentence of the first paragraph of the description
> (the part about this being an alternative to the conventional
> approach), and re-wording the first bullet in what is excluded (used
> to say locating users for SIP, now says locating users for SIP-based
> communications, since some folks were worried that didn't cover doing
> presence/IM with the located resources, which we will likely want as
> well as media calls).
>
> No other changes.
>
> I hope this incorporated many (most?) of the suggestions we seemed to
> have reached consensus on.
>
> --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. 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.
>
> 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)
>
> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>

---

From: dbarrett at quinthar.com (David Barrett)
Date: Wed, 1 Feb 2006 10:30:36 -0800

I agree with the crowd, this draft looks great.  The only nit I could pick:

> -----Original Message-----
> 
> While ensuring:
> 

Should we define security in this context?  For example, does this include
'resistance to government monitoring' or 'compatibility with existing
government monitoring systems' -- both of which fall under the umbrella of
security depending on your viewpoint.

I'm no security guru, but I'd toss out:

"1. Interoperability with existing transport-level security infrastructures
for encryption, tamper-resistance, and authentication."

In other words, I'd suggest protection against traffic analysis, anonymous
communications, or other really advanced (and research-centric) security
topics be left out of scope.

-david

---

From: dean.willis at softarmor.com (Dean Willis)
Date: Wed, 1 Feb 2006 13:14:07 -0600

> group." (i.e. remove the mention of zeroconf.)

You've got a point.

I was actually thinking "bonjour", but that's overly restrictive.

--
Dean