[03:50:45] --- jlcjohn has joined
[03:51:31] --- xmlscott has joined
[03:55:15] --- ericc has joined
[03:57:34] --- johnson has joined
[03:57:54] --- mlepinski has joined
[03:59:41] --- avwijk has joined
[04:02:29] --- frodek has joined
[04:02:30] --- lowekamp@gmail.com has joined
[04:02:32] --- xmlscott has left
[04:03:08] --- Jack3010 has joined
[04:03:09] --- axelm has joined
[04:04:18] --- Jabber-Wile has joined
[04:04:24] --- csp has joined
[04:04:43] --- dku has joined
[04:05:03] --- richard.barnes has joined
[04:05:26] --- cgn has joined
[04:06:00] --- xmlscott has joined
[04:06:07] --- ysuzuki has joined
[04:06:10] --- emcho has joined
[04:06:11] <richard.barnes> Good morning, I will be your jabber scribe
[04:06:17] <richard.barnes> Reviewing the charter
[04:06:25] --- Jack3010 has left: Computer went to sleep
[04:07:02] <axelm> http://www.ietf.org/html.charters/p2psip-charter.html
[04:07:31] <richard.barnes> Describing primary tasks in charter
[04:07:41] <richard.barnes> 1. overview document
[04:07:49] <richard.barnes> provides direction for the next two things
[04:08:01] --- marcel has joined
[04:08:01] <richard.barnes> 2. standard for Peer protocol & 3. standard for client protocol
[04:08:21] <richard.barnes> NB: No firm decision yet on whether there is a client proto
[04:08:23] --- eburger has joined
[04:08:26] <richard.barnes> or on a DHT algorithm
[04:08:40] <richard.barnes> or about what the protocol will be for either protocol
[04:09:02] <richard.barnes> 4. usage document -- how do you use this in a SIP environment
[04:09:26] <richard.barnes> assuming an enrollment process that provides unique names
[04:09:46] <richard.barnes> we will work with other WGs, not re-inventing SIP
[04:10:00] <richard.barnes> unique security challenges to be addressed
[04:10:20] <richard.barnes> NOT in scope:
[04:10:36] <richard.barnes> applications other than locating users & resources
[04:10:56] <richard.barnes> solving "research"-type questons, e.g. a fully-distributed User ID system
[04:11:05] <richard.barnes> replacing the DNS
[04:11:19] --- bewo has joined
[04:11:21] <richard.barnes> multicast/dynamic DNS
[04:11:29] <richard.barnes> (those last 4 things are out of scope)
[04:11:34] <richard.barnes> Goals & milestones:
[04:11:51] <richard.barnes> overview doc WGLC by Chicago IETF 69
[04:11:59] <richard.barnes> protocol docs in 2008
[04:12:07] <richard.barnes> (these may slip)
[04:12:12] <richard.barnes> usage doc in 2009
[04:12:24] --- cullenfluffyjennings@gmail.com has joined
[04:12:33] <richard.barnes> please read the charter if you haven't
[04:12:54] --- rjaksa has joined
[04:12:54] <richard.barnes> Dean Willis: P2PSIP Concepts and Terminology
[04:13:30] <richard.barnes> Credit goes to Philip, David
[04:13:54] <richard.barnes> Changes:
[04:14:04] <richard.barnes> Terminology clean up
[04:14:12] --- avwijk has left
[04:14:12] <richard.barnes> locating and joining an overlay
[04:14:23] <richard.barnes> Terminology changes
[04:14:30] <richard.barnes> (third slide)
[04:15:03] <axelm> slides: http://www3.ietf.org/proceedings/07mar/slides/p2psip-1.pdf
[04:15:04] <richard.barnes> (fourth slide)
[04:15:34] <richard.barnes> [thanks axel]
[04:15:35] --- JeffH has joined
[04:15:45] <richard.barnes> Note that bootstrap server is NOT a peer,
[04:15:52] <richard.barnes> but could be colocated with bootstrap peer
[04:15:57] <richard.barnes> all these roles could be in one box
[04:16:03] <richard.barnes> (fifth slide)
[04:16:18] --- AdamUzelac has joined
[04:16:24] --- Jack3010 has joined
[04:16:36] <richard.barnes> JDR: Admitting peer is part of the DHT, right?
[04:17:16] <richard.barnes> So you get assigned an admitting peer by the DHT
[04:17:17] --- xmlscott has left
[04:17:30] <richard.barnes> Philip: Bootstrap peer could choose itself
[04:17:43] <richard.barnes> e.g. with Chord, if the bootstrap peer happened to be the successor....
[04:17:51] <richard.barnes> JDR: But that gets increasingly improbable
[04:18:06] <richard.barnes> ... so admitting peer can't be the same box
[04:18:28] <richard.barnes> Admitting peer is a function of the DHT, and not a choice
[04:18:58] <richard.barnes> Cullen: Confusion: some people view the admitting peer as the first hop, some as the place you get inserted
[04:19:19] <richard.barnes> these are two different views, and this needs to be clarified
[04:19:37] <richard.barnes> Philip: Thought it was clear. Feel free to send text
[04:19:51] --- bhoeneis has joined
[04:20:18] <richard.barnes> Idea is that bootstrap is the first you contact, admitting peer does the "heavy lifting" (chosen by DHT)
[04:20:42] <richard.barnes> Cullen: That's what the doc says, and I still don't know
[04:21:25] <richard.barnes> Henning: We want to do several things with these, we should say what each thing does
[04:22:13] <richard.barnes> 1. Admits you and gives you the right to be part of the overlay
[04:22:29] <richard.barnes> 2. Insertion peer: new neighbor, inserts you in the routing table
[04:22:45] <richard.barnes> 3. Insertion point: where you get inserted
[04:23:18] --- bewo has left: Replaced by new connection
[04:23:32] <richard.barnes> Philip: Assumption is that "bouncer" role is both bootstrap peer and admitting peer; both could reject
[04:23:53] <richard.barnes> Do you think that we need a separate peer for that
[04:24:02] <richard.barnes> Henning: Start with roles, then worry about boxes
[04:24:29] <richard.barnes> Slide 5
[04:25:07] <richard.barnes> Slide 6
[04:25:26] <richard.barnes> 8 node overlay
[04:25:33] <richard.barnes> alice puts contact into overlay
[04:25:47] <richard.barnes> bob get's alice's contact from the overlay
[04:25:56] <richard.barnes> bob sends INVITE to alice
[04:26:10] <richard.barnes> Slide 7
[04:26:28] <richard.barnes> Alternative: Overlay routes INVITE on behalf of bob
[04:27:00] --- danwing has joined
[04:27:00] <richard.barnes> Allows for persistent relationships between bob/alice and their peers (e.g. to pass firewalls)
[04:27:07] <richard.barnes> Slide 8
[04:27:19] <richard.barnes> Overlay stores contact for alice's proxy
[04:27:38] <richard.barnes> Slide 9
[04:27:43] <richard.barnes> Slide 8
[04:27:56] <richard.barnes> Cullen: Would proxy always be a peer?
[04:28:03] --- dumdidum has joined
[04:28:04] <richard.barnes> Dean: Not necessarily. Could be.
[04:28:37] <richard.barnes> JDR: There's a different model: What's stored is Alice's peer identity, and one function of the peer protocol is to establish a connection (through NAT) to a peer
[04:29:11] <richard.barnes> Peer service could facilitate a P2P TCP connection
[04:29:37] <richard.barnes> Once you have this connection, you could do a few things, e.g. peer join or INVITE
[04:29:44] <richard.barnes> (add to concepts draft)
[04:30:00] <richard.barnes> Philip: That model is orthogonal. Could do that in any of the previous models
[04:30:12] --- fparent@jabber.org has joined
[04:30:30] <richard.barnes> Dean: It's a different take on "how does overlay pass messages?"
[04:30:51] <richard.barnes> Vijay: That's a sipsec thing?
[04:30:57] <richard.barnes> Dean: Could be, that would be one way to do it.
[04:31:11] <richard.barnes> Slide 9: NAT traversal
[04:31:20] <ericc> Is it tunnelling or tunnel establishment?
[04:32:02] <richard.barnes> Slide 10: Credentials
[04:32:30] <richard.barnes> Working model is certificates
[04:32:37] <richard.barnes> could be IBE, or something else
[04:32:39] --- danwing has left
[04:32:41] --- danwing has joined
[04:33:21] <richard.barnes> service credentials related to the question of service names
[04:33:26] <richard.barnes> slide 11: Client models
[04:33:42] --- tobia has joined
[04:33:58] <richard.barnes> slide 12: Additional questions
[04:34:49] <richard.barnes> JDR: This is really important:
[04:35:05] <richard.barnes> We've been talking about regular SIP, people don't really trust proxies
[04:35:27] <richard.barnes> In any other model than a P2P SIP connection, have a large number of untrusted intermediaries
[04:35:39] <richard.barnes> Little choice but direct P2P connection for SIP
[04:36:05] <richard.barnes> Dean: Also possibly hybrid domains, some standard SIP, some P2P
[04:36:06] --- tobia has left
[04:36:30] <richard.barnes> Cullen: Not a conventional "domain" -- more like SIP domain working with P2P domain
[04:36:38] --- lowekamp@gmail.com has left
[04:36:49] <richard.barnes> Spencer: Part of the question is whether you have the same AOR in both domains
[04:36:54] <richard.barnes> Dean: Could
[04:36:59] --- xiaodong has joined
[04:37:02] <richard.barnes> Slide 12: Futures
[04:37:35] <richard.barnes> Open question: What to do with this draft?
[04:37:42] <richard.barnes> Brian: Discussion about what to do?
[04:37:50] <richard.barnes> JDR: Adopt as framework draft.
[04:38:03] <ericc> Agree.
[04:38:06] <richard.barnes> Bruce Loewenkamp: Would like revision process to be more formal
[04:38:21] <richard.barnes> Brian: If it's a WG doc, then that would be the case
[04:38:53] <richard.barnes> Keith Drage: Don't think there's a point to publishing now. Need to keep it flexible as things change
[04:39:12] --- imyelmo has joined
[04:39:21] <richard.barnes> Philip: Back in the fall, someone suggested we keep this as a draft and change as the protocol docs are developed
[04:39:37] <richard.barnes> Do we want to publish it now, incomplete, or miss the charter date?
[04:39:37] --- xavier.marjou has joined
[04:39:41] <richard.barnes> Henning: Keep it alive
[04:39:50] <richard.barnes> People who want it can read it
[04:40:33] <richard.barnes> If it's almost done, it's almost done, and we can ship it when we're ready
[04:41:10] <richard.barnes> Spencer: question for the group is "are we ready to be doing changes with WG consensus, as we would with a WG draft?"
[04:41:23] <richard.barnes> Henry: For the sake of Phil, I agree we should keep it as a draft
[04:41:29] --- hbaosiy has joined
[04:41:38] <richard.barnes> E.g., Hennings introduced terminology today
[04:42:08] <richard.barnes> Cullen: Right now this is a discussion draft that will evolved into what we actually do
[04:42:18] <richard.barnes> But we want to minimize late surprises
[04:42:33] <richard.barnes> Once we have a pretty good idea of what we're doing, go ahead and send this to IESG, etc
[04:42:39] --- eburger has left
[04:42:58] --- dp has joined
[04:43:04] <richard.barnes> Keith: This is a good starter for the framework doc, should be a WG draft
[04:43:13] --- danwing has left
[04:43:22] <richard.barnes> Brian: Hum on "Should this be a WG doc"?
[04:43:38] <richard.barnes> Hum in favor of WG doc
[04:43:41] <richard.barnes> Adopted.
[04:43:55] <richard.barnes> JDR: Formal editor?
[04:44:00] <richard.barnes> Brian: Chairs will appoint one
[04:44:02] --- joonhyung.lim has joined
[04:44:32] --- lowekamp@gmail.com has joined
[04:44:45] <richard.barnes> David Bryan on DHT selection
[04:44:48] <richard.barnes> Slide 2:
[04:44:54] <richard.barnes> DHT Selection
[04:45:14] <axelm> slides: http://www3.ietf.org/proceedings/07mar/slides/p2psip-2.ppt
[04:45:17] --- danwing has joined
[04:45:47] <richard.barnes> JDR: Must you use a single DHT for a single overlay
[04:46:03] --- xavier.marjou has left
[04:46:24] <richard.barnes> David: Not sure anyone believes that's possible
[04:46:27] --- xavier.marjou has joined
[04:46:39] <richard.barnes> Use a single DHT in a single overlay, but different overlays can use different DHT
[04:46:55] --- simov has joined
[04:47:03] <richard.barnes> Henning: Possible for a single software instance to run multiple DHTs simultaneously
[04:47:12] <richard.barnes> Whoever starts the DHT gets to pick
[04:47:32] <richard.barnes> Only really works if you have one that you MUST implement
[04:47:42] --- lminiero has joined
[04:48:03] <richard.barnes> Real question is what the clients support
[04:48:10] --- simov has left
[04:48:17] --- ttfr has joined
[04:48:35] <richard.barnes> Spencer: We need to choose one.
[04:48:50] <richard.barnes> We have use cases that imply a very loose relationship between peers
[04:49:10] <richard.barnes> Henry: Cannot have a preferred one if you have "ships in the night"
[04:49:21] <richard.barnes> Framework document is too narrowing
[04:49:40] <richard.barnes> Need flexibility not to have a default, in order to allow other functions
[04:50:06] <richard.barnes> Henning: Philosophically, we should pick one
[04:50:33] <richard.barnes> This is different than what we do for security, since peer nodes form a closed community
[04:50:58] <richard.barnes> If we can easily agree on one, or one as a MUST, but people are going to operate closed nets with different DHTs anyway
[04:51:08] <richard.barnes> So peer protocol should be DHT agnostic
[04:51:24] <richard.barnes> Cullen: Not sure what you just said is consistent with the charter
[04:52:01] <richard.barnes> Philip: I would like to have multiple choices. Before making a firm decision, though, we should see how it would work
[04:52:13] <richard.barnes> David: Henning's proposal, e.g., would support at least 2
[04:52:25] --- hbaosiy has left
[04:52:42] <richard.barnes> Philip: When a joining node tries to join the overlay, he says what he supports, admitting peer compares, and if there's a match, the node gets to join
[04:53:01] <richard.barnes> Could have a situation where overlays split up
[04:53:18] <richard.barnes> JDR: Unless the overlay shrinks to zero, the DHT algo never changes
[04:53:29] <richard.barnes> David: This assumes you're changing DHTs on the fly
[04:54:14] <richard.barnes> Keith: Obviously selecting a DHT for running SIP. Other apps also use DHTs, are we considering other apps?
[04:54:20] <richard.barnes> Chairs: Out of charter
[04:54:27] --- Jukka has joined
[04:55:01] --- Jelte has joined
[04:55:05] <richard.barnes> New speaker: We should standardize peer protocol, keep choices of DHT open
[04:55:49] <richard.barnes> Henning: From a practical perspective, only one DHT algo will be implemented in a ring at a time
[04:56:35] <richard.barnes> In order to change DHTs, you have to do the same data in two DHTs at once
[04:58:43] <richard.barnes> Hum: "WG agrees that the protocol is designed to support multiple DHTs, with one MUST implement"
[04:59:41] <richard.barnes> Henning: Only qualification is that you don't run multiple ones simultaneously
[05:00:16] <richard.barnes> Hum in favor of "multiple with one MUST"
[05:00:40] <richard.barnes> wrapping up here.
[05:00:56] <richard.barnes> rest of slides deal with which DHT to use; please read slides
[05:01:14] <richard.barnes> Philip Matthews: The NAT Traversal Problem in P2PSIP
[05:01:18] <axelm> slides: http://www3.ietf.org/proceedings/07mar/slides/p2psip-3.ppt
[05:01:58] --- bless has joined
[05:02:07] <richard.barnes> Slide 3
[05:02:11] --- ietf68-test4321 has joined
[05:03:17] <richard.barnes> Viewing RTP as a solved problem, by STUN/ICE
[05:03:30] --- xavier.marjou has left
[05:04:26] <richard.barnes> Slide 4
[05:05:19] <richard.barnes> Some peers get "promoted" to be super-peers
[05:05:37] <richard.barnes> ordinary peers connect to super-peers in a "client-server" sort of relationship
[05:05:56] <richard.barnes> messages between overlay nodes routed through super-peers
[05:06:17] <richard.barnes> JDR: Is super-peer status automatically configured?
[05:06:22] <richard.barnes> Philip: Open question
[05:07:00] <richard.barnes> Henning: Logically speaking, the ordinary peers are in the same place, independent of their role
[05:07:19] <richard.barnes> E.g., the chord ring might not correspond well to real topology
[05:07:35] --- cullenfluffyjennings@gmail.com has left
[05:07:54] <richard.barnes> Philip: The way that this is usually implemented is that DHT is done by the super-peers, and other nodes are more client-like
[05:08:10] <richard.barnes> Philip: Could also distribute DHT out to other peers as well
[05:08:38] <richard.barnes> Henning: This could cause confusion between clients and peers
[05:08:56] <richard.barnes> David: There's also an incentive to not be a super-peer
[05:09:03] <richard.barnes> e.g., people do this with Skype
[05:09:23] <richard.barnes> Henning: Don't see any way you can prevent that in an open protocol
[05:10:28] <richard.barnes> Kevin: Can two ordinary peers behind a NAT talk directly to each other?
[05:10:50] <richard.barnes> Philip: Open question. I would advocate that that be allowed, but could be forbidden
[05:10:57] <richard.barnes> Slide 5
[05:12:45] <richard.barnes> Slide 6
[05:12:53] <richard.barnes> In this situation, how do you do routing?
[05:13:15] <richard.barnes> DON'T want to run a routing protocol (like OSPF)
[05:13:16] --- marcel has left: Replaced by new connection
[05:13:56] <richard.barnes> Advantage in this situation is that the peers can choose what the links are
[05:14:07] <richard.barnes> Chord suggests choosing "exponential" peers
[05:14:51] <richard.barnes> New speaker: Seems that we're mixing NAT traversal and DHT approach
[05:15:13] <richard.barnes> Seems like you could just use ICE to deal with NATs and do whatever routing
[05:15:25] <richard.barnes> JDR: Like this approach because it lets you do that
[05:15:53] <richard.barnes> Philip: Could make connection topology match the DHT, but don't have to
[05:16:07] --- danwing has left
[05:16:37] <richard.barnes> JDR: Don't understand the meaning of separating the DHT from the routing. How do you know that where you send a message is closer to its destination?
[05:17:16] <richard.barnes> Think you'll find that in the super-node model, you'll have to only run the DHT on the super-peers
[05:17:39] <richard.barnes> Unless we choose the fully distributed approach, you'll only have DHT in the super-peers
[05:18:25] <richard.barnes> Bruce Lowekamp: I met this slide. SHould have said "routing should be a SUPERSET of DHT routing"
[05:18:58] <richard.barnes> Philip: The only thing you need to make this work is "greedy routing"
[05:19:04] --- danwing has joined
[05:19:19] --- hejingtong has joined
[05:19:21] --- AdamUzelac has left: Logging off
[05:19:39] <richard.barnes> New speaker: NAT traversal is orthogonal to this
[05:19:44] <lowekamp@gmail.com> clarification: most important point is "connections" is a superset of "dht routing edges"
[05:19:59] <richard.barnes> yes, thanks.
[05:20:39] <richard.barnes> New speaker: Deal with NAT traversal, then connection topology
[05:20:59] <richard.barnes> JDR: This is a no-brainer. If you do this, then you can still have a super-node configuration
[05:21:14] <richard.barnes> But if you mix NAT traversal with topolgy, then you rule out a lot of options
[05:21:59] --- LouBerger has joined
[05:22:03] --- marcel has joined
[05:22:03] --- xiaodong has left: Disconnected.
[05:22:05] <richard.barnes> Henry: This wouldn't be an issue if people had read the background material
[05:22:18] <richard.barnes> slide 7
[05:22:44] <richard.barnes> This shows how you can set up some of the connections in this model using ICE
[05:22:57] <richard.barnes> Using SIP as the method to establish a connection
[05:23:23] --- kamaji has joined
[05:24:25] <richard.barnes> Spencer: Do you need to know if you have a public IP?
[05:24:38] <richard.barnes> JDR: Can base super-peer decision on other things
[05:24:47] <richard.barnes> Slide 8
[05:24:56] --- fparent@jabber.org has left: Replaced by new connection
[05:26:40] <richard.barnes> Henning: There's a trade-off between implementation complexity and special circumstances
[05:26:45] <richard.barnes> not clear we have to make a choice
[05:26:52] --- marcel has left: Replaced by new connection
[05:27:25] <richard.barnes> You need STUN nodes in the distributed case, so you need some quasi-super-peers anyway
[05:27:33] --- cgn has left
[05:28:10] --- cgn has joined
[05:29:00] <richard.barnes> in either model, you need a rendezvous node, either to admit super-peers or to facilitate STUN
[05:29:47] <richard.barnes> Philip: Do want a hybrid?
[05:30:15] <richard.barnes> Henning: Should be possible to have a "public peers only" network or not
[05:30:22] --- dwillis has joined
[05:30:45] <richard.barnes> David: That would require that there should be a mechanism for telling someone whether they can be a peer or not
[05:31:00] <richard.barnes> Henning: Yes, and there will be lots of other reasons a peer candidate can be bounced
[05:31:21] <richard.barnes> JDR: This is actually not very hard. Just like with SIP, you only need to implement ICE if you're behind a NAT
[05:32:09] <richard.barnes> You can't really do better than Log(N) hops, but N may be smaller with only super-peers
[05:32:25] --- kamaji has left
[05:32:35] <richard.barnes> [Log(N) was meant to be Log N]
[05:32:59] <richard.barnes> Bruce: The only other use case where you don't need ICE is a single-enterprise provider
[05:33:25] <richard.barnes> the suggestion that we can develop a protocol to tell whether you need ICE is surprising
[05:34:05] <richard.barnes> Need to require ICE, since it will be necessary in almost all cases
[05:34:16] <richard.barnes> Henry: Missing from this is neighbor selection
[05:35:27] <richard.barnes> Doesn't matter if you declare super-nodes, need first to determine which peers you can see
[05:35:41] <richard.barnes> Philip: In which model?
[05:36:20] <richard.barnes> Henry: Chord/DHT routing is only half of the story, how do you select neighbors? This is missing from the story we're hearing here
[05:36:42] <richard.barnes> Then, how do you select who the best neighbors are, that you want to do ICE with
[05:37:03] --- johnson has left
[05:37:18] --- johnson has joined
[05:37:39] <richard.barnes> JDR: To answer Henry's question, ICE enables selection of candidates according to multiple criteria
[05:38:04] --- Jukka has left
[05:38:10] <richard.barnes> If you're going to use ICE, you'll also need to have TURN servers out there
[05:38:35] <richard.barnes> There are reported cases of people stealing public addresses for use within NATted nets
[05:39:36] <richard.barnes> Henry: Don't think we can make a good choice based on this discussion.
[05:39:53] <richard.barnes> Philip: Agreed, we'll probably end up with a hybrid
[05:39:58] --- johnson has left
[05:40:08] --- johnson has joined
[05:40:15] <richard.barnes> David: No consensus here, we'll take it to the list
[05:40:34] <richard.barnes> New Speaker: There is an alternative to ICE from another IETF WG
[05:40:48] <richard.barnes> From HIP WG
[05:40:53] --- bpenfield has joined
[05:41:08] --- johnson has left
[05:41:45] <richard.barnes> Next presentation...
[05:41:55] <axelm> slides: http://www3.ietf.org/proceedings/07mar/slides/p2psip-4.ppt
[05:42:05] <richard.barnes> Jiang XingFeng: Requirements for the Peer Protocol
[05:42:08] <richard.barnes> Slide 2
[05:42:33] <richard.barnes> Slide 3
[05:43:12] <richard.barnes> Slide 4
[05:43:42] <richard.barnes> Slide 5
[05:43:48] <richard.barnes> Bruce provided the next 2 slides
[05:44:20] <richard.barnes> Philip: Object a little bit to NAT traversal argument
[05:44:31] <richard.barnes> UDP better in some cases, worse in others
[05:44:48] <richard.barnes> More likely to get a connection with UDP, but you have to send keepalives
[05:45:00] <richard.barnes> With TCP, less likely to get a connection, but fewer keepalives
[05:45:30] <richard.barnes> Henning: Not worth debating TCP/UDP and binary/ascii here. Treat this as opinion and move on.
[05:45:46] <richard.barnes> Cullen: Need to add ASN.1 vs XML
[05:45:58] --- danwing has left
[05:46:05] --- Jabber-Wile has left
[05:46:15] <richard.barnes> Bruce: Just for clarification, this was trying to list things that the peer protocol design will have to decide
[05:46:36] <richard.barnes> Keith: Some of these questions, you need to leave to the very end of the protocol design process
[05:46:39] <richard.barnes> Slide 6
[05:47:29] <richard.barnes> Ted Hardie: You're conflating solutions and requirements
[05:47:37] <richard.barnes> authentication is a fine requirement, certificates are a solution
[05:48:02] <richard.barnes> More broadly, found comparison to non-p2p SIP distracting. Just do p2psip.
[05:48:14] --- cgn has left
[05:48:38] <richard.barnes> Philip: Think we've agreed that certificate distribution is out of scope
[05:48:55] <richard.barnes> Bruce: That's talking about distribution, not creation of certs, which could be in scope
[05:49:07] <richard.barnes> Or, more generally, credentials
[05:49:37] <richard.barnes> Brian: If we change cert to credential, then this is ok
[05:50:19] <richard.barnes> Cullen: EKR would say that you need a threat model to drive all this
[05:50:43] <richard.barnes> Slide N: Advanced requirements
[05:50:54] <richard.barnes> [I've lost track of N -- which slide are we on?]
[05:51:19] <ericc> I think 7.
[05:51:31] <richard.barnes> Done now, on to Henning
[05:51:59] <richard.barnes> Henning Schulzrinne: P2P Protocol Requirements
[05:52:02] <richard.barnes> Slide 2
[05:52:20] <axelm> (slides don't seem to be uploaded yet)
[05:52:20] <richard.barnes> We've been dancing around the type of data in the DHT
[05:52:34] --- johnson has joined
[05:52:38] <richard.barnes> OK: Slide 2 is about data
[05:52:40] --- danwing has joined
[05:52:51] <richard.barnes> Need to discuss whether large messages/objects are a requirement
[05:52:52] --- jpc has joined
[05:52:53] --- cgn has joined
[05:53:02] <richard.barnes> likely either ~500B or "infinity"
[05:53:13] <richard.barnes> Need to look at data expiration
[05:53:20] <richard.barnes> refresh should not require rewrite
[05:53:35] <richard.barnes> can creator specify expiration time?
[05:53:43] <richard.barnes> next slide: Meta data
[05:53:51] <richard.barnes> do we need it? or just "real" data?
[05:53:54] --- cgn has left
[05:54:07] <richard.barnes> e.g. content type, creation time, last updated/refreshed, ownership, access permissions
[05:54:09] <richard.barnes> Done!
[05:54:45] <richard.barnes> Philip: General procedural question: Seems like we might start a design team to work on this. How are we going to go forward with this?
[05:55:01] <richard.barnes> Brian: We'll take advice, but we'd like to see some drafts that a design team could start from.
[05:55:23] <richard.barnes> Henning: There have been 2 draft efforts (Henning's and Feng's)
[05:55:39] <richard.barnes> Brian: Like to see more discussion & drafts, then a design team will be appropriate
[05:55:54] <richard.barnes> Henning: Not sure that trying to merge drafts is appropriate.
[05:56:19] <richard.barnes> Brian: We had a use case discussion, which should drive requirements.
[05:56:39] <richard.barnes> Philip: Agree with that proposal
[05:57:24] <richard.barnes> Authors and Spencer have agreed to revive/revise those drafts
[05:58:44] <richard.barnes> Spencer will be talking to these slides
[05:58:51] <richard.barnes> (even though he hasn't seen them yet)
[05:59:00] <richard.barnes> Spencer Dawkins: P2PSIP Clients Discussion
[05:59:06] <richard.barnes> [are these slides on the web?]
[05:59:40] <richard.barnes> Slide 2
[05:59:42] <axelm> (no, don't seem to)
[06:00:16] <richard.barnes> Slide 3
[06:00:26] <richard.barnes> What clients are not
[06:00:32] <richard.barnes> Slide 4: Where clients are
[06:00:39] <richard.barnes> (figure from concepts draft)
[06:00:51] <richard.barnes> Clients sit on the edge of the ring and talk to edge peers
[06:01:02] <richard.barnes> Philip: That diagram assumes one particular model of a client
[06:01:14] <richard.barnes> And the name for the peer (Proxy peer) is limiting
[06:01:27] <richard.barnes> Next slide: What problem are we trying to solve?
[06:01:44] <richard.barnes> next slide: modes of operation
[06:01:49] <richard.barnes> interaction w/database
[06:01:53] <richard.barnes> routing of SIP requests
[06:02:36] <richard.barnes> next slide: IDEA: Client as a storage node
[06:02:48] --- imyelmo has left: Lost connection
[06:02:58] <richard.barnes> Proposed: keep storage function separate until someone comes up with a use case
[06:03:06] <richard.barnes> Next slide: Basic client picture
[06:03:27] <richard.barnes> Peers get "client adapters" bolted on that allow clients to connect through various protocols
[06:03:55] <richard.barnes> Next slide: Basic client questions
[06:04:15] <richard.barnes> Will all peers be able to do all client things, will all peers do more than one thing?
[06:05:09] <richard.barnes> Philip: We've been approaching this the wrong way by talking about mechanisms instead of what we're trying to do
[06:05:39] <richard.barnes> Spencer: We don't have use cases
[06:05:59] --- LouBerger has left: Replaced by new connection
[06:06:13] --- LouBerger has joined
[06:06:14] <richard.barnes> Brian: I understand why people want to connect normal SIP clients. We should accommodate that , but not let it limit us
[06:06:27] <richard.barnes> We should get rid of "P2PSIP clients"
[06:06:46] <richard.barnes> JDR: I don't see how you get rid of anything until you decide what problem you're trying to solve?
[06:06:50] <richard.barnes> Overlay scalability?
[06:06:51] --- jpc has left
[06:06:53] --- imyelmo has joined
[06:07:06] <richard.barnes> I thought the requirement was for nodes that get service despite not implementing p2p
[06:07:28] <richard.barnes> These are different requirements
[06:08:06] <richard.barnes> Philip: We do want to be able to handle existing SIP UAs, but don't want to call it a Client. A Client is something more than that, but less than a peer
[06:08:17] <richard.barnes> So, what is it then?
[06:08:48] <richard.barnes> Spencer: You're saying we need a list of reasons that you're not a SIP UA and not a peer either
[06:09:08] --- ietf68-test4321 has left
[06:09:17] <richard.barnes> Alan Johnson: it's way to early to throw out clients at this stage, e.g. for nodes that have batteries
[06:09:31] <richard.barnes> Requirements for client protocol don't map cleanly to SIP
[06:09:55] <richard.barnes> Henry: Spencer's chart is good for expressing various use cases
[06:11:06] <richard.barnes> JDR: Put/get that Alan set up won't work. What would you get? If it's IP/port, then you run into NAT traversal
[06:11:31] --- xiaodong has joined
[06:11:31] <richard.barnes> However, if you'd just glued a SIP proxy to the overlay, then it would do the heavy lifting for the client
[06:11:49] <richard.barnes> David: What is it that you want to be getting/putting other than location information
[06:12:12] <richard.barnes> Henry: I want to find all the Rosenbergs in Prague, and I can't do that with a SIP proxy
[06:12:27] <richard.barnes> Brian: Speaking as an individual, I would like to see use cases
[06:12:48] --- xiaodong has left
[06:13:22] <richard.barnes> Philip: Seconds what Brian just said. People who want clients should submit drafts before Chicago describing what they need
[06:13:36] <richard.barnes> If there aren't any drafts by Chicago, then we jettison clients
[06:13:45] <richard.barnes> (where clients != SIP UA)
[06:14:05] <richard.barnes> JDR: I was surprised by Henry's example. I thought we were just making calls
[06:14:17] --- dumdidum has left: Replaced by new connection
[06:14:24] <richard.barnes> David: What do we need beyond what we could do with, e.g., SIP
[06:14:43] <richard.barnes> New speaker: Like this "glue on adapter" model
[06:16:57] <richard.barnes> Hum: "Believe that as part of what we're doing, we include the SIP UA as client"
[06:17:15] <richard.barnes> Hum in favor of the motion
[06:17:37] --- dumdidum has joined
[06:17:47] <richard.barnes> Hold off further decisions until Chicago
[06:17:55] <richard.barnes> People who think there's more to do raising hands
[06:18:04] <richard.barnes> Several hands
[06:18:22] <richard.barnes> I see Dean, Henning near me, several others
[06:18:30] --- lowekamp@gmail.com has left
[06:18:31] <richard.barnes> we're done!
[06:18:40] --- ttfr has left
[06:18:41] --- lminiero has left
[06:18:46] --- dp has left
[06:18:47] --- axelm has left
[06:18:51] --- richard.barnes has left
[06:18:59] --- hejingtong has left: 已登出
[06:19:03] --- ysuzuki has left
[06:19:14] --- csp has left
[06:19:23] --- dwillis has left
[06:19:23] --- frodek has left: Replaced by new connection
[06:19:25] --- bpenfield has left
[06:19:43] --- ericc has left
[06:20:09] --- johnson has left
[06:20:40] --- johnson has joined
[06:20:44] --- johnson has left
[06:21:53] --- Jack3010 has left
[06:21:53] --- danwing has left
[06:22:03] --- dumdidum has left
[06:23:46] --- LouBerger has left
[06:24:09] --- rjaksa has left
[06:25:37] --- JeffH has left: Logged out
[06:30:28] --- emcho has left
[06:36:55] --- dku has left
[06:37:30] --- bhoeneis has left: Replaced by new connection
[06:39:03] --- dku has joined
[06:39:20] --- dku has left
[07:15:39] --- Jelte has left
[07:36:43] --- bless has left: Disconnected
[07:56:31] --- mlepinski has left
[08:05:01] --- imyelmo has left
[08:35:31] --- danwing has joined
[08:40:20] --- danwing has left
[08:49:32] --- joonhyung.lim has left
[09:02:08] --- jlcjohn has left
[09:11:50] --- ericc has joined
[09:11:51] --- joonhyung.lim has joined
[09:45:36] --- joonhyung.lim has left
[10:42:12] --- LOGGING STARTED
[11:31:41] --- joonhyung.lim has joined
[12:02:55] --- ericc has joined
[14:27:47] --- joonhyung.lim has left
[14:40:16] --- ericc has left