Subject: [p2p-sip] Some comments on Use-cases document

From: sathya at research.panasonic.com (Sathya Narayanan)
Date: Tue, 21 Mar 2006 14:10:03 -0500

Dean -

> 
> I propose that we first define an abstract model of an overlay  
> network that includes the requisite primitives INSERT and QUERY  
> (anything else needed?) and use this abstraction as our middle layer.

There is a section in draft-shim-sipping-p2p-arch-00.txt on P2P Overlay API which proposes a set of such primitives.
 
> For the lower-layer, we do a binding from the abstraction to one or  
> more distributed database models, probably starting with CHORD. This  
> leaves our P2PSIP architecture independent of the database, but gives a proof-of-concept adequate for implementation.

I am not sure if CHORD is the best option to start with. But, I will wait to hear other opinions/reasons before taking a position on this one.

> 
> For the upper-layer, we have one model defined using SIP REGISTER  
> messages. We've also heard of work that uses REGISTER for the  
> "INSERT" primitive and SUBSCRIBE/NOTIFY for the "query" primitive.
> 
> I'm also very interested in seeing if there's an obvious binding for  
> TURN here, as that might kill two birds with one stone.
> 
> I propose we start with the REGISTER/REGISTER model from the bryan 
> draft and talk that through a little further before we think about changing it.

My understanding of Bryan's draft is that it tries to extend SIP for overlay maintenance and resource location, i.e. a single layer approach (Please correct me if I am wrong). So, proposing to start with that model implicitely chooses that approach and ignores the other possibility of having two separate layers as proposed in draft-shim. I think we should have an explicit discussion on that "key" question before proceeding any further. 

thanks,
Sathya

> _______________________________________________
> p2p-sip mailing list
> p2p-sip at cs.columbia.edu
> https://lists.cs.columbia.edu/cucslists/listinfo/p2p-sip
>