Re: [P2PSIP] Concept draft: Open issues #5 - 8

Spencer Dawkins <spencer@mcsr-labs.org> Mon, 26 February 2007 18:39 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkkY-0006SO-NV; Mon, 26 Feb 2007 13:39:02 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLkkX-0006S7-CI for p2psip@ietf.org; Mon, 26 Feb 2007 13:39:01 -0500
Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLkkK-0007y5-J4 for p2psip@ietf.org; Mon, 26 Feb 2007 13:39:01 -0500
Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JE300MFC2GNF4@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Feb 2007 10:38:47 -0800 (PST)
Received: from s73602 (w173.z064002096.dfw-tx.dsl.cnc.net [64.2.96.173]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JE300LZY2GIGJ@usaga01-in.huawei.com> for p2psip@ietf.org; Mon, 26 Feb 2007 10:38:47 -0800 (PST)
Date: Mon, 26 Feb 2007 12:38:24 -0600
From: Spencer Dawkins <spencer@mcsr-labs.org>
Subject: Re: [P2PSIP] Concept draft: Open issues #5 - 8
To: p2psip@ietf.org
Message-id: <024901c759d5$501fb5b0$6501a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-Mailer: Microsoft Outlook Express 6.00.2900.2869
Content-type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <E4D9CFEA-3190-4939-B44C-889E58CCE1C0@magma.ca>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
Errors-To: p2psip-bounces@ietf.org

Hi, Philip,

Thanks for the heads-up on these proposed changes. Comments follow.

Spencer


> Folks:
>
> Back in late January I posted four more open issues for the Concepts 
> draft.
> There was some discussion on these, and I am going to summarize here
> what I think was agreed to as a result of these discussions.
>
> I plan to make these changes to the draft in the next couple of days.
>
> - Philip
>
>
> Open issue #5: Users vs. Resources vs. Services.
> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html
> =======================================
> I propose to go with the following description of these. This is my 
> original proposal above
> except for the addition of a change suggested by Richard Barnes.
>
> Users are humans. A user may be represented in the P2P Overlay by
> multiple UAs, which represent the various different ways that the
> user may be contacted (e.g., desk phone, mobile). Some of these may
> answer even if the user is not available (e.g., voicemail server).
>
> A service represents something that a peer can do on behalf of
> another peer.  Multiple peers may offer the same service. Within a
> service type (e.g., "STUN server"), there may be differentiation
> between the peers on the exact sub-type of the service provided
> (e.g., "STUN server" vs. "STUN server with relay service"). However,
> once the sub-type is selected, the service is identical  between
> peers, so which one to contact can be determined by things such as
> net-path efficiency.

After reading current shake-and-bake discussions about "service ID" on the 
SIPPING mailing list, if we can avoid using the word "service" in P2PSIP, 
that would be lovely. At the very least, the question of addressing should 
be mentioned - some people have assumed there's a SIP URI for services, 
while others are using service to include non-SIP "services" like STUN.

> Information about a UA, user, or service may be stored in the  distributed
> database. The information is stored in a "record", which has an
> associated "key" which is used for lookup.
>
> It may be that a P2PSIP Overlay will store other information in the
> distributed database. Generically, we use the term "resource" for
> the information that can be stored in the distributed database.
>
>
>
> Open issue #6: Data Model vs Service Model
> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/001998.html
> =========================================================
> I propose to add the concept of a Data Model vs a Service Model,
> as described in
>     http://mice.cs.columbia.edu/getTechreport.php?techreportID=388
> and
>     http://www.ietf.org/internet-drafts/draft-singh-p2p-sip-01.txt
> Dan Romascanu requested that we come up with different terms,
> and I will try to do that. (Feel free to make suggestions!)

I agree that both of these are overloaded now...

> Open issue #7: Admitting Peer
> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002000.html
> =========================================================
> I propose to add the terms "Joining Peer" and "Admitting Peer"
> and change "Peer  Insertion" to "Peer Admission".

I agree with this proposed change.

> Open issue #8: Expressing "Client protocol = SIP?"
> https://lists.cs.columbia.edu/pipermail/p2p-sip/2007-January/002013.html
> =========================================================
> I propose to rephase this question as "Do clients exist?".

I agree with this proposed change, but isn't there a parallel question like 
"Peer protocol = SIP?"? 



_______________________________________________
P2PSIP mailing list
P2PSIP@ietf.org
https://www1.ietf.org/mailman/listinfo/p2psip