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

[JiangXingFeng <[e-mail]>]

--
Jiang XingFeng

> -----Original Message-----
> From: JiangXingFeng [mailto:[e-mail]]
> Sent: Tuesday, February 27, 2007 10:28 AM
> To: 'Philip Matthews'
> Subject: RE: [P2PSIP] Concept draft: Open issues #5 - 8
> 
> Hi, Philip:
> 
> Comments are inline!
> 
> --
> Jiang XingFeng
> 
> > -----Original Message-----
> > From: Philip Matthews [mailto:[e-mail]]
> > Sent: Tuesday, February 27, 2007 2:23 AM
> > To: [e-mail]
> > Subject: [P2PSIP] Concept draft: Open issues #5 - 8
> >
> > 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.
> >
> > 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.
> >
> [JiangXingFeng] Basically, I agree with your proposals. In terms of
service, I have
> something to say. Service is a big concept, and we could define any
functions that a
> peer could provide as service. So in P2PSIP, we should narrow the scope of
service
> concept. Maybe we should confine the service which is helpful to SIP like
> applications, such as VoIP, IM, presence, etc.
> 
> Another point is that we should differentiate the service provided by the
peer itself
> and the service provided by the P2PSIP overlay. In
draft-willis-p2psip-concepts-03,
> we often say peers are providing storage and routing service for other
peers. I think
> the meaning of storage service, routing service, replication service is
different from
> the meaning of high level service like stun service, VM service, etc. So,
my
> suggestion is that we call the service provided by the overlay as function
in order to
> distinguish these two types of service on the different level.
> >
> >
> > 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!)
> >
> [JiangXingFeng] What I really concerns is that how the introduction of
Service model
> could help. My suggestion is that some examples are needed in the new
revision to
> explain the benefit from the service model.
> >
> >
> > 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".
> >
> [JIangXingFeng] Good job. This classification makes P2PSIP more like a
operable
> system.
> >
> >
> > 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?".
> >
> [JiangXingFeng] Do you mean that if clients reuse or extend SIP protocol,
it is no
> need to give the SIP entities a new name "client"? right?
> >
> > _______________________________________________
> > P2PSIP mailing list
> > [e-mail]
> > https://www1.ietf.org/mailman/listinfo/p2psip



_______________________________________________
P2PSIP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/p2psip