Minutes of the P2PSIP BOF at IETF 67 November 6, 2006, 3:20pm Chairs: David Bryan and Brian Rosen Notetakers/Jabber Scribe: Scott Brim, Bruce Lowekamp, Spencer Dawkins Opened with note well slide on screen. Chairs verbally presented agenda: Brian introduces agenda as: 1) concepts (Will strongly restrict to 30 minutes maximum w/discussion) 2) charter 3) revisit concepts if cut off PHILIP MATTHEWS PRESENTS CONCEPTS DRAFT - Rohan Mahy: don't bother with user versus resource for now. Everything we're talking about is just a user. Clarify that there is no mention of user in this draft that really matters in terms of difference from resource - a peer protocol will have some sort of nat traversal capability in it. - If the P2P client protocol is SIP, then there is no such thing as a P2P client, just SIP clients and P2P peers. - A lot of the examples don't work behind NAT. Concepts Discussion - Henning Schulzrinne: client versus peer protocol in multiplicity. Could have several client protocols, independent. Harder to have multiple peer protocols. That could be a significant distinguisher. - Eric Rescorla: are peers gateways, or are the clients directly connected? He talked too fast. He's concerned that you lose self-configuration in hybrid client and peer networks. Don't want to have a class of translators. - Henning: the design document is for a sense of possibilities. An overlay could consist only of peers. We don't want to have a required class distinction. Although it does help with the trust issue. If we keep the concept of peer/client, state explicitly that everything could be required to be peers. looking at a design space, and there are design choices that support the pure peer world, but not ready to rule out architectures with multiple tiers. - Dean Willis: what Henning said. - Ted Hardie: can a client join the overlay topology multiple times? Can be confusing if different peers offer different services. - Henning: raises a point -- with "client", "node" etc. concepts are too big. It may not be a physical entity. Can you have multiple clients at a single IP address? Yes. reminder that people have different concepts of terms node, peer, agents, clients, etc No further topics for mic at :25 minutes of dicussion on concepts draft. Will continue discussion on the list. CHARTER presented by Chairs, David Bryan reads/presents charter as is - Rohan: charter should be something where you don't need references. Just say the use cases have been documented. Then copy definitions for p2p peers and clients into 2nd paragraph. - Seemed to be concensus to remove references. No objections. - (Richard?) First paragraph is about "use of SIP" but you're using a p2p protocol. OK it's confusing. Need clarification that the task is to aid in SIP deployments but protocol to do location may not be SIP. - J D Rosenberg: use of stun and turn is very vague and waffley. But the charter is clear that you're replacing 3263 with a p2p lookup service. Discovery of replicated resources such as turn servers is hard and the answer is unclear. - Rohan: tasks point 3: p2p client protocol theoretically could be a third protocol. David clarifies that is the case as currently written. - Philip Matthews: tasks point 3: do we need to say "if necessary" since it is possible that we might not have clients in some designs? Cullen: No, and also could define multiple client protocols. - Khalid someone. Confused about p2psip. Do we mean SIP or peer to peer session. He's confused. David: explanation of goals. This is a lookup for a SIP network -- something different is another wg. It was more clearly stated in the concepts presentation. Do we need something in the charter that the protocol is about discovery and resolution with SIP for session control? - EKR: capture language about client protocol. The semantic difference between client and peer is that client doesn't store data and doesn't route. [OK, we can do that in e-mail.] Anyway just define "logical subset". Brian Rosen: wordsmithing will be done on the list. - Ted Hardie: eliminate "user" from primary tasks bullet 4. Use client/peer instead. Consensus of group was yes. - Joel Halpern: there are references to presence, status etc. Presence is handled by SIP but location is handled by the P2P protocol? Brian: does this cover more than an invite transaction? How about subscribe? Joel: yes that's the problem. - Miguel: Is point 4 an architecture document? Answer: we can reuse "architecture" but applicability statement is the generic. - Jim Fenton: "centralized"? [It's not about distribution of processing as much as distribution of power] Answer: well, we will probably use a centralized certificate authority, so not everything is distributed. "as distributed as we can" - Rosenberg: does "minimally centralized" allow for supernodes? He still thinks you need them for nat traversal. Response is yes. Also may need centralized authority for security authentication. - EKR: try to remove requirement for a set of devices that must be online for the system to work. Like 8 IP addresses in the DNS. What about bootstrap servers? Can be lots of them, cheap. - Topic moved offline, this isn't a charter issue, but implementation detail. - Rosenberg: but not ruling out supernodes? Answer: Supernodes ok. - someone??? ... one global network or many small ones? If many how to route between them? A: interesting but for future study. - Philip Matthews: to connect multiple overlays use conventional SIP services for now. - someone??? ... is there some technical document on locating sip resources? - Enrico Maracco: some work here to date - David: Interesting, but anyway, out of scope for now. - Rohan: need primary task to describe how you interoperate with ordinary SIP. - General agreement that should be there. Primary tasks will need revision. - Marcus ?: besides the charter are there technical design choices already made? will this work for other purposes? - David: we're not going to focus on stopping it, but not going to be concerned about full generalizability of adopted protocols. - Henning: easy to do, but simplifies the standardization process - Brian: other questions on primary tasks list? - Rohan: Goals & Milestones: the applicability statement should be informational. - Rosenberg: Timetable is slack ... Yes but we could go faster. - Henning: at least a year from now we'll have a good idea what the protocols look like. - Henning: applicability statement -- the name -- what's the content? Answer: This is how the pieces we produce, plus SIP, are all tied together and how they interact with one another. How to produce systems to do what you want etc. - Rohan: Could use "usage document" like in SIP. - David: Reread list of issues raised above. Call for a hum "Do the people here feel that this charter, modulo the changes suggested is acceptable and that a working group should be formed with this charter to explore P2PSIP?" - All hums for. No hums opposed noted.