[03:57:35] --- bharris has joined
[03:57:41] --- bharris has left
[03:59:36] --- renee has joined
[04:00:14] --- scribe has joined
[04:01:12] --- marc.bailly has joined
[04:01:20] --- avwijk has joined
[04:01:37] <scribe> NEW SPEAKER: So, this is SIPPING, peer to peer SIP,
[04:01:43] <scribe> got the note welcoming. Blue sheets are here, at this
[04:01:48] <scribe> point, everybody should really understand blue sheets. quh
[04:01:51] <scribe> they get to the back, please do bring them forward and we'll
[04:01:52] <scribe> make sure everybody get them.
[04:02:14] --- frodek has joined
[04:02:21] <scribe> The usual note well. All the usual rules apply. Our
[04:02:26] <scribe> agenda, we will have a short discussion on the charter. There
[04:02:32] <scribe> is the overview dwok document which hopefully you have all read
[04:02:36] <scribe> by this point. Selecting the D H T is one of the things that
[04:02:39] <scribe> we hope we will be able to accomplish pretty quickly in this
[04:02:47] <scribe> work group. Then we have three section, selecting D
[04:02:50] <scribe> H T, the nat and the requirements, we hope to run in the following way.
[04:02:51] --- isudo has joined
[04:02:53] <scribe> We're going to have a a very short presentation. We have
[04:02:58] <scribe> worked very har with draft authors to condense the issues to a
[04:03:01] <scribe> very small number of slides and a very short presentation. We're
[04:03:04] <scribe> trying to minimize the presentation and maximize the discussion.
[04:03:11] <scribe> We will try and be fairly Ruth less to try and keep within our
[04:03:16] <scribe> schedule, we'll let the last session slide, if we need to.
[04:03:21] <scribe> But we really would like to get time for what would the client
[04:03:23] <scribe> protocol look like, because that is something a lot of people are
[04:03:26] <scribe> really interestd in. However, we really
[04:03:29] <scribe> want to get this D H T, the nat and peer protocol issues and the
[04:03:34] <scribe> requirements in the peer protocol moving along. That's more important than
[04:03:37] <scribe> dealing with the client protocol. Okay.
[04:03:42] <scribe> Any discussion, questions or anything else on the agenda?
[04:03:50] <scribe> Okay. Charter.
[04:03:53] --- Jabber-Wile has joined
[04:03:55] <scribe> NEW SPEAKER: Go, yes? NEW SPEAKER: I thought we had
[04:03:59] <scribe> decided there was going to be a client, peer to SIP client,
[04:04:01] <scribe> have you decided there is going to be such a thing. NEW SPEAKER:
[04:04:05] <scribe> Well, we'll cover that in the discussion. I would say,
[04:04:08] <scribe> yes, there's no real agreement within the group that there is
[04:04:13] <scribe> a client. We have note takers are all set. NEW SPEAKER:
[04:04:16] <scribe> We should call for that. I know Spencer said he would do
[04:04:18] <scribe> some note taking, we also need one more. NEW SPEAKER:
[04:04:22] <scribe> Can I have one more note taker, I forgot to ask for that.
[04:04:25] <scribe> Someone please volunteer to take notes. We have one, we need
[04:04:25] <scribe> another.
[04:04:32] <scribe> I'll pick somebody. NEW SPEAKER: You're not afraid to
[04:04:36] <scribe> use it. NEW SPEAKER: No, I'm not afraid at all.
[04:04:39] <scribe> Somebody raise your hands, I really don't want to pick
[04:04:46] <scribe> on somebody, but I will. I'm going to pick somebody.
[04:04:54] <scribe> Oh, my goodness. Who came in late? No no. Everybody is
[04:05:00] <scribe> looking sdoun. That's really cute. How about vee Jay, would
[04:05:08] <scribe> you do that? Thank you. Jabber describe, we do have, we have both rooms open,
[04:05:12] <scribe> if you've been paying attention, there's a running commentary
[04:05:16] <scribe> of everything that's being said, but we want to have a normal
[04:05:19] <scribe> jabber describe, the fundamental thing is just key sitions that
[04:05:21] <scribe> are made and taking any questions up to the Mike.
[04:05:26] <scribe> Can somebody do that, jabber scribes,
[04:05:29] <scribe> anybody in the jabber room. Okay. Who is in? NEW SPEAKER:
[04:05:36] <scribe> NEW SPEAKER: C S H. Eric C. Jabber Wiley. Me. NEW SPEAKER:
[04:05:39] <scribe> I think at least two of those are not here. NEW SPEAKER:
[04:05:39] --- enrico has joined
[04:05:43] <scribe> They won't help.
[04:05:50] <scribe> NEW SPEAKER: I need a jabber scribe. Thank you. Appreciate it.
[04:06:01] <scribe> Okay. With that, any other thing, administrative, before
[04:06:02] <scribe> we begin? Okay.
[04:06:07] <scribe> NEW SPEAKER: Okay. So we just wanted to take a very short time here
[04:06:12] <scribe> to look at the charter as it was actually approved.
[04:06:16] <scribe> Mostly, just to make sure everybody kind of saw the final
[04:06:19] <scribe> version here and has a little bit of an understanding of what it
[04:06:20] <scribe> is we're looking at.
[04:06:24] <scribe> I'm not going to go through and read everything in detail, but what I
[04:06:28] <scribe> really wanted to look at was particularly, because there's
[04:06:31] <scribe> been a little bit of discussion, just to make sure, you know,
[04:06:34] <scribe> we're clear on it, what things were that ended up being in
[04:06:35] <scribe> and out of scope and what our
[04:06:36] <scribe> deliverables were.
[04:06:41] <scribe> So, obviously, you know, if you haven't gone and read this
[04:06:44] <scribe> in a great deal of detail and you want to participate actively
[04:06:45] --- csp has joined
[04:06:48] <scribe> here, you should go and read this in a good bit of detail.
[04:06:51] --- dku has joined
[04:06:53] <scribe> The basic function of what we're doing here is I think, just
[04:06:56] <scribe> about everybody is aware, is we're building an overlay of
[04:07:01] <scribe> peer to peer SIP entities, that are going to be providing resolution
[04:07:06] <scribe> services, possibly some other things, and we had basically have
[04:07:11] <scribe> the following primary tasks, and this is what I want to take
[04:07:14] <scribe> a look at, the tasks and what's in and out of scope.
[04:07:19] <scribe> The primary tasks are to produce three things, two, slash,
[04:07:23] <scribe> three things here. An overview document that explains the
[04:07:26] <scribe> concepts, terminology, rationale and use cases. For the
[04:07:29] <scribe> remaining work. So we call this the framework document in a
[04:07:33] <scribe> number of places, the idea here is we have something that talks
[04:07:37] <scribe> about what it is we're really doing, what it is we're going to
[04:07:40] <scribe> go build and some direction for the next two things.
[04:07:46] <scribe> I'm kind of lumping when I say two. I'm going to lump these
[04:07:51] <scribe> two and three items here together. We have a standard for a
[04:07:56] <scribe> peer to peer SIP protocol and optionally, a a peer to peer
[04:07:58] <scribe> client SIP protocol. These are probably sort of the main
[04:08:00] <scribe> focus of protocol wise of what's going to be
[04:08:03] <scribe> produced by this group for a while. A couple of important
[04:08:07] <scribe> things to note about this, as many people have noticed, and
[04:08:11] <scribe> as someone just pointed out recently, we have not made a decision
[04:08:14] <scribe> about whether there will be a client protocol or not for sure.
[04:08:17] <scribe> There may or may not be. We have not made decisions
[04:08:22] <scribe> about what the particular D H T algorithm is or technically, even
[04:08:26] <scribe> if there will be one. You'll notice that it says likely, a
[04:08:27] <scribe> particular D H T.
[04:08:31] <scribe> And finally, we have not made any decisions about the protocol
[04:08:37] <scribe> for either of these two, you know, what the sin tactic protocol will
[04:08:42] <scribe> be for these things. The 4th deliverable is a usage
[04:08:45] --- jgre has joined
[04:08:46] <scribe> document. And that usage document is once we finished, once we've
[04:08:50] <scribe> identified this protocol, how does this work, in
[04:08:53] <scribe> particular, this is peer to peer SIP. So once we define this
[04:08:57] <scribe> thing, how do we use that in a SIP environment to tie it in
[04:08:59] <scribe> with the other pieces that we're going to have out there.
[04:09:03] <scribe> How do we actually make it communicate? We mentioned being
[04:09:06] <scribe> able to find media relays, that sort of thing.
[04:09:08] <scribe> What are the pieces we need to tie together?
[04:09:11] <scribe> A couple of important points here, that are
[04:09:16] <scribe> somewhat administrative, but important to add.
[04:09:19] <scribe> Initially, we're assuming the existence of some sort of an
[04:09:23] <scribe> enrollment process to provide unique names. That's very
[04:09:26] <scribe> critical. We think it's a very difficult problem that we
[04:09:29] <scribe> don't know how to do fully
[04:09:32] <scribe> dristributed ted. And also, very clearly stated here,
[04:09:35] <scribe> that we will work with other working groups and we are not re
[04:09:37] <scribe> in venting the communications aspects of SIP.
[04:09:43] <scribe> Further, we assume fire walls and nats exist and we will be
[04:09:47] <scribe> working with that fundamental assumption. And we understand that there
[04:09:50] <scribe> are some very unique security challenges in
[04:09:54] <scribe> a peer to peer deployment that you do not have in a
[04:09:58] <scribe> client sr server deployment. We recognize that and we will
[04:10:01] <scribe> work in this working group to make sure
[04:10:06] <scribe> we're addressing those various things, privacy as well. They
[04:10:09] <scribe> are often sort of tied up in these discussions with security, but
[04:10:13] <scribe> obviously, it's an entity we have to worry about, some unique
[04:10:15] <scribe> privacy issues.
[04:10:19] <scribe> Almost as important as what it is we're going to do, what is it that
[04:10:21] <scribe> is not in the scope of this working group. Issues specific
[04:10:25] <scribe> to applications other than locating users and resources, for SIP
[04:10:29] <scribe> based communications and presence. We are not building file
[04:10:34] <scribe> sharing in here. Solving research type questions related to
[04:10:38] <scribe> peer to peer SIP or P to P in general. So again, we
[04:10:43] <scribe> mentioned that we assume a credential server or identity
[04:10:45] <scribe> server, something that's going to be the giving you an
[04:10:47] <scribe> identity. So one of the things that's out of scope would be for
[04:10:51] <scribe> example, fully dris difficulties xwrut ted
[04:10:55] <scribe> user identity system. Other things such as a peer to peer
[04:10:59] <scribe> for DNS and we're here to do peer to peer SIP, not something
[04:11:02] <scribe> like that. We will forward real research questions that we
[04:11:07] <scribe> discover onto, for now, the I R T F peer to peer research
[04:11:07] <scribe> group.
[04:11:12] <scribe> Locating resources based on something other than URIs
[04:11:16] <scribe> and the like, and finally, we're not really in here looking
[04:11:21] <scribe> for multi cast DNS look up. We're looking at structure type
[04:11:24] <scribe> things. Those tech neex may be in
[04:11:27] <scribe> scope for looking at boot strap location and things like that.
[04:11:31] <scribe> Finally, the goals and milestones, we have, if you have
[04:11:35] <scribe> listed on here, quite a few of them. The overview document
[04:11:38] <scribe> is the first thing on our agenda. If you take a look at that
[04:11:42] <scribe> data of working group last call for July 2007, that basically
[04:11:47] <scribe> means we we have to have some pretty thorough progress on this
[04:11:52] <scribe> by Chicago. After that, we have the two protocol
[04:11:55] <scribe> documents, possibly as we've all said, there may only be one of
[04:11:59] <scribe> these. Those we're looking at in January of 2008. We may
[04:12:02] <scribe> all decide that's a little optimistic, since it took us a little
[04:12:05] <scribe> longer to get this charter through than I think we expected
[04:12:08] <scribe> when those dates were first put on.
[04:12:13] <scribe> And finally, submitting a P to P usage document, obviously, that
[04:12:15] <scribe> follows after the protocol. We can't really talk about how
[04:12:19] <scribe> to use it until we define it. But that's pretty much what the
[04:12:22] <scribe> charter looks like. As I said, if there's anything in here
[04:12:26] <scribe> you don't understand or or if you haven't gone and read it in
[04:12:29] <scribe> detail, please do. And with that, I'm going to go ahead and
[04:12:33] <scribe> start with the first presentation here. Which is actually on the
[04:12:36] <scribe> overview document. I think, Dean are you
[04:12:39] <scribe> presenting on this one? Okay.
[04:12:43] <scribe> NEW SPEAKER: Well, I think then you'll present, how's that? NEW SPEAKER:
[04:12:51] --- cullenfluffyjennings@gmail.com has joined
[04:13:06] <scribe> Okay.
[04:13:09] <scribe> NEW SPEAKER: Test, test. Hey, I can hear myself. This is
[04:13:14] <scribe> scary. Okay. Well, as you know, we have a concepts and
[04:13:19] <scribe> terminology draft. Philip Mathews did most of the editing on
[04:13:23] <scribe> this version on it even though it's got my name up front. I
[04:13:25] <scribe> think David Brian did most of the work on the version before that.
[04:13:29] <scribe> So I just sort of coast ted the last two versions. NEW SPEAKER:
[04:13:34] <scribe> The slides. NEW SPEAKER: No, the version is the
[04:13:38] <scribe> draft. Just revised a few weeks ago, or last week. NEW SPEAKER: Slides?
[04:13:39] --- guido has joined
[04:13:47] <scribe> NEW SPEAKER: it not going to work. it P D F. Not
[04:13:48] <scribe> power point. NEW SPEAKER: Next slide. NEW SPEAKER:
[04:13:53] <scribe> Okay. So what we changed in this revision in the concepts of
[04:13:59] <scribe> terminology draft is primarily around, which slide we're looking
[04:14:00] <scribe> at.
[04:14:03] <scribe> We changed a bit of the terminology, cleaning it up as
[04:14:07] <scribe> requested. We added some discussion of locating and joining and
[04:14:10] <scribe> overlay. Talked about the role of the
[04:14:15] <scribe> overlays as distributed database. Added discussion about nat
[04:14:16] --- avwijk has left
[04:14:19] <scribe> traverse Sal, credentials and client mod
[04:14:20] <scribe> models.
[04:14:21] --- dgtlsoul has joined
[04:14:28] <scribe> Okay. So, for the terminology changes, other than the
[04:14:33] <scribe> fact that I have error on the right. There's a something to
[04:14:37] <scribe> add. Really, just sort of fine tweaking in
[04:14:42] <scribe> most of this, with the exception that in the discussion of
[04:14:46] <scribe> boot strapping, a couple of extra layers, including the
[04:14:57] <scribe> joining peer and boot strap peer
[04:15:02] <scribe> So, it's much more detailed discussion of locating and joining
[04:15:06] <scribe> an overlay in this revision of the concepts and terminology
[04:15:10] <scribe> jees, we defined the joining peer to be the new peer coming
[04:15:17] <scribe> into the overlay. The boot strap server to be an over
[04:15:21] <scribe> defining, anything called booth strap peer, which basically
[04:15:24] <scribe> helps you find an ad mything peer. Now, notice
[04:15:30] <scribe> that a boot strap server by definition is not appear, and a
[04:15:34] <scribe> boot strap peer is. Of course, they can be co-located.
[04:15:39] <scribe> And then we have an ad mything peer, which actually
[04:15:44] <scribe> is the node that performs or helps you perform the association
[04:15:48] <scribe> into the database. And it may stay on as some sort of link
[04:15:53] <scribe> into the database in sort of an outbound proxy sort of role. Of
[04:15:56] <scribe> course, all these rolls can be combined all in one box.
[04:15:56] --- JeffH has joined
[04:16:03] <scribe> So the overlay provides a distributed database. It stores information
[04:16:09] <scribe> about resources. Initially, that may be just as simple as contact
[04:16:13] <scribe> storage and a SIP registrar. It might be route storage. The
[04:16:17] <scribe> concepts and terminology draft doesn't conclude anything on that.
[04:16:18] <scribe> Questions from Jonathan?
[04:16:22] <scribe> NEW SPEAKER: Jonathan Rosenburg, would you on go back to
[04:16:26] <scribe> the previous slide? You said the four rolls here could be
[04:16:28] <scribe> one box. Unless I've dash NEW SPEAKER: Three of the
[04:16:31] <scribe> four rolls. NEW SPEAKER: The admitting peer is a
[04:16:33] <scribe> function of the D H T. NEW SPEAKER: It would be hard
[04:16:36] <scribe> to combine the joining peer with the other three rolls. NEW SPEAKER:
[04:16:40] <scribe> But the admitting peer, I thought it was a function of the D H
[04:16:43] <scribe> T, you don't get to choose an arbitrary, unless I
[04:16:46] <scribe> misunderstood what it is, this is the guy you're going to,
[04:16:50] <scribe> when you finally connect to the your initial boot strap peer,
[04:16:55] <scribe> do effectively a a peer join. And that a based on quarter or
[04:16:59] <scribe> whatever, to whoever is currently the guide where you would
[04:17:03] <scribe> otherwise live. And then you steel half his database. That's not an
[04:17:06] <scribe> arbitrary choice, right? That's a function of the D H T. NEW SPEAKER:
[04:17:09] <scribe> But the boot strap peer dash NEW SPEAKER: Go to the
[04:17:13] <scribe> microphone please. NEW SPEAKER: Go to the microphone. NEW SPEAKER:
[04:17:21] <scribe> Boot, sorry. Philip Mathews. The boot strap peer could
[04:17:24] <scribe> choose itself if it happened to be the neighbor that the
[04:17:29] <scribe> joining peer would be, say if you're doing cord for example,
[04:17:33] <scribe> okay, and the boot strap peer just happened to be the
[04:17:37] <scribe> successor, happened to be, NEW SPEAKER: I just, right,
[04:17:43] <scribe> if it happened to be, then the odds grow Lynn Raleigh
[04:17:49] <scribe> smaller, and it happens linearly smaller. NEW SPEAKER:
[04:17:51] <scribe> (Several people talking.) NEW SPEAKER: Assuming that you have
[04:17:57] <scribe> a D H T structure underneath, but we don't have a fixed structure on. NEW SPEAKER:
[04:18:01] <scribe> I'm not sure if you said the concepts draft said it could be the
[04:18:03] <scribe> same box. That's an incorrect statement. NEW SPEAKER: Whether or
[04:18:08] <scribe> not they could be the same box is probably dependent on other
[04:18:08] <scribe> decisions
[04:18:10] <scribe> (Several people talking.) NEW SPEAKER: The document
[04:18:13] <scribe> concepts draft is clear that this admitting peer is a role
[04:18:16] <scribe> that's a function of the D H T algorithm, and not an
[04:18:21] <scribe> arbitrary choice. NEW SPEAKER: Fair point for clarification. Put
[04:18:22] <scribe> that in the notes. Thank you.
[04:18:28] <scribe> Okay. So there's a couple of questions. We'll actually see
[04:18:30] <scribe> a little more of this dash NEW SPEAKER: Can I make a
[04:18:32] <scribe> comment on what the confusion is here. NEW SPEAKER:
[04:18:36] <scribe> Cullen. NEW SPEAKER: I think Jonathan is on a key point.
[04:18:39] <scribe> Some participants view the admitting
[04:18:46] <scribe> peer to be the first node or peer in the D H T that you might contact
[04:18:49] <scribe> to route yourself to the place that you eventually insert
[04:18:51] <scribe> yourself. NEW SPEAKER: Right. NEW SPEAKER: Some
[04:18:55] <scribe> people view it as the end one where you end up inserting yourself and stealing
[04:18:59] <scribe> half of -- and doing something with the finger table or something else on the
[04:19:02] <scribe> logical end. Right? So that's two very different
[04:19:04] --- marcel has joined
[04:19:06] <scribe> views on what the definition of admitting peer is, and the
[04:19:09] <scribe> document is not clear on this. I don't care what the answer
[04:19:17] <scribe> is, but I think that's, for some reason, s it was because I thought,
[04:19:21] <scribe> making that clear one way or another, what we mean by this
[04:19:23] <scribe> determine in the term, will be important. NEW SPEAKER:
[04:19:27] <scribe> I thought it was clear. Philip Mathews, but I guess,
[04:19:32] <scribe> feel free to maybe point out exactly where you think there's some -- NEW SPEAKER:
[04:19:35] <scribe> Or suggest text. NEW SPEAKER: Send text. NEW SPEAKER:
[04:19:39] <scribe> Send text please.
[04:19:43] <scribe> NEW SPEAKER: Which is it? NEW SPEAKER:
[04:19:49] --- hb47713 has joined
[04:19:50] <scribe> Oh, so the idea is dha the boot strap peer is the first guy in the
[04:19:53] <scribe> overlay you happen to contact and he may choose to help you choose
[04:19:58] <scribe> himself, itself, to help you join. Or, probably more
[04:20:03] <scribe> likely, it will refer you onto some other node which will do
[04:20:10] <scribe> the heavy lifting to allow the joining peer to join, and that's other node is the admitting
[04:20:12] <scribe> peer. NEW SPEAKER: And happens to be in the right spot. NEW SPEAKER:
[04:20:15] <scribe> Yes, depending on whatever the algorithm that we choose, the
[04:20:19] <scribe> D H T or whatever we do. It's, whatever seems to be the
[04:20:23] <scribe> right peer to do the heavy lifting, you get referred to, not in
[04:20:28] --- bhoeneis has joined
[04:20:30] <scribe> the literal SIP sense, but just passed onto that guy.
[04:20:34] <scribe> NEW SPEAKER: That's exactly what the document says, and I still
[04:20:36] <scribe> don't know. NEW SPEAKER: Okay. NEW SPEAKER:
[04:20:41] <scribe> Henning. NEW SPEAKER: I think part of the problem is that we
[04:20:44] <scribe> are putting boxes on three different things at least
[04:20:49] <scribe> that we want to do. One is finding the place where the peer
[04:20:53] <scribe> ends up. Deciding whether a peer should end up anywhere.
[04:20:58] <scribe> Admitting this is the bounce at the bar, that checks your
[04:21:03] <scribe> credentials, and finally, any peer who gets you to one of
[04:21:09] <scribe> these other two. If we can make that noise, clearly take, boot
[04:21:12] <scribe> strapping for example, from a WordPerfect expect tiff can mean just
[04:21:15] <scribe> about anything. But I think if we can have words which
[04:21:19] <scribe> somewhat reflect those meanings, if we agree on those
[04:21:21] <scribe> meanings, I think we'll all get a little further. NEW SPEAKER:
[04:21:25] <scribe> So you think there's another role down here that hasn't been
[04:21:28] <scribe> identified below admitting peer, which is the peer one insert
[04:21:31] <scribe> set? Would that clear things up for you NEW SPEAKER:
[04:21:32] <scribe> NEW SPEAKER:
[04:21:34] <scribe> (Several people talking.) NEW SPEAKER: Basically,
[04:21:36] <scribe> said, (Several people talking.) NEW SPEAKER: Call
[04:21:41] <scribe> it admission peer, call it a, a referred one, I can't come
[04:21:45] <scribe> up with a good name right now. I was thinking of one, but it's
[04:21:48] <scribe> not a good name. Something which just indicates a,
[04:21:53] <scribe> essentially, most systems that will be just about any peer,
[04:21:55] <scribe> which can get you to the other two rolls. NEW SPEAKER: Can
[04:21:59] <scribe> you just say what the three are again so we can get them in the
[04:22:03] <scribe> notes. NEW SPEAKER: So, the first one is a peer which,
[04:22:04] <scribe> well, let's start with the opposite way.
[04:22:08] <scribe> The first one is a peer which admits you in the sense, gives
[04:22:12] <scribe> you the right to be part of it. It stamps your
[04:22:15] <scribe> credentials or whatever it happens to be, whatever it -- I
[04:22:18] <scribe> mean, it may be zero but it may exist.
[04:22:23] <scribe> The second one is the insertion peer, that's the new neighbor, that's
[04:22:28] <scribe> one you visit and it inserts your new routing table
[04:22:30] <scribe> in one sort or another.
[04:22:35] <scribe> And the third role is a box which gets you to presumably, first
[04:22:38] <scribe> admitting peer, because you don't get much further without
[04:22:41] <scribe> that one. And eventually maybe into the insertion point.
[04:22:47] <scribe> So this is, and in most systems, refer role can be played
[04:22:50] <scribe> by just about anybody, because anybody should be able to get to anywhere.
[04:22:55] <scribe> But maybe special things that have, special
[04:23:00] <scribe> beacons which say hi, I'm your ambassador or your travel
[04:23:04] <scribe> agency here, which can get you anywhere. Obviously,
[04:23:08] <scribe> neither of these two terms I'm suggesting for the draft. NEW SPEAKER:
[04:23:15] <scribe> So I guess the only thing, there's only two rolls right now
[04:23:17] <scribe> defined. And it's sort of the assumption, at least in my
[04:23:21] <scribe> mind of doing that, is the bouncer role as you were calling
[04:23:24] <scribe> it, could be played by both the boot strap peer and the
[04:23:28] <scribe> admitting peer, since they can both ask for credentials and
[04:23:30] <scribe> choose to reject this attempt if they wanted to. I don't know
[04:23:35] <scribe> if the concept draft says that. But I think, well, okay.
[04:23:40] <scribe> So I think, I also wrote a boot strap mechanism draft and I
[04:23:43] <scribe> think it says in that one, although that one is not far along.
[04:23:46] <scribe> But maybe, so I don't know, do you think it's, I guess I see
[04:23:50] <scribe> this unlikely for us to have yet a third special peer to do
[04:23:52] <scribe> that. But maybe if we need the concept, we should have it. NEW SPEAKER:
[04:23:57] <scribe> I'm simply suggesting to start with rolls first and then worry about boxes
[04:23:59] <scribe> later. NEW SPEAKER: Okay.
[04:24:02] <scribe> NEW SPEAKER: I think all of these are listed as being
[04:24:06] <scribe> logical rolls in the document. NEW SPEAKER: Yes. NEW SPEAKER:
[04:24:15] <scribe> Okay. So a couple of assumptions about the overlay distributed
[04:24:18] <scribe> database. It stores information. We assume it stores this
[04:24:22] <scribe> information which we call resource records. Information on
[04:24:26] <scribe> resources and they are keyed by an I D that you need for the resource.
[04:24:30] <scribe> We think, currently we think we store information about several
[04:24:33] <scribe> different kinds of resources, users, basically your
[04:24:38] <scribe> user name has just a resource I D. Services whose name
[04:24:41] <scribe> hashes to resource I D. Question on whether or not there are other
[04:24:44] <scribe> types of resources that are stored in the distributed database.
[04:24:48] <scribe> The other open question is how does the overlay work to pass
[04:24:52] <scribe> messages, does it store and
[04:24:56] <scribe> really treev. Or do optsz, or message passing on behalf of
[04:25:02] <scribe> the pierce, or does it peers, or just store
[04:25:07] <scribe> a, plane old SIP proxy for all practical purposes and use it
[04:25:10] <scribe> for SIP requests. Undecided. So we have a couple
[04:25:13] <scribe> slides that work through examples. I don't think they're visible
[04:25:16] <scribe> from the back of the room. Anyhow, so in a very simple
[04:25:21] <scribe> model here, we have basically a 7 node or 8 node overlay.
[04:25:24] <scribe> Alice on the left, basically registers with the
[04:25:33] <scribe> overlay, she puts her contact into it. And okay. So
[04:25:38] <scribe> Alice puts her contact into the overlay. Having put her contact in the
[04:25:42] <scribe> overlay, Bob decides to talk to Alice. He gets where he's,
[04:25:46] <scribe> where Alice contact out. And sends a request to Alice. This
[04:25:50] <scribe> is a very simple sort of model. I think what Henry has been talking
[04:25:54] <scribe> about, with using the overlay as a network service to just
[04:25:57] <scribe> store and put things, and you could use basically anything that
[04:26:02] <scribe> gives you distributed dwb to do database to do this. It
[04:26:05] <scribe> doesn't answer things like how you get through fire walls with
[04:26:09] <scribe> Bob and Alice, so that's one problem we might have to deal
[04:26:10] <scribe> with.
[04:26:14] <scribe> The other possibility is that it routes the request on behalf of Bob
[04:26:17] <scribe> to get to Alice. Alice having registered, Bob having
[04:26:20] <scribe> decided to talk to her. Bob doesn't have to get anything from
[04:26:24] <scribe> the over wlai to talk to Alice. He just sends a
[04:26:27] <scribe> request for Alice into the overlay, and routed peer to peer,
[04:26:31] <scribe> whatever the model of routing within the peer structure is.
[04:26:35] <scribe> And the invite, or other SIP request is eventually delivered
[04:26:36] <scribe> to Alice.
[04:26:43] <scribe> This lets us re use, relatively persistent connections
[04:26:46] <scribe> between Bob and whatever peer he's working with, and between
[04:26:49] <scribe> Alice and whatever peer she's working with, to route the
[04:26:52] <scribe> requests to fire walls and things of that sort, assuming that we
[04:26:55] <scribe> don't have fire wall layers here, which we also could.
[04:26:59] <scribe> The other possibility that seems fairly obvious is
[04:27:03] <scribe> that the overlay simply stores the address of the SIP proxy
[04:27:06] <scribe> that Alice works with. So Alice, essentially registers,
[04:27:11] <scribe> puts her contact into this peer. Bob queries the overlay, to
[04:27:17] <scribe> get the information about Alice's proxy, which peer 7 is Alice's
[04:27:21] <scribe> proxy. Once he's gotten the proxy. He sends a
[04:27:26] <scribe> SIP request to the proxy, using plane old SIP. And that
[04:27:31] <scribe> acts like a plain old SIP proxy and forwards it onto Alice. This
[04:27:35] <scribe> again lets us use the SIP outbound type model between these
[04:27:37] <scribe> nodes to keep things alive.
[04:27:40] <scribe> Okay. NEW SPEAKER: Dean just Cullen Jennings.
[04:27:44] <scribe> Just a clarifying question about that. Are you imagining
[04:27:48] <scribe> that the proxy would always be the same as the peer, that had
[04:27:52] <scribe> stored the information? Or it was just, it was
[04:27:55] <scribe> actually just a different thing on the diagram. NEW SPEAKER:
[04:27:59] <scribe> It's the second case. The peer doesn't necessarily have to
[04:28:02] <scribe> be the same as the proxy. It could be for convenience purposes. (Several people talking.) NEW SPEAKER:
[04:28:06] <scribe> Conceptually could be. Jonathan? NEW SPEAKER: There's
[04:28:10] <scribe> another model which is, the way I thought it worked in
[04:28:13] <scribe> conversations with folks last night, said it wasn't the case, which
[04:28:19] <scribe> is that you know, what is stored is the peer identity of
[04:28:21] <scribe> Alice, as a peer in the protocol. And one of the
[04:28:25] <scribe> functions that the peer protocol needs to support is the
[04:28:32] <scribe> ability for you to establish TCP or U D P link through nat to
[04:28:35] <scribe> whatever peer the D H T requires you to connect to. So the peer protocol
[04:28:38] <scribe> in some sense provides another important service, which I'm
[04:28:45] <scribe> starting to think maybe val ubl piece of work, Philip nat
[04:28:49] <scribe> work of draft. Incredibly genius, I must say. Except
[04:28:53] <scribe> for the fact that it uses SIP. But besides that, the
[04:28:56] <scribe> general flow is great. It basically allows you to crate TCP connection
[04:29:01] <scribe> anyway. So then you would use the peer service to create a direct
[04:29:04] <scribe> TCP connection. I don't think that's one of the modes you
[04:29:06] <scribe> have. NEW SPEAKER: Good point. I had thought about
[04:29:10] <scribe> something like that, where the peer system provides you a SIP
[04:29:13] <scribe> second connection to the other end point which is pretty much
[04:29:15] <scribe> what you're talking about. NEW SPEAKER: Right. So
[04:29:19] <scribe> exactly. Yes, and once the TCP connection is connected,
[04:29:23] <scribe> then you could do a few things with it, which includes doing a
[04:29:26] <scribe> join, a peer join, but you could also send an invite. We
[04:29:30] <scribe> can debate that, I like that model and I want to make sure it's
[04:29:33] <scribe> covered. NEW SPEAKER: So note for the note taker,
[04:29:38] <scribe> make sure that the model that Jonathan just discussed here TCP
[04:29:41] <scribe> tunnelling model gets added into the concept
[04:29:46] <scribe> stream. NEW SPEAKER: Philip Mathews here. I thought
[04:29:49] <scribe> Jonathan's model was orthagonal, in the sense that we could
[04:29:56] <scribe> do what Jonathan had suggested in the calls. Okay.
[04:30:02] <scribe> In this one, for example, okay. Well, do you want -- anyway, I
[04:30:07] <scribe> do think it's orthagonal to it. And if you want to do that
[04:30:11] <scribe> off line, I'll talk to you about it. NEW SPEAKER: What I think
[04:30:14] <scribe> Jonathan has is actually a different take on this question here, how
[04:30:19] <scribe> does the overlay pass messages? And what Jonathan just
[04:30:20] <scribe> suggested, the overlay doesn't pass
[04:30:24] <scribe> messages. What it does it forms a tunnel between the end
[04:30:27] <scribe> points and they pass their messages over that
[04:30:31] <scribe> tunnel, whatever those messages happen to be. That's kind
[04:30:31] <scribe> of cool.
[04:30:42] <scribe> Okay. Nat traverse Sal. Somebody called? NEW SPEAKER:
[04:30:48] <scribe> Yes. NEW SPEAKER: vee Jay. NEW SPEAKER:
[04:30:52] <scribe> That's a SIP section? NEW SPEAKER: That would be one
[04:30:59] <scribe> way to do it. NEW SPEAKER: So, how the model gets added NEW SPEAKER:
[04:31:05] <scribe> Yes. Some kind of tunnel gets added as a message passing
[04:31:11] <scribe> mechanism. Okay. So, nat traverse Sal. So we've
[04:31:16] <scribe> described two methods or sort of models for nat traverse Sal and transport
[04:31:21] <scribe> service, where we have the, sort of the original super peer and
[04:31:27] <scribe> ordinary peer kind of model where the super peer is publicly address able and the
[04:31:32] <scribe> ordinary peer is the thing behind the nat. Another
[04:31:35] <scribe> model which Phil calls the fully distributed and I call the
[04:31:40] <scribe> partial mesh of inter connections with inter routing, allows for
[04:31:42] <scribe> no distinction between peers, and some of them might
[04:31:47] <scribe> be behind nats and if they're behind a nat, they're reached
[04:31:54] <scribe> hop by hop around the overlay, through relatively persist tent connection. I
[04:31:57] <scribe> think there's another discussion today on the transport model
[04:31:59] <scribe> and I think they'll go into that more.
[04:32:03] <scribe> Now, one of the things that we assume, is that resources, especially the users and
[04:32:06] <scribe> services, the two classes of resources we've already
[04:32:09] <scribe> identified, have credentials, that those are used in
[04:32:13] <scribe> authentication and authorization decisions. Sort of the
[04:32:16] <scribe> working assumption that those credentials are something like a certificate. So
[04:32:20] <scribe> when you enroll into the overlay, you get a certificate, and you
[04:32:24] <scribe> re use that. Now, there's no real hard reason that has to be
[04:32:26] <scribe> a certificate, that's just sort of the model we're thinking
[04:32:30] <scribe> about. You could use identity based encryption where you git
[04:32:33] <scribe> a private key to go with your public identity and that's all you
[04:32:34] <scribe> have.
[04:32:38] <scribe> Now, Phil can possibly express this term better
[04:32:44] <scribe> than I have. Pierce hold and show credentials for the user and
[04:32:48] <scribe> services identifying. Once the users services
[04:32:52] <scribe> are attached to the peer, they can help them identify. Is it
[04:32:55] <scribe> a can discrete class from user and service credentials in the overlay?
[04:33:01] <scribe> Which also relates to our peer names or is there such a thing
[04:33:05] <scribe> as peer name? That's an open question. And the other question is
[04:33:09] <scribe> how the service credentials work. And that comes back to how
[04:33:13] <scribe> do service names work, sort of U RN service class or something else?
[04:33:20] <scribe> Also, if we get to it, discuss client models later on here,
[04:33:23] <scribe> but there's basically three models, the clients
[04:33:26] <scribe> attach sort of a fixed basis to the peers and do all the
[04:33:29] <scribe> work for it just like out bound proxy would.
[04:33:36] <scribe> Clients that attach to a peer, and act as storage, and
[04:33:40] <scribe> probably not particularly useful idea but interesting.
[04:33:45] <scribe> And ways in which the clients
[04:33:47] <scribe> interact with with database but are not part of the database. They
[04:33:51] <scribe> don't store things on behalf of it. And if we get to a lot
[04:33:52] <scribe> more discussion, okay.
[04:33:58] <scribe> So, things we know that are open questions, and don't can have any
[04:34:02] <scribe> sort of way to describe or discuss very well, are things like
[04:34:05] <scribe> selecting between multiple peers that offer the same
[04:34:08] <scribe> service. If there's two things offerring Gateway service,
[04:34:11] <scribe> how do I pick one of them? That raises questions
[04:34:14] <scribe> of network path efficiency and things we don't have a handle on
[04:34:18] <scribe> yet. There's also questions like the disability of messages to
[04:34:21] <scribe> intermediate peers. As Jonathan was talking about,
[04:34:24] <scribe> having a tunnel form between two nodes, sort of cross the
[04:34:28] <scribe> overlay, do you have questions like can the peers that are sitting out there in the
[04:34:32] <scribe> overlay through which this ton dmel goes, see everything that
[04:34:36] <scribe> goes through them or is it encrypted. No fixed answers on that yet.
[04:34:39] <scribe> NEW SPEAKER: Let me, this is really important. I was just
[04:34:42] <scribe> whispering this to Philip and I'd like to highlight this in the
[04:34:45] <scribe> concepts draft. Because to me, think of it this way, it
[04:34:50] <scribe> makes it a no brain err choice actually. So we've been talking about regular SIP,
[04:34:56] <scribe> how you send your invite to the proxies. And people get all bent out of shape, well, I don't know
[04:35:02] <scribe> if I can trust the proxies with the proxies misbehave and some people think that
[04:35:13] <scribe> proxies run by big service route terse usually can be trusted. But sometimes we worry about it. In any other model, dhi of it as a SIP network where every proxy is not just in the service
[04:35:17] <scribe> router. It's by definition completely untrusted and there's a
[04:35:20] <scribe> very large number of them. Can we make SIP work in the way
[04:35:24] <scribe> we understand it today, through a sequence of proxies, every
[04:35:27] <scribe> single one of which is unknown and completely untrusted. I don't think we can.
[04:35:32] <scribe> I think you have really little choice but the direct TCP connection
[04:35:32] <scribe> for SIP.
[04:35:37] <scribe> And so, you know, if we don't want to make the decision right off the
[04:35:42] <scribe> bat. I'd at least like to capture something in the concepts
[04:35:45] <scribe> draft that I will sdraits in SIP, this is really what we're talking
[04:35:46] <scribe> about.
[04:35:47] <scribe> ( Illustrates what we're talking about.)
[04:35:51] <scribe> NEW SPEAKER: Okay. And there's also a question of hyper
[04:35:55] <scribe> domains where some parts are conventional SIP and some parts
[04:35:58] <scribe> are peer to peer. It sounds like it could be an interesting
[04:36:03] <scribe> thing but we don't have a lot of discussion on that in the current
[04:36:05] <scribe> concepts draft. NEW SPEAKER: Cullen Jennings. Let's
[04:36:08] <scribe> be careful how we use that. No one ever proposed that we
[04:36:12] <scribe> have a single domain, in the sense that we mean domain
[04:36:16] <scribe> typically in SIP. We're talking about a conventional
[04:36:20] <scribe> domain, working with a hybrid domain in the domain name portion
[04:36:23] <scribe> of it. It might be in the same administrative domain.
[04:36:27] <scribe> What I'm saying, the way that's written right there, it
[04:36:31] <scribe> fuzzes a lot of stuff together in once. Yes, right. NEW SPEAKER:
[04:36:34] <scribe> Okay. Spencer?
[04:36:38] <scribe> NEW SPEAKER: Spencer. So, I think that part of this question was whether you
[04:36:42] <scribe> had the same A O R for both domains, was it not? NEW SPEAKER:
[04:36:50] <scribe> Right. Which you could have the same A O R in both and move back and
[04:36:51] <scribe> forth and have it still work.
[04:36:56] <scribe> So, question is, where is this work going? We have
[04:36:59] <scribe> basically two alternatives. One is to sort of close down the
[04:37:04] <scribe> concepts and terminology draft, publish it, as an informational
[04:37:09] <scribe> RFC, so they establish a base line vocabulary going forward and
[04:37:14] <scribe> basically claiming to be done with it. Or possibly we keep it alive as
[04:37:18] <scribe> a working document and rev it occasionally as the concepts and
[04:37:19] <scribe> terminology change.
[04:37:23] <scribe> The other possibility is it could be become the framework draft
[04:37:26] <scribe> that's called for in our charter. That's an open question to
[04:37:29] <scribe> the working group. NEW SPEAKER: Do you want to go with that question? NEW SPEAKER:
[04:37:36] <scribe> Could we have some discussion about whether or not, what we
[04:37:40] <scribe> want to do with this document?
[04:37:44] <scribe> NEW SPEAKER: Or we could just set it on fire and do something else. NEW SPEAKER:
[04:37:47] <scribe> I propose to adopt this document as the deliverable for the
[04:37:52] <scribe> framework draft. NEW SPEAKER: Okay.
[04:37:55] <scribe> NEW SPEAKER: I am happy with this document between the
[04:37:59] <scribe> framework document. The only request, I guess I would
[04:38:02] <scribe> make, is that from now on, the revision process needs to be
[04:38:06] <scribe> much more formal and we actually may have multiple drafts
[04:38:09] <scribe> submitted and proposed modifications,
[04:38:11] <scribe> whereas to this point, it's been a smaller group doing it.
[04:38:14] <scribe> I just think the process is dash NEW SPEAKER: Yes. NEW SPEAKER:
[04:38:15] <scribe> Moving forward (Several people talking.) NEW SPEAKER:
[04:38:19] <scribe> If iingts a working group document the it follows the process. NEW SPEAKER:
[04:38:22] <scribe> It's certainly very useful to have this in the right propose
[04:38:25] <scribe> atsz always with the common terminology. It's been great to
[04:38:28] <scribe> this point already. NEW SPEAKER: Okay. NEW SPEAKER:
[04:38:34] <scribe> I don't think there's any point to publishing the dwok ment now. Even
[04:38:39] <scribe> if it's only a terminology document. You have to contain in the
[04:38:43] <scribe> terminology document something about the other. I suspect that means just
[04:38:48] <scribe> making combined terminology and framework, certainly for
[04:38:50] <scribe> publishing terminology. NEW SPEAKER: Okay. NEW SPEAKER:
[04:38:54] <scribe> Philip? NEW SPEAKER: Yes, I just have sort of a
[04:38:58] <scribe> carry onto that question. Back in a conference call we had,
[04:39:02] <scribe> back in the fall, somebody I think it was actually Scott brin
[04:39:07] <scribe> suggested that we keep this document alive as a draft, and
[04:39:10] <scribe> continue to rev it as the work went on in the two protocol
[04:39:13] <scribe> documents, keeping it up to date. So, basically, not
[04:39:18] <scribe> publishing it as the charter now says, in July, but keeping
[04:39:22] <scribe> it alive for a longer time. So I guess this is what I'm
[04:39:25] <scribe> interested in. Do we want to try to publish it more or less
[04:39:29] <scribe> as it is now, or do we want to keep it a live and therefore
[04:39:34] <scribe> not meet our charter can date? NEW SPEAKER: Henning.
[04:39:41] <scribe> Much more in favor of keeping it a live. I mean, people that read it
[04:39:47] <scribe> can read it. Having seed for framework requirements
[04:39:50] <scribe> documents always strikes me as a rule unnecessary, because
[04:39:54] <scribe> there's not this huge outside community of implementers that wouldn't
[04:39:58] <scribe> see it if it's an internet draft. It's really a working
[04:40:01] <scribe> document for the benefit of the group more than anybody else.
[04:40:05] <scribe> So having to, after we kind of figure out what we really want
[04:40:09] <scribe> to do, to web document and update RFC seems kind of silly. So
[04:40:13] <scribe> I would suggest not doing what the charter -- if it's almost
[04:40:17] <scribe> done, it's almost done. Ship it out as soon as we think the
[04:40:22] <scribe> rest is baked enough, we don't have to wait until we actually
[04:40:27] <scribe> go to the RFC editor. But as long as the other stuff is
[04:40:30] <scribe> baked you have enough to know where it's running. NEW SPEAKER:
[04:40:33] <scribe> He wanted me to be able to reserve his spot while he was
[04:40:38] <scribe> taking notes. NEW SPEAKER:
[04:40:40] <scribe> (Several people talking.) NEW SPEAKER: Hold on. Let
[04:40:43] <scribe> Spencer go. NEW SPEAKER: I told him I'd watch his
[04:40:46] <scribe> spot. NEW SPEAKER: That way I can run back and type what you say.
[04:40:51] <scribe> This is Spencer again. So I guess the question important the
[04:40:53] --- marcel has left
[04:41:00] <scribe> group is, are we ready to to be doing the changes, with working
[04:41:04] <scribe> group consensus, which is what we should be doing with
[04:41:06] <scribe> working group drafts? Or, I mean, is it time to do dha?
[04:41:10] <scribe> I think that's really the question we need to answer. NEW SPEAKER:
[04:41:15] <scribe> Henry. NEW SPEAKER: For the sake of flexibility, I
[04:41:18] <scribe> would argue just like Phil, we should keep it for a while, at
[04:41:24] <scribe> least as a draft, for example, Henning has use today
[04:41:29] <scribe> admitting now that a Gateway know, and as we write the
[04:41:33] <scribe> requirement, be more enlightened so this document becomes much
[04:41:40] <scribe> better. So, keep it for a while as a draft. NEW SPEAKER:
[04:41:47] <scribe> Cullen. NEW SPEAKER: So Cullen here. I think that, you know,
[04:41:51] <scribe> clearly as people said, right now, this is a document
[04:41:55] <scribe> that, that documents all the possible solutions we might try to do to try
[04:41:58] <scribe> and discuss them. And it's going to migrate down into the
[04:42:01] <scribe> solution we chose and evolve that way. So I'm very much in favor
[04:42:05] <scribe> of that. The thing I'd like to balance this off against a little bit,
[04:42:09] <scribe> is no late surprises. If it is possible for us to find some
[04:42:13] <scribe> way that once we have a fairly good idea of what roughly the
[04:42:16] <scribe> architecture we're going to use here is going to look like,
[04:42:23] <scribe> that we could get that out, and get it jen arc to see it. I S
[04:42:27] <scribe> G to see it and get some approval so people have seen and agree
[04:42:29] <scribe> with that architecture before we get to all of our
[04:42:33] <scribe> protocols are finished and everything is locked and loaded in and
[04:42:37] <scribe> here's the same architecture at the same time. It's hard to balance
[04:42:41] <scribe> and it's not a decision we're going to make now. Clearly the document
[04:42:44] <scribe> needs a lot of work before we get there. We have a lot to think
[04:42:46] <scribe> about. NEW SPEAKER: Keith. NEW SPEAKER: Keith, I
[04:42:52] <scribe> just want to say this document is about itself, charter item.
[04:42:57] <scribe> Framework, and I think it now is an appropriate time for this
[04:42:59] <scribe> document to move onto working group. NEW SPEAKER: Right.
[04:43:03] <scribe> So, the hum that we're going to carry is, should this
[04:43:08] <scribe> document be adopted as a working group item. To be carried
[04:43:12] <scribe> forward, and it seems to be unanimity of opinions. So for
[04:43:16] <scribe> the purposes of this this hum. We're just asking, should
[04:43:20] <scribe> this document be accepted as a working group gok ment and we know
[04:43:24] <scribe> it's going to evolve. Could I have a hum for those in favor.
[04:43:28] <scribe> ( Humming. ) NEW SPEAKER: Those opposed?
[04:43:31] <scribe> ( Silent. ) NEW SPEAKER: Okay. It's adopted as a working
[04:43:35] <scribe> group item and we have no immediate plans to publish an RFC. We'll
[04:43:38] <scribe> keep working on it. NEW SPEAKER: One more presses. NEW SPEAKER:
[04:43:41] <scribe> Quick. We're over. NEW SPEAKER: I I'd like to
[04:43:45] <scribe> suggest that we have a formal owner of the editor token. It
[04:43:50] <scribe> seems like it's a little bit of a passing buck. Dualing
[04:43:51] <scribe> editors. (Several people talking.) NEW SPEAKER: Are
[04:43:55] <scribe> you volunteering. NEW SPEAKER: We'll a point an editor. NEW SPEAKER: The
[04:44:01] <scribe> chairs will make sure there is an editor. An editor. NEW SPEAKER:
[04:44:32] <scribe> Okay. We wanted to talk briefly, and I'm going to try to be more brief,
[04:44:37] <scribe> because we're 5 minutes over already, about D H T selection and I want
[04:44:41] <scribe> to keep the slides extremely short so we can discuss this.
[04:44:45] <scribe> There's really sort of three major questions here. That we're
[04:44:49] <scribe> looking at about D H T selection. The first question is do we have
[04:44:52] <scribe> to choose one? In other words, are we going to be forced as
[04:44:56] <scribe> a group to select one particular D H T and stick with that
[04:45:00] <scribe> forever or can we have multiple choices can we come up with
[04:45:06] <scribe> some way to do that? If we do a modular
[04:45:09] <scribe> requirement, with protocol developed needs to be able to
[04:45:13] <scribe> implement multiple D H Ts, do we require one particular
[04:45:17] <scribe> must implement, so that we can guarantee there's sort of a base level of inter
[04:45:21] <scribe> operability between these things. If we have a modular
[04:45:25] <scribe> design and we don't force one, do we really get inter operability?
[04:45:30] <scribe> And finally, if we do, assuming we do select one must implement
[04:45:33] <scribe> D H T, how do we select that D H T?
[04:45:38] <scribe> Yes, John NEW SPEAKER: Jonathan. There's one question
[04:45:42] <scribe> I thought should be here, which is must you use a single D H
[04:45:45] <scribe> T for a particular D H T ring? NEW SPEAKER: Okay. That's a
[04:45:49] <scribe> different question. (Several people talking.) NEW SPEAKER:
[04:45:55] <scribe> Propose anything where you could do more than one. NEW SPEAKER: I think it's more the inverse, which is the question
[04:46:03] <scribe> is, could the protocol support multiple choices, and you end up picking one for different rings. Maybe these things dash NEW SPEAKER: I think that's part. I may not
[04:46:08] <scribe> have quite gotten it in the slides; but basically, yes,
[04:46:11] <scribe> that's what I'm asking here, if you're asking the question of can
[04:46:14] <scribe> you have more than one within a running instance of a ring, I'm not
[04:46:19] <scribe> sure anyone has advocate ted that or even believes it's possible.
[04:46:21] <scribe> What I'm talking about here is within a ring, can you select
[04:46:25] <scribe> a D H T algorithm to use? That everybody this that ring
[04:46:28] <scribe> uses. But you have more than one choice for that ring. NEW SPEAKER:
[04:46:31] <scribe> At least for the first guy. NEW SPEAKER: Yes. The
[04:46:34] <scribe> first guy gets to choose it. Everybody else gets stuck with it from
[04:46:38] <scribe> there on, but the protocol supports N. NEW SPEAKER:
[04:46:41] <scribe> Just to make it more clear, at least the models that we've
[04:46:46] <scribe> been proposing is, pursuing, is that it's quite possible for
[04:46:50] <scribe> a single software instance box, whatever, to run multiple
[04:46:55] <scribe> rings or other topologies, simultaneously, and NEW SPEAKER:
[04:46:57] <scribe> Right. NEW SPEAKER: And they, when they don't see
[04:47:01] <scribe> each other, they're like ships in the night, and you can,
[04:47:05] <scribe> whoever gets to recreate a new instance of this thing,
[04:47:09] <scribe> gets to choose which one it is and all kinds of other choices
[04:47:12] <scribe> which go along with that. That's I think roughly a model,
[04:47:17] <scribe> but that only works if you basically, if you have at least
[04:47:21] <scribe> one, it only works in general if you have, if you have one.
[04:47:26] <scribe> It's not strictly, or necessarily you can argue that as long as everybody
[04:47:29] <scribe> in that community agrees, and you find a service
[04:47:33] <scribe> provider and the klipts can pick multiple once. The
[04:47:39] <scribe> servers don't have to necessarily speak, saying I'm the pipe
[04:47:46] <scribe> provider. And I happen to be offering my new fancy D H T, and
[04:47:51] <scribe> only as long as I can convince a client vendor to do that, where
[04:47:54] <scribe> the clients support that as one of the defaults, things will work
[04:47:58] <scribe> fine. I just can't inter operate with anybody who is not
[04:48:00] <scribe> operating my super-duper D H T. NEW SPEAKER: Right. NEW SPEAKER:
[04:48:04] <scribe> And I think that goes to the second and third questions of, we
[04:48:08] <scribe> all know people want to make their super-duper ones, do we
[04:48:12] <scribe> pick one that every client must implement to insure we have a a
[04:48:15] <scribe> base one. Even though you can choose the super-duper ones. NEW SPEAKER:
[04:48:18] <scribe> Expense err is next in line. NEW SPEAKER: Henry is
[04:48:22] <scribe> timing he's always right after Spencer. NEW SPEAKER:
[04:48:23] <scribe> But we appreciate your note taking. NEW SPEAKER: Thank you.
[04:48:29] <scribe> Spencer. I believe that we have to choose one. It's not
[04:48:32] <scribe> that we have consensus on the use cases, but we have a number
[04:48:38] <scribe> of use cases in the use case draft that seem to imply a very
[04:48:40] <scribe> loose relationship between clients that come
[04:48:44] <scribe> together. I don't see how you can have clients
[04:48:47] <scribe> Rome into an overlay you've never seen before, and
[04:48:50] --- hbaosiy has joined
[04:48:52] <scribe> have inter operability without choosing a must implement. NEW SPEAKER:
[04:48:55] <scribe> Henry. NEW SPEAKER: Yes, you cannot have refer one
[04:49:00] <scribe> if you have sort of ships in the night, because outside of this
[04:49:06] <scribe> charter, you still have to do some real things, like range
[04:49:10] <scribe> queries for databases or multi cast. For
[04:49:13] <scribe> this reason, limiting, especially if we call it
[04:49:17] <scribe> framework, the previous document, it's already too narrowing.
[04:49:22] <scribe> So, for the previous document, con is September is a draft.
[04:49:26] <scribe> That was a good decision. But also, that flexibility not to
[04:49:30] <scribe> have default one, because again, for a complete service, you have to
[04:49:39] <scribe> have other functions besides the SIP discovery and run the
[04:49:42] <scribe> function.
[04:49:50] <scribe> NEW SPEAKER: Henning. The issue, philosophically, on
[04:49:55] <scribe> the, we should pick one side, practically speaking I want
[04:49:59] <scribe> to just say, this is a little different from a normal IETF inclination for security
[04:50:03] <scribe> protocols, where we always basically vote for the must have one,
[04:50:06] <scribe> so that we can talk. Because here, there's at least more
[04:50:09] <scribe> plausible, particularly if we have a separation between the client
[04:50:15] <scribe> protocol and the peer protocol. Lots of people have posed
[04:50:19] <scribe> that the peer nodes are only semi public or even private, in the
[04:50:22] <scribe> sense that they're all operated by one vendor and you don't get
[04:50:26] <scribe> to play peer at all, and all of these things. In those
[04:50:29] <scribe> instances, it really doesn't matter since it's not visible to
[04:50:30] <scribe> the rest of the world what you want.
[04:50:36] <scribe> So, if we can easily agree on one, on one must implement,
[04:50:39] <scribe> that's fine. I don't see a big problem. Certainly doesn't
[04:50:44] <scribe> hurt anybody. I just see from a practical reality, if you
[04:50:46] <scribe> get somebody who wants to build something
[04:50:50] <scribe> different, they will do that whatever we say or not. Because
[04:50:54] <scribe> it's not meant to be publicly join able, except through a non
[04:50:59] <scribe> D H T specific peer protocol. I hope we can agree on NEW SPEAKER:
[04:51:01] <scribe> Sure. NEW SPEAKER: As non peer specific. NEW SPEAKER:
[04:51:05] <scribe> That's true of almost anything we say. Of must implement. NEW SPEAKER:
[04:51:07] <scribe> Yes. NEW SPEAKER: That's not a reason not to choose
[04:51:09] <scribe> it. NEW SPEAKER: It's a reason not to be surprised
[04:51:12] <scribe> when it doesn't work. NEW SPEAKER: Henning, I'm not
[04:51:15] <scribe> sure what you just said was consistent with the charter. I think
[04:51:19] <scribe> what you basically said, you don't need to standardize the peer
[04:51:23] <scribe> protocol. People can can do peer protocol themselves. I
[04:51:25] <scribe> think you have to take the conversation, based on the
[04:51:28] <scribe> assumption, what do we do on peer protocol
[04:51:32] <scribe> whether we do it at all. NEW SPEAKER: I think if we
[04:51:35] <scribe> build peer protocol, I hope we do it so more than one vendor
[04:51:37] <scribe> can inter operate. I would like to see that.
[04:51:43] <scribe> NEW SPEAKER: Philip Mathews. So, the first question, I
[04:51:46] <scribe> think I personally, I would like to be able to make multiple
[04:51:51] <scribe> choices. I guess before though making affirm decision, I'd
[04:51:55] <scribe> like to see an example at least of how making multiple choices would
[04:51:57] <scribe> work. We haven't seen that there. NEW SPEAKER:
[04:52:02] <scribe> Actually, I'd argue that we have two that do it.
[04:52:06] <scribe> both Henning's proposal and the other one show how to
[04:52:08] <scribe> implement at least two. NEW SPEAKER: Backing up to one,
[04:52:13] <scribe> what I thought that would mean, so if I, maybe this is
[04:52:17] <scribe> misunderstanding on my part. My thought is, the joining node, you
[04:52:20] <scribe> know, when it tried to join the overlay, there would be
[04:52:25] <scribe> some sort of communication and he would say, I'm willing to operate
[04:52:25] --- hbaosiy has left
[04:52:28] <scribe> rate one of these 3-D H Ts and the admitting node would
[04:52:31] <scribe> say, here are the three we support or here's the one that the overlay is
[04:52:33] <scribe> running. NEW SPEAKER: Yes. NEW SPEAKER: The
[04:52:37] <scribe> if there's a match, it would come in, if not, it
[04:52:40] <scribe> wouldn't. And the only thing that I can, concerns
[04:52:43] <scribe> myself a little bit with that, you know, you can have these
[04:52:45] <scribe> situations where
[04:52:50] <scribe> overlays split up, because there are temporary communication
[04:52:55] --- hbaosiy has joined
[04:52:55] <scribe> problems, and if they then start making different decisions
[04:53:00] <scribe> and try to join again, maybe there's a problem. NEW SPEAKER:
[04:53:04] <scribe> That won't happen unless the overlay shrinks to zero. NEW SPEAKER:
[04:53:05] --- rjaksa has joined
[04:53:08] <scribe> If you make isolated nodes, it can think it's the overlay for
[04:53:12] <scribe> a bit. Okay. Because it can't talk to anybody else, or a small
[04:53:18] <scribe> group of nodes think that they're the overlay because they can't
[04:53:21] <scribe> actually talk to the other overlay for a while. NEW SPEAKER: I
[04:53:25] <scribe> think that's assumable. NEW SPEAKER: So this is, this is what I'm
[04:53:29] <scribe> misunderstanding, is the question, my, this is what, you
[04:53:31] <scribe> know, maybe I misunderstand the draft. NEW SPEAKER: Can
[04:53:34] <scribe> you cut the Mike off after Henning. NEW SPEAKER: Yes. NEW SPEAKER:
[04:53:37] <scribe> We're running short on time. NEW SPEAKER: Cut the line
[04:53:39] <scribe> off. NEW SPEAKER: We can talk about this off line. NEW SPEAKER:
[04:53:45] <scribe> Okay. NEW SPEAKER: Yes. If we do multiple choices,
[04:53:49] <scribe> yes, I can think we do, my personal opinion is we need to select
[04:53:53] <scribe> one as a must implement. NEW SPEAKER: Keith. NEW SPEAKER:
[04:53:57] <scribe> We're obviously selecting an entity for running SIP.
[04:54:04] <scribe> Obviously, that presumes you also want to use D H Ts. Is
[04:54:07] <scribe> there any something that supports multiple applications?
[04:54:09] <scribe> NEW SPEAKER: That would be out of charter. NEW SPEAKER:
[04:54:13] <scribe> I think we (Several people talking.) NEW SPEAKER: Decision
[04:54:16] <scribe> to make, basically what I'm trying to get to. NEW SPEAKER:
[04:54:20] <scribe> My attitude has always been no, we should be building it for SIP.
[04:54:25] <scribe> But I think I'm kind of in the minority after having a conversation with
[04:54:27] <scribe> Jonathan. I think Jonathan thinks we should be thinking
[04:54:30] <scribe> about building it for almost everything this the background. NEW SPEAKER:
[04:54:34] <scribe> Don't misquote me. NEW SPEAKER: Then I misunderstood you. NEW SPEAKER:
[04:54:40] <scribe> Stop. NEW SPEAKER: So, there is no perfect dash NEW SPEAKER:
[04:54:47] <scribe> Who is speaking NEW SPEAKER: So, if there is no D H T.
[04:54:52] <scribe> So everything depends can on the something scenario. So we
[04:54:57] <scribe> should standardize peer protocol and keep a choice of D H T.
[04:55:03] <scribe> And so to not just one. So this is my opinion.
[04:55:07] <scribe> NEW SPEAKER: I just wanted to go back to what you said, is I
[04:55:11] <scribe> think we have to be somewhat careful on, we must implement
[04:55:15] <scribe> and showing insure sureing inter operability.
[04:55:21] <scribe> Unlike the security perspective, as long as everybody in TLS does some crypt
[04:55:25] <scribe> tow, we're going to connect. Even if we do choose one D H
[04:55:30] <scribe> T, we all agree I believe that a single wing of nodes can
[04:55:36] <scribe> only implement one D H T at any given time. That means take the
[04:55:40] <scribe> scenario that the ring I am implements D H T
[04:55:46] <scribe> A, and let's say, the nodes are D H T implements A, which is the
[04:55:51] <scribe> default and B and C. And the client implements A and D and E.
[04:55:56] <scribe> And the operator of the nodes, wait. The one who
[04:56:00] <scribe> established that ring, decides that it liked B better, so it's
[04:56:05] <scribe> only going to run the IETF domain in B mode in that case. None of
[04:56:09] <scribe> the clients, even though they all speak A, can
[04:56:13] <scribe> join this particular ring, unless, and this is a vague different
[04:56:17] <scribe> thing, namely that you have to simultaneously run the same
[04:56:21] <scribe> data from two D H Ts in the sense that each time you insert
[04:56:26] <scribe> the key into D H T B or D, also you also implement it in
[04:56:31] <scribe> A so you can find the same data in multiple D H Ts. That's
[04:56:35] <scribe> the only way the God's of manage dash NEW SPEAKER: Line is cut
[04:56:38] <scribe> off. NEW SPEAKER: True inter operability. Does that
[04:56:39] <scribe> make sense? (Several people talking.) NEW SPEAKER:
[04:56:44] <scribe> So we should be careful as to what we truly get by that.
[04:56:50] <scribe> It's not the equivalent of TLS or H D P or SIP type. As long
[04:56:53] <scribe> as we have something mandatory to implement, random things can
[04:56:56] <scribe> actually talk to each other, in reality, simply because once
[04:57:01] <scribe> a D H T makes a choice, NEW SPEAKER: It only means that
[04:57:03] <scribe> you do have a particular one you can choose that everybody
[04:57:07] <scribe> should do. It doesn't mean that at a given, if you join a given
[04:57:10] <scribe> overlay you're guaranteed to be able to work. NEW SPEAKER:
[04:57:12] <scribe> Yes. As long as we're NEW SPEAKER: Yes. NEW SPEAKER:
[04:57:15] <scribe> As long as we NEW SPEAKER: Right. NEW SPEAKER:
[04:57:17] <scribe> Yes. NEW SPEAKER: That should
[04:57:20] <scribe> be made more clear, even in the concepts draft that that's the
[04:57:22] <scribe> case. NEW SPEAKER: Do you want to run hums on
[04:57:25] <scribe> this or are we ready for that? NEW SPEAKER: The
[04:57:28] <scribe> only, I think the only thing we can possibly be able to run a hum
[04:57:31] <scribe> on, is that people, the only thing I think we have
[04:57:36] <scribe> consensus on is we probably don't have people wants to choose
[04:57:41] <scribe> only one D H T. That might be a useful hum, to see if there's
[04:57:44] <scribe> anybody that we pick one and everybody only implements that. I don't
[04:57:48] <scribe> think we have enough consensus to call a hum on anything else. NEW SPEAKER:
[04:57:54] <scribe> I think we agree. NEW SPEAKER: I would suggest a hum that says
[04:57:57] <scribe> basically, we have one must implement, that we'll have at
[04:58:03] <scribe> any given time, only one, in any particular ring, and
[04:58:06] <scribe> that we'll we'll allow several others, if the protocol makes
[04:58:08] <scribe> it feasible. NEW SPEAKER: Several, but NEW SPEAKER:
[04:58:13] <scribe> That's basically this one. You're basically calling for,
[04:58:18] <scribe> you want to have multiple choices what one must implement. NEW SPEAKER:
[04:58:20] <scribe> Yes. Exactly. I've heard no other
[04:58:23] <scribe> comments. NEW SPEAKER: Sorry.
[04:58:25] <scribe> (Several people talking.) NEW SPEAKER: So, let's run
[04:58:31] <scribe> a hum on what Henning suggested, which is that the working group
[04:58:36] <scribe> agrees that the protocol is designed, the work of P to P SIP
[04:58:40] <scribe> is designed to support multiple D H Ts and there will be one
[04:58:43] <scribe> must implement. That's the question. So I'm calling
[04:58:44] <scribe> comments on the question.
[04:58:49] <scribe> NEW SPEAKER: It would help a lot, I'm confused, because
[04:58:54] <scribe> I thought that, I didn't sget that Henning was talking about
[04:58:58] <scribe> choice two. But then we said choice two was what Henning
[04:59:03] <scribe> said. I'm confused about what's being called. Is it
[04:59:05] <scribe> what's being said or what's on the screen or what Henning said? NEW SPEAKER:
[04:59:09] <scribe> I believe the question at hand and I think it is what Henning
[04:59:14] <scribe> sutd, is that the D H T support multiple, we support
[04:59:19] <scribe> multiple D H Ts and we do, we do pick one must implement
[04:59:22] <scribe> understanding that that has a significant limitations. NEW SPEAKER:
[04:59:27] <scribe> The only qualification, I mean No. 2, in the middle. With the
[04:59:31] <scribe> only understanding that we're not running multiple
[04:59:34] <scribe> simultaneously. NEW SPEAKER: Yes. (Several people talking.) NEW SPEAKER:
[04:59:35] <scribe> That was the difference. (Several people talking.) NEW SPEAKER:
[04:59:41] <scribe> Fine. So multiple means multiple
[04:59:44] <scribe> implementations, not running sim mule tain yus. NEW SPEAKER:
[04:59:46] <scribe> Yes. NEW SPEAKER: (Several people talking.) NEW SPEAKER:
[04:59:53] <scribe> Could I have a hum of those in favor of that, as our working
[04:59:55] <scribe> assumptions going forward?
[04:59:55] <scribe> ( Humming.)
[05:00:00] <scribe> NEW SPEAKER: And those who don't think that's a, at this point
[05:00:03] <scribe> anyway, is a reasonable assumption for moving forward, hum now.
[05:00:08] <scribe> ( Humming. ) NEW SPEAKER: We have some. But, I
[05:00:13] <scribe> think the consensus is that we're going to do it that way.
[05:00:17] <scribe> We will, we'll work towards supporting multiple D H Ts,
[05:00:20] <scribe> we will choose one must implement. It does have some
[05:00:25] <scribe> limitations and we're not requiring that you run D H T
[05:00:27] <scribe> simultaneously. NEW SPEAKER: We're already over.
[05:00:31] <scribe> I'm going to stop. The rest is about which D H T to use. Please look
[05:00:35] <scribe> at the slides. A little bit about that discussion. We'll
[05:00:41] <scribe> push that to another day. NEW SPEAKER: Okay. Next?
[05:01:15] <scribe> Philip. NEW SPEAKER: How is this? Can everybody hear me? NEW SPEAKER:
[05:01:19] <scribe> No. NEW SPEAKER: Yes. Up a little bit. NEW SPEAKER:
[05:01:23] <scribe> Is that better? Can everybody hear me? Yes. Okay.
[05:01:30] <scribe> Okay. So, I'm going to talk a little bit about the nat traverse
[05:01:42] <scribe> Sal problem. So, briefly, for those who aren't familiar
[05:01:48] <scribe> with it, you know, we have this problem with nat, with nats, if you try to sort
[05:01:53] <scribe> of send a packet to a peer that's located behind the nat and you
[05:01:57] <scribe> haven't previously sent packets out, then the nat will drop it.
[05:01:58] <scribe> Okay.
[05:02:04] <scribe> So, I'm not going to say much more about that.
[05:02:11] <scribe> So, in considering this, how the solutions of this type, we
[05:02:14] <scribe> need to think about the different types of messages that we
[05:02:18] <scribe> need to be passing around in a P to P SIP network. And there
[05:02:22] <scribe> are at least three different types, okay. There are the peer and klinlt
[05:02:28] <scribe> protocol messages. There are the SIP
[05:02:31] <scribe> messages, and then there is the R T P or whatever other
[05:02:35] <scribe> protocol we're using for transporting media
[05:02:35] <scribe> messages. Okay.
[05:02:40] <scribe> So, looking at these three types of
[05:02:45] <scribe> messages, we start with R T P first, the proposal which I don't
[05:02:50] <scribe> think we can change, and I don't see any reason to change I
[05:02:54] <scribe> it, is that we just follow what SIP, SIPPING, I think is
[05:02:58] <scribe> actually recommending, which is using ice and stun to
[05:03:01] <scribe> establish a direct media stream. Okay. So I don't propose
[05:03:02] <scribe> to say anything more about dha.
[05:03:07] <scribe> So, that, given that we have a solution to that, let's
[05:03:10] <scribe> look at the other two messages. How are we
[05:03:13] <scribe> going to get those across. In standard client server SIP,
[05:03:19] <scribe> those are basically, it's not as much of a problem, because of the
[05:03:23] <scribe> way they work there. But they're more of a problem in a P to
[05:03:23] <scribe> P SIP environment.
[05:03:32] <scribe> Okay. So what I want to do now is outline two approaches that have been
[05:03:35] <scribe> suggested and the purpose of this session is for people to sort of
[05:03:40] <scribe> comment on these two, or also suggest other ways that
[05:03:43] <scribe> we might move forward. But I have a few slides to talk about
[05:03:45] <scribe> these two approaches first, and then we can have
[05:03:46] <scribe> a discussion.
[05:03:50] <scribe> Okay. And these two approaches, I'm sort of right
[05:03:55] <scribe> now, they have this sort of nicknames right now of super peer
[05:03:58] <scribe> and fully distributed and various people have
[05:04:02] <scribe> commentd they don't particularly like these names. We'll
[05:04:04] <scribe> just choose them as labels for now.
[05:04:12] <scribe> So, these two solutions provide a solution for both the peer or client
[05:04:16] <scribe> protocol and the SIP messages. Okay. And could be
[05:04:22] <scribe> used as R T P, but I personally, I think that this is the way we're
[05:04:26] <scribe> probably going to go. Okay. So let me just briefly outline
[05:04:33] <scribe> these two proposals. Okay. So in the super peer
[05:04:39] <scribe> approach, you choose a number of peers, which have first
[05:04:43] <scribe> of all, they have to have the property that they have public IP
[05:04:47] <scribe> addresses. And second of all, they have the property that they are
[05:04:51] <scribe> otherwise capable. They have sufficient band with and
[05:04:54] <scribe> perhaps some other properties, and to do what's called
[05:04:56] <scribe> promoting them to super peers.
[05:05:01] <scribe> And then, the rest of the peers, are called
[05:05:05] <scribe> ordinary peers, and they connect up to super peer,
[05:05:12] <scribe> in sort of a client server type role or master slave type role.
[05:05:19] <scribe> Okay. Typically, there is sort of one, an ordinary peer
[05:05:21] <scribe> associates with one super peer, although you could imagine
[05:05:23] <scribe> what, you know, SIP
[05:05:27] <scribe> implementations where they would associate maybe with two or,
[05:05:27] <scribe> okay.
[05:05:33] <scribe> So that's, that's, by the way, that's the super peer
[05:05:38] <scribe> approach. So I guess I should say, given this then, nat
[05:05:42] <scribe> traverse Sal becomes, if you want to send a message from
[05:05:45] <scribe> here, this overlay node to this overlay node, you send it up to
[05:05:49] <scribe> the super peer, forward it over to the other super peer and he
[05:05:51] <scribe> can forward it down like that. For example.
[05:05:55] <scribe> Yes, Jonathan? NEW SPEAKER: I don't know if it's part
[05:05:59] <scribe> of the proposal or requirement that we would need to be able to
[05:06:04] <scribe> dine klee determine super peer status or stat klee configure it.
[05:06:09] <scribe> I think it's profoundly challenging to really know if you're in
[05:06:14] <scribe> super node. It's a question. I mean, I don't know. NEW SPEAKER:
[05:06:17] <scribe> I'm saying, this is just sort of one general approach, and
[05:06:20] <scribe> we haven't worked out the details. This, I guess what I
[05:06:25] <scribe> should say, this approach is commonly used today, and, in
[05:06:28] <scribe> peer to peer file sharing networks. NEW SPEAKER:
[05:06:33] <scribe> Henning. NEW SPEAKER: Henning, the question that I
[05:06:39] <scribe> have with this model, is that lodge
[05:06:42] <scribe> logically speaking, this appears different.
[05:06:47] <scribe> But in the same topology, in the same place, independent of
[05:06:51] <scribe> their rolls, so in a sense that, if you were to draw a ring for
[05:06:58] <scribe> example, or on the far right side, may we will be logically
[05:07:02] <scribe> connected to the S, which it's not shown here, so they
[05:07:07] <scribe> would, you could, you would traverse linearly and walk
[05:07:12] <scribe> around the ring. And ultimately visit some Os, some S,
[05:07:17] <scribe> in some undetermined order, but the load that would transport
[05:07:21] <scribe> would go through an S, if you are between an O and S or between two
[05:07:24] <scribe> Os. NEW SPEAKER: Sorry, is this a question or
[05:07:26] <scribe> statement. NEW SPEAKER: Yes, this is a question. I
[05:07:27] <scribe> want to understand the model better. NEW SPEAKER:
[05:07:32] <scribe> Right. So, all I can say is the way that it, that if this is
[05:07:36] --- cullenfluffyjennings@gmail.com has left
[05:07:36] <scribe> usually I am mre ment stead, the way it's usually implemented is
[05:07:40] <scribe> that the, as I understand it, the D H Ts are only run
[05:07:45] <scribe> amongst the Ss and Os, sort of hang off in some sense. NEW SPEAKER:
[05:07:47] <scribe> So they're much more client like. NEW SPEAKER: They
[05:07:52] <scribe> are more client like. Exactly. NEW SPEAKER: That's very
[05:07:54] <scribe> different. NEW SPEAKER: Now, that doesn't mean, that's
[05:07:59] <scribe> the way it's typically done. We could choose to do what you
[05:08:05] <scribe> wanted, what you suggested. And that's, you know, if
[05:08:09] <scribe> we chose this method, then we'd have to look at how well does
[05:08:14] <scribe> all this match up. And I think that is in fact, in my mind,
[05:08:17] <scribe> because I have a slide and I'm going to talk about pros and
[05:08:21] <scribe> cons. Your point there is a con with this approach. NEW SPEAKER:
[05:08:25] <scribe> Okay. I think this is
[05:08:29] <scribe> accrue crucial difference, which we will get confused with
[05:08:32] <scribe> klipts. NEW SPEAKER: So this these could be just
[05:08:35] <scribe> clients or they could be peers, in which case we have to
[05:08:38] <scribe> do what you said. NEW SPEAKER: I wanted to follow up
[05:08:42] <scribe> and add to what Jonathan said. This is more than just what
[05:08:46] <scribe> he said, even in the nice environment. There is also the problem of a
[05:08:50] <scribe> significant incentive to try to cheat and make yourself not
[05:08:54] <scribe> look like a super peer. Because some people deliberately
[05:08:57] <scribe> don't want to do routing and storage. There's a group of people
[05:09:02] <scribe> trying to do that, skip for example, where you can maybe your
[05:09:06] <scribe> peer look more or less capable. It can be very hard. NEW SPEAKER:
[05:09:12] <scribe> Too bad I don't see anyway in open protocol, unlike skooip. You
[05:09:18] <scribe> know, hide the mechanics to not do that. I think we should
[05:09:22] <scribe> declare that as possibility? Open environment. We can
[05:09:25] <scribe> always swap whatever messages we want and pretend to be dead.
[05:09:32] <scribe> So I think that's a non goal here. To enforce, force community spirit is
[05:09:35] <scribe> not something which is part of the IETF charter. NEW SPEAKER:
[05:09:45] <scribe> Okay. Any other questions on this model before I go to the
[05:09:51] <scribe> other current proposal? I I stress that these are the two that are
[05:09:55] <scribe> currently sitting out and the point of this is to raise
[05:09:59] <scribe> discussion and maybe call for other suggestions. NEW SPEAKER:
[05:10:03] <scribe> Yes, Kevin Jones. Just a point of clarification on this
[05:10:06] <scribe> model here. Your last statement or last paragraph there, talks
[05:10:09] <scribe> about ordinary peers establishing connections with other
[05:10:14] <scribe> ordinary peers, but then it says no need to super peer.
[05:10:18] <scribe> So I'm wondering if you have two ordinary peers
[05:10:21] <scribe> behind a nat, can they communicate directly or do they have to
[05:10:24] <scribe> go through super peer to make the communication. NEW SPEAKER: This
[05:10:28] <scribe> is a question. As I said, this in some sense, these are sort of
[05:10:31] <scribe> broader categories, if you you would, that we can put these
[05:10:34] <scribe> models in, and we could choose to have these guys
[05:10:38] <scribe> communicate directly, and certainly, if we chose this approach, I would
[05:10:41] <scribe> probably advocate that we do try to get them to communicate
[05:10:43] <scribe> directly.
[05:10:49] <scribe> But they could be forced to go through the super peer. If we
[05:10:53] <scribe> thought that was better.
[05:11:04] <scribe> Okay. So the second broad approach, okay, is to try not
[05:11:08] <scribe> to, we call the fully distributed or all nodes are equal type
[05:11:20] <scribe> approach, okay. Where each node
[05:11:27] <scribe> establishes a small number of connections with other nodes, each,
[05:11:31] <scribe> sorry, each peer establishes a number of connections
[05:11:33] <scribe> with other peers in the overlay. Okay.
[05:11:39] <scribe> And then you do what is effectively message routing. To your
[05:11:42] <scribe> destination. So, here I've tried to draw this, I've
[05:11:47] <scribe> tried to in this diagram, assuming here that something
[05:11:51] <scribe> roughly, a ring shaped architecture, okay. So these
[05:11:57] <scribe> things are mostly sort of laid out on a ring. And so you have, you
[05:12:02] <scribe> know, each node has connections to its predecessor and
[05:12:06] <scribe> successor, and in addition has sort of like one extra, most of
[05:12:10] <scribe> them have like one extra connection that sort of goes across the ring.
[05:12:13] <scribe> Okay. So you get relative, that way you can get to another
[05:12:18] <scribe> node in the ring with a relatively small number of hops and
[05:12:22] <scribe> this is sort of all in expired by cord if we went to something like this.
[05:12:28] <scribe> So, if this node here had a message over for this guy here, it could be sent here for
[05:12:34] <scribe> example, hop hop or maybe more efficiently here, two
[05:12:35] <scribe> hops shs things like that. Okay.
[05:12:42] <scribe> And so, this, this leads then to the question of how do you
[05:12:46] <scribe> actually sort of make all this, in a situation like that,
[05:12:52] <scribe> how do you actually route things through the overlay? Well,
[05:12:55] <scribe> what I think you would not want to do, and you could
[05:12:59] <scribe> conceptually do and I think you do not want to do, is you
[05:13:03] <scribe> could run some routing protocol, like O S P F. But I don't think you want
[05:13:04] <scribe> to do that.
[05:13:12] <scribe> Instead, the proposal is to, instead, the proceeds Al is
[05:13:17] <scribe> to base, the advantage that we have here, over standard internet
[05:13:20] <scribe> routing is the peers get to choose the links,
[05:13:24] <scribe> okay. And so you can set up the links to be efficient,
[05:13:26] <scribe> give efficient routing.
[05:13:30] <scribe> So, in particular, one way to do it is to base the links on the
[05:13:35] <scribe> links that you come up with cord. So, cord suggests that
[05:13:39] <scribe> you arrange the nodes in a ring. And you do
[05:13:44] <scribe> successors, you sort of make connections to nodes which are
[05:13:47] <scribe> sort of a power of two away from you in the ring. Okay.
[05:13:53] <scribe> And so, if X here is X here, X would have a connection to
[05:13:59] <scribe> A, which is its successor, which is one away. And B to
[05:14:05] <scribe> which is two away and C which is four away and D which is 8
[05:14:08] <scribe> away and across the ring from it. If X has a message to send to
[05:14:12] <scribe> say, this peer over here, well, according to the cord rules
[05:14:15] <scribe> it forwards it onto C, because C is the
[05:14:20] <scribe> closest one going in the clockwise direction around, and then
[05:14:23] <scribe> C makes the same choice when it goes on, when it has
[05:14:24] <scribe> to forward it on.
[05:14:29] <scribe> And I see a question. NEW SPEAKER: Jeff Hodges. This
[05:14:35] <scribe> is a perhaps a naive question. It seems to me we're mixing two
[05:14:41] <scribe> things, nat traverse Al and the D H T approach. So, my
[05:14:47] <scribe> question is, gee, if we perhaps do something like ice to
[05:14:53] <scribe> handle nat traverse Sal, then the D H T stuff needs to be
[05:14:55] <scribe> separately addressed, yes? NEW SPEAKER: If I can
[05:14:57] <scribe> address this --
[05:14:59] <scribe> NEW SPEAKER: I was going to say, that's one of the reasons I like
[05:15:02] <scribe> this approach, because it lets you do that. NEW SPEAKER:
[05:15:04] <scribe> Cool. But --
[05:15:07] <scribe> NEW SPEAKER: So, my question, so my question then
[05:15:12] <scribe> becomes, does not, doing that, in other words, using ice,
[05:15:16] <scribe> then let you, in other words you don't have to doo
[05:15:19] <scribe> necessarily cord. You can do whatever, right? NEW SPEAKER: Yes. NEW SPEAKER:
[05:15:25] <scribe> So, that would separate things out. NEW SPEAKER:
[05:15:30] <scribe> Maybe I misunderstanding what you're saying. But, yes,
[05:15:37] <scribe> it, you could make the connection topology match the D H T. And
[05:15:41] <scribe> personally, I think that's a good idea. But I don't think
[05:15:45] <scribe> it's a, it's a requirement. You don't have to do it. We could
[05:15:50] <scribe> choose to make a connection topology based on cord. But run something else
[05:15:53] <scribe> instead. I'm not sure if it would make sense, but you could
[05:15:54] <scribe> do it.
[05:15:59] <scribe> NEW SPEAKER: Jonathan Rosenburg. I just don't get it then. One of
[05:16:03] <scribe> the things I worry about, people's understanding, and my
[05:16:06] <scribe> understanding ever peer to peer protocols, is that the
[05:16:11] <scribe> figure tables that define the routing defines who you talk
[05:16:14] <scribe> to. That's the purpose of routing. I don't understand the
[05:16:19] <scribe> meaning of separating the kek topology from the D H T, because then you
[05:16:22] <scribe> have the problem, how do you know that the hap is closer to
[05:16:26] <scribe> where you want to go. That doesn't make any sense to me. I was
[05:16:30] <scribe> going to come up here and say, exactly what Jeff just said. This is
[05:16:34] <scribe> one of the reasons I like, what you're calling fully distributed,
[05:16:38] <scribe> because it uses what ice e lets you do. You can at
[05:16:42] <scribe> least reach somehow, to create a direct connection so we can have
[05:16:48] <scribe> the kek topology. That's why I was going to object to this slide. Because it has
[05:16:52] <scribe> nothing to do with cord. We can actually do P to P. Because
[05:16:57] <scribe> otherwise, I think in a super model, you may find you have
[05:17:02] <scribe> little choice than to just run the D H T amongst the super
[05:17:07] <scribe> nodes, because they can mesh. Once you start establishing direct client
[05:17:10] <scribe> questions, you run into the question, how do I know whether I
[05:17:13] <scribe> should route them on that path. And then it gets back to the
[05:17:17] <scribe> D H T problem. To the previous point, I think these
[05:17:21] <scribe> are a problem, unless we choose a fully distributed
[05:17:25] <scribe> approach, you will have very little choice only to have super
[05:17:29] <scribe> nodes. NEW SPEAKER: And this is worth pointing out, this helps
[05:17:33] <scribe> with some of the problems you raised. NEW SPEAKER: Maybe we should have
[05:17:36] <scribe> this discussion off line. I believe it's possible to separate
[05:17:40] <scribe> it, but personally I don't advocate it. NEW SPEAKER: Can
[05:17:42] <scribe> you prove that it will work. NEW SPEAKER: I believe I can.
[05:17:45] <scribe> I'll show you off line. NEW SPEAKER: Bruce somebody.
[05:17:49] <scribe> I apologize for this. I did this slide by merging two of
[05:17:51] <scribe> Philip's slides, and what I should have done with
[05:17:56] <scribe> the slide is to take the third bullet point, bold it and put it in a
[05:18:00] <scribe> box. And establish connections through nats to make the connection
[05:18:04] <scribe> table that you have through nats be a super set of the D H T
[05:18:05] <scribe> routing table. (Several people talking.) NEW SPEAKER:
[05:18:09] <scribe> Or a super set of the can D H T. Everything else on here
[05:18:13] <scribe> mentioning cord is a specific example of how to do this, but
[05:18:17] <scribe> the idea is the connection table will if at all possible, the
[05:18:21] <scribe> super set D H T routing, what exactly you do if you require a
[05:18:25] <scribe> relay to form a connection with a peer, that it should be in your
[05:18:35] <scribe> routing table, is I think something somewhat of an open question. But the connection here is a super set of the routing
[05:18:37] <scribe> table. NEW SPEAKER: Maybe I can just say one other thing
[05:18:42] <scribe> about this that may clarify it. What I believe, the only
[05:18:46] <scribe> thing I think you need to do to make this work is to have a
[05:18:50] <scribe> connection topology where you can do what I'm calling greedy
[05:18:55] <scribe> routing. Greedy routing means you do the locally optimal
[05:18:59] <scribe> decision is the globally optimal decision. So each
[05:19:03] <scribe> point, C routes it on to the guy that he believes is closes to
[05:19:06] <scribe> the final destination, and as long as you make sure your connection
[05:19:10] <scribe> topology alts means you get closer and never get to dead
[05:19:18] <scribe> ends, you will get there. NEW SPEAKER: not
[05:19:21] <scribe> logarithmicly. NEW SPEAKER: So that you get it, that's an
[05:19:24] <scribe> extra choice that you have to make. Or an extra thing that you dash NEW SPEAKER:
[05:19:28] <scribe> I think now we're getting into a D H T discussion. NEW SPEAKER:
[05:19:34] <scribe> Yes. Jeff Hodges. It seems to me that we should just, that
[05:19:39] <scribe> nat traverse sals are orthagonal, and just deal with nat traverse
[05:19:45] <scribe> Sal, and then whether or not you have a completely fully
[05:19:48] <scribe> distributed connection topology on top of that, or you choose
[05:19:53] <scribe> to do super nodes or not, is a separate decision. There may be
[05:20:00] <scribe> reasons other than how many hops you're doing to choose whether or
[05:20:03] <scribe> not a node is something called a super node that has different properties
[05:20:08] <scribe> than other nodes. That for instance, you may be using one of those
[05:20:12] <scribe> nodes to store portions of your directory or whatever.
[05:20:17] <scribe> There's other considerations.
[05:20:21] <scribe> So you just, the nat tra dash NEW SPEAKER: Not nat traverse Sal
[05:20:24] <scribe> situations. NEW SPEAKER: Right. I would consider them
[05:20:27] <scribe> completely orthagonal. NEW SPEAKER: Okay. So now you're
[05:20:29] <scribe> getting into D H T discussion. NEW SPEAKER: Not necessarily.
[05:20:33] <scribe> You just deal with the nat traverse Sal, and then your connection
[05:20:38] <scribe> topology is a separate question. NEW SPEAKER: Right.
[05:20:42] <scribe> Jonathan. To me, this is a such a no brain err decision.
[05:20:46] <scribe> If you do this, then you're able to separate all these other things. If
[05:20:50] <scribe> you do this, you can still have a super node architecture, where
[05:20:53] <scribe> the super nodes run the peer protocol we just defined or you
[05:20:56] <scribe> can choose a protocol where there are no super nodes or pick
[05:21:00] <scribe> whatever D H T you want. As soon as you say I'm going to couple
[05:21:04] <scribe> my nat traverse Sal connection topology, you merge all the
[05:21:07] <scribe> decisions to go. I think that's a mistake. If this was an
[05:21:10] <scribe> unsolve able problem, I would say, maybe we have no choice.
[05:21:14] <scribe> But the draft points out how to nicely solve it.
[05:21:18] <scribe> So I don't see why we're having this discussion. I think it's a
[05:21:22] <scribe> no brain err. NEW SPEAKER: At that note, let's cut
[05:21:26] <scribe> it off after Henry. NEW SPEAKER: I'd like to close the
[05:21:30] <scribe> discussion by mentioning, they wouldn't have happen, if
[05:21:33] <scribe> people come here having read some background that you have the
[05:21:38] <scribe> D H T routing and then you have leaves and neighbors and connection table
[05:21:41] <scribe> as you said, it should have been a draft to it. And
[05:21:46] <scribe> finally, there are also how do you select the your a neighbor's
[05:21:49] <scribe> selection, by what criteria for example, minimum delay and so
[05:21:53] <scribe> forth. So we shouldn't discuss this here. Please, next time,
[05:22:01] <scribe> if you want to discuss it, do your reading first. So,
[05:22:10] <scribe> NEW SPEAKER: Okay. Well, okay. So, we can skip these
[05:22:16] <scribe> if we're running out of time. NEW SPEAKER: You have or
[05:22:18] <scribe> eight or nine minutes. Use it however you want. NEW SPEAKER:
[05:22:23] <scribe> Okay. This is a slide that just shows you how you can
[05:22:29] <scribe> go back and set up some of these connections in this table or
[05:22:33] <scribe> in this fully distributed model. So, what it's
[05:22:41] <scribe> trying to show you, is, so one is, you know, if you try
[05:22:46] <scribe> to send directly it would fail. So in, if you instead,
[05:22:50] <scribe> what you can do, here we're assuming we're using SIP as the method
[05:22:55] <scribe> for setting up connection. You can send these SIP invite
[05:23:00] <scribe> over to this node here. Send it here and then you can therefore set up
[05:23:03] <scribe> a, by signalling internet path here, you can
[05:23:08] <scribe> set up a direct connection between these two nodes. Spencer? NEW SPEAKER:
[05:23:13] <scribe> Spencer, I'm sorry. Could I back you up to the slide that
[05:23:20] <scribe> shows the, the previous one on, where's if one on super peer? NEW SPEAKER:
[05:23:25] <scribe> One more. NEW SPEAKER: So basically, people were
[05:23:29] <scribe> kind of speaking all over the idea that you can know you have the
[05:23:33] <scribe> addresses and stuff like that. I think what Jonathan just said
[05:23:38] <scribe> was, you don't have to know that you, you don't have to know
[05:23:41] <scribe> that you have public IP addresses in order to do super peer.
[05:23:46] <scribe> If I understood it correctly. That that's an orthagonal
[05:23:47] <scribe> decision. I think that's really important. NEW SPEAKER:
[05:23:52] <scribe> Is that what you said? I thought you said you wouldn't know
[05:23:54] <scribe> necessarily that you could be a super peer. NEW SPEAKER:
[05:23:58] <scribe> No. That if super peer decision was not made specifically
[05:24:01] <scribe> because you knew you had public IP addresses. NEW SPEAKER:
[05:24:04] <scribe> Yes, right. So my point is, if you had a fully
[05:24:08] <scribe> distributed algorithm that lets you connect to
[05:24:12] <scribe> whoever, you can use some other criteria, like stack
[05:24:15] <scribe> selection or whatever. Or some other, you know, it might
[05:24:19] <scribe> be hard but it's not a function that's difficult to determine I
[05:24:21] <scribe> have a publicly routed IP address. NEW SPEAKER: Right. NEW SPEAKER: Thank you.
[05:24:35] <scribe> NEW SPEAKER: I am going to skip over the rest of this one.
[05:24:40] <scribe> This is an attempt to briefly summarize the pros and cons. In
[05:24:44] <scribe> the super peer approach, presumably, we establish a
[05:24:48] <scribe> connection with something like outbound, okay. In the
[05:24:52] <scribe> fully distributed approach, we would set up connections using
[05:24:55] <scribe> SIP signalling, say, with ice or something
[05:24:58] <scribe> else as we were talking about yesterday, with Jonathan or he was
[05:25:02] <scribe> suggesting maybe something other than SIP, but SIP would be
[05:25:05] <scribe> one possibility for signalling the
[05:25:08] <scribe> connections. The super peer approach is, to get down to
[05:25:11] <scribe> the pros and cons, the super peer is approach is a quote,
[05:25:16] <scribe> the classic scheme. It is already, there are a lot of
[05:25:19] <scribe> examples of this approach today. Whereas this fully
[05:25:24] <scribe> distributed is something that is has been proposed but there's not
[05:25:26] <scribe> much operational experience yet with this one.
[05:25:34] <scribe> However, the super peer requires that there's, that there be
[05:25:38] <scribe> enough peers eligible for super peer status, where
[05:25:42] <scribe> fully dris distributed does not have one. It
[05:25:46] <scribe> requires that there are some nodes which have public IP
[05:25:50] <scribe> addresses and there are some proposed use cases where that is not true.
[05:25:56] <scribe> Whereas this one does not have this requirement. We have
[05:26:00] <scribe> already talkd about whether you want to need to limit
[05:26:04] <scribe> the D H T to super peers or not. It suggests that maybe you
[05:26:07] <scribe> do, where this one does not have that limitation. And in this
[05:26:11] <scribe> case, you need a mechanism to assign ordinary peers
[05:26:15] <scribe> to super peers. Whereas here, you may have, there
[05:26:18] <scribe> is, there may be some number of hops to get from one spot to
[05:26:24] <scribe> another. Henning? NEW SPEAKER: Okay. As usual,
[05:26:27] <scribe> I think there's a trade off here between implementation
[05:26:29] <scribe> complexity and special circumstances and all that. So it's
[05:26:34] <scribe> not clear to me that we actually have to make a choice as such, in
[05:26:40] <scribe> the sense that, you could imagine a kind of bear bones environment,
[05:26:44] <scribe> say, within an enterprise or some other environment where just isn't as
[05:26:48] <scribe> big a problem, to draw peers if you've got enough of the
[05:26:52] <scribe> type you need and you don't have to go through the discovery, because
[05:26:55] <scribe> what you basically have to do on the right hand side is, you have to
[05:26:59] <scribe> have a discovery mechanism of finding within the supply of peer
[05:27:05] <scribe> nodes, one's that can serve as ice nodes or stun nodes,
[05:27:07] <scribe> equivalent, to do that, and then you go through the
[05:27:07] <scribe> machinery.
[05:27:12] <scribe> And so to me, this is an additional layer of functionality
[05:27:17] <scribe> that you can add to one, in a particular instance of D H T,
[05:27:20] <scribe> doesn't support that, then you look for consequences, you may
[05:27:24] <scribe> not get as big a D H T, may not scale as well, but it's
[05:27:27] <scribe> certainly easier to implement. NEW SPEAKER: How I
[05:27:33] <scribe> guess I don't see that. NEW SPEAKER: Let me see, bs let's say a
[05:27:35] <scribe> candidate, assume we have some number of peers
[05:27:37] <scribe> existing, right sf NEW SPEAKER: Yes. NEW SPEAKER:
[05:27:42] <scribe> And if you operating in the left hand mode, say all thee NEW SPEAKER:
[05:27:45] <scribe> Super peer mode. NEW SPEAKER: All these people are
[05:27:53] <scribe> operating as non something devices. Let's take that extreme
[05:27:57] <scribe> example. If a new peer shows up and says, hi, I'm
[05:28:00] <scribe> willing to serve as a peer node, but I'm sorry, I don't
[05:28:06] <scribe> have a public IP address, it would contact one of these
[05:28:10] <scribe> rendezvous peers, whatever we end up calling them.
[05:28:14] <scribe> Thanks for your offer, but I'm sorry I can't accommodate
[05:28:18] <scribe> you, please go back as a peer and come back to me after we rev the
[05:28:22] <scribe> software. So that works. And it needs to be discoverable certainly. NEW SPEAKER:
[05:28:25] <scribe> Right. NEW SPEAKER: And then if you go to the fancy
[05:28:28] <scribe> version of the same thing and it says thank you very much for
[05:28:33] <scribe> contacting me. Let me forward you to a suitable stun node if I don't
[05:28:37] <scribe> do it myself, and we'll integrate you into this and things
[05:28:42] <scribe> will work as well. So I think we need to get them, and ice
[05:28:46] <scribe> implementation is not trivial, let's put it that way. And
[05:28:49] <scribe> since you purely can't do the simple version here, in most
[05:28:51] <scribe> cases, maybe that's something Jonathan can discuss. NEW SPEAKER:
[05:28:54] <scribe> You mean the light version. NEW SPEAKER: Yes. NEW SPEAKER: I don't
[05:28:56] <scribe> think you can. NEW SPEAKER: It seems to me that we
[05:29:02] <scribe> should simply plan on having a mechanism to support both
[05:29:05] <scribe> implementations, just to avoid, well, if we require the
[05:29:09] <scribe> fully distributed version, that raises the bar
[05:29:13] <scribe> significantly. If we, and people will then not be able to
[05:29:20] <scribe> have a sane way to discover what goes on unless we have a
[05:29:24] <scribe> negotiation and discovery mechanism which
[05:29:27] <scribe> allows a candidate peer mode, because that's the only one that
[05:29:31] <scribe> really matters to make discover what's possible and what's not possible. NEW SPEAKER:
[05:29:37] <scribe> So what I take you as saying, is that, in some sense you may want
[05:29:43] <scribe> a high bread, you know, hybrid, the possibility to
[05:29:45] <scribe> migrate from one to the other. NEW SPEAKER: You know, it
[05:29:48] <scribe> doesn't make sense to do the same thing, this the same ring
[05:29:51] <scribe> topology or not, I haven't thought about that. But
[05:29:55] <scribe> certainly I would like to make it possible to have an all super
[05:30:01] <scribe> peer only, all public peer only, that's my term here.
[05:30:06] <scribe> Public peers only, and if a candidate node shows
[05:30:11] <scribe> up, candidate peer node shows up, it simply gets turned away
[05:30:14] <scribe> if it doesn't satisfy that. NEW SPEAKER: So it's a bit
[05:30:16] <scribe> that's said, cleared for the overlay. NEW SPEAKER:
[05:30:18] <scribe> Exactly. NEW SPEAKER: And you just say, this overlay
[05:30:23] <scribe> is going to use this architecture or that architecture. NEW SPEAKER:
[05:30:25] <scribe> Yes. NEW SPEAKER: Can I ask a question. You're
[05:30:29] <scribe> basically proposing two things then, that would require that we
[05:30:33] <scribe> have some sort of a peer protocol, whatever it may be. But
[05:30:36] <scribe> more importantly, you're saying we should build a mechanism for
[05:30:39] <scribe> telling somebody whether they're going to be able to be a peer or
[05:30:42] <scribe> not. NEW SPEAKER: Exactly. You need to be, thanks
[05:30:45] <scribe> for asking, sorry, no. Version will have to have any
[05:30:49] <scribe> number of other reasons besides just being able to
[05:30:54] <scribe> be a public peer as well. I just may not like your face, you may be on a
[05:30:58] <scribe> black list, there's any number of reasons why a peer
[05:31:02] <scribe> candidate may be bounced. NEW SPEAKER: Jonathan rose Burg, I
[05:31:05] <scribe> think this is not hard, it's much like we did with ice and
[05:31:09] <scribe> SIP, you know, no one says if you implement SIP, you must
[05:31:12] <scribe> implement ice. You only do that if you think you're going to
[05:31:17] <scribe> be on a nat. So I think I can implement this the same way,
[05:31:21] <scribe> it's a different, this one is different in that I think it you
[05:31:25] <scribe> can make the choice differently in each peer in the ring. I
[05:31:28] <scribe> implement the ice protocol when I think I'm one of these guides
[05:31:30] <scribe> behind a nat, so I think there's some work here.
[05:31:34] <scribe> What I came up here to talk about is this slide here. A
[05:31:40] <scribe> couple of things is con may require up to log two N hops. You have that
[05:31:45] <scribe> in anyone. It's just that N may be small in the super peer
[05:31:50] <scribe> architecture. But that's what it is. It's not -- are you
[05:31:56] <scribe> aware of a D H T that provides a hop Count 6 less than log N. NEW SPEAKER:
[05:32:01] <scribe> Yes. There are. NEW SPEAKER: Wow. NEW SPEAKER:
[05:32:03] <scribe> Just because they have huge figure tables. NEW SPEAKER:
[05:32:05] <scribe> Okay. (Several people talking.) NEW SPEAKER: But what I'm
[05:32:10] <scribe> trying to say here is, that's true. The D H T thing is
[05:32:14] <scribe> true on look up. But this is true even for say, the response
[05:32:17] <scribe> coming back. Or whatever. If you route it. NEW SPEAKER:
[05:32:20] <scribe> Okay. I'd just like to be clear on that. NEW SPEAKER:
[05:32:26] <scribe> I agree it's sort of squished into here. Okay. So, NEW SPEAKER:
[05:32:30] <scribe> Bruce. Going back to the question of whether
[05:32:34] <scribe> peers need to implement ice, my concern is the number of use
[05:32:38] <scribe> cases in which peers to do not need to implement ice
[05:32:42] <scribe> is manage blee small. And in fact, it's only the global P to
[05:32:46] <scribe> P service provider skip. In e every other case, the only
[05:32:51] <scribe> other use case I can think of, where you might be able to argue you
[05:32:54] <scribe> don't need ice is a single enterprise provider. But the
[05:32:59] <scribe> issue that I quite frankly am surprised Jonathan didn't explode
[05:33:02] <scribe> with, is that, the suggestions that we can develop a
[05:33:08] <scribe> protocol to identify whether you can be a peer that does not need
[05:33:12] <scribe> ice, is going to essentially proposing develop protocol that
[05:33:16] <scribe> we've determine is positive. In that you can determine that
[05:33:19] <scribe> you're not behind a nat, that no peer that you wish to
[05:33:21] <scribe> connect with the in the future dash NEW SPEAKER: No. (Several people talking.) NEW SPEAKER:
[05:33:28] <scribe> NEW SPEAKER: Microphone. NEW SPEAKER: That doesn't
[05:33:30] <scribe> help. NEW SPEAKER: You're saying that people steel? NEW SPEAKER:
[05:33:34] <scribe> Oh, yes, they do. NEW SPEAKER: Yes. NEW SPEAKER:
[05:33:39] <scribe> It's certainly, in a global service provider case, you don't need
[05:33:42] <scribe> ice, but it would take a lot of convincing, I think,
[05:33:45] <scribe> certainly to convince me, that you can prove that the other
[05:33:49] <scribe> use case doesn't require ice. So I think that I will argue
[05:33:53] <scribe> strongly for P to P SIP peers must implement ice,
[05:33:57] <scribe> because I think that for almost all use cases it is required. NEW SPEAKER:
[05:34:01] <scribe> Let's cut this off after Jonathan, we're three minutes over. NEW SPEAKER: The
[05:34:12] <scribe> missing element in this discussion is labor selection, you make
[05:34:16] <scribe> this charge, and the confusion I hear is the notion of super
[05:34:21] <scribe> peer. For me, I can see two neighbors. I can see you
[05:34:26] <scribe> and Brian. One can be in Australia and the other one in ba
[05:34:29] <scribe> vair yeah. Because I can see you, that's the first requirement.
[05:34:36] <scribe> Now, I have to select which to use, especially for ice. The
[05:34:42] <scribe> criteria for selecting the closest one is latency. Most of all.
[05:34:49] <scribe> So if we use ice, and here comes something in addition to
[05:34:54] <scribe> ice, ice is very good and perhaps this crosses the
[05:34:58] <scribe> selection, you may want to add to ice if you select the
[05:35:01] <scribe> candidates based on labor. NEW SPEAKER: Okay. NEW SPEAKER:
[05:35:05] <scribe> So that's good. But we have to clarify.
[05:35:09] <scribe> What I wanted to clarify is that, to me, that doesn't matter
[05:35:14] <scribe> if they declare super node because they have better software or
[05:35:18] <scribe> whatever. The first requirement would be to see you. And after I see
[05:35:21] <scribe> you, I select between you and Brian, whichever is closer.
[05:35:29] <scribe> So I believe this chart has to be re drawn with the notion of neighbor
[05:35:32] <scribe> selection. NEW SPEAKER: In which of these models?
[05:35:35] <scribe> Would this a apply? NEW SPEAKER: Yes. NEW SPEAKER:
[05:35:39] <scribe> No, I'm asking the question. Are you talking about the
[05:35:42] <scribe> super peer model or are you talking about the fully distributed
[05:35:45] <scribe> model or which one? NEW SPEAKER: I'm talking
[05:35:49] <scribe> xw the about the last two slides. With one is when you present
[05:35:52] <scribe> the cord, the D H T, okay. But that's only the first half of the
[05:35:58] <scribe> story. The second half, which is more important, after you
[05:36:02] <scribe> have done the rerouting, now you have to make the real tough
[05:36:08] <scribe> decision, and they are based on practical things, trans
[05:36:12] <scribe> sift and Internet fall, and how can do I select my neighbors. And this
[05:36:13] <scribe> story is not here.
[05:36:19] <scribe> After I select my neighbors, we have this interaction with
[05:36:24] <scribe> ice, which are my most important neighbors, which means I
[05:36:28] <scribe> really want to do the ice process. NEW SPEAKER: I think
[05:36:32] <scribe> what you're talking about, there are D H T, like somebody for
[05:36:36] <scribe> example, selects neighbors based in part, on
[05:36:39] <scribe> latency to that neighbor. NEW SPEAKER: Somebody else does
[05:36:45] <scribe> it as well. And I'm sorry, to complicate things, but the
[05:36:51] <scribe> circuitry is only one of them. So for example, somebody has
[05:36:54] <scribe> two Dee on him trees it has both tree and circle. Because
[05:36:58] <scribe> if I have the tree as well as circle, I can do multi cast and
[05:37:03] <scribe> I can do database searches. So, we have to go a little bit
[05:37:07] <scribe> more in depth. One. And the second is, I believe that
[05:37:14] <scribe> the notion of super is wrong. It's a confusing term. NEW SPEAKER:
[05:37:17] <scribe> Yes. We already talked, maybe the names for these are not
[05:37:21] <scribe> the best. NEW SPEAKER: Jonathan Rosenburg. To
[05:37:26] <scribe> answer Henry's question, ice algorithm has this thing
[05:37:31] <scribe> called regular selection that chosees, latency or favorite color or whatever you
[05:37:36] <scribe> want. It can specify, must use regular and must should be
[05:37:37] <scribe> applied as choice.
[05:37:43] <scribe> The one thing I also want to point out, you have to be careful
[05:37:49] <scribe> with ice because the issue of where is the turn and stun
[05:37:51] <scribe> server. If you're going to use turn, it still has to be a
[05:37:55] <scribe> northern point between the two peers, so you may
[05:37:58] <scribe> effectively still have super turn nodes. I have been
[05:38:02] <scribe> thinking a lot about it, for a long time in fact how one
[05:38:05] <scribe> could get around centralizing those. And I
[05:38:09] <scribe> haven't come up with a way to discover that. So I just want to be quite
[05:38:13] <scribe> careful. NEW SPEAKER: I've given it some thought and we can talk off line. NEW SPEAKER:
[05:38:18] <scribe> The last point, yes, there are reported cases of people
[05:38:23] <scribe> stealing allocated public address. I asked this question. And he
[05:38:27] <scribe> said, yes e, yes. People take for example, government IP addresses
[05:38:31] <scribe> and ports that are allocated for use on one of these huge D O T
[05:38:35] <scribe> networks, known not to be connected to public internet but
[05:38:41] <scribe> using public address. This is not a recommended practice. NEW SPEAKER:
[05:38:45] <scribe> There's, there are even more cases where people have stolen
[05:38:48] <scribe> addresses that actually are currently in use in the public space. NEW SPEAKER:
[05:38:54] <scribe> And so, again, ice theory, don't make any assumption and
[05:38:57] <scribe> that's an assumption that doesn't always hold. NEW SPEAKER: Philip, can
[05:39:00] <scribe> you wrap it up NEW SPEAKER: Into I think the one question
[05:39:04] <scribe> which I think would be interesting, here are two proposals.
[05:39:09] <scribe> Is there anybody who is going to, who wants to
[05:39:11] <scribe> advocate some different approach that we should look at? I
[05:39:14] <scribe> mean, there's are the ones that cup up on the mailing list.
[05:39:18] <scribe> Is there somebody who has something else that they think we should
[05:39:23] <scribe> look at? NEW SPEAKER: I believe you cannot make good selection based
[05:39:27] <scribe> on this representation, because we don't have discussed the whole
[05:39:30] <scribe> story about the neighbors selection. NEW SPEAKER: Yes,
[05:39:32] <scribe> I agree that this is, you know, there's more discussion,
[05:39:37] <scribe> and I do believe that there are some sort of ways of
[05:39:39] <scribe> hybrids between these approaches. I don't
[05:39:42] <scribe> think dash what I'm trying to, I think the point of this is
[05:39:46] <scribe> to try to say, is there some third totally different things that we should be
[05:39:48] <scribe> looking at. NEW SPEAKER: Maybe a better question to ask here
[05:39:52] <scribe> is, can I ask for a hum of, is there anybody who thinks we've
[05:39:55] <scribe> solved this or can we just say, we'll stop here, there's
[05:39:58] <scribe> still a lot of discussion but let's take this off to the
[05:40:01] <scribe> mailing list. I don't think anybody, I can ask, is there
[05:40:04] <scribe> anybody who will hum that thinks we can close this?
[05:40:07] <scribe> ( Silence. ) NEW SPEAKER: Then I propose we go on to
[05:40:11] <scribe> the next topic, we're already ten minutes over and we just
[05:40:13] <scribe> kind of go from there. Closing comment. NEW SPEAKER:
[05:40:20] <scribe> Okay. So, my name is something. There is an alternative
[05:40:26] <scribe> to ice. And so, I come from the host something working group and we
[05:40:30] <scribe> are doing some nat traverse Sal also there, which is kind of
[05:40:37] <scribe> nice, because you've got, you can globally address
[05:40:39] <scribe> both, nat devices. NEW SPEAKER: Which working group did
[05:40:42] <scribe> you say? NEW SPEAKER: Host identity. NEW SPEAKER:
[05:40:45] <scribe> Host identity. Okay. NEW SPEAKER: So I'm going to
[05:40:50] <scribe> finish here, and mention it on the mailing list. NEW SPEAKER:
[05:40:55] <scribe> That's very interesting. I have actually seen a number of
[05:40:58] <scribe> possible parallels with the host identity
[05:41:01] <scribe> work. And I would be very interested in talking with anybody
[05:41:04] <scribe> who is knowledgeable about the host identity protocol,
[05:41:08] <scribe> because I do think it has some relationship, some useful
[05:41:11] <scribe> parallels with the P to P SIP stuff. NEW SPEAKER:
[05:41:16] <scribe> Okay. The next topic we have is talking a bit about what
[05:41:21] <scribe> requirements for peer to peer SIP peer protocol might look
[05:41:48] <scribe> like. Johnson.
[05:42:03] <scribe> NEW SPEAKER: Okay. My name is Johnson, my presentation is
[05:42:04] <scribe> requirements for peer protocol.
[05:42:11] <scribe> Most people know that there was previous requirements drafts in
[05:42:19] <scribe> peer to peer SIP, and this was my draft as mostly dependent
[05:42:23] <scribe> from Sherman's draft, but we will be looking together more
[05:42:28] <scribe> quickly on next revision and I have re used some tags with
[05:42:29] <scribe> permission from the authors.
[05:42:35] <scribe> Let's talk about some basic requirements. I introduced
[05:42:41] <scribe> them one by one. Peer protocol should rely on a transport
[05:42:46] <scribe> mechanism which would guarantee reliable message delivery. There is
[05:42:51] <scribe> sure a the ratio of pay load to message size should be kept
[05:42:54] <scribe> as high as possible. Peer protocol must provide a few
[05:42:58] <scribe> primitive functions which are essential for most D H T
[05:43:03] <scribe> algorithms. They are join, leave, get, put, remove operations.
[05:43:09] <scribe> Peer protocol should provide routing function in the overlay.
[05:43:15] <scribe> Peer protocol should provide redundant storage function this the
[05:43:20] <scribe> overlay. Peer protocol should accommodate a few existing D H T
[05:43:27] <scribe> algorithms and at the same time should be extensible enough to
[05:43:32] <scribe> support support new D H T algorithms in the future. Peer protocol
[05:43:36] <scribe> should allow peers to communicate with each other by
[05:43:39] <scribe> traversing nates
[05:43:47] <scribe> The following two slides is provided by Bruce. And he delayed
[05:43:52] <scribe> ted me to present them. U D P TCP, the size of peer
[05:43:57] <scribe> message often are large, so it is hard to be fitted into one M
[05:44:05] <scribe> T U. But U D P good for nat traverse salary dueses loads
[05:44:06] <scribe> with more connections.
[05:44:10] <scribe> NEW SPEAKER: Philip Mathews here. I want to object a little.
[05:44:14] <scribe> I'm not sure that U D P necessarily, in some ways,
[05:44:18] <scribe> it's good for nat traverse Sal, but it's also bad in some
[05:44:25] <scribe> ways. NEW SPEAKER: You first obtain things that U D P
[05:44:30] <scribe> will have
[05:44:36] <scribe> NEW SPEAKER: So, my opinion, you are, according to stats, I've
[05:44:40] <scribe> seen, you are more likely to get a connection with U D P,
[05:44:44] <scribe> but the validate the problem with U D P is you have to send
[05:44:48] <scribe> keep a lives more often. With TCP, you're less likely to
[05:44:51] <scribe> get the connection, slightly less likely, but you don't have
[05:44:56] <scribe> to send keep alives as much. So the load is less. NEW SPEAKER:
[05:45:01] <scribe> This slide miraculously combines two of the most
[05:45:05] <scribe> stereo typical IETF discussion topics. Is this bin near rn
[05:45:09] <scribe> TCP. And I think this is, and I think, in the interest
[05:45:14] <scribe> of time, I don't think it's, I don't think this is a fair
[05:45:17] <scribe> representation of the trade offs and I'll leave it at that, and
[05:45:21] <scribe> I think we should simply, unless we want a full dmrejd discussion, we
[05:45:25] <scribe> should treat this as personal and unsubstantiated opinion of
[05:45:28] <scribe> one person and move on. Otherwise we'll spend the rest of the morning on
[05:45:31] <scribe> that particular topic, and it's, I don't think that this is
[05:45:34] <scribe> necessary to resolve at this point. NEW SPEAKER: Okay.
[05:45:39] <scribe> Good point. NEW SPEAKER: Can we, let's move on. NEW SPEAKER: To
[05:45:43] <scribe> fully complete the slides, so we can have all the debates, we
[05:45:48] <scribe> need A N S1 versus X M L. NEW SPEAKER: Okay. I
[05:45:50] <scribe> don't want to hear anymore about it. NEW SPEAKER:
[05:45:51] <scribe> (Several people talking.) NEW SPEAKER: Just for
[05:45:55] <scribe> clarification, the goal of this was to discuss open issues that
[05:45:58] <scribe> we need to decide in peer protocol, not present a conclusion.
[05:46:03] <scribe> I tried to list reasons why both U D P and TCP are good. NEW SPEAKER:
[05:46:05] --- Jabber-Wile has left
[05:46:06] <scribe> I disagree with you. NEW SPEAKER: I willfully admit, this
[05:46:10] <scribe> is not a complete list, and we do not have time for a
[05:46:15] <scribe> complete list, not problems, not to mention SIP. NEW SPEAKER:
[05:46:18] <scribe> Keith, you have, something really worth it to say on this
[05:46:22] <scribe> topic? I'd really like to get on. NEW SPEAKER:
[05:46:25] <scribe> Keith. I was just going to say, some of these questions,
[05:46:27] <scribe> you need to leave until the last part of the process. NEW SPEAKER:
[05:46:33] <scribe> Yes. NEW SPEAKER: Okay. Next slide. NEW SPEAKER:
[05:46:43] <scribe> There are some security requirements from Bruce. Need
[05:46:47] <scribe> certificates to authenticate all messages.
[05:46:51] <scribe> Distributed mechanism to distribute acquire
[05:46:57] <scribe> certificates. Resource registration need to be authenticated
[05:47:00] <scribe> by registering entity, not responsible peer.
[05:47:10] <scribe> In my draft, I have proposed some advanced requirements. NEW SPEAKER: Could
[05:47:14] <scribe> I ask you to move back a slide. NEW SPEAKER: Okay. NEW SPEAKER: Name? NEW SPEAKER:
[05:47:19] <scribe> I I would actually like to know the direction you're going
[05:47:22] <scribe> here, a solution and requirement. I think it would be easier
[05:47:27] <scribe> if you focus on the authenticate all messages as a requirement.
[05:47:31] <scribe> The particular choice of using certificates may or may not
[05:47:35] <scribe> make sense in each network. So I think you may want to separate
[05:47:36] <scribe> those out.
[05:47:41] <scribe> Also, as a broader comment since I happen to be at the Mike, on the
[05:47:46] <scribe> draft, I actually found the organizational principle of
[05:47:51] <scribe> comparing to non peer to peer SIP a distraction and not worth
[05:47:54] <scribe> it. If you started without that, and listed the
[05:47:57] <scribe> requirements you see in the protocol, without trying to do a
[05:48:00] <scribe> comparison to how some other protocol does them, you actually
[05:48:03] <scribe> would probably find it easier to focus on the requirements. I
[05:48:08] <scribe> agree with you that inter operability is a critical
[05:48:14] <scribe> requirement, but that shouldn't be an organizational guide for how
[05:48:15] <scribe> to put a requirements document together. NEW SPEAKER:
[05:48:21] <scribe> Okay. Fill lip Mathews here. I'm not sure what you mean by
[05:48:26] <scribe> the second point but if you mean what I think you mean, I think we
[05:48:29] <scribe> agreed that was going to be out of scope. We weren't going
[05:48:31] <scribe> to talk about how you acquire certificates. We just said there
[05:48:35] <scribe> was going to be some unspecified process for doing that. NEW SPEAKER: Right. NEW SPEAKER:
[05:48:40] <scribe> The second point is true, forgetting a copy, not for
[05:48:44] <scribe> originally generated. So if you want to authenticate with a
[05:48:47] <scribe> message that's signed, is the certificate always included m
[05:48:49] <scribe> the message or some way of requesting the certificate for that
[05:48:53] <scribe> entity from the URI. So (Several people talking.) NEW SPEAKER:
[05:48:57] <scribe> There is occasions. NEW SPEAKER: It's not creating a certificate.
[05:49:00] <scribe> It's a question. I should say credential. NEW SPEAKER: Yes. NEW SPEAKER:
[05:49:05] <scribe> If you have a credential object, you must have, it's not
[05:49:07] <scribe> how you create it, it's how you find it. NEW SPEAKER:
[05:49:15] <scribe> So, to ted's point, if we change this word and use the word
[05:49:18] <scribe> credential instead of certificate, I think people would be happy. NEW SPEAKER:
[05:49:23] <scribe> But isn't the second bullet point, it's not a requirement,
[05:49:24] <scribe> it's a possible solution, isn't that correct? NEW SPEAKER:
[05:49:27] <scribe> I think he's saying, if we're going to use a credential, that
[05:49:31] <scribe> you need a distributed way, if I give you a message that's
[05:49:35] <scribe> signed with my credential, there needs to be some distributed
[05:49:40] <scribe> way for you to go get what you need to verify it.
[05:49:43] <scribe> NEW SPEAKER: Okay. NEW SPEAKER: I don't think he
[05:49:48] <scribe> means distributed mechanism to issue. He means to get what you need
[05:49:51] <scribe> to verify. NEW SPEAKER: I got that. I guess -- NEW SPEAKER:
[05:49:53] <scribe> The other would be out of scope. NEW SPEAKER: Okay.
[05:49:57] <scribe> I'm not, I guess I'm not 100 percent sure that you have to
[05:50:00] <scribe> have that, but that's certainly one way to do it.
[05:50:08] <scribe> NEW SPEAKER: Cullen Jennings, I would like to pass on a message
[05:50:14] <scribe> that ek EKR would say if he was here. Except I can't say it fast
[05:50:18] <scribe> enough. Once we understood what the threat model is, we can
[05:50:20] <scribe> figure out the requirement. Authentication is not a
[05:50:23] <scribe> requirement. It's something we do to deal with a threat,
[05:50:27] <scribe> right. So, I think we need more work on this. But it will
[05:50:31] <scribe> just evolve along. NEW SPEAKER: Okay. NEW SPEAKER:
[05:50:39] <scribe> In my draft, I have proposed some advanced requirements. We
[05:50:42] <scribe> have some val ability, and there are two function
[05:50:46] <scribe> requirements, are used to address availability. One is neighbor
[05:50:51] <scribe> detection. Some remedial actions could be taken after peer's
[05:50:55] <scribe> failure is Dee tebt ted. The other one is rep indication. Peer protocol
[05:50:59] <scribe> should place several replicas into the overlay
[05:51:04] <scribe> and make the corresponding information available all the time. In
[05:51:08] <scribe> terms of routing efficiency, cache mechanism is proposed. By
[05:51:16] <scribe> using cache mechanism, hops which requests traversed are
[05:51:20] <scribe> shortend and the hook up becomes more. Thanks.
[05:51:26] <scribe> NEW SPEAKER: Do you have my slides?
[05:51:31] <scribe> NEW SPEAKER: We need the last slides.
[05:51:42] <scribe> Let's see.
[05:51:46] <scribe> NEW SPEAKER: Thanks. Okay. This is hopefully
[05:51:58] <scribe> extremely quick. Next, please. NEW SPEAKER: So
[05:52:02] <scribe> one of the things I just want to focus on, and I don't want to go through
[05:52:06] <scribe> this in detail, I just want to highlight things that the
[05:52:08] <scribe> requirement draft will have to cover I believe at some point.
[05:52:12] <scribe> Namely, once of the things that we've been dancing a roubd is
[05:52:16] <scribe> the type of data that the D H T stores. I think that's one of
[05:52:20] <scribe> the most crucial aspects of the design, because that drives
[05:52:24] <scribe> many other low level protocol decisions and I want to highlight
[05:52:27] <scribe> some questions, without making any stailts as
[05:52:30] <scribe> to what the it should be, but simply that we have to answer
[05:52:35] <scribe> the questions at some point. In particular, these also apply to both peer to peer as well
[05:52:39] <scribe> as if that's a separate protocol, the client peer protocol. For
[05:52:42] <scribe> example, we need to discuss as to whether supporting large
[05:52:46] <scribe> messages and large object is a requirement. I suspect there will be
[05:52:52] <scribe> essentially only two choices, 500 or less, meaning U D P M T U
[05:52:55] <scribe> size or infinity of whatever that means.
[05:53:01] <scribe> We need to decide as to whether data has a built in from a D H T
[05:53:06] <scribe> implementation or if some other overlay implementation soft
[05:53:08] <scribe> state model and I think that's been the general assumption,
[05:53:10] <scribe> although I'm not sure it's stated at this point.
[05:53:16] <scribe> We should probably require that refreshing data does not require
[05:53:21] <scribe> rewriting the data again. Particularly for data is large.
[05:53:26] <scribe> And do we want to support a model where the creator of data can
[05:53:32] <scribe> actually specify that the dat that should expire.
[05:53:36] <scribe> Should it live for ten years for example, or is this a policy which
[05:53:42] <scribe> needs to be part of a D H T configuration which also influences
[05:53:43] <scribe> protocol.
[05:53:50] <scribe> Do we need meta data? Is it
[05:53:54] <scribe> stored or more complicated. Might the data that we want to
[05:53:58] <scribe> keep for maintenance reasons as well as for generality. So
[05:54:01] <scribe> just as examples, content type, creation time. Et
[05:54:04] <scribe> cetera. I'm not arguing you need all of those. We just need
[05:54:06] <scribe> to think about e those. That's it.
[05:54:22] <scribe> NEW SPEAKER: Thanks. Philip. NEW SPEAKER: This
[05:54:25] <scribe> is a general procedural question, but to address to the
[05:54:29] <scribe> chairs, do the chairs, it seems to me to be useful to maybe put together
[05:54:34] <scribe> some sort of design team or something like that, to try to
[05:54:36] <scribe> work on a requirements document. NEW SPEAKER: Yes. NEW SPEAKER:
[05:54:39] <scribe> Or something like that. And how do we want to do this?
[05:54:42] <scribe> Are we just going to get individual authors to put together
[05:54:45] <scribe> something or try to send something together NEW SPEAKER:
[05:54:50] <scribe> Well, I think we'll take advice. I really would like to see some
[05:54:54] <scribe> drafts. And then I think a design team might be appropriate.
[05:55:02] <scribe> Rather than a design team now. I'll take
[05:55:05] <scribe> comments or suggestions. NEW SPEAKER: I think that would
[05:55:09] <scribe> be, to having two drafts efforts at least or
[05:55:12] <scribe> possibly more, one expired, and I had some
[05:55:16] <scribe> comments on on. And the one which he just presented a few minutes
[05:55:19] <scribe> ago. I think we have the first condition, but at some
[05:55:23] <scribe> point or another, it needs broader input and design team. NEW SPEAKER:
[05:55:27] <scribe> I'd like to see more list discussion on specifically
[05:55:31] <scribe> requirements, I'd like to see drafts and then I think a
[05:55:33] <scribe> design team is probably appropriate. NEW SPEAKER: I'm quite
[05:55:37] <scribe> frankly not sure that creating more drafts, and then kind of
[05:55:40] <scribe> trying to merge them is necessarily a good idea, simply
[05:55:44] <scribe> because if, I mean, each of us has different things that we
[05:55:48] <scribe> want to put in, but you can't just simply have, you're
[05:55:53] <scribe> attempted to write broader than you have to. So you end up
[05:55:55] <scribe> ditching a lot in order to make sense of --
[05:55:57] <scribe> NEW SPEAKER: Well, here's my thought. My thought is that
[05:56:03] <scribe> we have this use case, had a use case discussion. And use
[05:56:06] <scribe> cases tend to drive requirements. And I'd like to see the
[05:56:09] <scribe> people who developed the use cases to develop the requirements for
[05:56:14] <scribe> those use cases, and get them put together. And if we
[05:56:17] <scribe> don't do that with the draft, we can do it on e-mail and the
[05:56:21] <scribe> list, that's perfectly acceptable to me, but I'd like to see
[05:56:23] <scribe> them kind of come out, and then, you know, in the usual
[05:56:26] <scribe> way, we'll take the contributors and make them the design
[05:56:29] <scribe> team. NEW SPEAKER: Maybe some self organizing will work
[05:56:31] <scribe> out. NEW SPEAKER: Peer to peer. NEW SPEAKER: I
[05:56:35] <scribe> guess I'd like to say, yes, to that proposal. I think
[05:56:39] <scribe> that's what Spencer actually attempted to do with this charter which
[05:56:42] <scribe> unfortunately, he didn't get much feedback. And yes,
[05:56:44] <scribe> what I think you're saying is, let's work out the
[05:56:49] <scribe> requirements for a particular use case, you know, a number
[05:56:52] <scribe> of use cases and then try to see what the commonalty
[05:56:54] <scribe> points are. That was my point to you. NEW SPEAKER: Yes. NEW SPEAKER:
[05:56:58] <scribe> Okay. NEW SPEAKER: Just a little update on the use cases by
[05:57:03] <scribe> the way. Just before this meeting, the authors of that
[05:57:08] <scribe> plus now also including Spencer, have agreed to take some time and
[05:57:12] <scribe> attempt to iterate that and revive those drafts. So that work will be
[05:57:13] <scribe> going on.
[05:57:19] <scribe> NEW SPEAKER: But I mean, that document has some authors,
[05:57:23] <scribe> but a lot of those use cases came from other people. The
[05:57:30] <scribe> authors collected them into a document. The people who supply supplied
[05:57:33] <scribe> those use cases and are, you know, there are people in the room and people
[05:57:36] <scribe> on the mailing list who are, you know, have this picture in
[05:57:39] <scribe> mind of how they want to use this. If they could assist everybody by
[05:57:42] <scribe> putting out what they think the requirements to make that
[05:57:47] <scribe> particular use case work, I'm not, I don't necessarily
[05:57:50] <scribe> think the people who are responsible for
[05:57:54] <scribe> the use case document are responsible for all the documents that the use
[05:57:59] <scribe> cases are, they com pid the document that the people put out. NEW SPEAKER:
[05:58:03] <scribe> Okay. Moving onto this discussion about the P to P SIP client
[05:58:06] <scribe> discussion, who wants to actually come up and present these
[05:58:12] <scribe> slides, Spencer are you going do do it or is Dean doing it NEW SPEAKER:
[05:58:15] <scribe> Did we decide? NEW SPEAKER: You can do it. NEW SPEAKER:
[05:58:24] <scribe> I guess Spencer is snoochlt do we lose our scribe?
[05:58:26] <scribe> NEW SPEAKER: We have another. NEW SPEAKER: Dean,
[05:58:30] <scribe> can take notes in case of Spencer, just for this little bit. NEW SPEAKER:
[05:58:34] <scribe> Jabber describe scribe or staking notes. NEW SPEAKER:
[05:58:38] <scribe> Taking notes.
[05:58:47] <scribe> NEW SPEAKER: This is interesting, because Spencer hasn't
[05:58:51] <scribe> seen this version of the slides. NEW SPEAKER: Good
[05:59:24] <scribe> luck, here you go. NEW SPEAKER:
[05:59:29] <scribe> NEW SPEAKER: Okay. Are we good? Okay. These are
[05:59:37] <scribe> slides that we discussed with Henning and with Dean. Just
[05:59:40] <scribe> want to say, basically, what clients are.
[05:59:44] <scribe> That they are, you know, this is from the terminology
[05:59:52] <scribe> concepts draft. And I wanted to say, basically, pointing
[05:59:56] <scribe> out the bottom bullet, which this is all in one paragraph in
[06:00:01] <scribe> the definition, but the last bullet I think is the important one, which
[06:00:04] <scribe> is we're not talking about a SIP UAC when we say client here.
[06:00:08] <scribe> We talked about changing the word to avoid that confusion.
[06:00:11] <scribe> We talked about what clients are not. They're
[06:00:16] <scribe> not the equivalents of peer of a super peer peer
[06:00:20] <scribe> architecture, at least not in the concepts draft as it
[06:00:24] <scribe> appears today. It's not the peer behind nats, in the
[06:00:26] <scribe> concepts draft today.
[06:00:36] <scribe> This is where they are in the architecture today. So
[06:00:44] <scribe> basically, so you have the proxy here, and the, a client which may
[06:00:49] <scribe> also be co-located with the U A over here. And there's a client
[06:00:51] <scribe> protocol, so it's basically where they are in the
[06:00:54] <scribe> architecture. NEW SPEAKER: I'd just like to point out
[06:00:58] <scribe> that that diagram actually assumes one particular model of a
[06:01:01] <scribe> client and I don't think it's, it handless
[06:01:06] <scribe> all of the ones we could propose. And also, I want to say that
[06:01:08] <scribe> the name for that peer, whether it's proxy NEW SPEAKER:
[06:01:09] <scribe> Yes, yes. (Several people talking.)
[06:01:14] <scribe> NEW SPEAKER: Actually, we, I wish we could get the picture up
[06:01:18] <scribe> there. Maybe we can do that at another time.
[06:01:23] <scribe> So, basically, what problem are we trying to solve? Do we
[06:01:26] <scribe> need the clients for overlay scaleability. If
[06:01:31] <scribe> we agreed on use cases that would help a lot to know that. Are
[06:01:36] <scribe> they different from SIP U As do they speak vanilla SIP or something else.
[06:01:40] <scribe> How do they interact with distributed database and how do they
[06:01:41] <scribe> route SIP requests?
[06:01:44] <scribe> You have the modes of operation, with interaction with the
[06:01:51] <scribe> database. This actually turned out to be a quadrant diagram
[06:01:53] <scribe> with a 5 quadrants, so we're showing it
[06:01:55] <scribe> this way. But basically, you can interact with the
[06:01:59] <scribe> database in a number of ways, either directly or on
[06:02:02] <scribe> through client protocol input or treat the overlay, the entire
[06:02:04] <scribe> overlay as a SIP registrar.
[06:02:09] <scribe> You can route SIP requests retrieving the contact from the
[06:02:15] <scribe> overlay, and sending requests to that contact or route. Or you
[06:02:19] <scribe> can use the relatively fixed peer in the overlay as an outbound
[06:02:23] <scribe> proxy so basically you have the opportunity to use either redirects or
[06:02:24] <scribe> proxy forwarding.
[06:02:33] <scribe> The idea, we've had an idea that was to store data on a
[06:02:36] <scribe> client. That was made on the list. Somebody suggested that
[06:02:40] <scribe> this could be coupled with the client rolt in the client
[06:02:43] <scribe> protocol. We're proposing to keep that separate and and
[06:02:46] <scribe> don't con found the discussion and defer additional discussion
[06:02:49] <scribe> about storage nodes until somebody comes up with a
[06:02:52] <scribe> credible use case. Here's the picture. I think this
[06:03:01] <scribe> is the most helpful picture I've been able to come up with. So
[06:03:06] <scribe> basically, you have an overlay here with six peers
[06:03:10] <scribe> on it. And that you have some clients over
[06:03:14] <scribe> here, that we are imagining that there's some client adapter that's
[06:03:19] <scribe> associated with a peer that speaks the peer to peer SIP client
[06:03:21] <scribe> protocol. We're imagining other peers that are
[06:03:26] <scribe> located together with the SIP proxy function. That support
[06:03:30] <scribe> clients through SIP, and we're
[06:03:34] <scribe> visualizing there may be peers that have both
[06:03:38] <scribe> kinds of adapters, have an adapter and proxy that speak both
[06:03:39] <scribe> protocols.
[06:03:46] <scribe> So, there were the basic questions that we wanted to talk
[06:03:49] <scribe> about during the discussion. Do we all agree, when I say
[06:03:55] <scribe> these cases, do we agree they're all desirable? Do we
[06:03:58] <scribe> think that all peers will be able to do any of these things?
[06:04:01] <scribe> Do we think that all peers are going to be doing more
[06:04:05] <scribe> than one of these things at the same time? And the ever popular,
[06:04:11] <scribe> where are we, at the end of the discussion?
[06:04:17] <scribe> NEW SPEAKER: Clarification, when you're saying here, do
[06:04:20] <scribe> we agree that all these cases are Dee ire rabl, you mean
[06:04:26] <scribe> being able to have both protocols running
[06:04:28] <scribe> simultaneously? NEW SPEAKER: I'm saying, do we
[06:04:31] <scribe> agree that we want to do this, even, because NEW SPEAKER:
[06:04:33] <scribe> I understand. NEW SPEAKER: Do we agree that we're
[06:04:37] <scribe> going to be doing this. I think the answer is yes. Then do we
[06:04:38] <scribe> agree that this is interesting?
[06:04:44] <scribe> NEW SPEAKER: Philip Mathews the again. In this whole discussion
[06:04:47] <scribe> of clients, I think that we perhaps have been
[06:04:50] <scribe> approaching this the wrong way. NEW SPEAKER: I'm
[06:04:53] <scribe> almost sure that's true, Philip. NEW SPEAKER: In the
[06:04:57] <scribe> sense that I think we've been talking about sort of
[06:05:01] <scribe> mechanisms, but we haven't been talking about sort of the
[06:05:05] <scribe> more fundamental question of what are we trying to achieve that's having
[06:05:08] <scribe> something different from a peer. Why do we need this?
[06:05:10] <scribe> This has always been my problem, to understand this. You
[06:05:14] <scribe> know, people suggested various ways
[06:05:17] <scribe> clients can operate rate. But the question is, why do we
[06:05:18] <scribe> want this?
[06:05:22] <scribe> So I think we should try to answer that question first. And
[06:05:25] <scribe> once we understand why we want a client, that will clearly tell
[06:05:29] <scribe> us what its properties are. NEW SPEAKER: I mean, I
[06:05:31] <scribe> think this is the critical thing. We do not have agreed use
[06:05:36] <scribe> cases. We have a set of use cases that we have discussed as an individual draft before we
[06:05:42] <scribe> were a working group. So, I think that's a critical point. NEW SPEAKER:
[06:05:48] <scribe> Brian Rosen. I understand why people want to take normal SIP
[06:05:52] <scribe> clients and connect them up. And I think that we ought to cater
[06:05:55] <scribe> for that, but I think that we ought to not be willing to say
[06:06:00] <scribe> we're going to compromise everything else in order to make that
[06:06:04] <scribe> look that work wonderfully. I don't understand the P to P
[06:06:08] <scribe> SIP client. I don't think we want it. I think as long as
[06:06:11] <scribe> we've agreed that some peers are behind nats and all
[06:06:14] <scribe> that other stuff, we get through those, those are still
[06:06:18] <scribe> peers, I just would like to get rid of them. NEW SPEAKER:
[06:06:23] <scribe> So basically summarizing, we're talking about keep this one, get
[06:06:24] <scribe> rid of this one. NEW SPEAKER: Yes. NEW SPEAKER:
[06:06:28] <scribe> And korz correspondingly, get rid of that one. NEW SPEAKER:
[06:06:33] <scribe> Jonathan Rosenburg. I don't see how you get rid of anything
[06:06:39] --- otmar has joined
[06:06:40] <scribe> until you answer the question of what problems are we trying to
[06:06:42] <scribe> solve. The problem is, most of these are not the
[06:06:44] <scribe> requirements we're trying to solve. You've only got one
[06:06:48] <scribe> thing on the list that's a requirement. Do we need this for
[06:06:51] <scribe> overlay scaleability. That may be the requirement. NEW SPEAKER:
[06:06:54] <scribe> Yes. NEW SPEAKER: What I thought the requirement
[06:06:59] <scribe> was, have entities in the architecture that were not able
[06:07:04] <scribe> to implement P to P, and that has several variations, one, they don't want
[06:07:07] <scribe> to implement the protocol at all. So we want to support
[06:07:10] <scribe> regular SIP clients, peer to peer network. That could be a
[06:07:12] <scribe> requirement. Or it could be a requirement that one of the
[06:07:15] <scribe> entities that have a new protocol, but we don't want them to
[06:07:18] <scribe> have to store any information or otherwise participate in the routing.
[06:07:20] <scribe> Those are different requirements. NEW SPEAKER: Right. NEW SPEAKER:
[06:07:24] <scribe> I think before you really do much else, you really better as
[06:07:26] <scribe> a group answer whether that's the issue or it's something else. NEW SPEAKER:
[06:07:28] <scribe> Yes, I agree. NEW SPEAKER: Philip? NEW SPEAKER:
[06:07:34] <scribe> So, my opinion is, that we do want to be able to handle
[06:07:39] <scribe> sort of, whatever you want to call it, existing SIP U As, want to
[06:07:42] <scribe> be able to interact there. So if you go to your diagram,
[06:07:45] <scribe> the middle example, and personally, I don't want to call that
[06:07:50] <scribe> thing over there a client. I think -- NEW SPEAKER: At that
[06:07:53] <scribe> point, it's a SIP U A. NEW SPEAKER: It's a SIP U A.
[06:07:55] <scribe> And the standard SIP. Okay. NEW SPEAKER: Yes. NEW SPEAKER:
[06:07:59] <scribe> And so I think, in my opinion, the, a client is
[06:08:02] <scribe> something that's not that, but it's something more than
[06:08:05] <scribe> that, but less than a peer. NEW SPEAKER: Agreed. NEW SPEAKER:
[06:08:08] <scribe> Okay. And the question is then, you know, what is it? NEW SPEAKER:
[06:08:12] <scribe> Okay. NEW SPEAKER: It's not a proxy
[06:08:15] <scribe> either bishtion by the way. NEW SPEAKER: Really,
[06:08:18] <scribe> okay. NEW SPEAKER: Proxy registrar I think it is. NEW SPEAKER:
[06:08:23] <scribe> Yes. So good-bye. NEW SPEAKER: All right. Fine.
[06:08:29] <scribe> Okay. Yes. NEW SPEAKER: Okay. Let me keep you at
[06:08:32] <scribe> the mooik for just a second. So, basically, you're
[06:08:35] <scribe> saying, we need to come up with a list of the
[06:08:38] <scribe> reasons we need to do this, when you wouldn't be be doing
[06:08:42] <scribe> this, and you wouldn't be doing this. Basically. So, you
[06:08:47] <scribe> know, so basically, why are we doing this? I agree, yes.
[06:08:51] <scribe> NEW SPEAKER: Allan Johnson, I agree with Jonathan that
[06:08:56] <scribe> the things he mentioned are the real requirements on the client
[06:08:59] <scribe> protocol. I think it's way too early to be throwing out
[06:09:02] <scribe> clients at this stage. And I think one of the main reasons that
[06:09:07] <scribe> we need it is for devices that have batteries, and if
[06:09:10] <scribe> we want them to be able to participate and get the benefits of the
[06:09:12] <scribe> overlay, then they basically can't do peers, because
[06:09:17] <scribe> if they do the keep a lives, your batteries will be
[06:09:20] <scribe> out within an hour. Basically unusable. Also, I don't
[06:09:25] <scribe> think that the rirlts of what the message
[06:09:28] <scribe> requirements in the nat protocol are. It's basically about
[06:09:30] <scribe> put and get. And I don't know what method you should use to
[06:09:35] <scribe> do a put and get, using SIP. NEW SPEAKER: We don't
[06:09:38] <scribe> know that on the peer protocol either, do we?
[06:09:42] <scribe> NEW SPEAKER: Spencer has made an excellent chart that I
[06:09:45] <scribe> think is very valuable for various user
[06:09:51] <scribe> scenarios that have accompanied this chart, to enforce what
[06:09:55] <scribe> Allan just said, just take an example of the mobile device, where
[06:10:00] <scribe> because of the battery, you have all kinds of constraints.
[06:10:06] <scribe> Yes, you want to act as SIP user agent, but you also want to do
[06:10:11] <scribe> some things with the D H T, so you need the, a client
[06:10:14] <scribe> protocol, definitely need it, and by the way, I'm sorry
[06:10:18] <scribe> I'm out of scope, but you want to do more than SIP location.
[06:10:22] <scribe> Once you have the mobile device. You have to have some other
[06:10:27] <scribe> functions, that's the reason why the client protocol may prove to
[06:10:31] <scribe> be not only critical, but extremely complex, and Brian, I'm
[06:10:36] <scribe> sorry, we have here disagreement. And so, that's my idea. NEW SPEAKER:
[06:10:38] <scribe> Cool. We'll Duke it out on the list.
[06:10:43] <scribe> NEW SPEAKER: Yes, so Jonathan Rosenburg, I think put
[06:10:47] <scribe> get, what Allan said, I'm going to disagree with that. I don't
[06:10:50] <scribe> think that works. What is it you're going to get? I'm suggesting
[06:10:53] <scribe> that, this this architecture, you got what you think, which
[06:10:57] <scribe> is the IP address and the port of the client you want to
[06:11:02] <scribe> connect to. The nat traverse Sal problem whether come up. In
[06:11:05] <scribe> reality, you have to do all these connection manage ments and
[06:11:09] <scribe> keep a lives, and all the stuff the peer has to do
[06:11:12] <scribe> to make it work. However, instead of getting, just send an
[06:11:17] <scribe> invite, the SIP proxy piece would do what it needs to do,
[06:11:20] <scribe> grab that thing to presumably a peer that was also a U A or a
[06:11:24] <scribe> SIP proxy connected to a client and it would work. So I don't,
[06:11:29] <scribe> again, I think you have to step back and really understand
[06:11:32] <scribe> what is the constraints you're trying to
[06:11:35] <scribe> solve here, to understand what is the right protocol. NEW SPEAKER:
[06:11:38] <scribe> I'm going to expand that a little and I'll probably guess this
[06:11:43] <scribe> is what Henry is coming up for too. But what is it that you want to be
[06:11:46] <scribe> getting and putting, other than location information? And what are you
[06:11:50] <scribe> trying to do here? And dash NEW SPEAKER: I put myself
[06:11:53] <scribe> at the head of the list, at the back of the list, because he was up
[06:11:55] <scribe> there and we have no chairs. NEW SPEAKER: Very short.
[06:12:01] <scribe> I want to find all the Rosenburgs in
[06:12:05] <scribe> Prague and I cannot do this in SIP proxy. So there are more
[06:12:09] <scribe> functions in SIP proxy. Yes, the SIP proxy is the basic,
[06:12:12] <scribe> it's in scope, but to have a real service, I have to have
[06:12:16] <scribe> some other functions that go beyond what the SIP proxy does.
[06:12:20] <scribe> NEW SPEAKER: Speaking as an individual, not as a chair,
[06:12:25] <scribe> what I would like to see, on all of these is, like a worked
[06:12:28] <scribe> out use case with the subtle requirements. I don't
[06:12:30] <scribe> understand what you're trying to accomplish.
[06:12:36] <scribe> Specifically, you talked about having a device with limited
[06:12:41] <scribe> resources, having some kind of partial participation in the D
[06:12:45] <scribe> H T or the overlay, without being the full member peer.
[06:12:48] <scribe> Okay. I sort of understand that, but please, work that out
[06:12:52] <scribe> for me. Tell me what that means, what you are trying to accomplish,
[06:12:57] <scribe> what you are, you know, don't have to do, so that we can figure out
[06:13:00] <scribe> what the requirements are and figure out whether any of this
[06:13:03] <scribe> makes any sense. NEW SPEAKER: I'm going to, Philip
[06:13:08] <scribe> Mathews. ip going to second with Brian and say that those
[06:13:11] <scribe> people who want clients, should you know,
[06:13:15] <scribe> between now and Chicago, submit a draft describing what the
[06:13:19] <scribe> client is, and you know, the requirement, why they think they
[06:13:23] <scribe> need it, what the requirements are there. And if there
[06:13:27] <scribe> aren't any credible ones by Chicago, we say
[06:13:30] <scribe> clients go away. But if there are, we continue on
[06:13:32] <scribe> the discussion. NEW SPEAKER: That's a good idea. (Several people talking.) NEW SPEAKER:
[06:13:34] <scribe> Stop worrying about them. Yes. NEW SPEAKER:
[06:13:38] <scribe> Jonathan Rosenburg, they don't have to go away. If we choose
[06:13:40] <scribe> this option with SIP proxy. (Several people talking.) NEW SPEAKER:
[06:13:43] <scribe> Other than SIP U A. NEW SPEAKER: But the main thing, you
[06:13:46] <scribe> know, to respond to what Henry said, which was I was
[06:13:49] <scribe> surprised, he asked for a client protocol that didn't search
[06:13:56] <scribe> for Rosenburg's err whatever, at least the scope of the work is
[06:14:00] <scribe> limited to not just making calls. Are we doing searches
[06:14:02] <scribe> through this? NEW SPEAKER: Not with this charter. NEW SPEAKER:
[06:14:05] <scribe> I think that's a great idea, and I think what we want sto
[06:14:09] <scribe> doshtion I mean, putting in there and saying we need a client
[06:14:12] <scribe> protocol to find location information, what do we need beyond
[06:14:16] <scribe> what we could do with some other mechanism, like SIP in this case?
[06:14:22] <scribe> Beyond just the finding location. NEW SPEAKER: I
[06:14:26] <scribe> really like this notion that given the picture and layout,
[06:14:30] <scribe> and the basic of all that stuff, is that we have to use
[06:14:36] <scribe> different attachments behind it. This could be server,
[06:14:40] <scribe> client use, and therefore the notion is good. But
[06:14:47] <scribe> definitely, you cannot complete this notion, but the notion
[06:14:51] <scribe> is perfect, to have a starting point to continue. NEW SPEAKER:
[06:14:54] <scribe> Well, NEW SPEAKER: Can we agree on that? NEW SPEAKER:
[06:14:58] <scribe> No. I think that, what I believe the circumstances, I think
[06:15:01] <scribe> we pretty much have a clear picture of where we want to go with
[06:15:05] <scribe> this. I think we're agreeing, we want to be able to
[06:15:10] <scribe> connect to SIP U A. To a peer, with some box that
[06:15:12] <scribe> connects it. I think that, I mean, I don't know that I
[06:15:17] <scribe> need to hold a hum. I think that's just plain clear. Do
[06:15:19] <scribe> you want me to hold a hum. NEW SPEAKER: Yes. (Several people
[06:15:22] <scribe> talking.) NEW SPEAKER: We'll do that. Before we,
[06:15:23] <scribe> we'll see whether everybody oh
[06:15:25] <scribe> R agrees with that. I think there's a discussion.
[06:15:30] <scribe> There are people who think absolutely we need something else.
[06:15:33] <scribe> And people are saying, I don't know what that something else would be.
[06:15:36] <scribe> What I'm asking, people who think we need something other
[06:15:40] <scribe> than a SIP U A connected to a peer by some box. NEW SPEAKER: Let's
[06:15:44] <scribe> do the first question. Let's find out those who want standard ones
[06:15:45] <scribe> first. NEW SPEAKER: We'll do that. NEW SPEAKER:
[06:15:48] <scribe> I'd like to have one hum that passes this this presentation. NEW SPEAKER:
[06:15:52] <scribe> Right, right. I understand. NEW SPEAKER: So, but what
[06:15:56] <scribe> happens after that is, if we need something beyond that,
[06:16:00] <scribe> then we need a better, a use case. We need a worked out use
[06:16:03] <scribe> case, what it is you're trying to accomplish, that won't be
[06:16:06] <scribe> accomplished with the other things we agreed to do. NEW SPEAKER:
[06:16:12] <scribe> Right now, everything is fine with SIP. If somebody
[06:16:16] <scribe> wants a client that re assembles a drawing board or movie
[06:16:18] <scribe> camera. NEW SPEAKER: Okay. But if we're going to
[06:16:22] <scribe> cover it with this in karn nation of the charter, get the use case out
[06:16:25] <scribe> there. NEW SPEAKER: Okay. NEW SPEAKER: So,
[06:16:29] <scribe> Spencer asked a reasonable question, Philip brings up the
[06:16:33] <scribe> point, I'd like to have a hum for people who believe that,
[06:16:36] <scribe> as part of the effort that we're doing with this iteration of the
[06:16:40] <scribe> charter, we include the case, the middle piece of the
[06:16:43] <scribe> diagram that's up there. A peer connecting to some box.
[06:16:47] <scribe> It may not be a SIP proxy. Jonathan wants to argue
[06:16:49] <scribe> about exactly what it is, but it's something that
[06:16:55] <scribe> connects to an existing SIP something. Okay. A SIP U A.
[06:16:58] <scribe> Can I have a hum for those in favor of doing that? ( Humming.)
[06:17:04] <scribe> And can I have a hum for people who do not think that is
[06:17:06] <scribe> something we ought to be doing here.
[06:17:08] <scribe> ( Silence. ) NEW SPEAKER: All right. So you got
[06:17:10] <scribe> it. Successful hum. NEW SPEAKER: Good job. Thank you.
[06:17:13] <scribe> NEW SPEAKER: Queer going to verify this on the list. NEW SPEAKER:
[06:17:17] <scribe> Absolutely, all decisions like this are taken on the list.
[06:17:20] <scribe> Nothing is definitive coming out of the meeting. It's always
[06:17:22] <scribe> taken to the list. NEW SPEAKER: Cool. Did you want
[06:17:25] <scribe> to do the other one? NEW SPEAKER: What, do you want to go
[06:17:27] <scribe> beyond that? NEW SPEAKER: Yes. NEW SPEAKER: Are
[06:17:29] <scribe> you ready (Several people talking.) NEW SPEAKER: No.
[06:17:32] <scribe> Well. NEW SPEAKER: I want list discussion and/or drafts for
[06:17:34] <scribe> Chicago. We'll hold that discussion in Chicago. NEW SPEAKER:
[06:17:37] <scribe> Sounds fair. NEW SPEAKER: I'd like to have a
[06:17:40] <scribe> hum just to see who should go talk to each other. NEW SPEAKER:
[06:17:43] <scribe> That was, fine. NEW SPEAKER: This is the birds of a
[06:17:46] <scribe> feather discussion. Those who think there are more
[06:17:49] <scribe> interesting things to do raise your hands, other
[06:17:53] <scribe> things to do beyond the SIP connection, raise your hands
[06:17:56] <scribe> just so that other people who are raising their hands
[06:18:00] <scribe> can see who else they should talk to. Raise your hand if you
[06:18:02] <scribe> think there's something else to be done beyond. There's a
[06:18:06] <scribe> whole bunch of hands, everybody recognize whose got
[06:18:06] <scribe> their hands up.
[06:18:11] <scribe> All right. You guys ought to maybe get together and see what you can come up
[06:18:13] <scribe> with. NEW SPEAKER: That would be lovely.
[06:18:20] <scribe> NEW SPEAKER: Okay. I think we're done, unless there
[06:18:27] <scribe> are final topics? We have not much. Thank you very much.
[06:18:30] <scribe> Blue sheets, anybody that did not sign the blue sheets, they're
[06:18:39] --- dgtlsoul has left
[06:19:16] --- csp has left
[06:19:19] --- enrico has left: Logged out
[06:19:20] <scribe> both up here. And I have them.
[06:19:20] --- scribe has left
[06:19:23] --- frodek has left: Replaced by new connection
[06:19:41] --- hbaosiy has left
[06:19:54] --- otmar has left
[06:19:56] --- guido has left
[06:20:27] --- renee has left
[06:21:02] --- hb47713 has left
[06:21:21] --- marc.bailly has left
[06:22:30] --- isudo has left
[06:24:11] --- rjaksa has left
[06:25:37] --- JeffH has left: Logged out
[06:36:55] --- dku has left
[06:37:31] --- bhoeneis has left: Replaced by new connection
[06:39:03] --- dku has joined
[06:39:28] --- dku has left
[06:47:32] --- jgre has left
[07:47:55] --- isudo has joined
[07:58:16] --- isudo has left
[10:42:12] --- LOGGING STARTED