[03:15:24] --- rpelletier has joined
[03:15:35] --- rpelletier has left
[03:23:44] --- renee has joined
[03:42:45] --- renee has left
[03:45:54] --- renee has joined
[03:52:32] --- mw has joined
[03:53:14] --- scribe has joined
[03:56:33] <scribe> IETF SIPPING session, March 19 2007
[03:58:13] --- mw has left
[03:58:19] --- RjS has joined
[03:58:59] --- marc willekens has joined
[04:00:42] --- marc willekens has left
[04:01:33] --- mwi has joined
[04:02:03] --- mwi has left
[04:02:07] --- tsavo_work@jabber.org/Meebo has joined
[04:02:14] --- tsavo_work@jabber.org/Meebo has left
[04:02:47] --- spencerdawkins has joined
[04:04:15] <scribe> NEW SPEAKER: All right. Folks, we started circulating the blue
[04:04:18] <scribe> sheets and we're going to get started, and this is the
[04:04:26] <scribe> SIPPING working group meeting. Here's the usual note well
[04:04:27] --- csp has joined
[04:04:31] <scribe> statement, and any statements you make in the meeting, the
[04:04:33] <scribe> IP R policies apply.
[04:04:37] <scribe> All right. So we need two note takers. Just to
[04:04:39] <scribe> make sure we get notes for this session.
[04:04:52] <scribe> We can't get started without note takers.
[04:05:01] <scribe> Okay. Our official note taker for Spence ser. We still
[04:05:07] <scribe> need a back up in case our machine crashes. Okay. Tom, thanks.
[04:05:11] <scribe> For this session, we're dwoing an experiment with the jab better and we're
[04:05:17] <scribe> using Arnoud's transcriptionist to stream to the jabber
[04:05:20] <scribe> session. So we still need somebody to moderate. So dp
[04:05:22] <scribe> anybody has questions, you can do that from there. All
[04:05:25] <scribe> right. And I just want to highlight that the Friday morning
[04:05:28] <scribe> session, we're on again for Friday morning. And for
[04:05:33] <scribe> SIPPING ends at 10:30. And we'll be handing over that last
[04:05:36] <scribe> hour of our slot to eeecrit
[04:05:39] <scribe> It was great difficulty scheduling all the working groups
[04:05:43] <scribe> because of all the conflicts and this is how we worked this one
[04:05:44] <scribe> out.
[04:05:47] <scribe> And just to clarify, we do have the M P three
[04:05:53] <scribe> streaming so make sure to use the microphone to make
[04:05:57] <scribe> comments and make sure the wireless is not in ad hoc mode. All
[04:06:00] --- dmalas has joined
[04:06:01] <scribe> right. And I just want to highlight the supplementary web
[04:06:04] <scribe> page. Again, what we're keeping up there now is basically
[04:06:08] <scribe> our work group review process, to track the documents and there
[04:06:12] <scribe> are spread sheets out there that are updated usually about monthly.
[04:06:15] <scribe> We fell behind after the holidays. But this is really important, because this
[04:06:19] <scribe> is how we are tracking all of our working group
[04:06:21] <scribe> deliverables. And it's important that the document to be
[04:06:24] <scribe> aware of the information in there, in terms of dates and
[04:06:28] <scribe> expectations for next versions of documents. As well, this
[04:06:32] <scribe> information is available and other S D Os are actually using
[04:06:34] <scribe> this to track their dependencies.
[04:06:37] <scribe> All right. So the good news is the charter that we've been talking
[04:06:41] <scribe> about for the past, you know, 9 months for a year was
[04:06:43] <scribe> proofd, so I'm just going to fly through this.
[04:06:46] <scribe> We now have another set of updates to make to the charter.
[04:06:47] --- frodek has joined
[04:06:51] <scribe> And that's all the red there. Some of the stuff is done,
[04:06:54] <scribe> but we're making the update because we completed milestones, which
[04:06:58] <scribe> is a good thing. About half of them are changing milestones.
[04:07:04] <scribe> So, you know, slipping months here and there. And some
[04:07:08] <scribe> things I have highlighted. For example, the last item, has
[04:07:13] <scribe> a dependency on ice. We've been pushinging that forward until ice
[04:07:17] <scribe> is completed. All right. And then I've got the 4th from the
[04:07:17] --- pelletier has joined
[04:07:20] <scribe> bottom, consent based communications in SIP,
[04:07:23] <scribe> actually had a goof in the last update to the charter,
[04:07:28] <scribe> because we had three documents in SIPPING. One of them we shipped over to SIP
[04:07:32] <scribe> and I inadvertently deleted the entire thing and so we have to
[04:07:36] <scribe> add that back in. But those documents are almost done.
[04:07:39] --- ttfr has joined
[04:07:40] <scribe> Next charter, and these are just more updates here, just changing dates.
[04:07:44] <scribe> But again, some of them we actually kept the same and per
[04:07:48] <scribe> Gonzalo's comment on the list, we put some of the documents
[04:07:52] <scribe> later, as far as when we're g going to get to them. So this takes
[04:07:55] <scribe> us pretty much through the end of this year. And we'll post
[04:07:57] --- hejingtong has joined
[04:08:00] <scribe> this on the list. And then we need to support it to the A D for
[04:08:04] <scribe> approval. So feedback on this and the realisticness of the
[04:08:08] <scribe> dates would be appreciated. I have gotten a reality check here and
[04:08:12] <scribe> expanded, added more buffer, between when working group
[04:08:15] <scribe> last call completes and IESG and that's one of the things.
[04:08:15] <scribe> Okay.
[04:08:17] --- rohan has joined
[04:08:21] <scribe> So we've had one, RFC published. Go ahead.
[04:08:32] <scribe> NEW SPEAKER: It might be kind of generally helpful to have
[04:08:34] <RjS> (Henning)
[04:08:38] <scribe> a generic time lines in, as in working group last
[04:08:44] <scribe> call, X two I S G, X plus three so we can simply note the
[04:08:46] <scribe> operational -- NEW SPEAKER: Right, that's exactly what I
[04:08:49] <scribe> have. iingts generally, although I have to be careful,
[04:08:53] <scribe> because we try, at this point I'm trying to limit it so I've got
[04:08:57] <scribe> no more than two items e going to the A D in a single month.
[04:08:59] --- cgn has joined
[04:09:00] <scribe> Just from that perspective. Yes. NEW SPEAKER: Just
[04:09:02] <scribe> document it. That's all. sdmoo okay. I understand.
[04:09:06] <scribe> Right. NEW SPEAKER: We have, the last few minutes
[04:09:08] <scribe> this the session is devoted to discussion like that. NEW SPEAKER:
[04:09:11] <scribe> Right. NEW SPEAKER: So let's discuss it there. NEW SPEAKER: All
[04:09:18] <scribe> right. Thanks and we've had one RFC published since IETF
[04:09:20] --- ysuzuki has joined
[04:09:24] <scribe> 6.7. And we've got three in the RFC editor queue and the newer
[04:09:28] <scribe> one is in the queue since the last IETF. And the same for
[04:09:33] <scribe> post publication request. The last two are the new ones
[04:09:35] <scribe> added to the list since the last IETF.
[04:09:42] <scribe> NEW SPEAKER: Jonathan rose even bering this
[04:09:44] <scribe> one is going to need changes. NEW SPEAKER: All right.
[04:09:52] <scribe> Okay. Okay. NEW SPEAKER: We were talking br
[04:09:56] <scribe> NEW SPEAKER: You're right, I still carry that error
[04:09:57] <scribe> forward. Thank you, Keith.
[04:10:06] --- Jim Martin has joined
[04:10:08] <scribe> NEW SPEAKER: It's right in the database.
[04:10:14] --- agallant has joined
[04:10:16] <scribe> NEW SPEAKER: Okay. Then we've got several that completed
[04:10:19] <scribe> working group last call and they're in the processing stages of
[04:10:23] <scribe> making sure, going back to the reviewers, and making sure the
[04:10:29] <scribe> chairs will do the write ups. And the service
[04:10:34] <scribe> example, and any additions, so these are ones ones, that
[04:10:37] <scribe> speak now or forever hold your piece sort of thing. Because
[04:10:40] <scribe> we think these are fairly well cooked. All right. And
[04:10:44] <scribe> then we've had two documents that completed working can group last
[04:10:47] --- gas has joined
[04:10:48] <scribe> call. And spam document. And we did post to the list,
[04:10:51] <scribe> because they had a few more issues than some of the other
[04:10:54] <scribe> documents, to get people to look at these again, after the
[04:10:58] <scribe> first round of review xhepts were incorporated and there's
[04:11:01] <scribe> been some feedback but we need more. These are done with
[04:11:04] <scribe> working group last call, we would like to forward these to
[04:11:05] --- Glenn Parsons has joined
[04:11:08] <scribe> IESG and we need people to look at these. And even if it's
[04:11:10] <scribe> just posting to the list, yes, I think it's ready to
[04:11:10] <scribe> go.
[04:11:15] <scribe> Again, we'll go into it later, but the spread sheets has all the
[04:11:17] <scribe> details of the feedback provided.
[04:11:22] <scribe> We've got two documents under working group last call right now.
[04:11:26] <scribe> Long periods of time since it overlaps this meeting. V6
[04:11:31] <scribe> torture test and the v6 framework. Jonathan?
[04:11:33] <scribe> NEW SPEAKER: Question, Mary, back to the previous
[04:11:37] <scribe> slide, does this request more comments imply
[04:11:43] <scribe> that we're going to be waiting for comments, or NEW SPEAKER:
[04:11:46] <scribe> It's more, NEW SPEAKER: I'm surprised to stee spam out
[04:11:50] <scribe> there. NEW SPEAKER: The part of it is, the expectation
[04:11:54] <scribe> is, part of this gets into our process, the expectation,
[04:11:57] <scribe> people who had been initial reviewers, they should be the
[04:12:01] <scribe> ones that stayed with the documents. That's how we follow
[04:12:03] <scribe> the document. Once you get the document it's yours
[04:12:07] <scribe> and you follow it through. And we haven't had the
[04:12:10] <scribe> reviewers go back and review it and say yes, my
[04:12:13] <scribe> comments were addressed. The chairs can do dha, but we
[04:12:17] <scribe> can't always make sure that what the reviewer intended is an
[04:12:19] <scribe> adequate solution. NEW SPEAKER: Okay. All right. NEW SPEAKER:
[04:12:23] <scribe> Yes. NEW SPEAKER: That still doesn't
[04:12:25] <scribe> answer the question about whether we're
[04:12:27] <scribe> weightsing for those people to step forward. NEW SPEAKER:
[04:12:32] <scribe> Actually, I think personally, yes, on both drafts to see
[04:12:33] <scribe> if they can post.
[04:12:36] <scribe> Basically, Jonathan addressed my comments, that's
[04:12:38] <scribe> it. NEW SPEAKER: But I still hoj necessarily think
[04:12:42] <scribe> that honestly think, from a working group
[04:12:46] <scribe> perspective, if we can't get people from the working group say
[04:12:49] <scribe> it's ready to go, we can't forward it. This is the whole
[04:12:51] <scribe> point. This is not our working group. It's not the
[04:12:53] <scribe> editor's working group. It's for everybody and everybody
[04:12:57] <scribe> needs to review the documents. At least a reasonable subset and
[04:12:59] <scribe> say, yes, we think this is ready to go. Right?
[04:13:07] --- afh@jabber.netzwert.ag has joined
[04:13:08] <scribe> NEW SPEAKER: I was one of the guys. So when do you
[04:13:10] <scribe> need it? NEW SPEAKER: What? NEW SPEAKER: When
[04:13:12] <scribe> do you want it? NEW SPEAKER: Last queek shing of
[04:13:16] <scribe> course. But by the end of the month. Just to
[04:13:18] <scribe> go back and say, your comments were addressed
[04:13:22] <scribe> and you're okay with the way the document was written. John
[04:13:34] <scribe> is going to say something here. NEW SPEAKER: Is the
[04:13:37] <scribe> document a draft called SIPPING S P C O R sdm NEW SPEAKER:
[04:13:41] <scribe> What did you say? NEW SPEAKER: He's saying is this
[04:13:42] --- Jim Martin has left
[04:13:44] <scribe> the accurate document name? NEW SPEAKER: Yes, is the
[04:13:48] <scribe> document name accurate? I'm looking in the track err and I
[04:13:51] <scribe> can't find it. NEW SPEAKER: It says error on my part.
[04:13:55] <scribe> Okay. Sorry. Is it the document title? NEW SPEAKER:
[04:13:56] <scribe> Yes. Sorry.
[04:14:09] <scribe> Okay. I'll make that correction in these charters. Thanks. Okay.
[04:14:17] <scribe> Okay. Again, these are undergoing working group last call.
[04:14:17] <rohan> The correct draft name is: draft-ietf-sipping-sbc-funcs-01.txt
[04:14:21] <scribe> And here again we ask for volunteer reviewer, and we don't have
[04:14:23] --- alexis has joined
[04:14:24] <scribe> any right now. So we go through working group last call and we
[04:14:28] <scribe> don't have anybody review the document it can't go anywhere.
[04:14:33] <scribe> So it takes people out in this room do review the documents.
[04:14:36] <scribe> And we have a lot of people that want to bring in new work, and
[04:14:39] <scribe> if you want new work to come in, we have to finish existing
[04:14:41] <scribe> charter work to go forward.
[04:14:46] <scribe> All right. So here's the agenda for today. We've been
[04:14:52] <scribe> through the status, and if you a few minutes if you want to
[04:14:57] <scribe> bash the agenda, and so we're fixed on time and Samantha is going to
[04:15:01] <scribe> go over the configuration framework. And then Jonathan is going
[04:15:04] <scribe> to give us the status on the overload design team, and then
[04:15:07] <scribe> Jonathan is going to talk about the service identification.
[04:15:12] <scribe> If we have time, we'll get into some of the how do we get working group
[04:15:14] <scribe> deliverables completed in a good time
[04:15:18] <scribe> frame. All right. On Friday, again, we end at
[04:15:22] <scribe> 10:30, so we have file directory and performance, call
[04:15:25] <scribe> completion services and then two drafts on early media that
[04:15:30] <scribe> we're going to talk with and then we'll have a buffer to switch for
[04:15:35] <scribe> eeecrit And I want to highlight, as usual usual shing we
[04:15:39] <scribe> have a lot of individual requests for agenda time. And the
[04:15:42] <scribe> majority of time does go to charter working group items. The
[04:15:47] <scribe> other documents get the agenda time based on mailing list level
[04:15:51] <scribe> of feedback. NEW SPEAKER: Should I interpret that to
[04:15:53] <scribe> say that it goes to dead null. NEW SPEAKER: You can't read
[04:15:56] <scribe> it, sorry. NEW SPEAKER: No. It's out there.
[04:16:00] <scribe> Just that that, the highlighting for that. It's on the soft
[04:16:03] <scribe> armor site. NEW SPEAKER: I'm just being a pest. NEW SPEAKER:
[04:16:07] <scribe> I just want to suggest, there is interesting work that
[04:16:09] <scribe> people want to do. So people, if you have a chance,
[04:16:12] --- adam@xmpp.estacado.net has joined
[04:16:13] <scribe> please review the documents and put feedback on the list.
[04:16:17] <scribe> John el well did not request the slot, but this is another
[04:16:21] <scribe> important document as well. And then dealing with some
[04:16:24] <scribe> response stuff, so, people, please do look at the dock
[04:16:27] <scribe> documents and give feedback, because it's
[04:16:29] <scribe> important to do that work as well.
[04:16:31] --- adam@xmpp.estacado.net has left
[04:16:32] <scribe> And again, I can't say this enough times, completing charter
[04:16:37] <scribe> work, including the detailed reviews is what makes room for
[04:16:38] <scribe> the new work to come into the working group.
[04:16:45] <scribe> And we have yet another one that we should probably highlight. NEW SPEAKER:
[04:16:50] <scribe> Is Henry in the room? Henry? Okay. Yes. You want
[04:16:54] <scribe> to talk maybe 30 seconds about the draft that, your draft
[04:16:58] <scribe> from peer to peer SIP just to draw the attention. NEW SPEAKER:
[04:16:59] --- adam has joined
[04:17:01] <scribe> Now? NEW SPEAKER: Yes. That would be great. NEW SPEAKER:
[04:17:04] <scribe> Just at the Mike there. NEW SPEAKER: You have my
[04:17:06] <scribe> slides sdm
[04:17:17] <scribe> NEW SPEAKER: No. NEW SPEAKER: What was is that we
[04:17:20] <scribe> have found the usage scenario that doesn't have a good name.
[04:17:24] <scribe> So for now, we just can call it SIP to SIP. And that
[04:17:29] <scribe> assumes that all the indications reside at end
[04:17:36] <scribe> points. This user scenario, certifications, one is incline
[04:17:42] <scribe> server systems, like the other C3 2 six one, and you have
[04:17:48] <scribe> only the SIM proxy registrar and redirect server. And then you
[04:17:53] <scribe> can put all the end points and there are known
[04:17:53] <scribe> services.
[04:17:55] --- richard.barnes has joined
[04:18:02] <scribe> The other applications scenario is peer to peer SIP, where there
[04:18:05] <scribe> are no servers, obviously, and everything is in
[04:18:09] --- dwillis@jabber.org has joined
[04:18:10] <scribe> the peers. Now, those peers can be light
[04:18:15] <scribe> weight or heavy weight. But to have the basic services like voice
[04:18:22] <scribe> mail and conferencing, and even com Plaintiff's
[04:18:25] <scribe> Exhibit work station and whatever, they all can be
[04:18:30] <scribe> implemented doing peer to peer call control. So we have a
[04:18:34] <scribe> draft, and we are looking for a home for it.
[04:18:36] <scribe> And
[04:18:39] <scribe> NEW SPEAKER: What's the name of it. NEW SPEAKER: I
[04:18:43] <scribe> hope this user scenario is interesting enough to complement all
[04:18:48] <scribe> the other stuff that's going on. So, people will have some
[04:18:54] <scribe> guidance whenever they want to do peer to peer SIP, or call control
[04:18:56] --- lowekamp@gmail.com has joined
[04:18:59] <scribe> simple client server SIP. Let's call it from fundamental
[04:18:59] <scribe> list SIP.
[04:19:03] <scribe> NEW SPEAKER: What's the draft name, Henry? NEW SPEAKER:
[04:19:06] <scribe> What's the name? NEW SPEAKER: I'm looking for the
[04:19:08] --- cgn has left
[04:19:08] --- kivinen has joined
[04:19:09] <scribe> draft name. I'll let you know as soon as possible. NEW SPEAKER:
[04:19:14] <scribe> I was going to say, it's got a SIP. It's like --
[04:19:16] <scribe> (Several people talking.) NEW SPEAKER: It's called, NEW SPEAKER:
[04:19:21] <scribe> The draft name is draft hill Fred, SIP tools, or one. And the
[04:19:25] <scribe> thing is, it was initially discussing peer to peer SIP, and
[04:19:29] <scribe> now we decided to discuss it here in SIPPING, because as Henry
[04:19:32] <scribe> was saying, we were looking dpor a home for the draft.
[04:19:35] <scribe> Please have a look at it and discuss it here in the working group. NEW SPEAKER:
[04:19:39] <scribe> Exactly, please take a look at it first and then, we
[04:19:43] <scribe> really appreciate any frank comments on the
[04:19:46] <rohan> Henry's draft is: draft-sinnreich-sip-tools-01.txt
[04:19:46] <scribe> list, don't hold back anything. It may not be complete,
[04:19:51] <dwillis@jabber.org> http://www.ietf.org/internet-drafts/draft-sinnreich-sip-tools-01.txt
[04:19:53] <scribe> actually, plan to have a new version, but with your
[04:19:56] <scribe> input. NEW SPEAKER: Thank you, Henry. NEW SPEAKER: Thank you.
[04:19:57] <scribe> Thank you.
[04:19:59] --- kivinen has left
[04:20:01] <scribe> NEW SPEAKER: All right. Samantha is going to give us the
[04:20:03] <scribe> update on con fig framework now.
[04:20:13] <scribe> NEW SPEAKER: So I have a 30 second update on the con fig
[04:20:14] <scribe> framework. Right.
[04:20:18] <dwillis@jabber.org> That's Sumanth.
[04:20:20] <scribe> Just to give an idea as to why we have this presentation, we
[04:20:27] <scribe> had break out session at IETF six7 and we a design team
[04:20:32] <scribe> volunteer to on review and revise con fig framework draft O
[04:20:32] --- bhoeneis has joined
[04:20:36] <scribe> 9, and again, I listed the people involved in that, but
[04:20:38] <scribe> please check draft 11 and apologies if I
[04:20:42] <scribe> didn't list anybody. As Mary indicated earlier, we had two
[04:20:44] <scribe> drafts that were released. Draft ten the and 11.
[04:20:49] <scribe> And we planned so that we could get maximum feedback from the
[04:20:54] <scribe> working group and then being present to this working group.
[04:20:55] <scribe> Paragraph pravr
[04:20:58] <scribe> And there have been various comments and
[04:21:02] <scribe> resolutions. Thanks to everybody who reviewed and provided
[04:21:06] <scribe> comments and we received sp some post drafts
[04:21:09] <scribe> comments and I'll highlight some of those
[04:21:13] <scribe> discussions at the end so we get feedback as the a working group as a
[04:21:13] <scribe> whole.
[04:21:18] <scribe> So what's being presented? I don't know if I should read
[04:21:21] <scribe> this. My significant other told me I may not get any reaction
[04:21:21] <scribe> from people.
[04:21:26] <scribe> But essentially, the problem boils down to today, if you are
[04:21:32] <scribe> serving der on the menu, there are quite a few ways
[04:21:39] <scribe> to serve. There was something, and there was one
[04:21:42] <scribe> problem, question finally had unique and adequate rules for
[04:21:46] <scribe> serving. And now Jonathan, with all due respect from
[04:21:50] <scribe> you, I cannot rip this off from the external portion, see,
[04:21:53] <scribe> I guess I was wrong. I did not get any reaction. So thanks
[04:21:56] <scribe> for that. NEW SPEAKER: It's Monday morning. A bunch
[04:21:58] <scribe> of people are still jet lagged. NEW SPEAKER: Maybe
[04:22:01] <scribe> that will carry over to the rest of the presentation when I ask
[04:22:05] <scribe> all the hard questions. Some people are saying, how do you
[04:22:08] <scribe> configure a SIP U A. That's what it boils down to.
[04:22:15] <scribe> So some are technical. What does it do? It proposes a
[04:22:20] <scribe> framework, why? For propagating file data to SIP U As.
[04:22:23] <scribe> How does it accomplish it, as you know, it uses, it
[04:22:29] <scribe> defines a new package, based on 3265. What else does it do?
[04:22:33] --- akiniemi has joined
[04:22:34] <scribe> It defines alive cycle. It's not just configuration, you
[04:22:41] <scribe> also need to obtain updates and there are ways to
[04:22:46] <scribe> obtain actual data. So, it defines how a normal retrieval
[04:22:51] <scribe> will take place and how change notifications are given to the
[04:22:51] <scribe> client.
[04:22:56] <scribe> It defines three types of profile, based on the fact that you
[04:22:59] <scribe> have different sources for these profiles and the local
[04:23:02] <scribe> network, the device and the user.
[04:23:06] --- adam has left
[04:23:06] <scribe> What does it not do? It does not give you the recipe for the
[04:23:10] <scribe> dishes. In other words, it does not specify data models,
[04:23:11] <scribe> just so that we clarify that.
[04:23:18] <scribe> So, I can kind of start out on the break out session of 6.7.
[04:23:22] <scribe> What came out of that? As a design team, what we wanted
[04:23:26] <scribe> to do. There were structural changes that were proposed.
[04:23:29] <scribe> Keith sent an e-mail and there were discussions as well as
[04:23:31] --- fneves has joined
[04:23:33] <scribe> discussions in the Dee skin group. And then design
[04:23:33] <scribe> group.
[04:23:39] <scribe> And then we were also asked to discuss the profiles and there
[04:23:42] <scribe> were other problems in the working group or elsewhere that
[04:23:44] <scribe> needed to be addressed as well.
[04:23:50] --- JeffH has joined
[04:23:50] <scribe> So what was done in draft ten? I indicated that we had two
[04:23:54] <scribe> drafts that were released. Draft ten was mostly focused on
[04:23:57] <scribe> the restructuring aspect. So, we
[04:24:03] <scribe> kind of revised quite a few interrupt sections. And then we
[04:24:08] <scribe> kind of compiled all the requirements into a single section.
[04:24:11] <scribe> We kind of took the use cases and split them into high level use
[04:24:17] <scribe> cases and just held examples, so it would be better articulate what was
[04:24:21] <scribe> intended here. And there were a few other changes and you
[04:24:22] <scribe> can refer to the draft.
[04:24:28] <scribe> Draft 9, there were quite a few comments and
[04:24:32] <scribe> thanks for those of you who provideds
[04:24:34] <scribe> comments and we tried to address those all in the next the
[04:24:39] <scribe> draft. So if you haven't read it, quickly can I do a show of hands how
[04:24:41] <scribe> many people have read draft 11?
[04:24:44] <scribe> Okay. Thank you.
[04:24:49] <scribe> So what was done in the draft 11. The major
[04:24:54] <scribe> changes, if I had to summarize them, would be that profiles
[04:24:57] <scribe> were simplified. Up until draft ten, we kind of had
[04:25:00] <scribe> various steps, we NEW SPEAKER: Just a second. NEW SPEAKER:
[04:25:03] <scribe> For the note taker, there were 30 people that read the draft.
[04:25:04] <scribe> Okay.
[04:25:12] <scribe> NEW SPEAKER: Thanks. We simplified the life cycle
[04:25:16] <scribe> process. We kind of, you know, took a few steps and put them
[04:25:21] <scribe> together. Specifically the whole separation of discovery and
[04:25:26] <scribe> initial notification was all combined into file enrollment,
[04:25:30] <scribe> given that's what really defines enrollment. So there are only
[04:25:35] <scribe> three main steps, enrollment, how do you obtain retrieve
[04:25:38] <scribe> data using content interaction, as well as how do
[04:25:41] --- worley has joined
[04:25:41] <scribe> you obtain change notification. There are two other steps
[04:25:46] <scribe> for profile modifications and you know, the content direction or
[04:25:50] <scribe> file, that way. But you know, those are logical steps we
[04:25:51] <scribe> don't specify those in detail.
[04:25:59] <scribe> The second section was revised and we fixed terminology and
[04:26:02] <scribe> editorials based on the comments of the working
[04:26:05] <scribe> group. Again, the next draft has a complete list of the
[04:26:09] <scribe> changes and once again, thanks to those of you who read and
[04:26:11] <scribe> actually provided those comments.
[04:26:18] <scribe> So, this is where kind of hoping we have discussions for the
[04:26:22] --- fneves has left
[04:26:22] <scribe> working group. There are being some things that are being
[04:26:25] <scribe> questioned in the past and I want to get feedback. The first
[04:26:31] <scribe> one, does the layout and I already see people walking up to
[04:26:31] <scribe> the Mike.
[04:26:35] <scribe> You know, there was, there were quite a few questions about
[04:26:39] <scribe> complexity and things like that. And but again, when we took
[04:26:42] <scribe> out information, there were recommendations to kind of put
[04:26:46] <scribe> certain things back in to better explain what was being done.
[04:26:49] <scribe> So the question is, draft 11,
[04:26:56] <scribe> given R F T. Does it instructly sound, does it give you
[04:26:59] <scribe> adequate information to help you understand the problem better
[04:27:03] <scribe> or the framework, you know, are there things we can remove from
[04:27:07] <scribe> there without any loss of understanding or are there things
[04:27:09] <scribe> that you would like to see that are removed. NEW SPEAKER:
[04:27:13] <scribe> Did you want comment individually or did you want to get
[04:27:15] <scribe> through and then receive comments?
[04:27:18] <scribe> NEW SPEAKER: Oh, we can -- sdmoo is this comment relative
[04:27:20] <scribe> to this particular item. NEW SPEAKER: Yes. (Several people talking.) NEW SPEAKER:
[04:27:25] <scribe> Please. NEW SPEAKER: My comment is two fold on that.
[04:27:30] <scribe> Namely, I'd like to discuss, last night, how an executive
[04:27:37] <scribe> summary or example, early on. And I find myself, reading
[04:27:42] <scribe> what this is really all about. Playing dumb so to say and that's
[04:27:44] --- avwijk has joined
[04:27:46] <scribe> not a good thing. The dwravt is 60 pages long. And that
[04:27:50] <scribe> means there's room for cutting. This should not take 60
[04:27:53] <scribe> pages to describe. Like I said, I will take an action
[04:27:56] <scribe> items to suggest specific things we can do.
[04:28:03] <scribe> One thing I think is a problem, even though the document uses
[04:28:07] <scribe> concepts that we have elsewhere, such as subscription notification,
[04:28:11] <scribe> all of that, kind of creates terminology which is orthagonal
[04:28:16] <scribe> to that. For example, it has enrollment process which really
[04:28:21] <scribe> just mention subscription, from what I can tell. My
[04:28:26] <scribe> suggestions would be to take a clear look as to if it is really
[04:28:30] <scribe> in technical actuality, something which is happening, an
[04:28:36] <scribe> existing SIP concept, even though with could generalize it in some sense.
[04:28:36] <scribe> But we're not.
[04:28:40] <scribe> Then just call it what it is, because that removes a lot of what it
[04:28:44] <scribe> is. I mean, what terminology, conceptually, what we have
[04:28:48] <scribe> to introduce. That's probably the biggest way that I could
[04:28:52] <scribe> see reducing complexity as much as possible, refer to things
[04:28:56] <scribe> that we already know how to do, and where people who know SIP
[04:29:00] <scribe> concepts, can simply, substitute the names and don't have
[04:29:05] <scribe> to say, is this really the exact same concept or is
[04:29:09] <scribe> enrollment suddenly something different than 3265, that makes
[04:29:12] <scribe> it much harder for me to read. Because I'm constantly on
[04:29:18] <scribe> the look out, on are we modifying 3265 are we not? Is it
[04:29:20] <scribe> just a different meaning for something I already know?
[04:29:24] <scribe> NEW SPEAKER: Thanks for that. Just to comment on that. There
[04:29:30] <scribe> are a lot of pages that, like the changes from draft one through
[04:29:35] <scribe> 99 so that's a lot of pages. The second thing is, again,
[04:29:38] <scribe> you know, thanks for the comments on draft ten.
[04:29:42] <scribe> We tried to simply things in the next draft, so try to read
[04:29:46] <scribe> it and see if those comments apply. NEW SPEAKER:
[04:29:50] <scribe> I'd like to point out that the enrollment, Rohan, sorry.
[04:29:54] <scribe> The enrollment is not just a subscription. That the key thing here
[04:30:03] <scribe> is that, enrollment refers to a process which needs to happen
[04:30:05] <scribe> at the, at the server that receives the subscription,
[04:30:10] <scribe> that's not something that normally happens when you send a
[04:30:13] <scribe> subscription every time you send a subscription. So, if
[04:30:13] --- Adam has joined
[04:30:17] <scribe> there's some way that you know, I've explaind
[04:30:21] <scribe> this, that if there's someone out there that can explain this
[04:30:25] <scribe> in a way that will make it more concise for more people to put
[04:30:28] <scribe> it in the draft, please send text. NEW SPEAKER: In
[04:30:30] --- jhlim has joined
[04:30:32] <scribe> general, I find it -- NEW SPEAKER: If that's so, it's more
[04:30:35] <scribe> important to do a 3265 diff, we can assume that everybody
[04:30:36] --- ben has joined
[04:30:41] <scribe> that reads this document is familiar with 3265 and just simply
[04:30:45] <scribe> highlighting, wa what are the really important differences,
[04:30:48] <scribe> makes it better than trying to extract that by reverse
[04:30:52] <scribe> engineering. And I'll try to post comments. NEW SPEAKER:
[04:30:54] <scribe> Great. Any other comments on this specific slide?
[04:30:59] <scribe> There's been no recommendation on the secure requirements,
[04:31:02] <scribe> and draft revisions ten and 11. We
[04:31:05] <scribe> kind of took all the is security requirements out and put it in
[04:31:10] <scribe> one section. And that will help me get complete review of
[04:31:13] <scribe> what it takes, you know, for, it doesn't matter. Dan? NEW SPEAKER:
[04:31:19] <scribe> Just really confused here. Because this is basically,
[04:31:23] <scribe> 3265 event package. There's more, because, this isn't
[04:31:27] <scribe> just an event package. But I'm really confused as to why
[04:31:32] <scribe> this, you know, what's the diff from 3265? We're note
[04:31:35] <scribe> modifying 3265. NEW SPEAKER: Now I'm more confused.
[04:31:37] <scribe> I hear two statements which (Several people talking.) NEW SPEAKER: We
[04:31:39] <scribe> are not modifying
[04:31:40] <scribe> NEW SPEAKER: Microphone. NEW SPEAKER: (Several people
[04:31:40] <scribe> talking.)
[04:31:43] <scribe> NEW SPEAKER: It's on top of and in addition to. We're not
[04:31:47] <scribe> changing 3265 behavior here. NEW SPEAKER: Let's make
[04:31:50] <scribe> sure that's crystal clear in the RFC actually. What we are
[04:31:55] <scribe> doing, if we are in sceesing increasing Delta or
[04:31:57] <scribe> whatever. NEW SPEAKER: If this is the case, then there should
[04:32:01] <scribe> be clearly a step which says subscription, which means
[04:32:05] <scribe> immediately, 3265 to me. And then there should be a step
[04:32:09] <scribe> which says, authorization, whatever it happens to be. And
[04:32:15] <scribe> then I can say, okay, this is a tiny thing which, there's
[04:32:19] <scribe> only two steps. NEW SPEAKER: There are three places
[04:32:22] <scribe> where it says SIP subscribe. NEW SPEAKER: I think we're
[04:32:27] <scribe> making this too complicated for what it is. It seems to me this
[04:32:31] <scribe> is a process that includes subscription. And some other stuff.
[04:32:36] <scribe> And we just need to explain that. It's not a di, in my
[04:32:41] <scribe> definition of diff. It's just on top of. If we just
[04:32:44] <scribe> clarify that in the beginning, I forget what the terminology
[04:32:48] <scribe> is, and then explain what it is, then that should make it
[04:32:51] <scribe> very east easy for the reader to figure out what it is.
[04:32:55] <scribe> Just NEW SPEAKER: Just to explain, draft
[04:32:58] <scribe> 11, that's with what we tried to do. So I would take a look
[04:33:03] <scribe> at it. If you say you use one package and specify the steps, you
[04:33:06] <scribe> know, using the define pablingt. You say it's a
[04:33:10] <scribe> subscribe, and we try to define that. So, I would take a
[04:33:13] <scribe> look at it and see if that's not clear.
[04:33:16] --- jhlim has left
[04:33:16] <scribe> Okay. Anything else on this specific slide?
[04:33:18] <scribe> Okay.
[04:33:25] <scribe> We can probably, I don't know if there are D N S experts in this
[04:33:31] <scribe> group that have specific comments, but to use
[04:33:34] <scribe> under score. NEW SPEAKER: I missed, on generally
[04:33:38] <scribe> speaking, I'm just going on, on a secondary issue, and
[04:33:40] --- hb47713 has joined
[04:33:42] <scribe> I'm not an D N S expert or pure wrist, but my general
[04:33:47] <scribe> perception is, that overloading, creating specific naming
[04:33:50] <scribe> convention in D N S for host name type of things is not such a
[04:33:56] <scribe> hot idea. We have mechanisms S O U records and things of that
[04:34:00] <scribe> nature that are specifically meant for addressing services.
[04:34:01] --- jhlim has joined
[04:34:04] <scribe> And the reason I'm saying that, we have this long long ago
[04:34:09] <scribe> discussions in the SIP working group, I think it was set, it was
[04:34:14] <scribe> probably predate be SIPPING, about specific host naming
[04:34:18] <scribe> conventions for specific SIP services and let's just say that
[04:34:21] <scribe> was not received well. So I'm concerned what we're doing
[04:34:25] <scribe> here, is having these type of defined D N S names, as
[04:34:30] <scribe> opposed to using a new record for a specific service, is not such a hot
[04:34:30] <scribe> idea.
[04:34:33] <scribe> So instead of going with the under score, maybe we should have the
[04:34:34] --- Jabber-Wile has joined
[04:34:39] <scribe> bigger discussion first, as to whether other D N S mechanisms
[04:34:44] <scribe> that we now have that weren't available ten years ago are now
[04:34:47] <scribe> work able. NEW SPEAKER: Just sto clarify, with
[04:34:56] <scribe> SIPPING, recommendation came in. To something, just to set
[04:34:58] <scribe> the context. NEW SPEAKER: So the alternative would be,
[04:35:02] <scribe> if we want to do that at all, based on our discussion last
[04:35:04] <scribe> night, the question, do we want this at all. NEW SPEAKER:
[04:35:06] <scribe> That's another question that comes up. NEW SPEAKER:
[04:35:13] <scribe> Is, I would actually suggest strongly looking at S U V or S
[04:35:15] <scribe> RV, just define the service, because that's what it is.
[04:35:19] <scribe> It's a specific service, that you have, where you want to
[04:35:23] <scribe> obtain a service, which is not something, it's not just
[04:35:26] <scribe> another U A. NEW SPEAKER: True. The only thing I'm
[04:35:29] <scribe> worried about there, I don't know if you can use that
[04:35:32] <scribe> reference, because this is just what gets populated in the
[04:35:37] <scribe> request URI. But we can discuss that.
[04:35:45] <scribe> NEW SPEAKER: You milt want to talk to D N S folks (Several people talking.) NEW SPEAKER:
[04:35:49] <scribe> Yes. My general perception is, application specific D N S
[04:35:52] <scribe> names are not going to be looked on favorably. NEW SPEAKER:
[04:35:59] <scribe> Just to add something, add a note there, but somebody else
[04:36:03] <scribe> and I contacted the chairs for D F S and we're ready for the
[04:36:05] <scribe> response. NEW SPEAKER: Some of this got inserted
[04:36:08] <scribe> because I brought it in. And I could be wrong. And we
[04:36:12] <scribe> need to talk to the D N S people and sort this out. This
[04:36:15] <scribe> room does not have the expertise to do that. We need to talk
[04:36:19] <scribe> to D N S people to sort this out. NEW SPEAKER: Thanks
[04:36:22] <scribe> Collin. NEW SPEAKER: Next. There's been discussion
[04:36:26] <scribe> on device I D and based on discussions of, I don't know if I
[04:36:30] <scribe> got this right in terms of what was being proposed. But
[04:36:35] <scribe> currently there's a device parameter that can be, where you
[04:36:40] <scribe> can put in a device identifier for the local network to be able
[04:36:46] <scribe> to identify the profile. There are suggestions that we don't
[04:36:50] <scribe> need this and maybe we can use a contact header. And the
[04:36:54] <scribe> discussion is, you know, is that it? I mean, do we not
[04:36:58] <scribe> need it and rely on con dakt header and put in actual
[04:37:00] <scribe> information we need, or thoughts on that?
[04:37:05] <scribe> NEW SPEAKER: I had sent a different comment to, at least some
[04:37:08] <scribe> subset of people. There seems to be a strong overlap here,
[04:37:12] <scribe> with the user two parameter that we already have. And so,
[04:37:16] <scribe> why not just use that? Instead of having two ways of
[04:37:19] <scribe> doing the same thing. NEW SPEAKER: Do you mean the contact header?
[04:37:23] --- jhlim has left
[04:37:23] <scribe> NEW SPEAKER: Like the user agent server headers. Yes, this was
[04:37:30] <scribe> proposed back, around somewhere around 2,000, dash 06 or
[04:37:34] <scribe> '07 and there was a discussion on the mailing list, because of the pre
[04:37:38] <scribe> formed nature of that field because it's said rset for
[04:37:42] <scribe> debugging purposes and implementation, we came to consensus at
[04:37:44] <scribe> that point that it was ntd appropriate. NEW SPEAKER:
[04:37:45] <scribe> Okay.
[04:37:51] <scribe> NEW SPEAKER: That was my suggestions in O four. NEW SPEAKER:
[04:38:01] <scribe> So then are we agreeing then that we're going to continue the
[04:38:03] <scribe> use of the device?
[04:38:06] <scribe> NEW SPEAKER: Unless people have thoughts? Collin, do
[04:38:11] <scribe> you want to -- NEW SPEAKER: Cleats go ahead and capture
[04:38:16] <scribe> that in the minutes then, right? NEW SPEAKER: Yes. We
[04:38:18] <scribe> can use it unless people have over thoughts there. NEW SPEAKER:
[04:38:21] <scribe> Collin, I knew you would get to the Mike. NEW SPEAKER:
[04:38:24] <scribe> So explain to me why you need to put the same number in two different
[04:38:26] --- jhlim has joined
[04:38:28] <scribe> places in the same message. Every time we've done that in the
[04:38:32] <scribe> past, it led to what happens when they're not the same number
[04:38:35] <scribe> even though it says they have to be the same number. Of
[04:38:39] <scribe> course we need a device I D. The question is, do we need
[04:38:42] <scribe> it in two places in the message and if so, why?
[04:38:48] --- jhlim has left
[04:38:51] <scribe> NEW SPEAKER: It's in the contact and it's in the event
[04:38:54] --- csp has left
[04:38:57] <scribe> header.
[04:39:00] <scribe> NEW SPEAKER: Try to use the Mike. NEW SPEAKER: Use
[04:39:01] --- joonhyung.lim has joined
[04:39:03] <scribe> the Mike, please. NEW SPEAKER: It's not in the event
[04:39:07] <scribe> header. NEW SPEAKER: It's not in NEW SPEAKER:
[04:39:10] <scribe> (Several people talking.) NEW SPEAKER: Draft it is. NEW SPEAKER:
[04:39:16] <scribe> Can somebody explain that, because not everybody has
[04:39:18] <scribe> memorized that. NEW SPEAKER: What does the draft say? NEW SPEAKER:
[04:39:23] <scribe> Just to clarify, you know, we went back on this draft and
[04:39:26] <scribe> said the from header is going to have the user A O R. So
[04:39:32] <scribe> given that the from header has a uses A O R, we decided to
[04:39:36] <scribe> use event header parameter, which previously was provided from the from
[04:39:37] <scribe> header. (Several people talking.)
[04:39:40] <scribe> NEW SPEAKER: So the draft header says that. NEW SPEAKER:
[04:39:44] <scribe> So I'm suggesting we say, the device I D comes out of the
[04:39:48] <scribe> instance I D as contact header and the user name comes out of
[04:39:50] <scribe> the from header. And the advantage of doing that is we
[04:39:54] <scribe> already have a lot of drafts that deal with confidentiality and
[04:40:00] <scribe> what needs to have anonymous calls and it's an in credited able
[04:40:06] <scribe> amount of work. Incredible amount of work. And I don't see what happens when
[04:40:09] <scribe> it's different and how do we deal with all the confidentiality
[04:40:12] <scribe> stuff. NEW SPEAKER: So to summarize, we should
[04:40:13] --- joonhyung.lim has left
[04:40:13] <scribe> probably
[04:40:16] <scribe> (Several people talking.) NEW SPEAKER: You should say, we have to have, you
[04:40:21] <scribe> know, if it's defined in out bound GRUU or wherever it is, you
[04:40:24] <scribe> have have got to do that. Must implement. And that's
[04:40:26] <scribe> where you get the information from. NEW SPEAKER: Okay. NEW SPEAKER:
[04:40:32] <scribe> So, I, it's fine for the local profile, but for the device
[04:40:35] --- joonhyung.lim has joined
[04:40:36] <scribe> profile, I mean, the device name has to be part of the
[04:40:38] <scribe> URI, otherwise we don't have identification for the resource. NEW SPEAKER:
[04:40:41] <scribe> For the device, NEW SPEAKER: I mean, it's still, I
[04:40:45] <scribe> want to point out, it's going to be, it's going to be more than
[04:40:46] <scribe> one place.
[04:40:50] <scribe> NEW SPEAKER: For the device profile request, yes. NEW SPEAKER:
[04:40:51] --- mhp has joined
[04:40:56] <scribe> So, I'm not sure I care as much for the request URI, but it
[04:40:59] <scribe> doesn't have to be -- I mean, we have lots of other things where
[04:41:03] <scribe> you look at something other than the request URI in a subscribe
[04:41:08] <scribe> and decide what data you're returning in the notify. NEW SPEAKER:
[04:41:12] <scribe> In the case of looking at the instance I D, for the device I D,
[04:41:19] <scribe> if you look at the U A, for example, your device profile,
[04:41:23] --- isudo has joined
[04:41:23] <scribe> or your user profile, then you're not, that may be re
[04:41:27] <scribe> written by one of those things.
[04:41:31] <scribe> NEW SPEAKER: So, you're saying that it might be lost
[04:41:32] <scribe> during --
[04:41:34] --- joonhyung.lim has left
[04:41:36] <scribe> NEW SPEAKER: U A can lose anything. NEW SPEAKER:
[04:41:38] --- joonhyung.lim has joined
[04:41:41] <scribe> For the local profile NEW SPEAKER: Yes. NEW SPEAKER:
[04:41:47] <scribe> So, Rohan, would you be okay with removing device I D
[04:41:52] <scribe> because it's for the local network profile?
[04:41:56] <scribe> NEW SPEAKER: Okay. So, I think removing the device I D
[04:42:02] <scribe> and the line on the instance I D, seems like a fairly safe
[04:42:06] <scribe> thing to do for the local network profile. But we should
[04:42:10] <scribe> check that out a little bit more carefully. But, that I don't
[04:42:13] <scribe> think it's appropriate for use when fetching the
[04:42:16] <scribe> device profile because you could be fetching it
[04:42:20] <scribe> from, you could be fetching it from several hops
[04:42:23] <scribe> away, and there's a good chance that information could be lost. NEW SPEAKER:
[04:42:28] <scribe> Yes, just for the device profile, yes, we don't rely on that right
[04:42:30] <scribe> now. Okay.
[04:42:35] <scribe> So for the notes, we, you know, it might be okay to remove
[04:42:40] <scribe> device I D and remove it for the local network profile but we need
[04:42:41] <scribe> more information. Okay. Thanks.
[04:42:47] <scribe> So, draft oh hasz a fall back, and
[04:42:52] <scribe> we say that you do need the device profile, and NEW SPEAKER:
[04:42:55] <scribe> Just for the floats, I don't agree with what Rohan said at
[04:43:04] <scribe> all. NEW SPEAKER: As an individual, Collin jenks as
[04:43:09] <scribe> an individual. Collin jenings. Are you
[04:43:16] <scribe> going to take every header in the U A, just to get past this.
[04:43:20] <scribe> That's ridiculous. The question here is what happens to an
[04:43:24] <scribe> instance I D when it goes through a U A. It's not really in
[04:43:27] <scribe> the scope of this draft. So, I don't know. Just don't
[04:43:29] <scribe> take it as there was consensus in the room on that. NEW SPEAKER:
[04:43:31] <scribe> We didn't ask for it. NEW SPEAKER: If I can clarify
[04:43:35] <scribe> specifically what I think about the device, the
[04:43:39] <scribe> fetching device profile. Is that you are trying to fetch a
[04:43:40] --- kvehmanen has joined
[04:43:43] <scribe> specific resource. The resource is named by URI. The device, the
[04:43:47] <scribe> name of the device that you're trying to fetch should be
[04:43:51] <scribe> therefore in that resource. That is a very appropriate way
[04:43:53] <scribe> to, a very appropriate place to put the name.
[04:43:59] <scribe> In the case of the local network profile, this is sort of
[04:44:02] <scribe> additional, the device is additional information, which is
[04:44:06] <scribe> already in the message, in the contact header and can be gleaned
[04:44:06] <scribe> that way.
[04:44:16] <scribe> Saying that we should fetch a resource, not by its name but by
[04:44:20] <scribe> some other name and instead rely on some header which may or may
[04:44:27] <scribe> not be present, in that context, I think is silly. NEW SPEAKER:
[04:44:28] <scribe> Request URI
[04:44:30] <scribe> NEW SPEAKER: For the device. NEW SPEAKER: ilt should
[04:44:32] <scribe> be in the --
[04:44:36] <scribe> NEW SPEAKER: For the device profile it should be in the request
[04:44:41] <scribe> URI shing, for the local network profile, it's supplemental
[04:44:44] <scribe> information, and I feel getting it out of the contact header
[04:44:47] <scribe> is perfectly appropriate. NEW SPEAKER: Okay. NEW SPEAKER:
[04:44:51] <scribe> I think you guys are a agreeing, rnlt you, other than the
[04:44:54] <scribe> context, of how you originally started making your statement. NEW SPEAKER: Yes,
[04:44:58] <scribe> I think that's consensus. In the device profile, it's still
[04:45:03] <scribe> URI. In the local profile, we're saying we should remove it. Any
[04:45:08] <scribe> objections to that? Once, twice, okay.
[04:45:14] <scribe> NEW SPEAKER: So, going back to the slide, fall back to H T
[04:45:18] <scribe> T P. Draft 11, as well as all the
[04:45:22] <scribe> other drafts, have proposed the fall back mechanism, in
[04:45:28] <scribe> case you can obtain the device profile. And this has been
[04:45:33] <scribe> questioned. And I guess the question is, do we need this?
[04:45:38] <scribe> Or not? And
[04:45:40] <scribe> NEW SPEAKER: I think the things that sort of changes back and
[04:45:44] <scribe> forth at different times or whatever, when you fall back to H
[04:45:48] <scribe> T T P, is it all right that you know longer have a
[04:45:50] <scribe> subscription model so if something changes you'll never be
[04:45:55] <scribe> updated about it? Right? Are we all right with a scheme where
[04:45:59] <scribe> if something sort of goes wrong, we fall into this mode where
[04:46:03] <scribe> the device will never again be updated with the information that
[04:46:06] <scribe> might get it back to where something wasn't really wrong
[04:46:10] <scribe> anymore. Right? NEW SPEAKER: Just clarify, the expectation (Several people
[04:46:10] <scribe> talking.)
[04:46:14] <scribe> NEW SPEAKER: Okay. NEW SPEAKER: So, okay. If
[04:46:19] <scribe> if the draft does dmot have a pole and you want to change it until we have
[04:46:22] <scribe> a pole mechanism. That's different. NEW SPEAKER: If
[04:46:27] <scribe> it's P, I don't know if it's specified and presumably there would
[04:46:32] <scribe> be expiration in the H T T pcht P response, which would be uphold,
[04:46:34] <scribe> essentially. And re try every hour or something like that.
[04:46:40] <scribe> Again, what I'm worried about, the fall back mechanism, which is
[04:46:42] <scribe> general concern and problem we might want to discuss, given
[04:46:46] <scribe> the 60 page spec, my concern is what will happen is, people
[04:46:49] <scribe> will implement the simplest possible thing that they need,
[04:46:53] <scribe> whatever subset it happens to be. That serves their needs,
[04:46:59] <scribe> and if they say, oh, I can just get away with H T T P, which is
[04:47:04] <scribe> much more equivalent of what people are doing in proprietary
[04:47:05] <ttfr> waa, we have super-scribe today!
[04:47:10] <scribe> ways, people will just implement H T T P because most things
[04:47:14] <scribe> work with 95 percent of the functionality they care about.
[04:47:18] <scribe> That's my pre prediction. Record it for 5 years from now, NEW SPEAKER:
[04:47:24] <scribe> Adjustor R for the record, the expectation is given enough
[04:47:28] <scribe> information, this is a case where you can get your P D S and
[04:47:32] <scribe> you want to booth strap a device with certain information. NEW SPEAKER:
[04:47:38] <scribe> I think it will be closer to 99 percent and not 95 percent of people
[04:47:42] <scribe> doing the H P T T P. And I think this is more complicated
[04:47:47] <scribe> than that. If you look at what most application software
[04:47:49] --- sk137 has joined
[04:47:51] <scribe> does today, the vast majority of it today has almost no
[04:47:56] <scribe> automation configuration update of any sort. A bunch of
[04:48:03] <scribe> it, the good stuff does periodic hold. And a very small
[04:48:06] <scribe> amount is notification of update at the time it's immediately
[04:48:09] <scribe> available. So I mean, if the rest of the world is more or less
[04:48:13] <scribe> getting by on daily pol on, with random myselfd
[04:48:18] <scribe> pol times, we set the bar way higher than that. And I'm
[04:48:23] <scribe> worried. Let's at least make sure, I'm not suggesting remove
[04:48:27] <scribe> everything, but at least let's have a fall back H T T P,
[04:48:31] <scribe> with an expiration and a periodic fall so there's something,
[04:48:33] <scribe> that we have.
[04:48:41] <scribe> NEW SPEAKER: I think it's wrong to call this fall back. I
[04:48:44] <scribe> think it's actually completely the opposite. This
[04:48:48] <scribe> is what we have today. And I think it's important to
[04:48:52] <scribe> recognize that that's kind of the lowest common denominator.
[04:48:57] <scribe> And I, if there's no real good reason to do what this draft
[04:49:01] <scribe> is proposing, I think we're in trouble. But I don't think that's the
[04:49:05] <scribe> point. I think people will, that have issues, today,
[04:49:11] <scribe> recognize there's some problem, it's not optimal. And maybe
[04:49:15] <scribe> instead of calling this feedback, we just explain that as
[04:49:20] <scribe> kind of the can common practice, and just explain why it's useful to
[04:49:25] <scribe> have something beyond this, which basically means the a
[04:49:28] <scribe> synchronous notification. And call it a day. I don't think
[04:49:30] <scribe> we need to do much more than that.
[04:49:33] <scribe> And I don't think we should remove this. I think it's
[04:49:36] <scribe> important to recognize it's in there. Otherwise people are
[04:49:40] <scribe> just going to say, oh, well, we can just use H T T P. Why
[04:49:41] <scribe> didn't I think of that?
[04:49:46] <scribe> NEW SPEAKER: Okay. Rohan may. So, I have two
[04:49:50] <scribe> comments, one on complexity and the other on this H T P, you
[04:49:57] <scribe> know, being able to use H T T P sort of stand alone here.
[04:50:02] <scribe> The complexity in this draft is entirely in its specification.
[04:50:09] <scribe> Implementation of this draft in its entirety is actually quite
[04:50:14] <scribe> easy. I've had somebody, go off and do it. And NEW SPEAKER: Something
[04:50:17] <scribe> really wrong. NEW SPEAKER: Well, exactly. Something
[04:50:20] <scribe> is really wrong. And everybody here who keeps saying, oh,
[04:50:24] <scribe> well, I want my little thing added here and there, and that's
[04:50:27] <scribe> exactly how we got to Dan retiring from this document.
[04:50:33] <scribe> Because we basically have been yanking his chain back and
[04:50:36] <scribe> forth, various different directions and
[04:50:39] <scribe> have not decided on what do do. And we get up here and start
[04:50:43] <scribe> discussing, well, maybe this shoulding in this
[04:50:46] <scribe> header instead of this place and not to try to beat up on him.
[04:50:50] <scribe> But the user agent header example, yes, we discussed that back
[04:50:56] <scribe> when the draft was at say dash O four and then again at '07 and
[04:51:01] <scribe> '08 and we switched it from one thing and another back again.
[04:51:08] <scribe> And that's why it seems so complicated, because we kept saying
[04:51:11] <scribe> we want to incorporate more and more stuff and we kept changing
[04:51:14] <scribe> the way in which, the place in which we put this information. (Several people
[04:51:20] <scribe> talking.) NEW SPEAKER: Actually try to remove something. NEW SPEAKER:
[04:51:26] <scribe> In any case, back to H T T P, yes, most people are doing
[04:51:29] <scribe> http://, The nice thing about this document is it
[04:51:32] <scribe> unifies, rather than having this as a fall back, it
[04:51:38] <scribe> unifies the use of http://And the ability to use a description of
[04:51:40] <scribe> when that has khainkd and that's a really good thing.
[04:51:47] <scribe> NEW SPEAKER: The document is saying NEW SPEAKER: I just (Several people
[04:51:47] <scribe> talking.)
[04:51:51] <scribe> NEW SPEAKER: I think maybe I'm, I want to make sure I'm talking
[04:51:54] <scribe> about the right thing here, but are we talking about in terms
[04:51:59] <scribe> of fall back H T T P? I think this is perhaps just the wrong
[04:52:01] <scribe> term. NEW SPEAKER: Probably. NEW SPEAKER: If this
[04:52:06] <scribe> is what I think it is, this is boot strapping in H T T T P.
[04:52:10] <scribe> It is starting the exact same process, of whether we're
[04:52:15] <scribe> doing, you know, we would normally with a
[04:52:20] <scribe> subscription except we start with H T T P get. And we just
[04:52:22] <scribe> start at a different place in the process, instead of
[04:52:26] <scribe> starting at step one, we start at step four and can go
[04:52:30] <scribe> through the kakt same cycle, just starting in a different place.
[04:52:35] <scribe> This is not fall back. This is boot strapping the process,
[04:52:41] <scribe> okay. So I think this is being, unless I'm really confused
[04:52:44] <scribe> and this is not adding koment Plaintiff's Exhibit tea. This is
[04:52:48] <scribe> starting the exact same process that we defined in here, but
[04:52:51] <scribe> starting not at step one.
[04:52:55] --- Jean-Francois has joined
[04:52:56] <scribe> And it's nothing more than that. And it's a simplified way
[04:52:58] <scribe> for some environments, this is the easiest way to boot strap
[04:53:02] <scribe> because you don't have to worry about all sort of fire wall and
[04:53:06] <scribe> kind of, it's a minimal, you know, boot strapping
[04:53:11] <scribe> mechanism to get into the absolute normal process, that, or
[04:53:15] <scribe> ordinary process. This is not adding new features or steps or
[04:53:18] <scribe> capabilities here. NEW SPEAKER: I don't think there
[04:53:20] --- bhoeneis has left
[04:53:23] <scribe> are two separate discussions here. Namely the discussion is,
[04:53:28] <scribe> user I D, they should be only as a first class citizen of
[04:53:31] <scribe> this particular draft. In a sense that somebody could implement
[04:53:37] <scribe> only H T T P, and do it as maybe only modestly bad about it, and
[04:53:41] <scribe> only doing That. Or somebody could reverse engineer out
[04:53:48] <scribe> of it, that is fall back, and pretend to always fail.
[04:53:52] <scribe> I mean fail as in fail to implement. The subscription part
[04:53:54] <scribe> of it and hope that kind of works of
[04:54:00] <scribe> So my inclination would be to say, recognize this as a first
[04:54:03] <scribe> class citizen that if you don't have a need for a subscription
[04:54:08] <scribe> mechanism and one to do something which is roughly equivalent
[04:54:14] <scribe> in complexity in what you're doing today, and maybe say,
[04:54:18] <scribe> oh, I can get away with doing that model and it still kind of
[04:54:21] <scribe> works model. It has nothing to do with complexity. It has
[04:54:25] <scribe> to do with the reality of that's what people are going do do, as
[04:54:27] <scribe> Jonathan was saying, anyway. NEW SPEAKER: That's
[04:54:31] <scribe> right. This fall back, I put it in, that's how some people seem
[04:54:36] <scribe> to look at it. But it's, you know, like Dan put it, it's
[04:54:41] <scribe> actually a boot strapping mechanism. It's not a Stan alone
[04:54:44] <scribe> mechanism. It's mostly like if you don't have the
[04:54:46] --- sureshk has joined
[04:54:48] <scribe> information necessary, and you can go through from step one,
[04:54:51] <scribe> then user information, get back to where you need to be. NEW SPEAKER:
[04:54:55] <scribe> Well, the question is, can you basically do a system which only
[04:55:00] <scribe> ronly did does H T T P and never
[04:55:03] <scribe> subscribes. NEW SPEAKER: The way it's set up now, it
[04:55:06] <scribe> will lead you back to subscription and whatever else (Several people
[04:55:06] <scribe> talking.)
[04:55:10] <scribe> NEW SPEAKER: My prediction is, 95 percent of the system
[04:55:15] <scribe> will never get to that state and will happily do H T T P. NEW SPEAKER: The
[04:55:18] <scribe> reality is, we can write the spec however we want and people
[04:55:20] <scribe> will do what they want as well. NEW SPEAKER: There's no
[04:55:25] <scribe> reason to dwo anything in this draft. All we need is H T T
[04:55:29] <scribe> P. Don't bother even looking at the draft. We don't need anything in
[04:55:33] <scribe> here to do H T T P configuration. (Several people talking.) NEW SPEAKER:
[04:55:38] <scribe> You need to find out where to go to. NEW SPEAKER: But
[04:55:41] <scribe> that's not defined in here. NEW SPEAKER: Then we have
[04:55:46] <scribe> a problem. Bigger problem. NEW SPEAKER: I mean, if
[04:55:50] <scribe> you're not going inform do subscription, there's no reason to
[04:55:52] <scribe> even pick up this draft. NEW SPEAKER: That's the whole
[04:55:55] <scribe> idea. It gets back to, you know, the data you get in this
[04:55:59] <scribe> leads back to a subscription. That's the whole idea. NEW SPEAKER:
[04:56:02] <scribe> Sorry. NEW SPEAKER: There is a reason to pick this draft, even
[04:56:06] <scribe> if you're just using H T T P. And it's basically, the fact
[04:56:12] <scribe> that this draft explains how to direct rooiz the different
[04:56:17] <scribe> profiles, partition them between different networks, users
[04:56:21] <scribe> and device or whatever you call it, which may not be
[04:56:25] <scribe> necessarily the way people have implemented this so far. If
[04:56:29] <scribe> I look at the way we have this, in my mind, there's a
[04:56:34] <scribe> couple of steps that need to happen. We need to kind of a
[04:56:40] <scribe> line the general data model, I guess, at a very abstract
[04:56:42] <scribe> level, as a first step.
[04:56:49] <scribe> The notification mechanic, I don't think is that complicated. I don't think
[04:56:53] <scribe> we do a good job of explaining the boot strap sequence in
[04:56:57] <scribe> the document. Although I do think it's getting better. But
[04:57:00] <scribe> it's not rocket science. I mean, doy think that people
[04:57:04] <scribe> will implement this. Because people will understand the
[04:57:09] <scribe> value of a notification. Having to do a, but we need to
[04:57:13] <scribe> publish this. I mean, in my mind, the biggest problem is
[04:57:16] <scribe> not that it's complicated. The fact that it's taking so long
[04:57:19] <scribe> that people are starting to give up on it and people are
[04:57:23] --- alexis has left
[04:57:24] <scribe> saying, we'll just keep our H T T P forever and figure out some
[04:57:29] <scribe> other hack because we cannot make up our
[04:57:31] <scribe> minds. And I think we need to stop farting
[04:57:34] <scribe> around and issue the draft. NEW SPEAKER: Okay. We are
[04:57:37] <scribe> cutting the line for this particular issue and we appreciate
[04:57:39] <scribe> brief and concise comments. NEW SPEAKER:
[04:57:46] <scribe> Jay and Jason. We've got several hundred service providers
[04:57:50] <scribe> that have deployed and they've all deployed with H T T P based
[04:57:53] <scribe> mechanisms. And the reason that happened is because there's
[04:57:56] <scribe> nothing coming out of the working group on how to do this a different
[04:57:57] <scribe> way.
[04:58:02] <scribe> So, the more we delay, the more and more service providers
[04:58:06] <scribe> will deploy proprietary mek nition ms, such as the one we do.
[04:58:11] <scribe> And we wonlt solve the problem. So I think the document is
[04:58:14] <scribe> pretty close right now, and we should just move forward.
[04:58:19] <scribe> If you want to do H T T P, you'll just go ahead and do it like you are
[04:58:20] --- mcharlesr has joined
[04:58:21] <scribe> now. NEW SPEAKER: Just a quick question. I'm more
[04:58:22] --- alexis has joined
[04:58:26] <scribe> confused because it was mentioned earlier that we should use
[04:58:30] <scribe> the initial boot strap mechanism, but if the draft doesn't
[04:58:35] <scribe> specify how to get the URL, I'm not sure how useful this is. NEW SPEAKER:
[04:58:38] --- tomkri has joined
[04:58:41] <scribe> Keith, some of what I'm hearing, is not a problem.
[04:58:47] <scribe> Maybe something that should be stripped out.
[04:58:56] <scribe> NEW SPEAKER: Okay. Rohan and sdmoo okay. So we like
[04:58:58] <scribe> to defer this discussion to the list. NEW SPEAKER: I'll
[04:59:01] <scribe> respond to that Henning. NEW SPEAKER: And you have one
[04:59:04] <scribe> last issue? NEW SPEAKER: Yes, one more. Hopefully
[04:59:11] <scribe> not as controversial. NEW SPEAKER: Some of you have questioned
[04:59:16] <scribe> which in the past so I'm posting it here. Do we need
[04:59:19] <scribe> local network profile? And if so, why?
[04:59:23] <scribe> NEW SPEAKER: Rohan. Do you want to do session policy?
[04:59:28] <scribe> If the answer is yes, then you need network profile. I
[04:59:32] <scribe> think it's a simple question and a simple answer. NEW SPEAKER:
[04:59:36] <scribe> Any thoughts?
[04:59:40] <scribe> I'm posting this to the working group. NEW SPEAKER:
[04:59:44] <scribe> I think the document would be finished sooner with local
[04:59:49] <scribe> network profile than debating it. NEW SPEAKER: I think
[04:59:54] <scribe> it could be done as an extension, but, I agree with Collin. NEW SPEAKER:
[04:59:57] <scribe> So are we saying, take it out of the --
[04:59:57] <scribe> (Several people talking.)
[05:00:01] <scribe> NEW SPEAKER: I just wanted to get a response to that. Just
[05:00:05] <scribe> want to make sure that we are all on the same page. NEW SPEAKER:
[05:00:08] <scribe> Keep it. NEW SPEAKER: The basic problem that we have
[05:00:16] <scribe> is, we don't have a red ee framework, sorry. Data model. So
[05:00:17] <Jean-Francois> NEW SPEAKER == Henning S.
[05:00:19] <scribe> all of us have different notions as to what goes where. So,
[05:00:24] <scribe> is it truly the case for example, that you have a network
[05:00:27] <scribe> profile is just session policy as defined already. I don't
[05:00:30] <scribe> think it says that anywhere so we don't know. So everybody has
[05:00:35] <scribe> their own notion as to what goes where, which makes it hard
[05:00:39] <scribe> to know whether it's not a retrieval mechanism that I'm worried
[05:00:43] <scribe> about, just one more URL to deal with. It's the more
[05:00:46] <scribe> things you have, two versus three for example, the more
[05:00:50] <scribe> possibilities there for overlap and combinatorial, what happens if this
[05:00:54] <scribe> fails and that, and how, where do I get information and what happens if
[05:00:56] <scribe> it gets updated later. All of these things, that's what
[05:00:58] <scribe> causes problems later.
[05:01:03] <scribe> It's not subscribe to one more URL. It's essentially a data
[05:01:06] <scribe> model things, where three is much more complicated than two,
[05:01:09] <scribe> particularly where, as soon as you have three, there's a
[05:01:13] <scribe> big problem with the middle one. NEW SPEAKER: I agree
[05:01:17] <scribe> with the concept of the data model. And this framework
[05:01:21] <scribe> explicitly provides anything about the data model and it's an issue
[05:01:25] <scribe> we need to deal with. NEW SPEAKER: Logic weapon to
[05:01:29] <scribe> point to our extremities, that's all. NEW SPEAKER: I
[05:01:36] <scribe> think the data model is emerging discussion that we had, you get
[05:01:40] <scribe> the same value, which one do you use, it's outside the
[05:01:45] <scribe> scope of the framework than what we need to put in the data
[05:01:46] <scribe> model. NEW SPEAKER: All I'm saying is (Several people
[05:01:47] <scribe> talking.)
[05:01:49] <scribe> NEW SPEAKER: Three items merge. (Several people
[05:01:49] <scribe> talking.)
[05:01:53] <scribe> NEW SPEAKER: Okay. NEW SPEAKER: I think that's pretty
[05:01:55] <rohan> That was Volker Hilt
[05:01:57] <scribe> much what I had. So just for the record, we're going to keep
[05:02:01] <scribe> the local network profile type for now, and data model
[05:02:06] <scribe> discussions that's something we need to deal with. That's pretty
[05:02:09] <scribe> much what I have. So thanks. NEW SPEAKER: Let me
[05:02:12] <scribe> remind you that this is the work of the design team. We are
[05:02:15] <scribe> having weekly calls. If you have an opinion on these, like
[05:02:19] <scribe> people going to the Mike that they are not in that design
[05:02:21] <scribe> team, please contact the chairs, because this is the only way
[05:02:25] <scribe> to progress fast and I think this is one of the most important
[05:02:29] <scribe> items we have in our charter. So please volunteer, join the
[05:02:33] <scribe> calls, provide your feedback so we can actually wrap up this as soon
[05:02:33] <scribe> as possible.
[05:02:42] <scribe> And the next presentation will be vok vok ker. NEW SPEAKER:
[05:02:46] <scribe> This is a quick update dash NEW SPEAKER: Hello? NEW SPEAKER:
[05:02:47] <scribe> Microphone is not working.
[05:02:58] <scribe> NEW SPEAKER: All right. That's better. So this is a
[05:03:02] <scribe> quick update on the session policy framework draft and the
[05:03:04] <scribe> event package for session specific policies.
[05:03:08] <scribe> NEW SPEAKER: Again, let me clarify. I didn't put
[05:03:14] <scribe> these two drafts in there to make it short, so the presentation will be
[05:03:19] <scribe> on the third draft but he will volunteer to give a status
[05:03:21] <scribe> update on these two drafts. NEW SPEAKER: This is very
[05:03:25] <scribe> brief. There were lots of changes that are discussed at the last
[05:03:27] <scribe> IETF meeting or based on comments on the
[05:03:27] --- akiniemi has left
[05:03:32] <scribe> mailing list. The only thing that's new is the usage of policy
[05:03:36] <scribe> draft. Now, you either have to use, if you receive pol
[05:03:39] <scribe> east, you have to use those policies or you must not set up the
[05:03:44] <scribe> session. So essentially a user agent that complies with this
[05:03:46] <scribe> specification would not violate any policies that it
[05:03:50] <scribe> receives, I mean, accept them or not set up the session.
[05:03:56] <scribe> There are no major changes in the event package draft, so I think
[05:04:01] <scribe> both drafts can are actually ready for working group last call.
[05:04:04] --- mcharlesr has left
[05:04:08] <scribe> Okay. This is the user agent profile data set draft, this is
[05:04:12] <scribe> actually about, this draft has not received as much attention
[05:04:16] <scribe> as the other ones, so we'll talk a little more about this
[05:04:16] <scribe> draft.
[05:04:24] <scribe> The biggest change that happened was that it became apparent
[05:04:29] <scribe> that we essentially need a separation between session
[05:04:32] <scribe> information documents and session policy documents and I'll
[05:04:35] <scribe> talk more about this issue on the next slide, but this has
[05:04:38] <scribe> been a major change in this draft, essentially, that we are
[05:04:42] <scribe> encoding session information that essentially things that are
[05:04:46] <scribe> in S T P announcement that we're sending to the policy
[05:04:49] <scribe> server, this is one type of dock mingt we need and the other
[05:04:53] <scribe> one is SIP session policies that we had before, delivered to
[05:04:55] <scribe> the policy agent back to the user agent.
[05:04:59] <scribe> Another change that is related to that that I made in the draft, is that I
[05:05:02] <scribe> added rules for mapping between SDP and session information
[05:05:08] <scribe> documents. So fv you have a SDP announcement, it's very
[05:05:11] <scribe> easy to create session information document and you know,
[05:05:15] <scribe> it's very easy for a user agent to create those documents.
[05:05:18] --- gas has left: Replaced by new connection
[05:05:19] <scribe> And there were a couple of changes to X M L elements and
[05:05:23] <scribe> attributes that were discussed in the last IETF meeting and I'm
[05:05:24] <scribe> not going overall of them.
[05:05:31] <scribe> This is the major change that happened in the draft. It
[05:05:36] <scribe> turned out that we really have two different usagees of this format
[05:05:39] <scribe> that have different semantics and we have the session
[05:05:41] <scribe> information documents that are used for session specific
[05:05:45] --- gas has joined
[05:05:46] <scribe> policies and what happens is that, a user agent takes an SDP
[05:05:51] <scribe> announcement, and converts that to this session info
[05:05:54] <scribe> document, and by this I mean, putting media strings and
[05:06:00] <scribe> things like that into this format. And we had discussed this
[05:06:04] <scribe> on past IETF meeting. And then the, since that, the policy
[05:06:08] <scribe> server looks at that and modifies the document so
[05:06:12] <scribe> that this document is compliant with policies and returns the
[05:06:13] <scribe> modify document to the user agent.
[05:06:16] <scribe> So this is actually very similar to the idea that we had
[05:06:21] <scribe> initially, where we wanted do send SDP announcement toll policy
[05:06:25] <scribe> server, and the policy server modify the announcement. Now
[05:06:30] <scribe> we're sending the policy info to the policy server and has a
[05:06:34] <scribe> couple of additional values and that's modify by the policy
[05:06:34] <scribe> server.
[05:06:41] <scribe> The second usage of this format is actually does the
[05:06:46] <scribe> user have before, to even code policies that are sent from
[05:06:49] <scribe> the policy server to the user agents. This is
[05:06:51] <scribe> for session independent policies and those policies are
[05:06:54] <scribe> essentially independent of the session so you would say,
[05:06:57] <scribe> well, video is not allowed and you apply that for all your
[05:06:58] <scribe> sessions descriptions.
[05:07:03] <scribe> So as a consequence of those two different usagees, I
[05:07:07] <scribe> defined two route elements for the two different documents
[05:07:12] <scribe> types, there's a route element for session policy and
[05:07:16] <scribe> documents. But inside those different route elements, there
[05:07:23] <scribe> are the same X M L elements to include property like video or
[05:07:27] <scribe> audio code Defendant's Exhibit and
[05:07:30] <scribe> codecs. And we're using the same elements there.
[05:07:36] <scribe> This was a previous, can you go back to the previous slide.
[05:07:40] <scribe> This was a major change and I'd like to get some feedback, if people have thoughts
[05:07:42] <scribe> if this is the right thing to do?
[05:07:47] --- sureshk has left
[05:07:54] <scribe> NEW SPEAKER: I mean, just send me an e-mail. NEW SPEAKER:
[05:07:57] <scribe> These documents did go through working group review in the
[05:08:00] <scribe> past. We did get comments, but we still need more
[05:08:03] <scribe> feedback. NEW SPEAKER: This has changed since the review. NEW SPEAKER:
[05:08:07] <scribe> Right. So the expectation will be that we expect the
[05:08:11] <scribe> previous re vi errs to take reviewers to take
[05:08:16] <scribe> a look. NEW SPEAKER: Just one clarification
[05:08:21] <scribe> question, the subscription mechanism here, how about since we
[05:08:26] <scribe> just said local network policy is, how true the accurate
[05:08:29] <scribe> discussion to make sure these are the same or at least closely
[05:08:32] <scribe> related or have you thought about that? NEW SPEAKER: I
[05:08:37] <scribe> mean, the local profile is essentially the session
[05:08:41] <scribe> independent policy mechanism. For session specific pol
[05:08:45] <scribe> policies, we have the other ee venlt packages defined here.
[05:08:49] <scribe> And I mean, I think the scenario is really different,
[05:08:53] <scribe> because we're sending this information in a subscribe body to policy
[05:08:57] <scribe> server. I mean, it's, I don't see a close relation between
[05:09:00] <scribe> the two. They are not completely different, but the
[05:09:05] <scribe> scenario is different, in that we're sending one particular
[05:09:08] <scribe> session description to the policy server, that is modified and
[05:09:11] <scribe> then you get back the response in a notify. So it's slightly
[05:09:14] <scribe> different than the case where you get a policy from the policy
[05:09:15] <scribe> server.
[05:09:22] --- Robert has joined
[05:09:23] <scribe> Oh okay.
[05:09:29] <scribe> This is actually a non technical issue. The draft depends on
[05:09:33] <scribe> the U A data set. There was a discussion that we should a
[05:09:40] <scribe> line the draft with the U A data set so this draft inherits a
[05:09:45] <scribe> couple of attribute definitions and in hearths
[05:09:49] <scribe> all inherits all the U A merging in the data
[05:09:52] <scribe> set. And that essentially, I think is necessary to deliver
[05:09:58] <scribe> session policies long with other configuration, and I mean, we're
[05:10:03] <scribe> using the local profile, I think it makes sense to have both in
[05:10:04] --- swb has joined
[05:10:04] <scribe> the same data set framework.
[05:10:10] --- sureshk has joined
[05:10:10] <scribe> The problem is that the U A data set item is not a working group item
[05:10:13] --- Jelte has joined
[05:10:14] <scribe> yet. And I don't think I don't know if we
[05:10:18] <scribe> should make a a work being group item or decouple the drafts. NEW SPEAKER:
[05:10:22] <scribe> This goes back, I'm particularly worried about the last
[05:10:27] <scribe> merging rules, because if we get through the back door, and
[05:10:31] <scribe> accept that we need to be merging, I'm really worried,
[05:10:33] <scribe> because this is one of those things where we have had all
[05:10:37] <scribe> kinds of complexity discussions here, just a few minutes
[05:10:42] <scribe> ago, and this is the, I'm 99 point 9 percent sure that won't
[05:10:46] <scribe> be implemented correctly. Because the merging gets even more
[05:10:50] <scribe> messy once you have failures. And what happens if something,
[05:10:53] <scribe> one part of this configuration stuff didn't succeed the first time
[05:11:00] <scribe> around? Do you merge with call, or what happens if that is
[05:11:02] <scribe> lost mid call. Or there's all kinds of things that
[05:11:03] <scribe> can occur.
[05:11:07] <scribe> And I think we're way over engineering at this point. So,
[05:11:11] <scribe> really, I don't think anybody has paid attention to this merging
[05:11:17] <scribe> stuff. And some of us have expressed serious misgivings.
[05:11:22] <scribe> And to bring it in through the back door now seems to me to be
[05:11:25] <scribe> a big mistake. NEW SPEAKER: Okay. So we would like to
[05:11:29] --- swb has left
[05:11:29] <scribe> have discussions on the list. And this draft, they were
[05:11:32] <scribe> already reviewed and gone through working group last call yet,
[05:11:36] <scribe> so they will be reviewed once more. So that's something to
[05:11:36] <scribe> keep in mind.
[05:11:38] <dwillis@jabber.org> To summarize: Wow. This is complicated.
[05:11:40] <scribe> On on the particular slide that he's showing, we would like to get
[05:11:42] <scribe> the opinion, probably from Dan, who is the editor of the
[05:11:47] <scribe> other draft, and for people working on it. What would be the dpas test way,
[05:11:52] <scribe> re fastest way to finish both drafts? It was agreed
[05:11:56] <scribe> basically in the past they should be together. And this is how they look
[05:12:01] <scribe> now. But maybe at this point it looks like if we have them e
[05:12:05] <scribe> separate, that would be the fastest path. We don't want to
[05:12:09] <scribe> do what Henning is saying, just create something be then we have
[05:12:11] <scribe> problems when we work on that draft.
[05:12:15] <scribe> Does anybody have any opinion? Yes, Dan is going, great. NEW SPEAKER:
[05:12:29] <scribe> I think we have that merging discussion. Because you know,
[05:12:34] <scribe> I, I think that the, you know, the requirement from, for
[05:12:40] --- sbrim has joined
[05:12:41] <scribe> merging does get impact on what we want to be able to describe
[05:12:46] <scribe> in your disk. I don't think that it makes it anymore
[05:12:51] <scribe> complicated, not, you know, the data scheme, not the
[05:12:55] <scribe> merging. You can argue whether that makes things complicated
[05:12:58] <scribe> or not. But just talking about the schema, there are some
[05:13:01] <scribe> potential requirements that merging may have impact.
[05:13:07] <scribe> I think we have that, you know, the discussion of you know, if
[05:13:10] <scribe> we support merging or not. NEW SPEAKER: Once we
[05:13:14] <scribe> have that settled, because that's discussion we
[05:13:16] <scribe> need to have, would you be happy to have
[05:13:19] <scribe> the draft separate or -- NEW SPEAKER: I mean, there
[05:13:21] --- teemu has joined
[05:13:24] <scribe> isn't much, I mean shing merging out, I mean,
[05:13:28] <scribe> it would, you know, we don't need to support merging. I
[05:13:32] <scribe> mean shing I don't think, I don't see the merging as being a
[05:13:36] <scribe> huge volume of the data. Of the document. Certainly, I
[05:13:42] --- sbrim has left
[05:13:42] <scribe> suppose we could split it. But and define schema that, you
[05:13:47] <scribe> know, would support the requirements that might be for
[05:13:53] <scribe> merging. And not have the part of that in a separate draft.
[05:13:59] <scribe> We could basically, merging just a set of rules what do you
[05:14:02] <scribe> do whether there's overlap? And certainly, that could be except
[05:14:05] <scribe> e rated into the draft. NEW SPEAKER: Basically,
[05:14:10] <scribe> yes, it's clear. As next step, let's have the purging
[05:14:14] <scribe> merging discussion on the list and let's decide how to process
[05:14:16] <scribe> those drafts. That was the last slide. NEW SPEAKER: There's
[05:14:19] --- joshlitt has joined
[05:14:20] <scribe> one more. This is the status and next steps are, I we need
[05:14:24] <scribe> to resolve this issue that we just discussed and clean up a
[05:14:27] <scribe> couple of things and again I'd like to get more feedback. It
[05:14:30] <scribe> would be great if more people could read the draft and provide feedback. NEW SPEAKER:
[05:14:33] <scribe> So we'll schedule the working group last call as soon as we
[05:14:36] <scribe> finish the merging discussions. Thank you.
[05:14:44] <scribe> NEW SPEAKER: Yes. NEW SPEAKER: So next speaker I
[05:14:48] <scribe> think is Jonathan.
[05:14:55] <scribe> Let double check. Yes. It is Jonathan on overload design team.
[05:14:59] <scribe> NEW SPEAKER: Okay. Thank you. Next slide.
[05:15:04] <scribe> So, as a background, I don't think folks may not be aware of
[05:15:07] <scribe> what's going on here. We had the requirements document that defined
[05:15:13] <scribe> a problem. And at the last meeting, introduced simulation
[05:15:16] <scribe> model. It's a study, and we had a couple of drafts that were
[05:15:20] <scribe> merged to fix it. But there's still a lot of pretty hard
[05:15:23] <scribe> open technical questions on the mechanism. In particular, what is
[05:15:25] --- dwillis@jabber.org has left: Replaced by new connection
[05:15:27] <scribe> dm fact the suitable overload control method? What kind of
[05:15:32] <scribe> feedback do we require? Is it a load value, a percentage?
[05:15:39] <scribe> Are we using TCP, increase, decrease. How do we have
[05:15:42] <scribe> achieve fairness, what's the format of feedback. What's
[05:15:49] <scribe> the type of granularity tea. It's hard to get it right. And at the epd of the
[05:15:52] <scribe> day you spend a lot of time and produce a simple algorithm but
[05:15:55] <scribe> it's a complicated thinking to produce a correct.
[05:16:00] <scribe> So it became clear that a coordinated design team was needed
[05:16:02] <scribe> particularly to focus on simulation work.
[05:16:08] <scribe> January 2007 I got a design team put together to work on this by
[05:16:13] <scribe> taking experts in this area, many of which do not parts in
[05:16:21] <scribe> IETF who have extensive experience with congestion management
[05:16:24] <scribe> in the telephone area where the problems are not new. These
[05:16:31] <scribe> are the current folks, these are people that were recommended
[05:16:33] <scribe> by IETF folks, and said this is our guy who knows all
[05:16:37] <scribe> about the stuff and has worked on it for the last 20 years or
[05:16:39] <scribe> whatever, this is the kind of -- next slide.
[05:16:43] <scribe> What is the design team doing? It's been meeting regularly since
[05:16:45] --- cullenfluffyjennings@gmail.com has joined
[05:16:47] <scribe> January, about every two or three weeks on average. We're
[05:16:54] <scribe> doing work over dedicated sites and our objective is
[05:16:58] <scribe> to run simulations, to work through proposed algorithms and come
[05:17:01] <scribe> up with a recommendation. So our first step was to take the
[05:17:06] <scribe> simulation model in the draft, where the requirements draft,
[05:17:10] <scribe> vet it, simply it for some initial work, and begin to see
[05:17:14] <scribe> if we can independently implement the simulation model and
[05:17:17] <scribe> independently verify the problems with the same results, just
[05:17:22] <scribe> let's first check that the problems we've been talking about show up in the
[05:17:26] <scribe> simulations with the different simulators if we all implement
[05:17:26] <scribe> this model.
[05:17:29] --- dwillis@jabber.org has joined
[05:17:31] <scribe> We've already had some initial simulation results to demonstrate
[05:17:35] <scribe> the problem and that's moving along. Next slide.
[05:17:39] <scribe> So, what we will then do is get into the bulk of the work now. And
[05:17:43] <scribe> the bulk of the work is to start to run simulations on proposed
[05:17:48] <scribe> algorithms, to fix this thing up. And once we sort of
[05:17:54] <scribe> narrow it down to a few key proposed algorithms, run more
[05:17:58] <scribe> extensive simulations on bigger networks, more use cases,
[05:17:59] --- fparent@jabber.org has joined
[05:18:03] <scribe> complicated topology jees, mixed virments,
[05:18:07] <scribe> environments and then ultimately klund on a recommended algorithm in June.
[05:18:12] <scribe> So we want to produce a document that will be ready for the Chicago
[05:18:16] --- partim has joined
[05:18:16] <scribe> IETF, that has a design team recommendation to the working
[05:18:20] <scribe> group on what the overload algorithm should do. Of course,
[05:18:24] <scribe> as with any other document, this gets review and
[05:18:29] <scribe> comments by the working group and ultimately the working group
[05:18:32] <scribe> can accept it or not. But we hope to educate the working
[05:18:36] <scribe> group on what the experience is in the simulation, why this you
[05:18:38] <scribe> know, made us choose this path.
[05:18:43] <scribe> Possibly documenting the actual simulation results themselves in a
[05:18:47] <scribe> information document. That's a lot of work for ultimately
[05:18:51] <scribe> what's an intermediate deliverable. So I'm not sure we can
[05:18:51] --- eburger has joined
[05:18:54] <scribe> do that. Certain results can be made available informally.
[05:18:57] <scribe> Any questions, comment, concerns, anything like that?
[05:19:03] <scribe> Lovely. Thank you. NEW SPEAKER: I just want to
[05:19:06] <scribe> highlight that the requirements document is already a working group document.
[05:19:10] <scribe> And we plan on working group last calling that in the
[05:19:12] <scribe> next few months. So people should look at this and make sure
[05:19:15] <scribe> they're in agreement. I also want to highlight that I think
[05:19:19] <scribe> the design team is working really well and it's really ideal
[05:19:21] <scribe> that there's not IETF participants and
[05:19:25] <scribe> it's happening outside the meeting and a lot of progress is being
[05:19:27] <scribe> made. NEW SPEAKER: Would ilt get in the way if you
[05:19:31] <scribe> start to get some of the early simulation results to put them out where
[05:19:34] <scribe> folks can start to wrap their heads around them. NEW SPEAKER:
[05:19:39] <scribe> That's a good idea, sure. That should be no problem. NEW SPEAKER:
[05:19:45] <scribe> We can make it public. We have a yahoo groups collaboration site which
[05:19:49] <scribe> is not public at the moment but probably could make it so.
[05:19:56] <scribe> Okay. All right. Now for the fun part. NEW SPEAKER:
[05:19:59] --- partim has left
[05:19:59] <scribe> Yes, the fun part. NEW SPEAKER: So next
[05:20:03] <scribe> presentation is on a thread ha has been going for a time. NEW SPEAKER:
[05:20:06] <scribe> And going and going and going. NEW SPEAKER: And it
[05:20:09] <scribe> hats a lot of messages. NEW SPEAKER: So service
[05:20:11] <scribe> identification. NEW SPEAKER: All right. So, we
[05:20:14] <scribe> have a lot of time allocated for this discussion. I don't
[05:20:18] <scribe> actually have that many slides. I would like to mostly work
[05:20:21] <scribe> through the slides. I have like 5 of them. To try and
[05:20:25] <scribe> frame the discussion and at least put on the table a proposed compromise
[05:20:29] <scribe> approach to get us out of this rat whole. And then we'll have
[05:20:33] <scribe> this open discussion and I'm sure people can say whatever they want.
[05:20:37] <scribe> I think it's important to highlight, there is an important objective here to
[05:20:42] <scribe> do something. Okay. And you know, ultimately, you know, this
[05:20:48] <scribe> is one of these things where, an Andrew can speak to this more. It's
[05:20:53] <scribe> not a decision between let's not address the service
[05:20:57] --- eburger has left
[05:20:58] <scribe> identification problem or do we. We're going to do something in
[05:21:02] <scribe> this area. And the real issue is, is it guided by an IETF
[05:21:06] <scribe> recommendation on the problem or not. And the recommendation
[05:21:10] <scribe> could be whatever our recommendation it is, a new header, a
[05:21:12] <scribe> new technique, whatever. But whatever it is, what does the
[05:21:15] <scribe> IETF have to say generally about the problem of service
[05:21:18] <scribe> identification and how we think this problem ought to be
[05:21:18] <scribe> treated.
[05:21:23] <scribe> If we say something, there's some chance it is gets used
[05:21:26] <scribe> otherwise they use the existing contact thing and we have service
[05:21:31] <scribe> parameters defined bio even know what process that gets contacts
[05:21:36] <scribe> in. And whatever the implication of that is for cooperating
[05:21:40] <scribe> with I N S networks will be whatever it will
[05:21:43] <scribe> be. I think people should keep that in mind.
[05:21:47] <scribe> We're trying to propose something in order to guide these three
[05:21:53] <scribe> GP P decisions based on IETF input and our concerns. So,
[05:21:55] <scribe> keep that in mind. Next slide.
[05:21:59] <scribe> So I'm going to start with examples. Okay. Because this
[05:22:00] --- sureshk has left: Logged out
[05:22:05] <scribe> is, one of the things that's notoriously lacking is what are
[05:22:09] <scribe> we talking about. Every time somebody says service
[05:22:14] <scribe> or application, everybody says we think it's applications and
[05:22:18] <scribe> services or not services, that's an example of application
[05:22:21] <scribe> and not service. Boy what a useless comment that is.
[05:22:23] <scribe> Because everybody has a different definition.
[05:22:32] <scribe> So the most useful mail in the entire thread is about 3,000
[05:22:35] <scribe> messages into the thread that actually gave the most concrete
[05:22:37] --- sureshk has joined
[05:22:39] <scribe> examples of this. So I'm repeating them here and I'm going to
[05:22:42] <scribe> walk through, this is will hopefully get people's
[05:22:43] <scribe> minds going.
[05:22:50] <scribe> The stupid chest example. It's a useless example. Push to
[05:22:54] <scribe> talk, okay. Push to talk is one that's come up. It's come up as an
[05:22:58] <scribe> example because it looks like SIP, it smells like SIP, it
[05:23:03] <scribe> uses SIP messages e, but there's this hidden context, when
[05:23:10] <scribe> I send an invite for a pop session, my originating proxy better include
[05:23:13] <scribe> it in the call path or the whole things falls apart like a
[05:23:16] <scribe> house of cards. How would you know that? What is it that
[05:23:17] <scribe> signals it?
[05:23:21] <scribe> There's some missing information. This is an example.
[05:23:25] <scribe> Another one that was good, let's say we have a multi player
[05:23:29] <scribe> game and we're using voice, for comments like you
[05:23:35] <scribe> know, on a tell the guy he's an idiot or killing spree, people
[05:23:39] <scribe> are familiar with multi player games that have this background
[05:23:43] <scribe> announce err that says things as you're blowing people's heads
[05:23:45] <scribe> off. That kind of thing for voice.
[05:23:50] <scribe> And we've got an MSR P session to exchange game moves, format
[05:23:55] <scribe> and the format of those messages is little text messages. So you
[05:24:00] <scribe> know, application text playing. So if you look at what a
[05:24:04] <scribe> call would like like, if I wanted to play the game with
[05:24:09] <scribe> Henning, I would send invite request SDP and audio and video.
[05:24:14] <scribe> And messaging and S R P with type text.
[05:24:19] <scribe> Looks just like a text chat session, but there is a difference.
[05:24:23] <scribe> And the difference is, a service provider, let's say this is
[05:24:27] <scribe> over a wireless network, may actually want to give different
[05:24:31] <scribe> level quality of service to the voice part. Because the voice here
[05:24:35] <scribe> is not really as important and they may in exact choose to
[05:24:38] <scribe> prioritize it. Features might be different. Might, you
[05:24:41] <scribe> know. You might not want to do this. But you could make a
[05:24:45] <scribe> plausible argument that I don't want to invoke my outbound call
[05:24:50] <scribe> recording feature, which is otherwise on for voice calls for
[05:24:57] <scribe> my video games. Because I'll have a big chat log that says too
[05:25:01] <scribe> much that's not useful. Maybe it is. (Several people
[05:25:07] <scribe> talking.) NEW SPEAKER: We're not required to capture that.
[05:25:09] <scribe> So, you know, features could be different. Billing might
[05:25:12] <scribe> be different. You know, if there is a different user
[05:25:16] <scribe> perceived value, especially if there's different QoS and
[05:25:22] <scribe> feature treatment. You can make an argument
[05:25:23] <scribe> that you should do something different.
[05:25:27] <scribe> Next example. Instant messaging versus
[05:25:30] <scribe> software update. Talk about con fig framework, you know, I
[05:25:34] <scribe> know people are doing this. They just send an instant
[05:25:38] <scribe> message to the phone to tell it to go fetch new software re vision,
[05:25:42] <scribe> because message is just a ton easier than subscribe notify or
[05:25:44] <scribe> unsolicited notify is also used.
[05:25:48] <scribe> Let's look at message. I'm going to send a message request
[05:25:53] <scribe> inform a mobile phone and I'm going to use text plane and if
[05:25:57] <scribe> the context of my text plane, if I, I want this message to be
[05:26:01] <scribe> telling the phone to upgrade it based on the URI or
[05:26:03] --- rsfinlayson has joined
[05:26:04] <scribe> instructions in the text plane or it could be, or I could be having a
[05:26:07] <scribe> chat session. All right. And so again, this is a
[05:26:12] <scribe> message sent to a phone for one purpose of telling it to do con fig update and
[05:26:16] <scribe> another purpose is instant message chat. Same message, same
[05:26:21] <scribe> content type. And we want to do different things, dispatch
[05:26:25] <scribe> them differently on the phone, we better have away of different recent yaiting
[05:26:29] <scribe> them. And indeed for mobile phones thae that's the case.
[05:26:35] <scribe> If you send an S MS toss phone and a provider does, to force a con
[05:26:35] --- teemuk has joined
[05:26:39] <scribe> fig update that doesn't show up in your S MS log, it's not a
[05:26:44] <scribe> user S MS. NEW SPEAKER: Rohan, so, the I M versus
[05:26:49] <scribe> software update case, I sort of feel like we shouldn't be be glor
[05:26:55] <scribe> fiing this with by discussion, I'd like to streed that just
[05:26:59] <scribe> like a contrived chest example. Push to talk, and game,
[05:27:02] <scribe> and I T T P versus video conferencing are
[05:27:04] <scribe> sufficient for us to go keep working on this. NEW SPEAKER:
[05:27:08] <scribe> I think there's a real, I want to keep it in, because it's
[05:27:11] <scribe> going to speak to one of my next points but we don't
[05:27:15] <scribe> -- I'm going to move on, so unless other people want to xhept on
[05:27:18] <scribe> it. NEW SPEAKER: Let you finish and then we'll comment. NEW SPEAKER:
[05:27:22] <scribe> I D P versus video conferencing. So
[05:27:27] <scribe> we'll put aside for the moment whether you should use SIP or
[05:27:30] <scribe> not. I don't want to have that debate.
[05:27:35] <scribe> So if I'm going to browse video content, I'm going to be using
[05:27:41] <scribe> audio and video. And I want to compare IP TV to
[05:27:47] <scribe> conferencing. Both have audio and video. Both might use
[05:27:52] <scribe> the same codecs, and I might only be receiving and not
[05:27:56] <scribe> sending because nobody wants to see my ugly face
[05:27:57] <scribe> anyway, right?
[05:28:00] <scribe> So the invite is going to look pretty much the same. If you
[05:28:04] --- rsfinlayson has left
[05:28:06] <scribe> put the invite and invite from IP TV on the tail they're going
[05:28:10] <scribe> to look the same. But again, you can argue that I want do do
[05:28:13] <scribe> different things. I certainly want to dispatch on the phone
[05:28:13] --- Robert has left
[05:28:16] <scribe> differently or different APs on the phone using this.
[05:28:20] <scribe> And I I'm almost certainly we want different billing.
[05:28:26] <scribe> Again, that might drive off or may not drive off a different
[05:28:30] <scribe> QoS stream. When I send my invite off to a video, you
[05:28:37] <scribe> know, an IP TV session I almost certainly don't want to record the
[05:28:40] <scribe> content of that, because this is not that type of call.
[05:28:43] <scribe> Right. This is an IP TV call. So there is some difference
[05:28:45] <scribe> here that I'd like to affect. Next slide.
[05:28:50] <scribe> Let's focus on this type of example. When I went through
[05:28:54] <scribe> this, I said, here's the root issue. I don't actually care at
[05:28:57] <scribe> all what the definition of service or the difference between
[05:28:59] <scribe> service or application or if anyone
[05:29:04] <scribe> understands this I MS nonsense about application on top of
[05:29:07] <scribe> services. It's all irrelevant for us to understand that. And
[05:29:10] <scribe> the reason is, let's focus on what we do with these things.
[05:29:14] <scribe> Why is it I want to know what the service is? What is it I want
[05:29:15] <scribe> to do with that information?
[05:29:19] <scribe> And what's interesting about these examples, it
[05:29:25] <scribe> points to a very concrete set of things that are actual
[05:29:29] <scribe> activities that I might do. One is invoke application
[05:29:32] <scribe> servers in the network. So one of the problems we're seeing
[05:29:35] <scribe> is I need to include or not, application servers on a call
[05:29:35] --- lliuhto has joined
[05:29:39] <scribe> path, based on some information which I'm not currently seeing
[05:29:43] <scribe> otherwise in the invite. That's the problem that some of these
[05:29:45] <scribe> examples generate.
[05:29:52] <scribe> So, pop for example, the reason in the EUPLS, instant
[05:29:59] <scribe> message what I there's going to be a class of sument many tree services
[05:30:04] <scribe> and applications services which are sensibly invoked or not.
[05:30:09] <scribe> And for pok you wouldn't do out bound lition or call screening. You'll
[05:30:17] <scribe> have an entirely different in bound call screening for pok than
[05:30:18] <scribe> regular telephony.
[05:30:22] <scribe> Difficulties patch in the application. We had a whole thread
[05:30:25] --- schulzrinne has joined
[05:30:25] <scribe> on device architecture and things like that. I receive a
[05:30:30] <scribe> request, if two requests otherwise look identical but I dmeed
[05:30:35] <scribe> to send them different places I need something that tells
[05:30:41] <scribe> me how to dispatch. And I need accounting records.
[05:30:45] <scribe> We just want to say what happened. Okay. So if something different
[05:30:48] <scribe> happened we'd like to be able to account for it. And in
[05:30:53] <scribe> these examples, the SIP messages, even if you accounted, you record
[05:30:56] <scribe> did entire SIP message, you wouldn't see anything different
[05:30:59] <scribe> although something different happened. That's the accounting
[05:30:59] <scribe> issue.
[05:31:04] <scribe> To determine the network quality of sovs, so if I'm looking at
[05:31:09] <scribe> the S rSDP in order to authorize or install QoS or however I'm
[05:31:12] <scribe> going to doyt, I want to do it differently based on this
[05:31:12] <scribe> thing.
[05:31:17] <scribe> I'd like to include additional context to require process the request
[05:31:21] <scribe> at the application layer. So even once I've dispatched the request to the
[05:31:22] --- avwijk has left
[05:31:25] <scribe> right software application, actually, I think it's the same
[05:31:28] <scribe> as dispatch problem. Let me get rid of that.
[05:31:33] <scribe> There's an even separate problem in my draft, it's actually very
[05:31:37] <scribe> orthagonal to the rest of this. If the user would
[05:31:41] <scribe> specifically like to ask the network on a call by call basis to
[05:31:44] <scribe> please include this application server in my call path. And the
[05:31:48] <scribe> example I give is the call recording use case, where I might
[05:31:51] <scribe> not want to have a call recording AP on every call. I milt
[05:31:56] <scribe> only want it on call by call basis how do I signal that? So
[05:32:00] <scribe> I want to insert recording server. I propose a route header
[05:32:01] <scribe> for that.
[05:32:07] <scribe> We also have this the example of, these are fall back things, like this
[05:32:09] <scribe> is a service where if you can't do pok, this is what I can do
[05:32:14] <scribe> instead with you, if you don't support it. So I want to
[05:32:16] <scribe> use the service identifier as a fall back.
[05:32:21] <scribe> Next slide, another issue that comes up is who determines what
[05:32:24] <scribe> the service identifier is, and really, there's as far as I
[05:32:27] <scribe> can tell, there's only a few choices here, is the client
[05:32:31] <scribe> picking it? Is the network determining it by the request?
[05:32:35] <scribe> And one of the things Tom suggested which I thought twavs
[05:32:42] <scribe> clever is maybe I determine it by putting a tag in the network
[05:32:43] <scribe> and keep using that.
[05:32:47] --- schulzrinne has left
[05:32:48] <scribe> So, you know, one of the things I think is clear is why are
[05:32:50] <scribe> folks so botherd by this whole concept?
[05:32:56] <scribe> Personally, why I'm interesting in writing this draft is to
[05:32:59] <scribe> try to prevent this problem. So we're talking about
[05:33:02] <scribe> potentially having a single parameter that drives many many
[05:33:06] <scribe> aspects of system behavior. Quality of service,
[05:33:08] <scribe> accounting, billing, dispatch of application. And so,
[05:33:13] <scribe> all of this given by this one little thing, and so, if a
[05:33:14] <scribe> regular SIP phone,
[05:33:22] <scribe> Let's say some I MS provider does this, Dot version Dot one,
[05:33:25] <scribe> Dot, you know, provider three variant two.
[05:33:33] <scribe> Okay. That is an O MS certified pok variant and then I just
[05:33:38] <scribe> go and implement a vanilla SIP push to talk vair yanlt and I
[05:33:43] <scribe> send an invite and it happens to be an I MS phone. That
[05:33:47] <scribe> invite hits the perimeter of the I N S network and let's say it even
[05:33:49] --- lminiero has joined
[05:33:51] <scribe> passes. We're assuming they're allowing communication from
[05:33:53] <scribe> other SIP phones. We want to enable that.
[05:33:58] <scribe> Now, there's no service tag. And maybe they did pok in a
[05:34:02] <scribe> slightly different way. So now it won't properly be build
[05:34:07] <scribe> or dispatched to the phone or get the right QoS. Even if
[05:34:10] <scribe> that invite gets delivered to the phone it's going to stink.
[05:34:13] <scribe> We will have effectively isolated the world into groups of
[05:34:20] <scribe> users for whom these features work well, and who with everybody
[05:34:23] <scribe> else it doesn't work well. That is not the internet way.
[05:34:28] <scribe> Thank God we don't have 5 versions of IP, right, one for each country and
[05:34:31] <scribe> state in the United States. And some people want that by the
[05:34:35] <scribe> way. And shame on them. IETF, we don't believe? That
[05:34:41] <scribe> garbage. And believe in it at the SIP layer. That's why it
[05:34:43] <scribe> bothers my so much. They cannot do that.
[05:34:48] <scribe> So, next slide. You can see I'm very botherd
[05:34:49] <scribe> by it.
[05:34:52] <scribe> ( Laughter. ) NEW SPEAKER: So some of the things,
[05:34:56] <scribe> so, here's my, I'm pretty much at the proposal. So my
[05:34:57] --- frascone has joined
[05:34:57] <cullenfluffyjennings@gmail.com> Mark this point in audio recording as one of best JDR rants ever :-)
[05:35:00] <scribe> observations here are, some of the things that people want to
[05:35:05] <scribe> use these service tags for, -- what am I saying here?
[05:35:13] <scribe> Okay. So, a lot of these problems that I looked at the
[05:35:19] <scribe> examples previously are corner cases where it's kind of like,
[05:35:23] <scribe> we just don't have that SDP parameter. Go back to the IP TV
[05:35:25] <scribe> versus video conferencing, what if I
[05:35:30] <scribe> had a parameter that specified latency. This is latency sensitive
[05:35:34] <scribe> audio and this isn't. If I had that, then I could
[05:35:38] <scribe> usefully can drive the QoS in the network and do billing.
[05:35:41] <scribe> Maybe the problem isn't that we're missing a service
[05:35:47] <scribe> identifier, we're missing an SDP attribute for that case. You know, offer
[05:35:51] <scribe> list invite comes up all the time. I've got to include these
[05:35:53] <scribe> application servers on the invite and I don't know yet whether
[05:35:57] <scribe> I'm going to do pok or not. I think that's a capability negotiation
[05:36:00] <scribe> problem and maybe there's a better solution which I suggest on
[05:36:04] <scribe> the list, to include a offer preview in the invite. It's
[05:36:08] <scribe> not a real offer but it says, this is what I'm going to do,
[05:36:12] <scribe> if you answer this offer, if you give me an offer that sort of
[05:36:12] --- alexis has left
[05:36:16] <rohan> word!
[05:36:16] <scribe> doesn't match this, we're in trouble. So why don't you
[05:36:23] <scribe> guide your offer based my capabilities. Then you trigger your
[05:36:24] <scribe> stuff off of it.
[05:36:29] <scribe> So instead of in venting a new service concept, fix the
[05:36:33] <scribe> problem. How do you deal with offerless invites with this
[05:36:36] <scribe> treatment. My suggestions is, I came back to this, if
[05:36:40] <scribe> you come to a use case, if it looks like a duck, walks like
[05:36:43] <scribe> a duck, quax like a duck, it's a duck. Okay. If you
[05:36:47] <scribe> have two invites, that they are exactly the same, in every
[05:36:52] <scribe> single way, and you claim they're different, that's because
[05:36:56] <scribe> you haven't figured out what's different about the invite.
[05:36:59] <scribe> When you figure it out, we'll put it in and it will be
[05:37:03] <scribe> different. If there truly is nothing, then they aren't different. So this
[05:37:07] <scribe> comes back to this, you know, quoting the great Dave
[05:37:10] <scribe> somebody, and the whole parameter, do what I need versus do
[05:37:15] <scribe> what I say. And the service parameter is I mean pok, so do
[05:37:19] --- alexis has joined
[05:37:19] <scribe> whatever it is that pok requires. And I don't want that.
[05:37:24] <scribe> I want to have explicit things in the message that tell the network
[05:37:27] <scribe> exactly what it is you want to get the services people are talking
[05:37:27] <scribe> about.
[05:37:33] <scribe> So I want to do, do what I say. So the proposal is, let's
[05:37:36] <scribe> go investigate specific use cases where people are claiming
[05:37:43] <scribe> that the SIP message is not enough for them to determine what
[05:37:47] <scribe> motivates this. Let's add pok. We're missing an option tag. It
[05:37:48] --- avwijk has joined
[05:37:53] <scribe> doesn't have to be a service U RN. Let's do an I T F define to
[05:37:54] <scribe> fix the problem.
[05:37:59] <scribe> Let's add that SDP parameter if we want to deal with this SDP case.
[05:38:03] <scribe> And then what I'd like to do, to help address this concern,
[05:38:03] <frascone> a
[05:38:11] <scribe> is define something called a provider asserted service I D.
[05:38:15] <scribe> It's put on the, it's only valid within a domain, within a trust
[05:38:21] <scribe> domain and it's inserted at the perimeter, and you must be
[05:38:24] <scribe> able to construct it only by dpeeldz in the SIP message. You
[05:38:28] <scribe> don't need to know a magic number. And we'll put some other
[05:38:32] <scribe> musts in there, what if it doesn't work, how you properly
[05:38:35] <scribe> match these things and all that stuff we worked through in the
[05:38:36] <scribe> presence world.
[05:38:41] <scribe> And I'm hoping this is a good compromise proposal. You put it
[05:38:46] <scribe> in the perimeter you don't have to redo it at each hop. So three
[05:38:51] <scribe> GP p P can have what they want. Define the 50 different service
[05:38:52] --- frascone has left
[05:38:54] --- spromanoInPrague has joined
[05:38:55] <scribe> parameter that they like to have. By having this draft, we make
[05:39:02] <scribe> them think about them what values to come up with. To get
[05:39:05] <scribe> the end line changes dealt with in IETF so they
[05:39:09] <scribe> can construct their tags and we don't lose global inter
[05:39:13] <scribe> operability, because everything is still driven off of do what
[05:39:17] <scribe> I say in the SIP message. Thank you for letting me go on for
[05:39:19] <scribe> so long. Discussion?
[05:39:28] <scribe> NEW SPEAKER: Eric bering better ger.
[05:39:29] <scribe> NEW SPEAKER: Go back. (Several people talking.) NEW SPEAKER:
[05:39:32] <scribe> Go back to the exam p pels. Right there.
[05:39:39] <scribe> Okay. This the slide actually, just as everything came
[05:39:43] <scribe> clear to you on your flight out here, this slide made
[05:39:48] <scribe> everything clear to me. And what it made clear to me, the first
[05:39:54] <scribe> example, push to talk over cellular, can you tell me what
[05:40:00] <scribe> the target the request URI is in the invite? What do you put
[05:40:02] <scribe> down today? What are we doing? NEW SPEAKER: They
[05:40:05] <scribe> like it to be the same as U R. NEW SPEAKER: Exactly, which
[05:40:08] <scribe> is incorrect. The target is the push to talk application
[05:40:10] <scribe> server.
[05:40:14] <scribe> For the contact, you know, for recording, what is the target of
[05:40:17] <scribe> the invite? They like it to be the hand set. It is the
[05:40:21] <scribe> recording dash NEW SPEAKER: No, no. It's really not.
[05:40:26] <scribe> In that example, it's an E intermediary, not the target of the
[05:40:31] <scribe> request. NEW SPEAKER: The point being, we're
[05:40:36] <scribe> fundamentally going against the SIP, what SIP was built on.
[05:40:41] <scribe> Saying that I'm not talking from two peers, that
[05:40:46] <scribe> the network is intercepting man geling what I'm doing, trying
[05:40:48] <scribe> to infer what I'm doing and then adding value. NEW SPEAKER:
[05:40:52] <scribe> Right, yes. NEW SPEAKER: And then, I think that's
[05:40:57] <scribe> the, that's the big, the big bother. NEW SPEAKER:
[05:40:57] <scribe> Eric, I mean --
[05:41:00] <scribe> NEW SPEAKER: You know, why this all doesn't fit. NEW SPEAKER:
[05:41:02] --- spromanoInPrague has left
[05:41:07] <scribe> So, if we get wrapped around the network shouldn't have U to
[05:41:12] <scribe> As and application servers, that's all great. A lot of
[05:41:17] <scribe> people feel that way. And people say, we're going do go do
[05:41:21] <scribe> our things and it won't inter operate rate. The reality is
[05:41:25] <scribe> mixed. Some people put stuff in clients,
[05:41:26] <scribe> some people put stuff in the network.
[05:41:32] <scribe> I do think there is a point well made, and in the pok case,
[05:41:33] --- spromanoInPrague has joined
[05:41:35] <scribe> I'm going to go to my phone and you work this today. So I
[05:41:40] <scribe> scroll down my contact list, when I get a number, I can
[05:41:44] <scribe> message it or call it. I don't need a separate URI, to do
[05:41:50] <scribe> those things. And it's unacceptable I think, to say, for
[05:41:53] <scribe> every thing I want to do, I have to have a divide fire for me.
[05:41:59] <scribe> That does a divide fire for me. NEW SPEAKER:
[05:42:05] <scribe> Believe me, if there were no B U As, that's a couple of
[05:42:07] <scribe> hundred million dollars of business I don't have. So I love
[05:42:09] <scribe> those. Those are good.
[05:42:16] <scribe> But in fact, what hit me is the trans skoding. Where the
[05:42:20] <scribe> transcodeing doesn't magically happen. Somebody, somebody which
[05:42:25] <scribe> is in this case, the user interface thing, is saying, not
[05:42:31] <scribe> send it to Jonathan and I have a thing that says, by the
[05:42:35] <scribe> way, calm this server and that's Jonathan. And that does fit
[05:42:36] <scribe> in the SIP argument.
[05:42:43] <scribe> So this is my big bother. You know, the things that are
[05:42:49] <scribe> forgot ten, all these things MSR P, text, plane, please
[05:42:53] <scribe> please please, just send it to the applications review people
[05:42:56] <scribe> and we would have told you instantly, just as you do in my
[05:43:00] <scribe> type of review or URI to say this doesn't work. NEW SPEAKER:
[05:43:04] <scribe> Yes, that's my, on all those things I agree. Just like
[05:43:09] <scribe> if we use, you know, it's not all application slides X M L. You
[05:43:12] <scribe> have a sub layer, right? Which fixes the problem. NEW SPEAKER:
[05:43:21] <scribe> I'll let you get to that. NEW SPEAKER: So, actually,
[05:43:25] <scribe> I like the proposal you put forward but I think it's mitigated by
[05:43:28] <scribe> something else you said, basically we can go out here and
[05:43:31] <scribe> probably do the right thing in the IETF, and it probably
[05:43:35] <scribe> won't be accepted by three GP P and I'm looking at what's up
[05:43:39] <scribe> there and I suspect that's probably not going far enough.
[05:43:52] <scribe> And just sorry. Adam roach for the notes. And just to put a different
[05:43:56] <scribe> point on what Eric was saying, probably the biggest issue is something
[05:44:02] <scribe> coming from the terminal. Is that what happens is a surprise
[05:44:08] <scribe> user agent. And to the user is the consequence. The prospect that a
[05:44:11] <scribe> user agent would be sending something up, that is essentially
[05:44:16] <scribe> opaque to it, and the network may or may not apply different
[05:44:22] <scribe> QoS as a consequence, is a surprising thing. Or it may or may
[05:44:26] <scribe> not include a different application server, that is a surprising
[05:44:26] <scribe> thing.
[05:44:31] <scribe> So, it really is taking things out of control of the user
[05:44:35] <scribe> agent. And I think that's where we're running into problems
[05:44:38] --- rsfinlayson has joined
[05:44:42] <scribe> here. NEW SPEAKER: Okay. I thought, I'm
[05:44:48] <scribe> confused, when you you said you're not going far enough. I
[05:44:53] <scribe> thought you were going to say this isn't enough for three GP P and
[05:44:56] <scribe> then your point was, this is all bad because we shouldn't
[05:45:01] <scribe> have ex split sit activity on a a proxy. So I'm confuse dz
[05:45:04] <scribe> as to your point. NEW SPEAKER: The point is, you're going
[05:45:07] <scribe> halfway down the path -- NEW SPEAKER: That's what we call
[05:45:10] --- rsfinlayson has left
[05:45:10] <scribe> compromise. NEW SPEAKER: No one is going to use it,
[05:45:13] <scribe> but you're compromising your principles is what I'm saying. NEW SPEAKER:
[05:45:20] <scribe> So it's the worst of both worlds. I see. It remains to see
[05:45:24] <scribe> if any proposal would be adopted. NEW SPEAKER: Can I
[05:45:27] <scribe> ask a question about the three GP P time frame. My
[05:45:33] <scribe> understanding is what's there now that we don't like is in (Several people talking.) NEW SPEAKER:
[05:45:36] <scribe> This isn't an urgent item, is it Andrew? NEW SPEAKER:
[05:45:43] <scribe> Well, yes, it is. Release 7 of three GP P is frozen but
[05:45:46] <scribe> this issue is not complete. So there is some text but not very
[05:45:52] <scribe> much. Mostly because people like me vnlt allowed very much to
[05:45:52] --- lminiero has left
[05:45:56] <scribe> get done. And time is running out. And if we don't have something by
[05:45:59] <scribe> the end of this meeting and we can actually say we're working
[05:46:01] --- spromanoInPrague has left
[05:46:03] <scribe> on it, then those of us who have wanted an IETF approach to
[05:46:08] <scribe> this whole problem, will not have anything to offer so we'll have
[05:46:13] <scribe> to hold back. So yes, it is urgent. The time scale is this
[05:46:17] <scribe> meeting, with agreement to have a working group draft on
[05:46:25] <scribe> this, and we need to have a fairly good idea of what the IETF
[05:46:30] <scribe> perspective is on this. Not a solution that can be agreed
[05:46:36] <scribe> that the next three GP P plenary which starts at the end of
[05:46:40] <scribe> May, and working group at the beginning of May. NEW SPEAKER:
[05:46:45] <scribe> Do you mean this is a way to NEW SPEAKER: Use the Mike. NEW SPEAKER:
[05:46:50] <scribe> Sorry. I didn't give my name. Although Mary introduced
[05:46:54] <scribe> me. NEW SPEAKER: Yes, to solve these issues,
[05:46:57] <scribe> here, I think the one that is missing is authorization, based
[05:47:03] <scribe> on subscription, is also like the, this is the, does the
[05:47:08] <scribe> caller allow to impose a service, which is not a concept here.
[05:47:13] <scribe> Jonathan was --
[05:47:18] <scribe> NEW SPEAKER: While I've got the Mike, should I give my
[05:47:21] <scribe> comments. NEW SPEAKER: So three GP p P
[05:47:24] <scribe> would require both parts, the peer part as well as some of the other
[05:47:28] <scribe> parts, right? NEW SPEAKER: I don't know. I'm not
[05:47:32] <scribe> quite sure, because I've just seen these slides maybe a few
[05:47:34] <scribe> minutes before the rest of you. NEW SPEAKER: This was a (Several people
[05:47:37] <scribe> talking.) NEW SPEAKER:
[05:47:42] <scribe> NEW SPEAKER: My sense is, I mean, we clearly have no document which is ready. NEW SPEAKER:
[05:47:46] <scribe> Right. NEW SPEAKER: I think the best we can hope for to tell
[05:47:51] <scribe> Andrew to tell three GP P next week, let's say there is consensus
[05:47:55] <scribe> on a proposal, if there is nltd, you know, my hope is that by
[05:48:01] <scribe> the way, we have no consensus on this proposal, maybe we can come
[05:48:03] <scribe> up with something by Friday and see if there's con sense
[05:48:10] <scribe> uses on it. We need to show progress on it. NEW SPEAKER:
[05:48:13] <scribe> I think we need a design team this week. NEW SPEAKER:
[05:48:15] <scribe> Okay. NEW SPEAKER: Try to come up with something that could
[05:48:19] <scribe> be a working group draft. Get a working group draft before the tend of
[05:48:25] <scribe> May. NEW SPEAKER: Three GP P does not require that,
[05:48:29] <scribe> just I mean, three GP P can has many headers
[05:48:34] <scribe> NEW SPEAKER: P header requires an review. NEW SPEAKER:
[05:48:38] <scribe> This needs to be, P header is not a free ticket to random
[05:48:41] <scribe> header. (Several people talking.) NEW SPEAKER:
[05:48:44] <scribe> No, it's not. NEW SPEAKER: I would rather us write it. NEW SPEAKER:
[05:48:48] <scribe> The process is like that. I'm not saying that we shouldn't review it. NEW SPEAKER:
[05:48:51] <scribe> Right. Right. NEW SPEAKER: No. It does not
[05:48:54] <scribe> require, generally, it gets through a little bit faster
[05:48:59] <scribe> than a working group item. That's what I was height
[05:49:00] --- tobia has joined
[05:49:02] <scribe> lighting. NEW SPEAKER: Should I go back on that? NEW SPEAKER:
[05:49:04] --- philip_matthews has joined
[05:49:11] <scribe> Okay. So, I'm not quite clear whether the compromise,
[05:49:14] <scribe> that last slide is everything that I was proposing, other than what
[05:49:17] <scribe> was in the draft, like the level of what was in the draft before.
[05:49:22] <scribe> A couple of issues from the peer to peer per e expect tivr.
[05:49:26] <scribe> So we have three2 '88 that has defined certain
[05:49:36] <scribe> requirements. And we have drafts about those requirements. You
[05:49:40] <scribe> know one of the requirements is the service identifier to
[05:49:42] <scribe> identify the edge proxy. Right? NEW SPEAKER: I
[05:49:45] <scribe> think we're basically telling them that if there is
[05:49:53] <scribe> something, they have to switch from dwim to dwis. But if there's
[05:49:58] <scribe> smiing they think the client needs to tell the network, it
[05:50:04] <scribe> has to be signald, with no clear implied
[05:50:07] <scribe> semantic. That's the point of this. That's why it's a
[05:50:10] <scribe> compromise proposal. It says, hey, if you want to say, this
[05:50:15] <scribe> is IP TV, versus it's not, you need to be clear how the client
[05:50:19] <scribe> signals this, without having to have service IP TV, because
[05:50:23] <scribe> guarantee, no one else will now what that means.
[05:50:28] <scribe> So that's the piece that's a compromise. There's, and so,
[05:50:31] <scribe> it always is things that are end point signald
[05:50:35] <scribe> but it's just not, we're saying it's not a service I D tag for
[05:50:39] <scribe> everything. NEW SPEAKER: Okay. So, rather than
[05:50:42] <scribe> asserting a service identifier in the end point you're
[05:50:44] --- tobia has left
[05:50:45] <scribe> proposing there's enough information in the message NEW SPEAKER:
[05:50:46] <scribe> Yes. NEW SPEAKER: That they'll know. NEW SPEAKER:
[05:50:48] <scribe> Yes. NEW SPEAKER: And determine that. NEW SPEAKER:
[05:50:51] <scribe> Yes. NEW SPEAKER: And one of the issues of that is on
[05:50:55] --- avwijk has left
[05:50:57] <scribe> the edge. Three GP P I MS, is not in the same network.
[05:51:03] <scribe> It wouldn't necessarily understand. Or subscribe to it on the
[05:51:04] <scribe> network. NEW SPEAKER: Right. (Several people
[05:51:04] <scribe> talking.)
[05:51:10] <scribe> NEW SPEAKER: I seem to vaguely recall Andrew, don't get me
[05:51:12] <scribe> started on this network. NEW SPEAKER:
[05:51:13] <scribe> (Several people talking.)
[05:51:18] <scribe> NEW SPEAKER: It's already totally broken.
[05:51:21] <scribe> (Several people talking.) NEW SPEAKER: You just made a
[05:51:26] <scribe> great argument for another day. One of the reasons it went
[05:51:30] <scribe> that way is because it didn't actually need to have agreement on
[05:51:34] <scribe> exactly what the services and lo and behold we're right back
[05:51:36] --- philip_matthews has left
[05:51:38] <scribe> here where we started. Come on, you know, I think there's room for
[05:51:39] --- tobia has joined
[05:51:43] <scribe> us to push back on some of it. I hailt requirements that says we
[05:51:48] <scribe> require ahead err field whose semantic is GRUU. We are
[05:51:52] <scribe> having trouble differentiating services in the network and we require the
[05:51:55] <scribe> ability to do these things based on user specific request.
[05:51:59] <scribe> How do we do that? That's the requirement that we are really
[05:52:01] <scribe> getting at. NEW SPEAKER: Right. And I think it might
[05:52:05] <scribe> be a good idea to make sure everybody is on the same page that this
[05:52:07] <scribe> is the problem we're solving. Right?
[05:52:11] <scribe> NEW SPEAKER: I'm not sure it is. I think I heard Eric say
[05:52:15] <scribe> the whole thing is still stupid. NEW SPEAKER: I agree this
[05:52:18] <scribe> is basically what the problem is. NEW SPEAKER: I
[05:52:21] <scribe> missed it, yes. NEW SPEAKER: But we
[05:52:25] <scribe> have to work, at least from three GP P, at least I have to
[05:52:28] --- avwijk has joined
[05:52:29] <scribe> work with what I have in 2328 right now. And the people that
[05:52:33] <scribe> don't quant to see an IETF solution, there are many companies
[05:52:37] <scribe> that don't want an IETF solution shing because if we had one,
[05:52:40] <scribe> they'd be willing to work on it earlier, that they basically
[05:52:45] <scribe> didn't pursue that option, is they the use it to attack the
[05:52:50] <scribe> solution that we come up here and says it doesn't meet the requirements.
[05:52:54] <scribe> That's the problem I would face if I took the attempted
[05:52:56] <scribe> proposal -- NEW SPEAKER: I think (Several people talking.) NEW SPEAKER:
[05:53:01] <scribe> I understand. So the question is, is it worth it to try?
[05:53:08] <scribe> You know, in that, one of the things I've had, the IETF
[05:53:15] <scribe> three GP P relationship has been unknee relational. You
[05:53:18] <scribe> know, go make us a protocol that does this.
[05:53:23] <scribe> And they make a protocol. (Several people talking.) NEW SPEAKER:
[05:53:27] --- tobia has left
[05:53:28] <scribe> I think the relationship is mature and we both benefitted from
[05:53:34] <scribe> it. I don't want to demean three GP P, they've been a good
[05:53:38] <scribe> customer. And I think it's perfectly appropriate to say,
[05:53:44] <scribe> if the group agrees, if the group agrees we should use an IETF
[05:53:47] <scribe> solution, we should escalate it and say, hey, come on, you
[05:53:51] <scribe> can't do that. That's going to break SIP. That's not a valid
[05:53:55] <scribe> usage of SIP. I think we're in our rights to say that. NEW SPEAKER:
[05:53:59] <scribe> How do we actually do that, that's the question. I guess we
[05:54:01] <scribe> did that once before. Is that what we're saying? NEW SPEAKER:
[05:54:09] <scribe> I'm personally a fan of a well worded liaison statement. NEW SPEAKER:
[05:54:13] <scribe> Andrew, we have a long line there. NEW SPEAKER: All
[05:54:15] --- liuhto has joined
[05:54:21] <scribe> right. Rohan. So, I really like to rant. I agree
[05:54:27] <scribe> with it. I think that these, that this the set of
[05:54:33] <scribe> services, the ways in which this service identification
[05:54:36] <scribe> functionality needs to be used, I think that we can find
[05:54:41] <scribe> ways to describe all of these things, and for example, for
[05:54:45] <scribe> the, what I saw in the IP TV, versus video
[05:54:48] <scribe> conferencing, I immediately thought of something in the
[05:54:54] <scribe> conferencing, the ex con data model that has a participation
[05:54:56] <scribe> versus streaming field. NEW SPEAKER:
[05:54:59] <scribe> Right. NEW SPEAKER: Is that SDP parameter? NEW SPEAKER:
[05:55:04] <scribe> I think the best, you know, the way that we would probably
[05:55:06] --- fparent@jabber.org has left
[05:55:09] <scribe> be able to do this easily in SIP wrob would be a media
[05:55:12] <scribe> feature tag. NEW SPEAKER: Okay. NEW SPEAKER:
[05:55:17] <scribe> But the, as for the P header, I feel pretty uncomfortable
[05:55:22] <scribe> with that. I'm not absolutely saying, you know, I think
[05:55:28] <scribe> that's the worst idea I've ever heard, but I still feel bad about
[05:55:36] <scribe> RFC 34 six 5, because the, it was the P associated URI
[05:55:42] <scribe> header was this list of headers, or this list of URIs
[05:55:42] --- teemu has left
[05:55:50] <scribe> that are your URIs, but this and the call party
[05:55:55] <scribe> header, basically gave three GP P permission from us to go
[05:56:00] <scribe> and put the wrong URI in the request URI and this was a
[05:56:03] <scribe> problem we were discussing before that Eric brought up. Is that
[05:56:09] <scribe> if I have got two different services and we've had this problem with
[05:56:14] <scribe> GRUU as well, and if I've got two different versions of me on,
[05:56:20] <scribe> running on mobile hand set, I want the URI to address them
[05:56:25] <scribe> in, different. You know, the one I put in the to header,
[05:56:29] <scribe> if the I type something into my mobile phone or the stream I
[05:56:29] --- liuhto has left
[05:56:33] <scribe> would put in the two, could be the same, but the URI can
[05:56:33] --- brockners has joined
[05:56:34] <scribe> still be different for those two services. NEW SPEAKER:
[05:56:35] --- enrico has joined
[05:56:37] --- tobia has joined
[05:56:38] <scribe> Right. So we have vehicle for solving that problem called
[05:56:42] <scribe> presence and my draft talks about it. I think the problem,
[05:56:46] <scribe> and it's unreasonable to expect global worldwide deployment of
[05:56:49] <scribe> presence in order to allow me to send a push to talk. NEW SPEAKER: I don't
[05:56:56] <scribe> think you need presence for that item. I sthi we have
[05:56:58] <scribe> ways that we can go and address each of these specific
[05:57:03] <scribe> requirements, plus the other one Andrew mentioned that I
[05:57:04] <scribe> forgot. NEW SPEAKER: Authorization. NEW SPEAKER:
[05:57:08] <scribe> Authorization. Yes, I think we can go, I think we can do that.
[05:57:14] <scribe> And I think we should at least try to do that this week. If we can't
[05:57:19] <scribe> then maybe we should go with your presentation. NEW SPEAKER:
[05:57:26] <scribe> Okay. NEW SPEAKER: Just a second. John Peterson,
[05:57:29] <scribe> responsible area director. I'd really like this discussion
[05:57:33] <scribe> to remain focused for the time being if we can on whether or
[05:57:36] <scribe> not this is something that we should be thinking on as a problem, rather
[05:57:40] <scribe> than the specific, should it be P headers or something else,
[05:57:45] <scribe> whatever. I personally don't care about that. Paragraph path
[05:57:49] <scribe> if we need to act fast on this, and I need to be bugging the
[05:57:53] <scribe> I A D. We need the first understand whether there's a
[05:57:57] <scribe> commitment in this room to go forward with something along these
[05:57:57] <scribe> lines.
[05:58:01] <scribe> If there is, then we can go forward and talk about the issues.
[05:58:04] <scribe> But this is the thing that I think is most pressing probably
[05:58:08] <scribe> from a perspective of Jonathan, you know, potentially on work
[05:58:12] <scribe> that's very mature and in progress. So please try to keep it
[05:58:16] <scribe> focused. We don't have too much time. NEW SPEAKER:
[05:58:23] <scribe> Eric, as John pointed to, this is correct, you know,
[05:58:27] <scribe> going back to what Adam said, I read your
[05:58:31] <scribe> comments as basically, we probably shouldn't do anything here
[05:58:34] <scribe> at all if we had our choice, but because we're under a lot of
[05:58:40] <scribe> pressure, we should compromise. And you know, without, I would
[05:58:45] <scribe> throw out whether or not us doing anything would be better than
[05:58:51] <scribe> three GP P go around us. We sthud make sure they don't go
[05:58:56] <scribe> around us anyway. So I wouldn't rule out the compromise,
[05:58:59] <scribe> unless you were convinced they were going to accept it. And they were
[05:59:03] <scribe> convinced that the set of rules we were making wasn't so large
[05:59:08] <scribe> that we essentially created a whole that we were trying to fix. NEW SPEAKER:
[05:59:13] <scribe> There's a lot of confusion left here, mainly, you have to
[05:59:21] <scribe> explain how this maps with the I A D document, and I'm so
[05:59:26] <scribe> confused now, that I think this is the a plane denial service
[05:59:31] <scribe> attack on end points, and it's not close service
[05:59:41] <scribe> providers. So it's perfectly legitimate to have three GP P
[05:59:46] <scribe> and have such models and on the internet and supposed to be able
[05:59:50] <scribe> to connect any end point and another end point can understand
[05:59:53] <scribe> it. I think this is the wrong place. Unless you can
[05:59:57] <scribe> clarify to say you don't want to get wrapped around, like John
[06:00:02] <scribe> Peterson said, yes, you have to get wrapped around it and explain
[06:00:07] <scribe> it crystal clear how this maps to the document, the latest one is in
[06:00:11] <scribe> the specs. NEW SPEAKER: So Henry, my
[06:00:15] <scribe> objective for on standing in front of this room is I want to
[06:00:19] <scribe> preserve this property of the internet and I'd like to go do it
[06:00:21] <scribe> between internet phones and three GP P phones. NEW SPEAKER:
[06:00:26] <scribe> Then you have to explain why tht not an
[06:00:27] <scribe> outright service attack on the competition. NEW SPEAKER:
[06:00:30] <scribe> Okay.
[06:00:39] <scribe> NEW SPEAKER: I think this proposal addresses a very real
[06:00:49] <scribe> problem, so it's for people like us to have clarification.
[06:00:55] <scribe> And this implementation on the domain, is there anyway to
[06:00:58] <scribe> make it more general? NEW SPEAKER: No. NEW SPEAKER:
[06:01:03] <scribe> Are you -- NEW SPEAKER: I mean, that's the definition.
[06:01:09] <scribe> That's sort of asking, can we make P S cert work, even if they
[06:01:13] <scribe> don't have strus between each other. It fundamentally
[06:01:18] <scribe> doesn't work. The whole idea is, this is a summarization
[06:01:23] <scribe> technique, of a SIP message, because
[06:01:27] <scribe> you trust that person is running the same algorithms and your same
[06:01:30] <scribe> notion of services. If you interpret that information when you have
[06:01:35] <scribe> no idea who did that, no. It's meant for a trust domain.
[06:01:42] <scribe> NEW SPEAKER: Eric again. Aren't you going to say anything about the
[06:01:47] <scribe> proposed one? I'd like the proposal, but let me say the
[06:01:52] <scribe> caveats and they're not how I want it changed but they're the things that
[06:01:59] <scribe> must be present to make me stop complaining on on the list. NEW SPEAKER:
[06:02:04] <scribe> I think that's an empty step. NEW SPEAKER: That's
[06:02:09] <scribe> true. The beauty of SIP for somebody who has been doing S L 7 for
[06:02:13] <scribe> years, is service interaction, problems, feature interaction
[06:02:21] <scribe> problems. And I know Henning has sent me dirty
[06:02:21] --- teemu has joined
[06:02:24] --- teemu has left
[06:02:24] <scribe> words. Come about because we have bundles of
[06:02:27] <scribe> things that the network does and things that end points
[06:02:31] <scribe> do, we call them features. And they're bundled together and
[06:02:34] <scribe> they work in mysterious ways when you start combining
[06:02:39] <scribe> those bundles. And the beauty of the SIP approach, the
[06:02:43] <scribe> beauty of internet architecture is those things are pretty
[06:02:45] --- avwijk has left: Replaced by new connection
[06:02:46] <scribe> small and they are independent and you're free to compose them
[06:02:47] <scribe> anyway you want.
[06:02:51] --- lliuhto has left
[06:02:52] <scribe> In fact, since you are composing them, you have an idea and
[06:02:57] <scribe> clue of how this interact and in fact, they'll act the way you want
[06:03:01] <scribe> them to. So the part of the proposal that says, do what I
[06:03:09] <scribe> say, say what I mean, is great. The reality of why do we
[06:03:15] <scribe> have RSVP. It takes too much stuff. So the idea is,
[06:03:18] <scribe> yes, somebody, I'm noting going to say a service
[06:03:23] <scribe> provider, somebody may calculate an opaque stream, that is
[06:03:28] <scribe> whatever, it could be the summation of what it is. It could include the
[06:03:32] <scribe> database to see if they're authorized to do the service. That's great.
[06:03:35] <scribe> Because you can always go back. You know, we also have
[06:03:40] <scribe> the words you must not rely on that. But three GP P people
[06:03:42] <scribe> will do what they do. NEW SPEAKER: That's why this is
[06:03:44] <scribe> a proposal. NEW SPEAKER: That's right. And those
[06:03:45] --- avwijk has joined
[06:03:47] <scribe> are the things that make me say, I like the proposal.
[06:03:52] <scribe> I'd also say from a practical point of view, there will be three
[06:03:56] <scribe> billion hand sets out there the that do this thing that smells
[06:04:03] <scribe> sort of like SIP and maybe ten or 20 million or 30 or 40
[06:04:07] <scribe> million real SIP things that will make SIP irrelevant if we don't
[06:04:13] <scribe> bring three GP P into this. I think it's important that we
[06:04:16] <scribe> are responsive. If I miss dinner today or tomorrow for the
[06:04:19] <scribe> design team, let's do it. NEW SPEAKER: I'm almost sure
[06:04:21] <scribe> we require that. NEW SPEAKER: I think this goes back
[06:04:25] <scribe> to discussion we've had in the context. This is really a discussion
[06:04:29] <scribe> between kind of features by reference or features by value. In
[06:04:33] <scribe> a sense, features by reference have a model.
[06:04:39] <scribe> The concern that I have is future implementation, this is why I
[06:04:45] <scribe> objected so strongly to the service U R model, is enumerating
[06:04:48] <scribe> things as individual points means that you cannot
[06:04:54] <scribe> have features which have parameter eyes able features.
[06:04:59] <scribe> That's what I would like to tell three GP P
[06:05:04] <scribe> Every feature you want, you either have to extract random
[06:05:08] --- Alan H has joined
[06:05:08] <scribe> pieces out of SDP which is right back to where you were before
[06:05:13] <scribe> or have magic encoding, where you have a feature tag or something like
[06:05:17] <scribe> that. So unless they have this notion that every feature is going to be
[06:05:20] <scribe> exactly one thing, this isn't even going do work.
[06:05:27] <scribe> The other question I have is just for clarification, is so I can stop
[06:05:30] <scribe> reading, is the service U N stuff out now? NEW SPEAKER:
[06:05:38] <scribe> I think it's, at this point, I think, I'm not proposing
[06:05:43] <scribe> -- well, I might need a require header for pok, that doesn't
[06:05:51] <scribe> need to be a service you RN. There may be other service
[06:05:55] <scribe> things, and I think it makes sense for the end user request for
[06:06:00] <scribe> a well known service to be, like if I want the call recording
[06:06:06] <scribe> service, to be inserted on my outbound call Pat,
[06:06:09] <scribe> path, it makes sense to use that. I consider that quite
[06:06:12] <scribe> different, because this is, you know, -- NEW SPEAKER:
[06:06:17] <scribe> If it translates into URL, we can have the discussion. NEW SPEAKER:
[06:06:21] <scribe> Right. It works perfectly. But I think that's the extent
[06:06:24] <scribe> of where it is. NEW SPEAKER: Okay.
[06:06:29] <scribe> NEW SPEAKER: Andrew Allen. So to address John dhan's
[06:06:34] <scribe> point, and Jonathan said earlier, it's not a choice between
[06:06:40] <scribe> doing service identification and three G PP. And not doing
[06:06:45] <scribe> it. So it's either some certification is going to have some
[06:06:49] <scribe> input from us or are we going to have some influence on this
[06:06:54] <scribe> work, I'd like to insure that many of the issues that people brought
[06:06:56] <dwillis@jabber.org> This, I think, is a slippery slope that will lead us all into a deep hole of finite, named services and no interoperability. Bad, bad, all bad.
[06:07:00] <scribe> up on the list that I shared, the address, we don't end up
[06:07:04] <scribe> with a situation where we have three bill yoon SIP
[06:07:11] <scribe> billion SIP Dee scises in the world, mobile and fixed and unable to
[06:07:15] <scribe> sxhun indicate with other SIP devices.
[06:07:17] <scribe> ( Unable to communicate.)
[06:07:23] <scribe> Hotels, internet klipts, communicate can with mobile users
[06:07:28] <scribe> and three GP P networks or people who are in other
[06:07:31] <scribe> telecommunications networks. That use the same concepts.
[06:07:36] <scribe> So, if we don't have something here, something here that is
[06:07:40] <scribe> at least close enough to the three GP P requirements, that those of
[06:07:45] <scribe> us who will support such efforts within three GP
[06:07:53] <scribe> P can adopt this, get feature tags within three GP P
[06:07:59] <scribe> or maybe some other body like the GSM association, is going
[06:08:04] <scribe> to get control. And no mechanism for entities outside of
[06:08:09] <scribe> those closed specifications to actually take those tags and
[06:08:13] <scribe> invites are going to get rejected and not accepted if they
[06:08:16] <scribe> don't contain those tags. That's what's going to
[06:08:20] <scribe> produce inter operability problems
[06:08:21] <scribe> .
[06:08:27] <scribe> So I think we need to be involved in this work if we want to see
[06:08:34] <scribe> them merge in the world. NEW SPEAKER: Let's go through
[06:08:37] <scribe> the line and try to conclude here. NEW SPEAKER: I see
[06:08:40] --- Jabber-Wile has left: Replaced by new connection
[06:08:41] <scribe> value in having such a service identifier, not only for three
[06:08:45] <scribe> GP P, because the major problems, the way I see it, I'll
[06:08:49] <dwillis@jabber.org> Roni Even, speaker.
[06:08:51] <scribe> give you an example, in SDP, we have now the content which
[06:08:56] <scribe> defines semantics to a specific screen, but it does nltd describe
[06:08:59] <scribe> the behavior of how end points should behave.
[06:09:04] <scribe> It's deduction. But the problem is, it's not made by one
[06:09:08] <scribe> person. It's made by different persons and each one deducts
[06:09:10] <scribe> differently. NEW SPEAKER: Right. NEW SPEAKER:
[06:09:16] <scribe> So to me, it looks like SDP should be there. But the
[06:09:21] <scribe> identifier would let the developer look at some other
[06:09:25] <scribe> document that has to be done to achieve the functionality.
[06:09:28] <scribe> That's the value I see. Because I have another document that
[06:09:36] <scribe> defines how to do two streams. One is presentation, and
[06:09:40] <scribe> the other is peer to view, and how to control that using the
[06:09:43] <scribe> SDP. The SDP explains how to do that. But it's Bertha you
[06:09:47] <scribe> know you have to reference to document in order to do
[06:09:50] <scribe> something, in order how to manage it. And by having such an
[06:09:53] <scribe> identifier makes it clearer. That's my point. NEW SPEAKER: All
[06:09:56] <scribe> right. And I just want to be clear that the proposal again
[06:09:59] <scribe> is that these identifiers are local
[06:10:02] <scribe> summarizations based on entirely
[06:10:05] <scribe> local policy. The media policy says do what I say. Which
[06:10:09] <scribe> is, for all these things where you think there's hidden
[06:10:14] <scribe> semantics, you need to figure out what it is, be explicit
[06:10:14] <scribe> about it.
[06:10:18] <scribe> To be clear what this proposal is, when you say document, which
[06:10:23] <scribe> basically outlines this argument with some real example use
[06:10:27] <scribe> cases, not just this service is an application without giving
[06:10:30] <scribe> examples, to illustrate this point and to go through each of
[06:10:34] <scribe> these and say this is the kind of thing you should do. So
[06:10:39] <scribe> the way we identify services, we have a P asserted I D and
[06:10:42] <alexis> :roster search jim
[06:10:43] <scribe> whatever, that allows for local summarization to re avoid re
[06:10:47] <scribe> computation and these are the types of things one might do.
[06:10:50] <scribe> thais the document I'm proposing.
[06:10:54] <scribe> One last thing to address John's point, I think you can
[06:11:00] <scribe> argue this has value out of three GP P. I've run into this
[06:11:01] --- Jabber-Wile has joined
[06:11:04] <scribe> problem even within my own product teams, we have different
[06:11:10] <scribe> software aps that people connect to the software. And this is
[06:11:14] <scribe> really important so I want the quality to be higher. And oh,
[06:11:18] <scribe> I can't tell it's that client versus that client so I'm going
[06:11:22] <scribe> to create a tag. And our guys are going to do other random
[06:11:25] <scribe> things the. User agent or whatever. People do
[06:11:29] <scribe> that. I mean, this is a document that says, no, what
[06:11:32] <scribe> we always do is finding the hidden sa man particular about what
[06:11:36] <scribe> is truly different from a functional behavior level and include
[06:11:40] <scribe> that in the SIP or SDP. And use this for summarization. So I
[06:11:44] <scribe> think there's merit in this, it's a B C P type of thing, I
[06:11:47] <scribe> think with the P asserted, whatever we call it header, that
[06:11:52] <scribe> really trying to tell preem, when you think you have this service
[06:11:56] <scribe> identification, this is really the problem you have. NEW SPEAKER:
[06:12:04] <scribe> I'm fine with these services or whatever you want to call it.
[06:12:10] <scribe> But what I'm missing is the discussion of what people are doing
[06:12:14] <scribe> today to address this problem. I think basically, I think
[06:12:17] <scribe> that most people they are using feature tags or they use the
[06:12:21] <scribe> feature tags context to put service identification.
[06:12:23] <scribe> This is basically what people are doing. NEW SPEAKER:
[06:12:27] <scribe> No, no. That's what three GP P has written in the
[06:12:30] <scribe> specification. NEW SPEAKER: That's what people are doing.
[06:12:32] <scribe> Yes.
[06:12:34] <scribe> (Several people talking.) NEW SPEAKER: What people are
[06:12:38] <scribe> doing today. Right. Is to put, to use the feature
[06:12:42] <scribe> tags to use in the service identification. That is what they
[06:12:47] <scribe> do. And services and association with those services. So at
[06:12:51] <scribe> least there's three groups of people there using feature
[06:12:53] <scribe> tags to put service
[06:12:58] <scribe> identifications. And I think that the main argument behind this is
[06:13:02] <scribe> that the feature tags allows you to do this explicit
[06:13:06] <scribe> require, and so you can put it, just for your
[06:13:09] <scribe> information, in case you happen to have on service or in case there's
[06:13:12] <scribe> something that missed happen to know which is the service.
[06:13:16] <scribe> But there's no real requirement for the end point point of view
[06:13:20] <scribe> to draw up explicit definition or whatever. You can put it
[06:13:22] <scribe> without require. NEW SPEAKER: Well, well (Several people talking.) NEW SPEAKER:
[06:13:25] <scribe> NEW SPEAKER: Let's look at this slide.
[06:13:32] <scribe> You're saying that I don't need it, the service I D tag,
[06:13:35] <scribe> for, you're saying I don't need it for the identifying
[06:13:39] <scribe> additional context require to process the request. I
[06:13:42] --- alexis has left
[06:13:42] <scribe> agree, it's used for all of the other things. Does that not
[06:13:46] <scribe> make it important? Of course it's still important. NEW SPEAKER:
[06:13:50] <scribe> I do not the disagree. I'm just -- NEW SPEAKER: It is
[06:13:54] <scribe> a deep injustice to the industry to downplay this, and say,
[06:13:59] <scribe> no, it's just an informational thing. Pay no attention to
[06:14:03] <scribe> the tag behind the curtain. You don't need to understand it
[06:14:07] <scribe> in your end point to process the call. So don't worry about it.
[06:14:10] <scribe> Look at all the stuff. How can you stand here and say, we
[06:14:11] <scribe> don't have to --
[06:14:13] <scribe> NEW SPEAKER: I'm shocked. NEW SPEAKER:
[06:14:13] <scribe> (Several people talking.)
[06:14:18] <scribe> NEW SPEAKER: What I'm saying is, that people are using the
[06:14:21] <scribe> feature tag context, because it has properties and you can
[06:14:26] <scribe> add the require and just the for your information type of
[06:14:30] <scribe> thing. This is why I believe people are using that. By, so,
[06:14:37] <scribe> you will have something similar, then we will make these people happy.
[06:14:42] <scribe> If we start to, you know, in venting, you know,
[06:14:47] <scribe> honestly, like if you go through the proposal, the thing where I don't think
[06:14:52] <scribe> it's going to make it is the first part of it, trying to
[06:14:55] <scribe> identify the different shade shing because people have gone
[06:14:58] <scribe> through that already. NEW SPEAKER: Guys, we need to wrap
[06:15:06] <scribe> this up. We already froze the line after Keith. So,
[06:15:12] <scribe> NEW SPEAKER: Who is speaking. NEW SPEAKER:
[06:15:20] <scribe> meing gel. NEW SPEAKER: At damn roach. Just to talk to
[06:15:26] <scribe> the question that John raised, in terms of whether we should
[06:15:29] <scribe> take on this work, to satisfy three three GP P's
[06:15:34] --- alexis has joined
[06:15:34] <scribe> requirements, what I'm hearing is that the semantics of what
[06:15:39] <scribe> they want to have done has already been specified in T S
[06:15:41] <scribe> 2328. NEW SPEAKER: That's wrong. I think that's
[06:15:42] <scribe> something, we (Several people talking.) NEW SPEAKER:
[06:15:48] <scribe> Well, if we think we can change that, then sure, by all means
[06:15:54] <scribe> take on this work. Otherwise, it's, it's pretty much,
[06:15:58] <scribe> what I'm hearing is, they said, here's our
[06:16:03] <scribe> spec, give an RFC number, please. NEW SPEAKER: And
[06:16:05] <scribe> right. NEW SPEAKER: And accepting this as
[06:16:12] <scribe> a working item is misguided. We'd we'd be endorsing an
[06:16:13] <scribe> approach we don't agree can with.
[06:16:17] <scribe> And we can have a conversation and it's not as urgent and we
[06:16:22] <scribe> don't want to rush into something if there's an external
[06:16:25] <scribe> problem that looks similar that must be solved in a different
[06:16:29] <scribe> way. I also want to speak very briefly to Andrew's
[06:16:32] <scribe> assertion that we're look going to look at SIP
[06:16:35] <scribe> forking in the future. This phone does SIP, it does a good
[06:16:39] <scribe> job at it. When I set up an account, it asks me if I'm
[06:16:46] <scribe> using SIP, or I G three PP fork, that happened years ago.
[06:16:54] <scribe> NEW SPEAKER: Two points, the first one is on the
[06:16:59] <scribe> fork issue, not directing that (Several people talking.) NEW SPEAKER:
[06:17:05] <scribe> Okay. NEW SPEAKER: The second point is that in the
[06:17:09] <scribe> discussion, we've captured a fair amount of
[06:17:18] <scribe> guidance on what the IETF actually means. I think we also
[06:17:22] <scribe> need to capture some of these, don't use this mechanism to do
[06:17:25] <scribe> this in some places. NEW SPEAKER: Can you back back to
[06:17:26] <scribe> the slide. Okay.
[06:17:31] <scribe> Does anyone think that accept contact is every one of these
[06:17:38] <scribe> semantics? I don't.
[06:17:44] <scribe> NEW SPEAKER: There's one thing which is missing in this,
[06:17:48] <scribe> the idea is for ek, if you have two contacts that stand for
[06:17:54] <scribe> the same A O R. One for supports I D PP,
[06:17:58] <scribe> and the other doesn't. You need a way when you register you
[06:18:02] <scribe> want to say what services are supported by the contact. That's
[06:18:05] <scribe> missing. If that requirement is added here, then using the P
[06:18:08] <scribe> header can work. NEW SPEAKER: No, no. No. And the reason
[06:18:13] <scribe> is, because the whole idea of this proposal is that instead
[06:18:17] <scribe> of having this bulk I am bell la things that
[06:18:21] <scribe> umbrella thing that defines what this is and says we support
[06:18:26] <scribe> this or not. And we need to signal to the network. Not some
[06:18:30] <scribe> these are some of the 5 services I am able to do. That's
[06:18:33] --- rjaksa has joined
[06:18:34] <scribe> what we don't want to do. NEW SPEAKER: How do you know which services
[06:18:34] <scribe> --
[06:18:38] <scribe> NEW SPEAKER: I'm not trying do do that. That's my point. NEW SPEAKER:
[06:18:42] <scribe> That is three G g PP requirements. NEW SPEAKER: Okay. Maybe
[06:18:42] --- csh has joined
[06:18:45] <scribe> not I'm being clear. Okay. I'm saying that I think there
[06:18:49] <scribe> are a few that, there should be these six or 7 services that have
[06:18:53] <scribe> a bunch of additional semantics that imply all kinds of
[06:18:57] <scribe> behavior in the system that you basically have to understand, and
[06:19:00] <scribe> then you register support for them and when you signal, you
[06:19:04] <scribe> say what they are. Is not the way to solve this problem.
[06:19:10] <scribe> Because, it leads to, having to have global definition of what
[06:19:15] <scribe> those services are, and if you're one of those poor guys who
[06:19:20] <scribe> doesn't define the service or does not have the license rights to
[06:19:24] <scribe> that, you you have no inter operability. Because your invite
[06:19:27] <scribe> without this tag will come and it will not be properly
[06:19:30] <scribe> processed. I'm saying you don't want that. Are you saying
[06:19:34] <scribe> you want that? NEW SPEAKER: The problem is, for
[06:19:37] <scribe> example, let's say you have an A O R and there are two
[06:19:41] <scribe> contacts, you don't want to dispatch the request to the wrong contact which
[06:19:43] <scribe> doesn't support it. Right? NEW SPEAKER: Yes. We
[06:19:48] <scribe> have a very rich framework that allows you not to put things in
[06:19:51] <scribe> one big bucket. But to point out the specific things that this
[06:19:56] <scribe> things is capable of doing. So we go and identify the explicit
[06:20:00] <scribe> semantics, which is truly what I say when I'm invoking the service that are
[06:20:06] <scribe> supported by this thing and it's difficulties fachd based on
[06:20:10] <scribe> that dispatched on that. I'm suggesting that everybody
[06:20:13] <scribe> jumped to the solution as let's define a global service
[06:20:18] <scribe> parameter with lots of hidden semantics that are undocumented
[06:20:20] <scribe> and I'm saying that's the wrong solution.
[06:20:25] <scribe> The right solution is to invite very specific features that make
[06:20:29] <scribe> up the, features that make up very specific behaviors that
[06:20:33] <scribe> make up things you need to support whether it's SIP extensions or
[06:20:36] <scribe> whatever it is, and that's the thing you signal and you
[06:20:39] <scribe> indicate support for. That's what the proposal is. That's
[06:20:43] <scribe> how we did presence. Same thing.
[06:20:48] <scribe> NEW SPEAKER: The I think the missing word is capabilities.
[06:20:53] <scribe> The three GP P has a requirement to indicate the device is
[06:20:57] <scribe> capable of doing it. NEW SPEAKER: But I don't want to say
[06:20:59] <scribe> my capability is pok version (Several people talking.)
[06:21:04] <scribe> NEW SPEAKER: I want to say I support this option tag and I
[06:21:08] <scribe> support this, you know, floor control protocol and dispatch
[06:21:11] <scribe> a call with those things to me. That's what I want. NEW SPEAKER:
[06:21:14] <scribe> So we need that capability. NEW SPEAKER: Okay. NEW SPEAKER: All
[06:21:17] <scribe> right. NEW SPEAKER: I think, all right. All right.
[06:21:21] <scribe> Now, okay. I thought -- NEW SPEAKER: Okay. So,
[06:21:26] <scribe> that's a good discussion here. There seems to be more
[06:21:29] <scribe> general support than had been on the list, as far as there is
[06:21:32] <scribe> a problem to be solved here. So we'd like to take a hum vote
[06:21:35] <scribe> on whether or not there's support within the working group of
[06:21:37] <scribe> solving this problem that's been discussed here today and not
[06:21:42] <scribe> necessarily agreement on on the absolute details of the
[06:21:47] <scribe> proposal. Are people clear? Rohan?
[06:21:52] <scribe> NEW SPEAKER: So I think there's a sort of a difference
[06:21:56] <scribe> between get together and see what we can come up with, and if we
[06:22:01] <scribe> feel like we've come up with a consensus among some of us in in
[06:22:05] <scribe> the room then try to go and do this. Or, but I think if we
[06:22:08] <scribe> get together in the room and try to get consensus, and we
[06:22:12] <scribe> don't get consensus, I don't think there's any benefit in us
[06:22:16] <scribe> -- if we're not going to agree, I don't think there's much
[06:22:19] <scribe> use in us -- NEW SPEAKER: You're suggesting we need to
[06:22:20] --- sureshk has left
[06:22:23] <scribe> agree on the solution path before agreeing to solving the
[06:22:29] <scribe> problem. NEW SPEAKER: No, if we agree on, on some
[06:22:29] <dwillis@jabber.org> Repeat: Focus of AC's comment is that JDR's slide on "how is service identification used" entirely misses the requirement of expressing the capabilities possessed by the user agent in question.
[06:22:33] <scribe> kind of a general approach, then we have some hope of being
[06:22:37] <scribe> able to do this in a time frame where it will actually matter and get
[06:22:41] <scribe> incorporated into three GP P. If we are not able to come to
[06:22:45] <scribe> a consensus, then we could go and spend a lot of time going
[06:22:49] <scribe> and doing this and three GP P would have already done their
[06:22:56] <scribe> thing. NEW SPEAKER: We need consensus on a rough solution like soon. NEW SPEAKER:
[06:22:59] <scribe> So do people, it's clear that we need more discussion this
[06:23:03] <scribe> week with the interested parties. Do people want to delay
[06:23:05] <scribe> the hum vote until Friday. NEW SPEAKER: I think we
[06:23:09] <scribe> should take a hum. NEW SPEAKER: I think we should
[06:23:14] <scribe> decide to work on this. And do it in a timely fashion and decide to work
[06:23:20] <scribe> on it. NEW SPEAKER: Okay. Let's go ahead and see.
[06:23:23] <scribe> Let's do the hum vote on whether or not people think that
[06:23:27] <scribe> we've got a problem to work on here and whether or not we want
[06:23:29] <scribe> to work on it within the working group. Is that clear?
[06:23:34] <scribe> Okay. So all those in favor of working on a solution to this
[06:23:34] <rohan> dean: do you want this repeated at the mic
[06:23:37] <scribe> problem within this working group, please hum.
[06:23:37] <scribe> ( Humming.)
[06:23:42] <scribe> All those against working on this problem within this working
[06:23:42] <scribe> group,
[06:23:48] <scribe> ( Humming. ) NEW SPEAKER: dwasly split. NEW SPEAKER:
[06:23:52] <scribe> For the note taker, that was roughly the same, actually.
[06:24:00] <scribe> NEW SPEAKER: So shing NEW SPEAKER: Let the chairs
[06:24:02] <scribe> decide. NEW SPEAKER: Well, I still think there's enough interested
[06:24:06] <scribe> parties that probably want to meet during the week and perhaps
[06:24:09] <scribe> some of the people against working on this would like to meet with
[06:24:13] <scribe> them and see if we can't come up with a path forward then.
[06:24:16] <scribe> The reality is, three GP P has a solution and they're on the
[06:24:21] <scribe> road with it. Right? Unless we come up with an
[06:24:23] <scribe> alternative, they're on the road with it. NEW SPEAKER:
[06:24:28] <scribe> And even if we come up with an alternative, are they're on
[06:24:31] <scribe> the road with it. NEW SPEAKER: Andrew implied that if
[06:24:33] <scribe> we agree to work on something and the A D supports
[06:24:39] <scribe> us working on something, there's a possibility three GP PP
[06:24:42] <scribe> twov the mind changed. NEW SPEAKER: Adam was talking
[06:24:45] <scribe> about forking, in terms of user agent actually
[06:24:47] <scribe> registering in the network. What we're actually talking
[06:24:52] <scribe> about here shing potentially is, two U atss Just notd
[06:24:56] <scribe> able to communicate. We're talking about potentially communication
[06:25:00] <scribe> isolation. Between network. (Several people
[06:25:00] <scribe> talking.)
[06:25:02] --- hbaosiy has joined
[06:25:03] <scribe> NEW SPEAKER: I'm not ready to give up on that. I guess.
[06:25:08] <scribe> And I think you know, there's many roads to solve this.
[06:25:10] <scribe> Again, this is a discussion that happens at many layers.
[06:25:14] <scribe> One of the layers is us agreeing that we're going to work on it
[06:25:16] <scribe> and produce some kind of solution. Another layer that goes
[06:25:22] <scribe> with it, is appropriately escalated liaison statements that indicate
[06:25:25] <scribe> IETF concern over the problem. We're a big organization. And I
[06:25:29] <scribe> think we've had a great collaborative relationship with three
[06:25:31] --- rjaksa has left
[06:25:33] <scribe> GP P. And say, hey, you may not realize what you're
[06:25:36] <scribe> doing here and how bad this can be. Let's do something.
[06:25:39] <scribe> I'm optimistic that can be helpful. But I guarantee you the
[06:25:42] <scribe> outcome will not be positive if we do not try. NEW SPEAKER:
[06:25:47] <scribe> Right. This is Rohan. I think there are three separate
[06:25:48] --- teemuk has left
[06:25:53] <scribe> things that we might be trying to agree onto do or not do.
[06:25:58] <scribe> One is, to figure out whether there's interest incoming up
[06:26:02] <scribe> with a standards based way of expressing the capabilities to do
[06:26:06] <scribe> this kind of thing, which you can do outside of three GP P shing in
[06:26:11] <scribe> or out of that context. The second thing is whether we want to go
[06:26:14] <scribe> and do a P header or something like that, to be able to
[06:26:18] <scribe> express something like what is in the current draft, and the third
[06:26:22] <scribe> thing is whether we want to prioritize either one or two or both.
[06:26:26] <scribe> And so I think that you might get slightly different results if we ask at
[06:26:30] <scribe> least, you know, do people agree that we want to work on
[06:26:33] <scribe> one. And then on Friday, we can ask maybe whether we want
[06:26:37] <scribe> to work on two, and/or shing three and/or two.
[06:26:42] <scribe> And I don't want a discussion about that. I want the chairs
[06:26:47] --- Jabber-Wile has left
[06:26:48] <scribe> to decide if that is something we want to do.
[06:26:52] <scribe> NEW SPEAKER: Yes, I think we need to have some more off
[06:26:55] --- JeffH has left: Logged out
[06:26:56] <scribe> line discussion with tintd parties and then try and come to
[06:26:59] <scribe> a conclusion by Friday on the way forward. I mean, I agree with
[06:27:03] <scribe> Rohan's point that there are two separate things. People
[06:27:06] <scribe> are beginning to sort out a more general problem that we need
[06:27:10] <scribe> to solve and clearly there's a highly time dependent problem to
[06:27:14] <scribe> do something so that three GP P is not on totally off track, right.
[06:27:18] <scribe> But we do need more off line discussion. We're running out of
[06:27:24] <scribe> time. Can all the interested parties get together in a
[06:27:28] <scribe> session. We have 5 minutes and I'm going to ranlt and people
[06:27:33] <scribe> interested this this topic come up and we'll sort out what we
[06:27:33] <scribe> can do.
[06:27:42] <scribe> Now, here we have about fifteen minutes but we have 5 minutes
[06:27:52] <scribe> left to talk about how to meet milestones more efficiently and
[06:27:56] <scribe> effectively. We've been less than 50 percent being rat of
[06:27:59] <scribe> meeting milestones. Some of the delays are due to
[06:28:02] <scribe> dependencies on other documents which are hard to avoid. Other
[06:28:08] <scribe> delays are due to lack of cycles on behalf of document editors.
[06:28:13] <scribe> And other delays could be attributed toss the authors not
[06:28:18] <scribe> seeing whether their next up days are due and trying to do more
[06:28:20] <scribe> work before the meetings, rather than right before the
[06:28:21] <scribe> meeting.
[06:28:27] <scribe> There was a proposal on the list that Gonzalo made to move the
[06:28:31] <scribe> documents to the end of the queue, so it doesn't ripple
[06:28:34] <scribe> effect. And the mailing list so far was fully supportive. I
[06:28:37] <scribe> didn't see anybody posting that they were against
[06:28:42] <scribe> that proposal. So this mod model has been reflected in the new
[06:28:45] <scribe> updates. A few documents did not change because of the
[06:28:46] <scribe> delays of other documents.
[06:28:53] <scribe> Other options would be that the chairs do more regular
[06:28:59] <scribe> pings of bugging document editors to get things done. But we
[06:29:02] <scribe> don't prefer to do that. Given the fact that the information
[06:29:05] <scribe> is fully available on the spreadsheet and we do send out
[06:29:09] <scribe> summaries. What I might start doing is ccing. I don't
[06:29:13] <scribe> want to do that. That gets long as well. But I might call
[06:29:16] <scribe> out the editor's name against the document when the Milestone
[06:29:20] <scribe> is there so that people are aware they're up for that, on the
[06:29:20] <scribe> spot for that.
[06:29:24] <scribe> Okay. I may, I don't know if it would be useful to do more regular
[06:29:27] <scribe> updates. Right now, they're about once a month. Maybe every two weeks.
[06:29:30] <scribe> More reminders, I don't know if that's good or not.
[06:29:35] <scribe> Feedback on on that would be useful.
[06:29:39] <scribe> Longer terms, we'll get some tools, and that would be a good
[06:29:41] <scribe> thick to generate information. NEW SPEAKER: On the first
[06:29:44] <scribe> thing about regular pinks, I know you think it's a pink,
[06:29:50] <scribe> but I personally find that getting pingd helps.
[06:29:56] <scribe> Sometimes the squeaky wheel gets the oil. Sometimes you
[06:29:58] <scribe> promise and if I don't hear, you know, maybe they didn't
[06:30:03] <scribe> notice. NEW SPEAKER: Okay. Might start trying to do
[06:30:05] <scribe> that, bug people then. NEW SPEAKER: We do it
[06:30:09] <scribe> sometimes, when we feel that the editors are not delivering
[06:30:12] <scribe> on time. But we can do it for everybody. That's not a
[06:30:12] --- worley has left
[06:30:14] <scribe> problem. NEW SPEAKER: All right. I'll start doing
[06:30:16] <scribe> that more regularly. Andrew? NEW SPEAKER:
[06:30:19] <scribe> Generally, I think it's a good idea, but I'd like not to make
[06:30:23] <scribe> this a hard and fast rule. I think there needs to be
[06:30:26] <scribe> discretion on the chairs from sending it right -- NEW SPEAKER:
[06:30:28] <scribe> Yes. NEW SPEAKER: Get to (Several people
[06:30:28] <scribe> talking.)
[06:30:33] <scribe> NEW SPEAKER: Going back to the bottom. Because there are NEW SPEAKER:
[06:30:35] <scribe> Right. NEW SPEAKER: And people have, you know, family
[06:30:38] <scribe> issues, personal commitment, job gets
[06:30:42] <scribe> reorganized or whatever, that may distract them from actually
[06:30:45] <scribe> completing what they agreed to. So I think there should be
[06:30:49] <scribe> some consideration and -- NEW SPEAKER: Absolutely. We'll
[06:30:51] <scribe> use common sense. That's obvious. NEW SPEAKER: And
[06:30:54] <scribe> on that too, I mean, in the day job, if you're
[06:30:59] <scribe> unavailable, perhaps you can have someone come in and fill in
[06:31:03] <scribe> whatever your critical work was. You can report back I'm
[06:31:07] <scribe> going to be busy, great, we'll get a back up editor to do
[06:31:09] <scribe> the work. NEW SPEAKER: Yes, that was something we were
[06:31:13] <scribe> hoping to be able to do and we did some somewhat with the con fig
[06:31:16] <scribe> framework, we pulled one of the previous
[06:31:21] <scribe> reviewers, because we felt they had a knowledge base to be the
[06:31:26] <scribe> backup editor. We're going to do it more, because we are not
[06:31:27] --- tomkri has left: Logged out
[06:31:29] <scribe> getting as many volunteers. But I'll start tagging people and
[06:31:32] <scribe> approaching people to do the document reviews and it's going to
[06:31:36] <scribe> be some of the newer people that want their document accepted
[06:31:40] <scribe> into the working group. Because it's useful for people who want
[06:31:44] <scribe> new work to contribute to the past work. NEW SPEAKER: We
[06:31:48] <scribe> want to give incentive to people to do reviews and to be on time on
[06:31:51] <scribe> everything. So we're going to give rewards, in the sense
[06:31:51] --- gas has left
[06:31:53] <scribe> that the documents that are weaker and everything.
[06:31:58] <scribe> NEW SPEAKER: Yes. All right. And so, wunk thing I
[06:32:02] <scribe> want to do real quick is show the spreadsheet for people who have
[06:32:07] <scribe> not had a chance to look ALT at it. There's a lot of
[06:32:10] <scribe> information that's automatically available. I'm not on the
[06:32:11] --- sk137 has left
[06:32:13] <scribe> network, but anyway. I can only though you where the links
[06:32:13] <scribe> are.
[06:32:19] <scribe> So this link here, is pulled into straight to the data track err.
[06:32:23] <scribe> I'm not on line. But it shows that the status of the
[06:32:27] <scribe> document, it's got the working group last call dates, when we plan on
[06:32:31] <scribe> sending it to the IESG. The editor, the chair that's
[06:32:33] <scribe> primed for that, and the reviews
[06:32:39] <scribe> cached out here. And B J has senlt an updated ru view on the
[06:32:45] <scribe> spam document. And then we have further on down, you've got, the
[06:32:49] <scribe> sorted by review date, things that are completed or things
[06:32:53] <scribe> that have gone into IESG. With the A D. And then at the
[06:32:58] <scribe> bottom, really views, and you've
[06:33:01] <scribe> re, reviews, and all these are links to the reviews that have been
[06:33:02] <scribe> completed. Out here.
[06:33:07] <scribe> So there's a wealth of information in here for people to go and
[06:33:10] <scribe> find things. NEW SPEAKER: Where is that? NEW SPEAKER:
[06:33:13] <scribe> This is on soft armor. NEW SPEAKER: I went looking
[06:33:16] <scribe> for it. It may be out there. I couldn't find it easily.
[06:33:19] --- Jean-Francois has left
[06:33:20] <scribe> Could we make it easier to find. NEW SPEAKER: It's working
[06:33:23] <scribe> group last call process. But we can -- NEW SPEAKER: We
[06:33:27] <scribe> can move it up to the top page perhaps. Maybe the name is
[06:33:30] <scribe> not obvious or something. Okay. NEW SPEAKER: I went
[06:33:33] <scribe> looking and I couldn't find it. And if I can't find it dash NEW SPEAKER:
[06:33:38] <scribe> That's a good point. We'll look at that and make it more
[06:33:42] <scribe> obvious, get stars flashing at you or something. NEW SPEAKER:
[06:33:47] <scribe> Service I D. NEW SPEAKER: But I mean, doy include the link in
[06:33:51] <scribe> the e-mail every time I send it out. Anyway, I wanted e to
[06:33:53] <scribe> make people more aware of that if you will.
[06:33:57] <scribe> Okay. We're done for today and we'll see everybody on Friday.
[06:34:00] <scribe> And come to the room right now, up front. NEW SPEAKER:
[06:34:03] <scribe> One brief announcement, which is, in case you haven't
[06:34:05] --- kvehmanen has left: Computer went to sleep
[06:34:09] <scribe> noticed, the geo priv and the spear ment meeting have swapped.
[06:34:09] --- richard.barnes has left
[06:34:13] <scribe> So if you're going to either one of those meetings, make
[06:34:14] --- hbaosiy has left
[06:34:18] <scribe> sure you realize that. NEW SPEAKER: Sunday night sore
[06:34:29] --- ben has left
[06:34:31] --- hejingtong has left
[06:34:35] <scribe> something. NEW SPEAKER: And the room changed doo.
[06:34:35] --- scribe has left
[06:34:36] --- Adam has left: Computer went to sleep
[06:34:38] --- hb47713 has left
[06:34:43] <Alan H> who ended up scribing -- thanks!
[06:34:46] --- RjS has left
[06:34:47] <ttfr> thanks for the great scribe work!
[06:34:57] <Jelte> kudos on the streaming sound quality too
[06:34:58] --- ysuzuki has left
[06:35:02] --- lowekamp@gmail.com has left
[06:35:08] --- ttfr has left
[06:35:10] <avwijk> cheers everybody
[06:35:11] --- isudo has left
[06:35:17] --- tobia has left
[06:35:20] --- avwijk has left
[06:35:27] --- agallant has left
[06:35:27] --- csh has left
[06:35:56] --- dmalas has left
[06:35:56] --- dmalas has joined
[06:35:59] --- Alan H has left
[06:36:33] --- renee has left
[06:36:35] --- enrico has left: Logged out
[06:36:39] --- Jelte has left
[06:36:44] --- spencerdawkins has left
[06:36:49] --- dmalas has left
[06:37:42] --- cullenfluffyjennings@gmail.com has left
[06:38:05] --- dwillis@jabber.org has left
[06:42:09] --- joshlitt has left
[06:44:40] --- rohan has left
[06:48:15] --- teemuk has joined
[06:48:58] --- teemuk has left
[06:50:37] --- mhp has left
[06:53:04] --- frodek has left
[06:58:24] --- Glenn Parsons has left
[07:07:42] --- pelletier has left
[07:37:41] --- joonhyung.lim has left
[07:49:35] --- joonhyung.lim has joined
[07:58:44] --- joonhyung.lim has left
[07:59:46] --- spencerdawkins has joined
[08:10:52] --- Glenn Parsons has joined
[08:11:24] --- alexis has left
[08:11:48] --- Glenn Parsons has left
[08:33:21] --- JeffH has joined
[08:36:06] --- JeffH has left
[10:03:08] --- kvehmanen has joined
[10:04:13] --- kvehmanen has left
[10:04:53] --- spencerdawkins has left
[10:07:13] --- jyg has joined
[10:07:48] --- jyg has left
[10:15:31] --- spencerdawkins has joined
[10:16:33] --- spencerdawkins has left
[10:18:59] --- jyg has joined
[10:19:55] --- jyg has left
[10:23:41] --- miro has joined
[10:24:53] --- miro has left
[10:29:21] --- miro has joined
[10:45:45] --- philip_matthews has joined
[10:50:53] --- philip_matthews has left
[10:57:14] --- miro has left: Replaced by new connection
[10:58:26] --- bman has joined
[10:59:05] --- bman has left: Logged out
[10:59:10] --- bman has joined
[10:59:18] --- bman has left: Logged out
[12:17:43] --- pee has joined
[12:17:48] --- brockners has left
[12:18:34] --- pee has left
[12:31:51] --- bman has joined
[13:16:23] --- bman has left: Replaced by new connection
[18:07:56] --- isudo has joined
[18:08:57] --- isudo has left