Subject: [p2p-sip] work items we agreed on and not agreed on

From: eunsoo at research.panasonic.com (Eunsoo Shim)
Date: Wed, 14 Jun 2006 12:13:47 -0400

As repeatedly stressed, we should focus on creating the WG and thus on
work items for the first charter.

There was a discussion about whether an IETF WG should design a system
or a set of tools. Jon Peterson suggested that the proposed P2PSIP WG
should focus on tools. I believe his view is widely accepted in the
group and I also agree with him. Eventually the IETF produces protocols
and developers and vendors use the protocols to design and build systems .

We were requested to present our architecture(s) to explain what we are
going to do in the BOF in Dallas. But I believe the intention is to
explain what kind of tools we are going to produce using the
architectures but not to limit the architectures or systems that can use
the tools.

Maybe not fast as we have hoped, but I believe we have made meaningful
progresses. Below is my summary of our status in terms of consensus on
work items. There are other things like what protocol we will use for a
certain thing but we are not required to agree on those things or more
details of the tools/work items at this stage.

<THING WE MADE A ROUGH CONSENSUS ON>

We would build the following tools:
* P2PSIP Overlay Client Protocol
    - GET and PUT request/reply
* Types and formats of data to be stored and shared on the P2PSIP
Overlay Network for P2PSIP
    - There should be associated descriptions of how SIP can use the
defined data.
* Mechanism(s) to locate proximate STUN servers (TURN relay in a
different language)

For NAT Traversal, we agreed that NAT traversal should be considered
from the beginning and that STUN/TURN/ICE should and could be used for
P2PSIP but we would talk to the relevant WGs if we need anything new in
STUN/TURN/ICE.

For security, we agreed that the P2PSIP Overlay Network will typically
consist of users not trusted by each other and thus there should be
security mechanisms built into the protocols for P2PSIP.

For basic call setup, we agreed that the UAC retrieves the
location/contact/route information of the UAS from the P2PSIP Overlay
Network using the GET procedure and establishes the call following RFC3261.

<THINGS WE DID NOT MAKE A ROUGH CONSENSUS ON YET>

* P2PSIP Overlay Peer Protocol
      - GET,PUT,JOIN,LEAVE
      - Selection of the P2P algorithm (or DHT)

There are three positions about this.
       - We should select at least a DHT algorithm and design the Peer
Protocol for v1.0.
       - We should do it but postpone it after v1.0. (A variation of
this position suggests that, for v1.0, we assume multicast/broadcast
among Peers.)
       - We should not do this at all.

Does this summary concur with what you think?

Thanks.

Eunsoo