[06:45:36] --- chadolabba has left
[07:57:09] --- ttfr has joined
[07:58:25] --- isudo has joined
[07:58:49] --- bpenfield has joined
[08:00:04] --- Jabber-Wile has joined
[08:01:04] --- Jabber-Wile has left
[08:01:51] --- isudo has left
[08:02:09] --- kafka-j31415927 has joined
[08:02:21] --- isudo has joined
[08:02:23] --- scribe has joined
[08:02:26] --- frodek has joined
[08:02:51] --- renee has joined
[08:03:05] <scribe> SIP session, March 21, 2007, one p.M.
[08:03:27] <scribe> NEW SPEAKER: Testing, testing, yes, this is working.
[08:03:29] <scribe> Okay. Let's start so we can finish.
[08:03:40] <scribe> So, we'll talk about the draft SIP S URI, did draft IETF SIP
[08:03:44] <scribe> S, see, since the last meeting, we've had three
[08:03:49] <scribe> iterations of the draft on the mailing list. We went from an
[08:03:51] --- Alan Hawrylyshen has joined
[08:03:54] <scribe> individual draft to working group document. A substantial amount of
[08:03:58] --- hb47713 has joined
[08:04:02] <scribe> discussion on the list, all the open issues that were in the document have been
[08:04:08] <scribe> resolved the mailing list. And there is a draft draft, if
[08:04:12] <scribe> you want, draft O three that has not been submitted yet.
[08:04:17] <scribe> Which I've posted a link to on the list, if anybody wants
[08:04:18] <scribe> to look at it to make sure that everything is okay.
[08:04:25] <scribe> This document does not update RFC three 2 six one per se.
[08:04:29] <scribe> Okay. So it does not make normative changes to the
[08:04:33] <scribe> procedures in 3261. But let me get to that later. Sorry sf NEW SPEAKER:
[08:04:36] <scribe> Just a clarification, it says --
[08:04:38] <scribe> NEW SPEAKER: Who are you. (Several people talking.) NEW SPEAKER:
[08:04:45] <scribe> Open issues, on the draft, and an O three, this is being
[08:04:47] <scribe> repaired, which one is correct. NEW SPEAKER: Can you
[08:04:50] <scribe> repeat that? NEW SPEAKER: On the floor it says,
[08:04:54] <scribe> since O four, and then it says, O three preparation. NEW SPEAKER:
[08:04:57] <scribe> The title changed. NEW SPEAKER: The title changed.
[08:05:02] <scribe> It was originally draft something and now it's draft SIP. NEW SPEAKER:
[08:05:05] <scribe> That's the individual draft you're looking at. NEW SPEAKER:
[08:05:10] <scribe> So we went from individual draft O four, to zero one two and
[08:05:13] <scribe> there's a three in the way since the last meeting. NEW SPEAKER:
[08:05:17] <scribe> Since those of you who didn't hear him say it, that was John Elwell.
[08:05:21] <scribe> NEW SPEAKER: Okay. So we want to have working group
[08:05:28] <scribe> last call at this meeting, and submission to IESG June 2007.
[08:05:28] <scribe> Next slide.
[08:05:33] <scribe> One issue that has been, that I would like to resolve today is
[08:05:39] <scribe> the intended stat does of the draft. Okay. So, while it does not
[08:05:48] <scribe> really change RFC 3261, at this point, it does make significant
[08:05:56] <scribe> additions to it. There are some RFC 21 19 wording in the
[08:05:59] <scribe> document. It says you must do this and blah, blah, blah.
[08:06:04] <scribe> So a number of us are basically thinking that instead of having an
[08:06:08] <scribe> informational status, this should really be a
[08:06:12] <scribe> standards draft document. So the proposal, so this is
[08:06:16] <scribe> actually what I'm proposing right now, is that we make that a
[08:06:20] <scribe> standards document. It will have multiple sections
[08:06:24] <scribe> obviously, so the current text will remain in there, maybe with
[08:06:26] <scribe> some tweaking.
[08:06:30] <scribe> There will be a discussion of quote, bug fixes. So, there
[08:06:37] <scribe> are a few places where we are correcting slightly 3261. But
[08:06:39] <scribe> we'll treat them as bug fixes.
[08:06:42] --- dgtlsoul has joined
[08:06:44] <scribe> In order to do that, it does mean that we'll have to conform
[08:06:49] <scribe> to 44 '85. So it does change it a little bit. Some of
[08:06:53] <scribe> the format of the document. And we'll need to generate the bug
[08:06:59] <scribe> fixes document for the bug fix process, if there is any
[08:07:01] <scribe> changes to 3261.
[08:07:08] <scribe> So what I'd like to do now is to hear from the room if we support
[08:07:12] <scribe> making this a standards track RFC?
[08:07:16] --- ben has joined
[08:07:16] <scribe> NEW SPEAKER: Francois, is this on? NEW SPEAKER: Who are you
[08:07:20] <scribe> James. NEW SPEAKER: Who are you? NEW SPEAKER:
[08:07:26] <scribe> James. NEW SPEAKER: You said you get to later how this
[08:07:28] --- Jabber-Wile has joined
[08:07:30] <scribe> doesn't update 3261 and yet you say you're fixing something in
[08:07:36] <scribe> 3261, and you want it to be track, can you explain that apparent
[08:07:39] <scribe> inconsistency. NEW SPEAKER: I'll try to explain it.
[08:07:43] <scribe> Initially our idea was, our guidance, let's say, the
[08:07:45] --- ob has joined
[08:07:48] <scribe> guidance that was provided to me was to try to avoid changing
[08:07:58] <scribe> 3261. But the boundary between bug fixes and making actual
[08:08:04] <scribe> changes is I think kind of blurry. And I think it would be less
[08:08:08] <scribe> misleading to actually byte the bullet and say it is a
[08:08:14] <scribe> standards track document. NEW SPEAKER: Rohan. To the extent
[08:08:17] <scribe> to which, sorry, take a step back. I don't think we
[08:08:23] <scribe> should chicken out and not, and, and for, if we're
[08:08:26] <scribe> fundamentally changing what we're doing, we shouldn't chicken
[08:08:30] <scribe> out. It should be a standard track document. I don't have
[08:08:33] <Alan Hawrylyshen> NEW SPEAKER is really EKR pretending to be Rohan
[08:08:34] <scribe> anything that proves it's not, but I mean, you know, I
[08:08:40] <scribe> have reason, I screwed up when we did 3261 and we should get it
[08:08:43] <scribe> fixed and that is a standards document. NEW SPEAKER:
[08:08:47] <scribe> I agree. NEW SPEAKER: So Jonathan Rosenburg. Right
[08:08:49] --- chadolabba has joined
[08:08:52] <scribe> now, there's middle of the road status, I fear is doing injustice to the
[08:08:54] <scribe> industry at the expense, because that's what our process wants
[08:08:58] <scribe> us to do. What this does is it sort of clarifies shs sort of
[08:09:02] <scribe> fixes, it is still confusing, not a trivial document to
[08:09:05] <scribe> follow. And by the way, at the end of the day, it
[08:09:08] <scribe> doesn't achieve any of the security goals that we want to go out
[08:09:12] <scribe> and achieve with SIP. So if I'm an implementer, you just
[08:09:16] <scribe> gave me another document that basically clarifies something that is
[08:09:20] <scribe> still not useful to me. Thank you, let me put that in the shredder right
[08:09:25] <scribe> now. I thought our purpose was to serve the implementer xhun
[08:09:28] <scribe> tie and not our process. In this particular case, I think we
[08:09:31] <scribe> all agree that SIP S has, you know, it needs to be clarified
[08:09:33] <scribe> and it needs to be fixed.
[08:09:37] <scribe> What the industry really needs is a dook ment that says, this
[08:09:41] <scribe> is SIPs and it works. And I don't see why multiple documents
[08:09:43] <scribe> helps stha. NEW SPEAKER: So what should we do? NEW SPEAKER:
[08:09:47] <scribe> We should have a single document that updates RFC 3261, and
[08:09:52] <scribe> defines exactly how since is supposed to work, with props that gives
[08:09:57] <scribe> us the properties we require for SIPs to be useful to the industry. NEW SPEAKER:
[08:10:00] <scribe> That is what Francois is proposing to do. NEW SPEAKER:
[08:10:03] <scribe> I'm agreeing with it. I'm disagreeing dash NEW SPEAKER:
[08:10:05] <scribe> I have not even said anything. NEW SPEAKER: I
[08:10:08] <scribe> disagree with what John is about to say. NEW SPEAKER:
[08:10:11] <scribe> But it will note, in fact, what is proposed, there is
[08:10:15] <scribe> not a document that updates 3261. It's a document that
[08:10:19] <scribe> provides the standards track statement about the extension to
[08:10:25] <scribe> 3261, the bug fixes will ultimately roll into the track that Robert
[08:10:27] <ben> that's Keith Drage
[08:10:28] <scribe> sparks is doing. That will be the document that has the
[08:10:30] <scribe> changes that updates 3261.
[08:10:36] <scribe> NEW SPEAKER: All right. Jonathan has allowed me to state
[08:10:40] <scribe> my argument. First things first, this group is now charter
[08:10:41] <ben> Jon Peterson
[08:10:43] <scribe> the Ed to provide this as informational. So bear that in
[08:10:44] <scribe> mind as we go forward.
[08:10:49] <scribe> Primarily, I think if we're going to make changes to security text and I
[08:10:52] --- frodek has left
[08:10:54] <scribe> think this does make changes to security text in 3261, and as
[08:10:57] <scribe> it stands today and Jonathan wants more
[08:11:00] <scribe> of a change. I would foresee a document that looks more like
[08:11:05] <scribe> that S MIME document. That is a simple document that just says, these are
[08:11:08] <scribe> the Deltas, these get wrapped into the larger
[08:11:09] <scribe> project that just contains the Deltas.
[08:11:15] <scribe> This document contains a lot of just kind of informational
[08:11:19] <scribe> exploration, and argument taition of why things should be one way or
[08:11:22] <scribe> another. And I think that's a valuable thing to capture. But I don't think
[08:11:27] <scribe> those are the same document. NEW SPEAKER: I still
[08:11:30] <scribe> assert that whatever implementer I ever talked to
[08:11:33] <scribe> wants is a document they can pick up and say, this is the
[08:11:37] <scribe> document that says this is how SIPs works.
[08:11:43] <scribe> Not an document that updates 3261, that I then take and join
[08:11:49] <scribe> operation on two documents to figure it out. I want a Stan
[08:11:52] <scribe> alone document. This is how SIPs works.
[08:11:56] <scribe> Top to bottom. NEW SPEAKER: Maybe I can clarify what the
[08:11:58] <scribe> output would be. I think we get exactly what you're
[08:12:01] <scribe> proposing, that's my intention anyway.
[08:12:06] <scribe> But we also get a Delta document that says, this is what we
[08:12:10] <scribe> need to roll into 3261 at some point with the bug fixes. NEW SPEAKER:
[08:12:12] <scribe> What? Why?
[08:12:14] <scribe> NEW SPEAKER: Because that's the way --
[08:12:16] <scribe> (Several people talking.) NEW SPEAKER: Can we just
[08:12:19] <scribe> separate two issues. Is there anybody against having some document
[08:12:23] <scribe> proposed that changes it NEW SPEAKER: That would be a good question. NEW SPEAKER:
[08:12:28] <scribe> There's two documents. One document. But a document approach? NEW SPEAKER:
[08:12:33] <scribe> I'm not sure there's consensus for that document yet. I could
[08:12:35] <scribe> be right or wrong about that. NEW SPEAKER: Right.
[08:12:38] <scribe> So, let's ask if there's anybody that opposes that right
[08:12:42] <scribe> now, to see, dash NEW SPEAKER: I think it's very
[08:12:46] <scribe> questionable. Before you think that you can answer that
[08:12:48] <scribe> question, you have to know that you can answer the question of
[08:12:52] <scribe> what are the changes that this document makes to 3261? And
[08:12:58] <Alan Hawrylyshen> Cullen Jennings
[08:12:58] <scribe> I'm willing to bet fairly strongly that other than probably
[08:13:00] <scribe> France swa no one in the room can answer the question. The
[08:13:06] <scribe> changes here are extremely small to 3261 if at all. It's argue able
[08:13:09] <scribe> if it does or not. There's an ongoing argument about that.
[08:13:13] <scribe> So unless you're up to speed on exactly what that
[08:13:16] <scribe> proposes to change, you're probably not in a good place.
[08:13:18] <scribe> Cullen. NEW SPEAKER:
[08:13:22] <scribe> NEW SPEAKER: Hold on a second. Jonathan. Cullen, what I
[08:13:25] <scribe> think he was implying shs it would just be adopting this document
[08:13:29] <scribe> as it is, with whatever changes it has. That's not the
[08:13:33] <scribe> question. The question is, do we just continue to
[08:13:37] <scribe> informationally describe the problem three2 six
[08:13:41] <scribe> one or do we actually fix it with some kind of standards track document? That's
[08:13:43] <scribe> the first and fundamental question. NEW SPEAKER: But
[08:13:46] <scribe> not the one that's on the screen, right sf NEW SPEAKER:
[08:13:53] <scribe> No. The proposed work process would re up the one on the
[08:13:58] <scribe> screen into a proper 4 4 Complaint document with more clarity
[08:14:02] <scribe> and possible some additional changes. And a second document
[08:14:05] <scribe> which would roll into the essential corrections process, that
[08:14:09] <scribe> Robert talked about yesterday, would come out, that would contain
[08:14:13] <scribe> essentially the same text, but it would be merged into the
[08:14:18] <scribe> update 3261 document. Now, if you don't agree with that,
[08:14:20] <scribe> keep in mind that you are disagreeing with the already agreed
[08:14:24] <scribe> essential corrections process. Which says, if you fix RFC
[08:14:28] <scribe> 3261, you roll it into this annual fix. NEW SPEAKER:
[08:14:32] <scribe> I disagree with both things you just said. First of all, I
[08:14:35] <scribe> do not think we should have two separate documents, one that rolls
[08:14:39] <scribe> into the essential connections document and another one that
[08:14:42] <scribe> updates it. Because again, that's not serving the
[08:14:45] <scribe> industry. It's serving our process. Gosh darn it, we
[08:14:50] <scribe> can't actually deliver the document that people need because Keith said we neat
[08:14:53] <scribe> a separate document that contains only the fixes. If amongst
[08:14:58] <scribe> us we're having a hard time figuring out what's a new or old requirement
[08:15:02] <scribe> or clarification, just imagine an implementer sorting it out.
[08:15:07] <scribe> So I propose, get one document that top to bottom describes how
[08:15:11] <scribe> SIPs works. It starts first line, ignore
[08:15:17] <scribe> everything in 3261 and the essential corrections RFC assessee
[08:15:19] <scribe> that document. NEW SPEAKER: Essentially, there's
[08:15:22] <scribe> three elements in the document at the moment that we're talking about.
[08:15:25] <scribe> The informational discussion, which is very, very useful
[08:15:30] <scribe> that tells us how we actually use security, essentially it's saying
[08:15:34] <scribe> 3261 says this and this is how we therefore interpret this as
[08:15:35] <scribe> usage security.
[08:15:41] <scribe> The second element is the bug fix, which is basically the last
[08:15:46] <scribe> issue, and actually has to change 3261. Then there's the
[08:15:49] <scribe> third element which is basically adding some extensions to the
[08:15:53] <scribe> existing requirements, that basically doesn't normatively
[08:15:57] <scribe> change 3261 but does say, if you really want to use this
[08:16:00] <scribe> successfully, then do something sensible, then you also
[08:16:02] <scribe> need to comply with these requirements.
[08:16:08] <scribe> Now, yesterday we said we want to make sure that people are
[08:16:11] <scribe> implementing three six one have all the information available
[08:16:17] <scribe> for the scope of three six one in one bug fixes document. So
[08:16:20] <scribe> at least one element according to yesterday's decision,
[08:16:28] <scribe> should go into the bug fixes, not as, the text. So I guess the
[08:16:31] <scribe> question is, what do we do with the other two elements?
[08:16:35] <scribe> NEW SPEAKER: Does this deposition cat the last document. NEW SPEAKER: That's
[08:16:37] <scribe> the next slide we're going to talk about. NEW SPEAKER: What does the
[08:16:40] <scribe> dook ment say right now. NEW SPEAKER: The document does not
[08:16:42] <scribe> do that right now. NEW SPEAKER:
[08:16:44] <scribe> Proposeses we should do that. NEW SPEAKER: We'll get
[08:16:48] <scribe> to that. NEW SPEAKER: Okay. NEW SPEAKER:
[08:16:51] <scribe> So, this whole conversation about the status of the document,
[08:16:53] <scribe> without making that decision dpirs dash (Several people talking.) NEW SPEAKER:
[08:16:58] --- alexis has joined
[08:16:58] <scribe> Let's go do that. And come back to this later. I think that -- NEW SPEAKER:
[08:17:04] <scribe> e I believe we do have consensus to change this. NEW SPEAKER:
[08:17:05] <scribe> Let's move to (Several people talking.) NEW SPEAKER:
[08:17:10] --- worley has joined
[08:17:13] <scribe> Was that I believe we have it or official consensus? NEW SPEAKER:
[08:17:20] <scribe> Consensus can always change but my current understanding is
[08:17:23] <scribe> that we have consensus to make ha change, John. NEW SPEAKER:
[08:17:28] <scribe> Okay. NEW SPEAKER: Go to the next slide and we'll do
[08:17:28] <scribe> that. Next slide.
[08:17:43] <scribe> Jump ahead. Next slide. Next slide. Okay. The
[08:17:46] <scribe> deposition indication of the last hop exception is something
[08:17:49] <scribe> that has been mentioned many times on the mailing list as well
[08:17:53] <scribe> as previous meetings. It appears that we may have
[08:17:59] <scribe> a consensus. We have not heard of anybody that actually
[08:18:05] <scribe> opposed this for a long time. So, the idea would be to
[08:18:07] <scribe> confirm with the group that we should do this.
[08:18:11] <scribe> Now, if we recall this, what happened at the previous
[08:18:15] <scribe> meeting, the initial idea was to not do this in this
[08:18:21] <scribe> document. But to do that as a bug fix later on. Okay. So
[08:18:26] <scribe> the current status of the document is that it's somewhat wish
[08:18:29] <scribe> ee wash ee, it explaind it's a pretty bad
[08:18:32] <scribe> idea, we recommend against doing this. And we'll probably
[08:18:33] <scribe> deprecate it at some point.
[08:18:39] <scribe> So, a proposal that we've heard since then is well, let's just
[08:18:47] <scribe> make that change right now. And that would be a a change in three
[08:18:51] <scribe> 2 six one. And would justify the whole idea of having this
[08:18:55] <scribe> document being a standards draft document instead of an
[08:18:58] <scribe> informative document, informational document.
[08:19:02] <scribe> So I guess what I'd like to get from the group is, do we want
[08:19:07] <scribe> to do this right now, yes or no? And move on. NEW SPEAKER:
[08:19:10] <scribe> Can we separate the right now thing from, because that's a process
[08:19:12] <scribe> -- NEW SPEAKER: I'd libling to understand. NEW SPEAKER:
[08:19:12] <scribe> (Several people talking.)
[08:19:17] <scribe> NEW SPEAKER: Let's take a pole here. We have the
[08:19:21] <scribe> proposal that we deprecate the last hop exception for SIP S going
[08:19:26] <scribe> forward. So, at this point we make a change to make a
[08:19:28] <scribe> deposition indication. So those in favor of
[08:19:35] <scribe> deprecating the last hop, alternative one, deprecate the last
[08:19:40] <scribe> hop exception. Alternative two, do not do that, stay
[08:19:44] <scribe> with something else or do something else. So those in favor
[08:19:47] <scribe> of alternative one, deprecating the last
[08:19:49] <scribe> hop exception, please hum.
[08:19:53] <scribe> ( Humming. ) NEW SPEAKER: Those in favor of
[08:19:55] <scribe> alternative two, not deprecating the last
[08:19:57] <scribe> hop exception, please hum.
[08:19:59] <scribe> ( Silence. ) NEW SPEAKER: I believe that's pretty
[08:20:02] <scribe> unambiguous. We have consensus on
[08:20:05] <scribe> deprecating the last hop exception. I was the last hold out.
[08:20:09] <scribe> So. NEW SPEAKER: So, James Polk
[08:20:14] <scribe> again. Doesn't this piece alone make it standards track
[08:20:17] <scribe> update of 3261, if we just agreed to it. NEW SPEAKER:
[08:20:18] <scribe> Yes. NEW SPEAKER: (Several people talking.) NEW SPEAKER:
[08:20:22] <scribe> It's in this document. NEW SPEAKER: Whatever document
[08:20:26] <scribe> it is ends up in, just this piece ends up --
[08:20:28] <scribe> NEW SPEAKER: Yes, whatever that document that goes in,
[08:20:31] <scribe> that would make it standards track. There's also by
[08:20:34] <scribe> definition of the discussion yesterday, a bug fix. NEW SPEAKER:
[08:20:37] <scribe> And it also has the IETF tracking property of updates. NEW SPEAKER:
[08:20:42] <scribe> It's not an update to 3261. NEW SPEAKER: It is an
[08:20:44] <scribe> update to RFC 3261 but it's also a bug fix. NEW SPEAKER:
[08:20:46] <scribe> It's both. NEW SPEAKER: Both. NEW SPEAKER:
[08:20:49] <scribe> Both all right. NEW SPEAKER: I'd like to ask the
[08:20:54] <scribe> chairs for a, Robert sparks. For a moratorium on what
[08:20:58] <scribe> document we put this in. We don't need to burn time in the
[08:21:01] <scribe> room on that. We can work it out on the list. NEW SPEAKER:
[08:21:04] <scribe> Your queue. NEW SPEAKER: So, we've gotten, that's
[08:21:08] <scribe> a great thing and I'm glad we got consensus on this one more
[08:21:12] <scribe> problem. We have a multi last hop exception rule in SIP S
[08:21:16] <scribe> today. It's all the way, but if you re target, you can
[08:21:23] <scribe> switch to SIP. So at the end of the day, why is SIP S
[08:21:27] <scribe> useful. If you can have the thing that says, every hop
[08:21:32] <scribe> between UAC and U A S is armord with SIP, if
[08:21:34] <scribe> security property you get, if you trust, let's go with that
[08:21:38] <scribe> assumption. If you trust your proxies, you know that know
[08:21:42] <scribe> one else except your trusted proox see saw the signal. And there's
[08:21:44] <scribe> really interesting things we can do with this property.
[08:21:49] <scribe> Let's say somebody dreams up a way to pass
[08:21:51] <scribe> fingerprints or certificates or stuff
[08:21:54] <scribe> like that, between these things we can do media security. As long as
[08:21:57] <scribe> you trust your proxies, you'll get some good security
[08:22:00] <scribe> properties from that. Many many SIP extensions have this
[08:22:03] <scribe> thing that says, this extension would work if you trust your
[08:22:07] <scribe> proxies and no eve drop err could see this message. That's
[08:22:13] <scribe> the property that SIPs gives us. With any exception, last
[08:22:17] <scribe> hop, re target, whatever, you lose anything you want to
[08:22:21] <scribe> do with SIP S. If you look at this document today, it's
[08:22:26] <scribe> got the thing like the U A gets a request in, and it doesn't know the
[08:22:29] <scribe> hops, and here's a horrible algorithm to make that detection.
[08:22:33] <scribe> This is telling you that this mechanism is not useful. So
[08:22:36] <scribe> what I'm fearful to do, is to produce a document that
[08:22:40] <scribe> still, that just clarifies the security mechanism that still
[08:22:43] <scribe> doesn't provide any useful security properties. So I'm
[08:22:45] <scribe> advocating to the group that we take the next step and also
[08:22:48] <scribe> deprecate the re targeting exception, because it is an
[08:22:51] <scribe> exception just like last hop. NEW SPEAKER: I just want
[08:22:55] <scribe> to clarify what it means before you go. So, what he's
[08:23:00] <scribe> proposing is that when you do have a re targeting, that you
[08:23:05] <scribe> use the same scheme in the re target, if it's SIP versus SIP
[08:23:06] <scribe> S.
[08:23:12] <scribe> NEW SPEAKER: Okay. I didn't double check it. His
[08:23:16] <scribe> draft said it allows it. So I assumed you're right. So
[08:23:20] <scribe> let's forget what's in 3261. What it ought to do is, you
[08:23:26] <scribe> can't re target a proxy cannot re target from SIP S, to
[08:23:29] <scribe> anything except SIP S and it cannot
[08:23:32] <scribe> NEW SPEAKER: Exactly. NEW SPEAKER: Let me finish. If for
[08:23:36] <scribe> some reason it wants to change from SIP to
[08:23:40] <scribe> SIPs, it re directs and no one can recurs on the URI. So it
[08:23:44] <scribe> goes back to the end point. This is how H T T P works. A web
[08:23:48] <scribe> server can redirect you. My browser gives you a screen pop
[08:23:51] <scribe> that says, warning, you're about to visit an unsecure web
[08:23:54] <scribe> site. You can do whatever you want in the U A. But we
[08:24:00] <scribe> armor that link from UAC to U A S, completely and that's what SIP
[08:24:02] <scribe> S says. NEW SPEAKER: Jonathan, before you go away,
[08:24:05] <scribe> is the discussion of this in the document at the moment? NEW SPEAKER:
[08:24:09] <scribe> What? NEW SPEAKER: The discussion of whether this is
[08:24:11] <scribe> an option on the table or not. NEW SPEAKER: Right now
[08:24:15] <scribe> the document says there's an exception also that the re
[08:24:18] <scribe> targeting says you shouldn't do it. NEW SPEAKER: The
[08:24:22] <scribe> document says you shunlt not do it is preet pretty bad idea.
[08:24:26] <scribe> Then it describes what you need to do in a double record route if that
[08:24:26] <scribe> happens.
[08:24:34] <scribe> It also says there's no known use case for N in RFC 3261
[08:24:41] <scribe> foregoing from SIP S, from SIP to SIP S. And there is one
[08:24:48] <scribe> use case foregoing from, no. Actually, it doesn't say
[08:24:48] <scribe> that.
[08:24:52] <scribe> It basically says it's recommended not to do. But it's
[08:24:57] <scribe> allowed in 3261. NEW SPEAKER: John Peterson. NEW SPEAKER:
[08:25:02] <scribe> I definitely agree that the document says you're allowed to re
[08:25:07] <scribe> target from SIP to SIP S. I I can tell you feel very
[08:25:10] <scribe> strongly about this. But the sorts of cases we looked at and
[08:25:14] <scribe> it could be due to an exception or moreover it could be due to the
[08:25:17] --- marc.bailly has joined
[08:25:18] <scribe> fact that the initial user agent didn't know it could ask for SIP S
[08:25:22] <scribe> in this context. But some E intermediary discovers
[08:25:25] <scribe> contacts along the way to find a way for it to become secure.
[08:25:28] <scribe> Obviously, it's not going to provide any insurance, but I
[08:25:32] <scribe> have a hard time seeing why we need to prohibit it. I
[08:25:36] <scribe> mean, it certainly won't make security any worse to allow it.
[08:25:39] <scribe> NEW SPEAKER: Actually, it does, because the far end
[08:25:45] <scribe> client now believes that it was forwarded end to end using SIP
[08:25:48] <scribe> S. NEW SPEAKER: As the text I sent to the list today
[08:25:53] <scribe> suggests, the only way that a U A S, this is text from
[08:25:58] <scribe> 3261, knows that a connection would reach a SIP S
[08:26:02] <scribe> request is if the to header field contains -- NEW SPEAKER:
[08:26:06] <scribe> We do not have consensus on this decision on this poychbt and
[08:26:07] <scribe> further discussion is required. NEW SPEAKER: Okay. NEW SPEAKER:
[08:26:10] <scribe> Just a second. I think we're close. NEW SPEAKER:
[08:26:13] <scribe> Cullen, go to the mic phone. NEW SPEAKER: Cullen Jennings.
[08:26:19] <scribe> I think that we probably could get consensus fairly easily
[08:26:23] <scribe> here. Which is whether the document, whether 3261 currently says this or
[08:26:26] <scribe> doesn't say it, what we want it to be is that there isn't what
[08:26:30] <scribe> Jonathan called the multi hop exception at the last end to. That
[08:26:35] <scribe> it's not okay to have a call that SIPs and then re
[08:26:38] <scribe> target it to downgrade the security --
[08:26:39] <scribe> (Several people talking.)
[08:26:42] <scribe> NEW SPEAKER: He's more worried about upgrading. NEW SPEAKER:
[08:26:45] <scribe> Let me state my actual requirement. NEW SPEAKER: I think
[08:26:47] <scribe> --
[08:26:50] <scribe> NEW SPEAKER: My actual requirement is that when you user agent
[08:26:55] <scribe> receives a request. It can unbig
[08:27:01] <scribe> unambiguously determine whether it has every hop or not.
[08:27:04] <scribe> NEW SPEAKER: You're not speaking into the mic. NEW SPEAKER: It
[08:27:06] <scribe> actually provides that property. NEW SPEAKER: Can you
[08:27:08] <scribe> speak into the mic. (Several people talking.) NEW SPEAKER:
[08:27:10] <scribe> There's a question at the back microphone. NEW SPEAKER:
[08:27:14] <scribe> Moving right along. So I wanted to point out that the
[08:27:20] <scribe> properties that Jonathan described are related actually to
[08:27:26] <scribe> message and not something. The properties he described,
[08:27:30] <scribe> like fingerprint and being able to securely authorize, replaces
[08:27:34] <scribe> headers and things like that, that you can do that equally
[08:27:37] <scribe> well. NEW SPEAKER: Okay. I do not believe we're
[08:27:40] <scribe> going to come to consensus on this in the next two minutes and we're out
[08:27:44] <scribe> of time. So, unless it's just absolutely critical to discuss
[08:27:49] <scribe> this at this point, let's take it to further, Rohan, come
[08:27:57] <scribe> on down. NEW SPEAKER:
[08:27:59] <scribe> NEW SPEAKER: It's Cullen. NEW SPEAKER: Okay. Never
[08:28:04] <scribe> mind, Rohan. NEW SPEAKER: dprans swa,
[08:28:06] <scribe> Francois, you have two more slides left. NEW SPEAKER:
[08:28:11] <scribe> Yes, so, the, there is an a appendix in this docks many that talks
[08:28:15] <scribe> about document that talks about what do we do next.
[08:28:20] <scribe> And really, it's essentially a a short discussion of what
[08:28:23] <scribe> can we, should we do in the future. So, the main topic is
[08:28:28] <scribe> really true end to end SIP security. That's something
[08:28:31] <scribe> that, that was mentioned very often, and probably the main
[08:28:32] --- thomas.stach has joined
[08:28:38] <scribe> drawback with what we have in here. In this document, which is
[08:28:43] <scribe> hop by hop. So there's multiple things that could be done
[08:28:46] <scribe> for end to end security. I'm going to list a few, and if
[08:28:49] <scribe> other people have ideas, let's go along and list them.
[08:28:54] <scribe> What are we trying to solve? One or many problems? There
[08:29:05] <scribe> is one proposal, there is a draft, which basically is about
[08:29:12] <scribe> doing TLS end to end. Between the user agent and the user
[08:29:16] <scribe> client and server. So it kind of starts in a SIP type of fashion and
[08:29:21] <scribe> then it upgrades to SIP S. That's one idea. There could
[08:29:23] <scribe> be other ideas as well.
[08:29:24] --- bhoeneis has joined
[08:29:28] <scribe> Could we have a verifiable assertions that SIP S was used on each
[08:29:32] <scribe> op, that's another thing maybe people want. And there could be
[08:29:35] <scribe> others and so if anybody has any ideas, we'd be, you
[08:29:37] <scribe> know, post it to the mailing list.
[08:29:42] <scribe> So, the question is, do we charter the group for providing a
[08:29:48] <scribe> solution to this problem? And/or do people do not think that
[08:29:50] <scribe> the significant end to
[08:29:52] <scribe> end signalling security is something we should be
[08:29:55] <scribe> working on? So, questions or comments? NEW SPEAKER:
[08:29:59] <scribe> So I think it's actually quite e critical when you're
[08:30:02] <scribe> establishing a charter work, to describe whether or not one of
[08:30:06] <scribe> the end to end security properties you're looking for is that you
[08:30:09] <scribe> know longer need to trust the proxy. NEW SPEAKER:
[08:30:12] <scribe> Right. NEW SPEAKER: So, that's not clear. I think you'll end
[08:30:15] <scribe> up with a bunch of things that actually do very different stuff.
[08:30:17] <scribe> NEW SPEAKER: Right. NEW SPEAKER: Making that a very
[08:30:21] <scribe> clear part of the target exercise would be valuable work. NEW SPEAKER:
[08:30:25] <scribe> Correct. And that's kind of why I had a line that said one
[08:30:29] <scribe> problem or many problems. I agree. It I think it could be
[08:30:32] <scribe> very different. NEW SPEAKER: Eric. NEW SPEAKER:
[08:30:33] <Alan Hawrylyshen> q from ted hardie
[08:30:36] <scribe> So it's very deeper here, the security issue, which is I
[08:30:41] <scribe> mean, that if what you want is integrity of the situation is one
[08:30:46] <scribe> thing. What you want is confidentiality for, your verging
[08:30:49] <scribe> very close to throwing the entire SIP model away and replacing
[08:30:53] <scribe> it with something else. Because if you're going to hide the stuff that
[08:30:56] <scribe> proxies operate rate on, namely the headers. Then
[08:31:00] <scribe> basically, you know, everything you think of as SIP is just
[08:31:05] <scribe> going to be completely wiped out. Some sort of protocol that
[08:31:09] <scribe> has everything. There is media through the server, but
[08:31:11] <scribe> essentially it's something about concern.
[08:31:18] <scribe> So, on the SIP sek, that's what I see. And I don't know
[08:31:21] <scribe> how that could possibly work. Now, if you're willing
[08:31:26] <scribe> to say, oh, all I wanted was like a end to end, then you look
[08:31:31] <scribe> at something like identity. But, and if you want to do
[08:31:35] <scribe> confidentiality, basically, SIP one way is fine. NEW SPEAKER:
[08:31:39] <scribe> Before you leave the mic, Eric, Eric, Eric, before you
[08:31:42] <scribe> leave the mic, as a member of the SIP community, would you
[08:31:45] <scribe> like to say what you think we need? NEW SPEAKER: Well,
[08:31:49] <scribe> I think we clearly need integrity. There's no question about
[08:31:58] <scribe> that. The, I think confidentiality for you know, for the
[08:32:01] <scribe> message body, which is identified yet, it would be nice to
[08:32:09] <scribe> have. But I think that, you know, it's aversion towards using SIP
[08:32:12] <scribe> for a carry for signalling. So I could live
[08:32:16] <scribe> with sh arrangement where you're running something confidential
[08:32:17] --- hbaosiy has joined
[08:32:20] <scribe> and I carry a similar side channel. NEW SPEAKER:
[08:32:26] <scribe> Jonathan, NEW SPEAKER: Caplan. I think this is going
[08:32:29] <scribe> to be way too long a discussion this morning. NEW SPEAKER:
[08:32:33] <scribe> We have two minutes left. NEW SPEAKER: Yes. All I
[08:32:38] <scribe> can say is this is a path, you think it's end to end. It's
[08:32:42] <scribe> not. Even integrity headers is not. It's signed by another
[08:32:47] <scribe> hop. It is not actually end to end. If you think about S B
[08:32:51] <scribe> Cs or other products, that is the end as far as you know.
[08:32:56] <scribe> It's not RN U A. Let's keep those, unless we both start having
[08:33:00] <scribe> certificates, this will not occur. So I don't know, I don't know
[08:33:03] <scribe> why we keep going down this rat whole, you have to trust the
[08:33:07] <scribe> guy in the middle. It may not be proxies, I don't think there are that
[08:33:10] <scribe> many proxies anymore, but there seem to be other types of
[08:33:18] <scribe> boxes. But, yes, you know. NEW SPEAKER:
[08:33:23] <scribe> Jonathan Rosenburg, it's behavior. The only architecture in
[08:33:26] <scribe> which you can get everything, you know, completely secure
[08:33:30] <scribe> between two U As without trusting the proxies is if there are
[08:33:32] <scribe> no proxies. So you know, there's nothing, you can today do
[08:33:36] <scribe> that. You can send a SIP invite from one U A to another U A
[08:33:42] <scribe> directly. And if they have certificates. You can directly
[08:33:45] <scribe> encrypt that link. How do I find that other guy. Well, you
[08:33:48] <scribe> have to trust something to do that. If you e don't think
[08:33:53] <scribe> it's a proxy. If you think P to P SIP is better, we talked
[08:34:00] <scribe> about that this morning. To establish a direct P to P SIP, and
[08:34:04] <scribe> if you have end point signed by someone, trust self signed or
[08:34:09] <scribe> whatever, take your pick, you've got to drus a D H T. And more or
[08:34:12] --- frodek has joined
[08:34:13] <scribe> less in a proxy network. And I don't know. I think all of
[08:34:18] <scribe> this is out of the scope of SIP. You trust the proxies to do stuff.
[08:34:20] <scribe> And I think anything else is not SIP anymore.
[08:34:28] <scribe> NEW SPEAKER: Rohan may. So I'm going to agree slightly
[08:34:32] <scribe> with what Jonathan said. The SIP model means that, if you have an
[08:34:39] <scribe> address of record, that re solves to a specific proxy, that
[08:34:43] <scribe> you trust that proxy to do forwarding for you. And that I
[08:34:47] <scribe> think it is useful, eventually for us to go and to improve
[08:34:50] <scribe> what we tried to do with S MIME. I think that was done in a
[08:34:56] <scribe> hurry. And without a lot of implementation experience.
[08:35:00] <scribe> I think the priority right now is to get TLS, which is you
[08:35:02] <scribe> know, over half the
[08:35:07] <scribe> implementations in SIP, let's go get that fixed and let's get that
[08:35:10] <scribe> deployed. And when it looks like we're getting good
[08:35:14] <scribe> operational experience with that, and hopefully some
[08:35:17] <scribe> operational experience with the identity section, then let's
[08:35:21] <scribe> come back and fix end to end encryption.
[08:35:24] <scribe> And all that means is that we're going to make sure that the
[08:35:29] <scribe> stuff that needs to be end to end is integrity protected and
[08:35:33] <scribe> confidential in the proxies forward it correctly. It doesn't
[08:35:36] --- mph has joined
[08:35:37] <scribe> mean that we're going to guarantee a way that some proxy may or may
[08:35:40] <scribe> not forward it to the right place. It just means that you
[08:35:45] <scribe> can tell if it did. Thanks. NEW SPEAKER: I also
[08:35:49] <scribe> think end to end is kind of hopeless. And when I say
[08:35:53] <scribe> hopeless, I guess I mean, particularly, S MIME I would say is
[08:35:57] <scribe> kind of hopeless. But like Rohan, I want to be careful
[08:36:02] <scribe> when we say we trust intermediaries. I know I trust them to
[08:36:05] <scribe> perform specific functions and I know that I'm potentially willing
[08:36:09] <scribe> to trust an E intermediary with whom I have a direct
[08:36:13] <scribe> association, maybe that I control, to provide security,
[08:36:16] <scribe> much more than a network that I have no relationship. I'd
[08:36:20] <scribe> like to be able to have a model for SIP in which I am not
[08:36:24] <scribe> required to trust that whole network, so much as I'm required
[08:36:27] <scribe> to trust that one guy. And so I agree that end to end SIP
[08:36:31] <scribe> security is, let's figure out a way that UAC to have
[08:36:36] <scribe> credentials that will allow it tovt confidential and in teing
[08:36:40] <scribe> tie to a U A S ask a red herring. It doesn't mean that we
[08:36:45] <scribe> don't have to have a story about how you can have security; especially
[08:36:50] <scribe> if you're good security. And that's something we need to
[08:36:54] <scribe> control. NEW SPEAKER: Okay. To summarize, I think
[08:36:59] <scribe> what we're hearing is, we believe that there is some security properties
[08:37:06] <scribe> that we should address. But we're, it does not seem like we have
[08:37:11] <scribe> lots of support for end to end security as in everything will
[08:37:16] <scribe> be, everything between the two clients will be
[08:37:18] <scribe> integrity protected and everything. NEW SPEAKER: That
[08:37:21] <scribe> isn't what I said. NEW SPEAKER: What I think I'm
[08:37:25] <scribe> hearing from my side, the chair's side, is basically, we
[08:37:28] <scribe> don't have consensus to do anything. Anything that we are
[08:37:31] <scribe> going to do needs to be well proposed to the working group as
[08:37:33] <scribe> to what it achieves. NEW SPEAKER: Right. NEW SPEAKER:
[08:37:37] <scribe> And the fact that it is, well, first, what security
[08:37:40] <scribe> properties it gives you, and then is it possible to actually
[08:37:43] <scribe> achieve it. NEW SPEAKER: Right. Yes. NEW SPEAKER:
[08:37:46] <scribe> That should probably describe the threat model that it's
[08:37:55] <scribe> attempting to deal with. NEW SPEAKER: Okay.
[08:37:59] <scribe> NEW SPEAKER: You have not nearly enough time. NEW SPEAKER:
[08:38:08] <scribe> Next slide. So, I have presented
[08:38:11] <scribe> NEW SPEAKER: You're not on. NEW SPEAKER: Sorry. It's mute
[08:38:14] <scribe> ted. NEW SPEAKER: There we go. That's a preferable
[08:38:16] <scribe> situation, maybe, having me mute ted.
[08:38:19] <scribe> I have talked about exactly the topic I'm going to talk about
[08:38:24] <scribe> today, in at least 7 or 8 SIP meetings now. Some SIPPING.
[08:38:28] <scribe> Outbound has been around for a long time. We need to finish
[08:38:31] <scribe> it. It's extremely close to dying. It hasn't changed in very
[08:38:35] <scribe> many ways. Since the last time. We really are in the
[08:38:36] <scribe> last 8 months.
[08:38:40] <scribe> So, next slide. So I want to talk about briefly what the
[08:38:44] <scribe> changes are to this document. The pros and cons of the major
[08:38:47] <scribe> big issue we need to talk about, try and get feedback and discussion
[08:38:50] <scribe> on what the do about that and some smaller things to look at.
[08:38:55] <scribe> Certainly some people on the list felt that we should switch to
[08:39:02] <scribe> using C R L F scheme as the keep a live. The prior version of
[08:39:06] <scribe> this document had used stun for the keep a live doing TCP.
[08:39:10] <scribe> So what we did is, we wrote the text up in this document to really try
[08:39:14] <scribe> and give the working group a good idea to see what this would look like.
[08:39:17] <scribe> And what we're trying to do here is basically the big question
[08:39:20] <scribe> I'm going to be asking at the end of this today is, you know,
[08:39:23] <scribe> should we go to the previous version of the document which used
[08:39:27] <scribe> stun or should we use this version of the document which uses C
[08:39:28] <scribe> R L F. So that's the big change.
[08:39:32] <scribe> Another little detail that happened along the way is, we
[08:39:36] <scribe> changed the syntax of the keep alive slightly, because now
[08:39:40] <scribe> you had to be able to indicate you could have multiple one's
[08:39:46] <scribe> and this syntax was a bit easier for people, that was a tiny
[08:39:50] <scribe> little bit on the wire, it really didn't change much.
[08:39:55] <scribe> So, I should make it clear too, I'm just speaking here as the
[08:40:02] <scribe> editor of this document. The good side of this stuff, is
[08:40:04] <scribe> that implementations that only do
[08:40:10] <scribe> TCP and have no R T P implementation, no ice
[08:40:14] <scribe> implementation, no U D P implementation, they wouldn't knee
[08:40:18] <scribe> to do the stun stuff. They obl have to do TCP. This
[08:40:21] <scribe> probably is not going to be most am cases, because there's
[08:40:27] <scribe> not applications that only do the SIP, wouldn't do SIP over
[08:40:30] <scribe> TCP but it also relates to the media.
[08:40:33] <scribe> The other thing that came up was about multi Plaintiff's
[08:40:39] <scribe> Exhibiting of multi plexing into the TCP.
[08:40:43] <scribe> There's a layer, bottom layer, you're reading along and you need
[08:40:47] <scribe> to figure out where one message ends and the next
[08:40:51] <scribe> one starts. You need to add about six more lines of code to
[08:40:54] <scribe> be able to decide, was the new message, when a new message
[08:40:58] <scribe> starts, does a stun message or is it a SIP message and you look at the SIP
[08:41:00] <scribe> header and figure that out.
[08:41:04] <scribe> So you don't have to do that. And if you send a stun message
[08:41:09] <scribe> to a proxy that doesn't support this. Did TCP z gets out of sink and it
[08:41:12] <scribe> will close. So, that's one of the other things.
[08:41:17] <scribe> So, this is the good side. The C R L F, you just detect
[08:41:20] --- danwing has joined
[08:41:20] <scribe> the double C L RF and you're ready to go. Next slide.
[08:41:25] <scribe> The real problems that we ran into in doing this, is that we
[08:41:29] <scribe> now have two orthagonal things. We have which transport you're
[08:41:33] <scribe> using, and this is specified lots of, you know, there's
[08:41:36] <scribe> lots of different ways you can discover which transport
[08:41:40] <scribe> you're using in SIP at various times. Like the whole DNS resolution
[08:41:40] <scribe> thing.
[08:41:47] <scribe> And we also have another ACK committees, which
[08:41:51] <scribe> keep access, which keep alive you're using. You have a tag
[08:41:56] <scribe> that says, either use stun or use C R L F. And the problem
[08:42:02] <scribe> is, since these things are only defined on one, you can get
[08:42:06] <scribe> them in a contributing form. So your DNS can be
[08:42:12] <scribe> configured to tell you you need U D P. Or after TCP connection
[08:42:16] <scribe> failed you back down to U D P connection. And your outbound
[08:42:20] <scribe> proxy on the other hand says to use another keep alive. This makes
[08:42:26] <scribe> it hard to do an a deployment that says TCP is preferred but if
[08:42:30] <scribe> that doesn't work, use U D P. Because in that case, you
[08:42:32] <scribe> have to set your outbound proxy.
[08:42:38] <scribe> You wouldn't know C R L F keep alive or a stun keep alive which only
[08:42:41] <scribe> works with U D P. There would be no possible way to
[08:42:42] <scribe> configure that system.
[08:42:48] <scribe> So, this lands us into a bunch of corner cases.
[08:42:51] <scribe> And we can you know, there's other ways that corner
[08:42:55] <scribe> cases can quum come up too. Certainly when we discover some
[08:43:00] <scribe> of these things in a path header, they can could easily
[08:43:03] <scribe> contribute. But the S R P problem was the worst one.
[08:43:07] <scribe> The biggest problem that we came to in sort of writing this up. NEW SPEAKER:
[08:43:10] <scribe> Hold on a second. I want to make a comment. NEW SPEAKER:
[08:43:13] <scribe> Sure. NEW SPEAKER: If we were to always do
[08:43:17] <scribe> discovering of what keep a live to use by probing a life
[08:43:20] <scribe> connection, wouldn't all of these cases evaporate? NEW SPEAKER:
[08:43:23] <scribe> That would basically double the load of a start up situation on
[08:43:27] <scribe> proxies. And we discussed that extensively prior in the
[08:43:29] <scribe> working group and came to very strong agreement that was
[08:43:33] <scribe> completely unacceptable. So, I don't think people want to
[08:43:36] <scribe> do that. But yes, that's sort of one possible solution to
[08:43:39] <scribe> it, is that you have to open a connection, find out what you
[08:43:42] <scribe> really should be doing, and then go open another connection
[08:43:45] <scribe> to send your first registration. NEW SPEAKER: Rohan
[08:43:48] <scribe> may. I wanted to point out something that may not have been obvious from
[08:43:52] <scribe> Cullen's previous, the previous slide. NEW SPEAKER:
[08:43:58] <scribe> Fair enough. NEW SPEAKER: So going back to the back
[08:44:02] <scribe> here, I think we actually agreed on the wording of the slide
[08:44:05] <scribe> that we didn't say that it's extremely tricky to do this. It
[08:44:11] <scribe> just requires that either your stack keep a live processing or
[08:44:15] <scribe> the application needs to find out the resulting transport that was
[08:44:15] <scribe> used.
[08:44:20] <scribe> I will also point out that in the case where, that there's
[08:44:22] <scribe> several other extensions that we have, like the identity
[08:44:28] <scribe> header, s that require you to do exactly this same thing, where
[08:44:32] <scribe> the application or the stack needs to be, needs to cooperate in
[08:44:37] <scribe> a particular way to figure out what the resulting transport
[08:44:42] <scribe> was. And I also wanted to clarify that the way that the we
[08:44:47] <scribe> defined these tags, that it's very easy for somebody that
[08:44:53] <scribe> is willing to do either TCP or U D P and
[08:44:58] <scribe> supports stun over U D P and C R L F over TCP to put both
[08:45:03] <scribe> tags in and everything works beautifully. It's only when
[08:45:06] <scribe> somebody tries to configure something and says, only I
[08:45:10] <scribe> support stun or C R L F. And they're due to a
[08:45:13] <scribe> misconfiguration that those contradict. That is the problem that
[08:45:17] <scribe> Cullen is describing. So it's, that we have here
[08:45:21] <scribe> corner cases where there's a misconfiguration. NEW SPEAKER:
[08:45:29] <scribe> Next slide. NEW SPEAKER: Sorry. Kristen. I
[08:45:33] <scribe> still have one, it's related to this. I mean, of course, you
[08:45:37] <scribe> know, by doing wrong operation, you can screw up anything.
[08:45:42] <scribe> But I think, I'm not sure whether that, if you a few seconds
[08:45:46] <scribe> ago, you said we agreed to something we don't want to do. I didn't hear
[08:45:49] <scribe> what you said. So I'm not sure what I'm going to bring up.
[08:45:52] <scribe> But one thing I did bring up on the list a few days ago and it's
[08:45:56] <scribe> related to the second bullet. For example, is that do we
[08:46:00] <scribe> really need this keep parameter? Or is it enough just to
[08:46:05] <scribe> indicate to the URI that outbound, because I mean, from S R
[08:46:13] <scribe> scchlt, V. We get U D P or TCP from S RV and it
[08:46:16] <scribe> indicates that it supports outbound then it automatically
[08:46:20] <scribe> means that it supports C R L F keep a live. We
[08:46:24] <scribe> don't he really need to indicate that. I think that's one possible
[08:46:28] <scribe> solution which I think we should investigate. Thank you.
[08:46:34] <scribe> NEW SPEAKER: Next slide.
[08:46:42] <scribe> So we've taken working group hums on this a couple of times
[08:46:46] <scribe> before. I am really in the mode to, like, if people want to
[08:46:50] <scribe> have some discussion on what we should do, but I want to take
[08:46:53] <scribe> a hum on this and finish this document regardless of what the outcome
[08:46:58] <scribe> is. I feel it's far more important to actually make a choice on one of these
[08:47:01] <scribe> things today, than what the choice is, really.
[08:47:05] <scribe> Once we make a choice on this, every previous time we've made
[08:47:09] <scribe> a choice on this, we've gone back and flipped it later. And we
[08:47:12] <scribe> can't finish this document and keep doing that. So we've got
[08:47:15] <scribe> to make a choice here, take it to the list and call consensus
[08:47:20] <scribe> on it one way or the other very soon. So do peel want to talk
[08:47:23] <scribe> about what the issues are here?
[08:47:26] <scribe> NEW SPEAKER: I don't think I want to talk about the issue.
[08:47:32] <scribe> But I will point out that it seems to me, from the 5,000
[08:47:36] <scribe> e-mails we had on this, and the working group, 3,000, but
[08:47:42] <scribe> anyway, that there was a consensus from the group to -- NEW SPEAKER:
[08:47:46] <scribe> There was a consensus from about 8 or ten people that
[08:47:48] <scribe> participated in that list. No more. There's no more
[08:47:51] <scribe> authors than that. And that's quite a few more people than
[08:47:54] <scribe> that in this room. And we're on the previous hum. So I'm
[08:47:57] <scribe> perfectly happy if those ten people, if that's the only
[08:48:00] <scribe> people in this room that care, we're done. Right. NEW SPEAKER:
[08:48:01] <scribe> Okay. (Several people talking.) NEW SPEAKER: We
[08:48:06] <scribe> can do that, but anyway, it seems to me that we exhausted this
[08:48:09] <scribe> topic. Maybe the best thing to do would be to do a hum.
[08:48:13] <scribe> But I do find it strange that sometimes we do the consensus on the
[08:48:16] <scribe> mailing list and sometimes we do it in the room. NEW SPEAKER:
[08:48:21] <scribe> We're going to be doing it on this call on both. But,
[08:48:25] <scribe> obviously, as required, we take into account consensus from the room
[08:48:28] <scribe> and consensus from the mailing list. NEW SPEAKER: Can
[08:48:33] <scribe> you just go back about three slides to where, I think it said,
[08:48:40] <scribe> sorry. Good. Okay. So, is this the entire argument
[08:48:43] <scribe> for doing this, NEW SPEAKER: Rohan, do you want to
[08:48:45] <scribe> add any additional arguments for doing this. NEW SPEAKER:
[08:48:49] <scribe> I think this has been well discussed on the list and if you
[08:48:51] <scribe> don't understand it, we're going to have spend two minutes with you right
[08:48:55] <scribe> now, before we take a hum. NEW SPEAKER: Yes or no. NEW SPEAKER:
[08:48:59] <scribe> I would say yes. -- NEW SPEAKER: I understand this
[08:48:59] <scribe> point. NEW SPEAKER: (Several people talking.)
[08:49:02] <scribe> NEW SPEAKER: I don't think you do understand the point. (Several people talking.) NEW SPEAKER:
[08:49:06] <scribe> I've heard a a lot so I do (Several people talking.) NEW SPEAKER:
[08:49:10] <scribe> Yes or no. NEW SPEAKER: There is one other argument
[08:49:13] <scribe> that some people who, I don't see in the room right now,
[08:49:16] <scribe> have raised repeatedly on the list, that is pt really
[08:49:19] <scribe> represented in this discussion. Which is there are people
[08:49:26] <scribe> who feel that implementing U D P is not worth the effort.
[08:49:30] <scribe> And that it is, they are strongly in favor of not discussing U
[08:49:37] <scribe> D P inside outbound at all. And as a result, see no need
[08:49:41] <scribe> to implement stun inside a transport protocol.
[08:49:45] <scribe> NEW SPEAKER: The way I would have phrased what Dean just
[08:49:49] <scribe> said would be there's a bunch of people who would like to deprecate
[08:49:54] <scribe> U D P and they do breaking outbound with U D P as an
[08:49:58] <scribe> advantageous way to go. sthoo I think you
[08:50:03] <scribe> already decide ed you weren't going to say that Rohan. NEW SPEAKER:
[08:50:05] <scribe> I didn't agree I wouldn't (Several people talking.)
[08:50:08] <scribe> NEW SPEAKER: You did agree you wouldn't say it. NEW SPEAKER:
[08:50:12] <scribe> You said that you would be fair. And that's not fair. But
[08:50:16] <scribe> if you want to continue to remain the editor of this
[08:50:16] --- lowekamp@gmail.com has joined
[08:50:19] <scribe> document, I suggest that you behave yourself when standing in
[08:50:22] <scribe> the front of this room. NEW SPEAKER: All right. NEW SPEAKER:
[08:50:28] <scribe> So I would like to add to EKR's point that there is a subtle
[08:50:31] <scribe> nuance in this second bullet, which is that many vendors that I
[08:50:35] <scribe> have spoken with, they are using a different stack for SIP
[08:50:40] <scribe> than they would use for stun. And stitching these two
[08:50:44] <scribe> together for implementation perspective for U D P is fairly
[08:50:48] <scribe> straightforward. But stitching them together for TCP is more
[08:50:53] <scribe> complicated because they need to go and do something in the
[08:50:59] <scribe> guts of the framing of the SIP stack, to go determine whether
[08:51:04] <scribe> something is a stun message and then pass it off to the stun
[08:51:04] <scribe> stack.
[08:51:07] <scribe> Now, I am just relaying information that I
[08:51:13] <scribe> received from several people about this. And SIP its
[08:51:14] --- lowekamp@gmail.com has left
[08:51:17] <scribe> And private. NEW SPEAKER: I agree with what Rohan, I
[08:51:20] <scribe> glee with what Rohan is saying. I will note they will also
[08:51:25] <scribe> need to make changes to something to detect that. You do have
[08:51:27] <scribe> to edit that code. NEW SPEAKER: Yes. NEW SPEAKER:
[08:51:32] <scribe> Okay. NEW SPEAKER: So Rohan and I are in, complete
[08:51:34] <scribe> agreement on that point. NEW SPEAKER: I just want to
[08:51:37] <scribe> clarify that the second bullet is actually the one that I
[08:51:42] <scribe> believe is important. And it's really in my opinion,
[08:51:49] <scribe> mostly an issue on the server side. Multi plexing on the
[08:51:53] <scribe> client side is not necessarily that difficult, but for the
[08:51:59] <scribe> server side it is significantly more complicated than what we've
[08:52:04] <scribe> seen and a lot of people have expressed the same point of
[08:52:04] <scribe> view.
[08:52:07] <scribe> So I would suggest that we -- NEW SPEAKER: Do you want to
[08:52:10] <scribe> expand on the complications there? Because I'm clearly not
[08:52:13] <scribe> doing a fair job. So say something about it if you want.
[08:52:17] <scribe> Why is it complicated? NEW SPEAKER: Well, so for a
[08:52:22] <scribe> start, they're doing a SIP proxy. They're not doing a stun
[08:52:27] <scribe> server. Stun server is somewhere else and it's used for
[08:52:29] <scribe> media and it's well optimized and it may not
[08:52:32] <scribe> even be done by the same vendor.
[08:52:37] <scribe> This essentially forces you to implement a new protocol, multi
[08:52:41] <scribe> plex on the same port, and as Rohan was saying, if you're
[08:52:46] <scribe> purchasing your or acquiring your stack from different vendors, it
[08:52:51] <scribe> is more complicated. So, I don't think it would be fair to
[08:52:54] <scribe> say it's not complicated. Most of the time it's more
[08:52:55] <scribe> complicated.
[08:53:00] <scribe> So, I, I'm not sure we really want to dig into redo the whole
[08:53:04] <scribe> mailing list argument right now, because I think it can only
[08:53:08] <scribe> get worse. So I really support that we do a final hum on
[08:53:14] <scribe> this and move along. I a, a real final hum. Because I
[08:53:18] <scribe> think we had many final hums.
[08:53:20] <scribe> NEW SPEAKER: Microphone, please. NEW SPEAKER:
[08:53:24] <scribe> State your name again, louder, please. NEW SPEAKER:
[08:53:37] <scribe> I think the protocol something about TCP and U D P. But
[08:53:45] <scribe> this could be the dust both TCP and U.S. But requires outbound
[08:53:52] <scribe> something. NEW SPEAKER: Sorry, Eric. Can you go
[08:53:58] <scribe> back to the right. So. Do we still have this probing stuff in
[08:54:01] <scribe> here, or did we get rid of that. NEW SPEAKER: No,
[08:54:04] <scribe> that's still in there. I have that as a later question. NEW SPEAKER:
[08:54:08] <scribe> Okay. So when you want to discuss that. Okay. We'll
[08:54:11] <scribe> do that separately? NEW SPEAKER: Unless you think they're coupled
[08:54:14] <scribe> together here. NEW SPEAKER: I think, okay. No.
[08:54:15] <scribe> They're not. Really.
[08:54:22] <scribe> Yes, I mean, I don't know. I hear people saying about
[08:54:26] <scribe> having a couple of stacks, and in my experience, that's not
[08:54:29] <scribe> particularly difficult. To do a couple of things like
[08:54:34] <scribe> especially since I imagine difficulty of doing it, the stun
[08:54:40] <scribe> implementation makes this work. But you know, people, ask what's right
[08:54:44] <scribe> about it. You know, I guess it's sort of having two things
[08:54:49] <scribe> only sort of being like, NEW SPEAKER: Jonathan
[08:54:51] <scribe> Rosenburg, this is a question for the chairs for the most
[08:54:59] <scribe> part, which is, you know, Rohan made an interesting point.
[08:55:05] <scribe> And I have been noodleing a compromise approach
[08:55:10] <scribe> and I won't say it unless the chairs want to hear it. So is, is
[08:55:13] <scribe> there interest in it. Do we think we need a compromise or do
[08:55:16] <scribe> we think we're going to have consensus to pick one or the other? NEW SPEAKER:
[08:55:21] <scribe> My opinion is that there is no way I could in good faith
[08:55:25] <scribe> declare a rough consensus in either direction at this time.
[08:55:28] <scribe> And outside of using baseball baths to the
[08:55:33] <scribe> components and locking them into a conference room and see who
[08:55:35] <scribe> comes out. I have no --
[08:55:40] <scribe> (Several people talking.) NEW SPEAKER: There's an A D
[08:55:45] <scribe> in the back of the room. The guy in the red shirt.
[08:55:48] <scribe> NEW SPEAKER: Go for the bats. NEW SPEAKER:
[08:55:53] <scribe> I heard you speaking. I'm not speaking as an A D. I'm speaking
[08:55:57] <scribe> as an author. I actually wrote a draft called
[08:56:01] <scribe> three920. It's a whole set of procedures you can use when you
[08:56:05] <scribe> have working group consensus that there must be a single
[08:56:09] <scribe> solution. And you do not have yet have working group
[08:56:12] <scribe> consensus on what that solution must be. If you'd like to
[08:56:16] <scribe> run an experiment and use it, I'll be happy to tell you how to
[08:56:21] <scribe> go through it. But first, I would suggest a hum, on is everybody board
[08:56:24] <scribe> enough that we're willing to do quhavr it takes to get
[08:56:28] <scribe> something out? And if you get violent nodding from everybody
[08:56:32] <scribe> like you just got from Cullen, then there's a bunch of stuff we can
[08:56:36] <scribe> do that may boil down to flipping a coin. But realisticly
[08:56:39] <scribe> has some other possible properties. So if you
[08:56:43] <scribe> actually want to do that first, then there may be ways
[08:56:46] <scribe> around it that don't involve the baseball bats,
[08:56:49] <scribe> because that does prejudice you. NEW SPEAKER: I have
[08:56:52] <scribe> outbound communication from a number of people that indicate
[08:56:55] <scribe> they would not be willing to compromise in any case. NEW SPEAKER:
[08:56:58] <scribe> I think, could we take a hum. I think from everybody I
[08:57:03] <scribe> heard, I certainly would rather have a decision today,
[08:57:06] <scribe> regardless of the decision. NEW SPEAKER: Okay. Let's (Several people talking.) NEW SPEAKER:
[08:57:09] <scribe> Then I'll take a hum on that question. NEW SPEAKER:
[08:57:13] <scribe> Cullen. NEW SPEAKER: Speak up. NEW SPEAKER:
[08:57:16] <scribe> So I think, I think the consensus on the mailing list was
[08:57:20] <scribe> pretty clear. Maybe because I was sort of on the other
[08:57:23] <scribe> side, that's how I feel. That's the reason why I feel that
[08:57:26] <scribe> way. But I mean, I think what Cullen just brought up in
[08:57:31] <scribe> the second slide or whatever it was, the problem with having two
[08:57:36] <scribe> different keep a live methods for TCP and U D P. I don't
[08:57:39] <scribe> think you said it on the list either. It's some weird
[08:57:43] <scribe> configuration issue, I mean, like what is the real problem you
[08:57:48] <scribe> have with having C R L F for TCP and stun for U D P? I'm not
[08:57:52] <scribe> hearing that there's such a problem with having those two.
[08:57:56] <scribe> Be present. NEW SPEAKER: So you're suggesting all the
[08:57:59] <scribe> outbound proxy configuration sets would have both of those in them?
[08:58:04] <scribe> NEW SPEAKER: So I just don't see the case. Like he was
[08:58:09] <scribe> saying, if you indicate that your outbound proxy is out
[08:58:15] <scribe> bound, and resolve to an address for U D P, U D P transport.
[08:58:20] <scribe> Use stun. Right. If you get a TCP transport, you use C
[08:58:24] <scribe> R L F. Where is the problem? NEW SPEAKER: Well,
[08:58:27] <scribe> people want to be able to specify whether which keep a
[08:58:30] <scribe> lives are supported on different things. We've had several
[08:58:34] <scribe> wireless vendors come and tell us that they're willing to do
[08:58:37] <scribe> TCP keep a lives, but the TCP keep a
[08:58:42] <scribe> lives, not the C R L F ones, but they can't do C R L F, so
[08:58:46] <scribe> if you want to configure your stuff that it forced that kind of
[08:58:49] <scribe> keep a live, and you wanted to also configure such that you
[08:58:54] <scribe> preferred TCP but would fall back to U D P if there was a fire wall
[08:58:57] <scribe> or the opposite way, there's currently no way to configure
[08:59:01] <scribe> that. And I'm glad to pursue an option, and I did put this
[08:59:05] <scribe> on the list. NEW SPEAKER: My point was vendor --
[08:59:06] <scribe> NEW SPEAKER: Okay. NEW SPEAKER: And first of
[08:59:09] <scribe> all, I think TCP keep a live, isn't just a great idea
[08:59:13] <scribe> actually, even though I like it m the beginning. It
[08:59:18] <scribe> doesn't support that. Can't say TCP something. You can't
[08:59:21] <scribe> use it in SIP yet. But C R L F you certainly can. NEW SPEAKER:
[08:59:27] <scribe> Some of the later O is.s You can
[08:59:29] <scribe> (Several people talking.) NEW SPEAKER: Yes. Okay. NEW SPEAKER:
[08:59:34] <scribe> I think we should vote, seriously. NEW SPEAKER:
[08:59:37] <scribe> That's what I've agreed to do before. After he talked. NEW SPEAKER:
[08:59:41] <scribe> I mean, sometimes we argue for like an hour and we have a
[08:59:44] <scribe> vote and there's two people that support it and a hundred that support
[08:59:46] <scribe> the other one. So it's a waste of time. NEW SPEAKER:
[08:59:51] <scribe> Okay. So, let me take a quick pol on something before
[08:59:54] <scribe> there's more speaking. There are those who apparently believe
[09:00:02] <scribe> stha we must come to some conclusion today on A or B. To the
[09:00:07] <scribe> extent that they would be willing to accept whatever more or
[09:00:10] <scribe> less the majority believes, even if it disagrees with them.
[09:00:14] <scribe> There are also those who do not agree that they would
[09:00:17] <scribe> be willing to accept whatever the majority agrees and that it
[09:00:24] <scribe> needs further discussion. So, if you're willing to accept the
[09:00:27] <scribe> majority position of whatever it is, and stop arguing about
[09:00:28] <scribe> it, please hum.
[09:00:33] <scribe> ( Humming. ) NEW SPEAKER: If you think we need
[09:00:36] <scribe> further discussion and that we don't really have an answer yet.
[09:00:37] <scribe> Please hum.
[09:00:42] <scribe> ( Humming. ) NEW SPEAKER: Good. Okay. Thank you.
[09:00:45] <scribe> NEW SPEAKER: Can you call that. NEW SPEAKER: The majority
[09:00:47] <scribe> seems to be in favor of --
[09:00:51] <scribe> NEW SPEAKER: Chris ten. NEW SPEAKER: Just maybe go into
[09:00:53] <scribe> details, the problem we have just here, there was a
[09:00:56] <scribe> question, you know, what if we have multiple keep a live
[09:01:01] <scribe> mechanisms for one transport protocol, you know, and we
[09:01:04] <scribe> only indicate open. I think that will be solved. One of
[09:01:07] <scribe> the other things which I have proposed and which I understood are
[09:01:13] <scribe> okay. I proposed for example, you know, you do your S RV get
[09:01:18] <scribe> TCP and have outbound U R A only indicating outbound, you don't know
[09:01:22] <scribe> what keep a live mechanism it is. You send the register,
[09:01:25] <scribe> to the edge proxy and what I propose, the edge proxy can
[09:01:31] <scribe> actually serve in the part header, to key parameter actually.
[09:01:35] <scribe> So that edge proxy can then actually insert actual keep
[09:01:40] <scribe> parameter, which is it want toss use and then it goes back to the response to
[09:01:44] <scribe> the U A and you U A can use that. Then you don't have a
[09:01:49] <scribe> problem. You know, then of course, if I use the TCP and edge
[09:01:53] <scribe> proxy returns, keep stun, again, something is wrong and we don't
[09:01:53] <scribe> --
[09:01:58] <scribe> NEW SPEAKER: So, this is, you know, both the editors
[09:02:00] <scribe> deserved to be fired on this document. Chris ter brought
[09:02:05] <scribe> this up before the last IETF. We sent an e-mail that said,
[09:02:07] <scribe> yeah yeah yeah, if you get one of these tags in the path
[09:02:11] <scribe> header, then you would pay attention to what it did when you
[09:02:13] <scribe> formed a new connection based on that.
[09:02:19] <scribe> And then we promptly forgot to fix the two lines of text that you sent
[09:02:23] <scribe> us to fixes it. We've agreed to fix that mistake. We'll fix
[09:02:27] <scribe> it in the next version. That does solve it in the case of path header
[09:02:29] <scribe> ordeal with that issue. It doesn't this the cases where
[09:02:32] <scribe> you're not using that type of environment though. That's the
[09:02:35] <scribe> only way to do it. NEW SPEAKER: I actually put it into
[09:02:39] <scribe> the previous version and we accidentally deleted it in this
[09:02:41] <scribe> one. Very sorry. Please accept my apologies. NEW SPEAKER:
[09:02:44] <scribe> Bad Rohan. NEW SPEAKER: Okay. So now on the screen
[09:02:47] <scribe> is the option one, versus option two decision we now need to
[09:02:51] <scribe> make. So Cullen, is there anything you want to re write on
[09:02:54] <scribe> this slide before we, or is there anything else anybody else
[09:02:56] <scribe> wants to re write on this slide before we call it? NEW SPEAKER:
[09:03:05] <scribe> I'm fine with this slide. If somebody thinks it's an unfair
[09:03:08] <scribe> representation of the issue -- NEW SPEAKER: Can we
[09:03:11] <scribe> just, there will be absolutely an option one, means there will
[09:03:14] <scribe> be no C R L F keep a live in TCP, is that what -- NEW SPEAKER:
[09:03:20] <scribe> Right. Okay. So the '07 draft used stun inside of TCP and
[09:03:25] <scribe> the O A draft uses C R L F. That's what the two
[09:03:28] <scribe> drafts are. Vote for the old version or new version. NEW SPEAKER:
[09:03:31] <scribe> We're going to discuss probing later, right? NEW SPEAKER:
[09:03:35] <scribe> Yes. NEW SPEAKER: Obviously, once we've selected the
[09:03:38] <scribe> solution we can always improve it. But basically, this is
[09:03:41] <scribe> the, we want the definite directions forward on which way this
[09:03:45] <scribe> goes. NEW SPEAKER: Call it. NEW SPEAKER:
[09:03:48] <scribe> Wait. NEW SPEAKER: Spencer wishes to address this. Before
[09:03:56] <scribe> I make the call. NEW SPEAKER: So, I thought, Spencer.
[09:04:01] <scribe> I thought Cullen said that you were getting push back from
[09:04:06] <scribe> wireless vendors to do TCP keep a live? Did I misunderstand. NEW SPEAKER:
[09:04:10] <scribe> Some of them want to use that because it's a better way for
[09:04:13] <scribe> them to control their battery life. NEW SPEAKER: I understand.
[09:04:17] <scribe> The question is, that's not either one of these choices, is it? NEW SPEAKER:
[09:04:22] <scribe> Okay. Both drafts allow a TCP keep a live fall back. NEW SPEAKER:
[09:04:23] <scribe> Okay. (Several people talking.) NEW SPEAKER: Okay.
[09:04:25] <scribe> That's off the table. Thank you.
[09:04:28] <scribe> NEW SPEAKER: Thanks for clarifying. Yes. NEW SPEAKER:
[09:04:33] <scribe> But some wireless vendors are pushing for a C R L F keep a live
[09:04:37] <scribe> because it has the same battery properties as TCP keep a live
[09:04:44] <scribe> and works with their operating system. Just making sure you understand.
[09:04:47] <scribe> So there have been two options presented. Option one, which
[09:04:57] <scribe> is to use the stun over TCP. Option two, which is to use C
[09:05:02] <scribe> R L F over TCP. All those in favor of option one, please
[09:05:03] <scribe> hum.
[09:05:06] <scribe> ( Humming. ) NEW SPEAKER: All those in favor of
[09:05:08] <scribe> option two, please hum.
[09:05:14] <scribe> ( Humming. ) NEW SPEAKER: I think that was pretty clear,
[09:05:17] <scribe> from my opinion, that people selected Rohan's option, would be my
[09:05:20] <scribe> call from up here. NEW SPEAKER: Well, it was, three
[09:05:23] <scribe> to two in favor of option two. NEW SPEAKER: We just
[09:05:26] <scribe> agreed it was a majority, not a consensus things. NEW SPEAKER:
[09:05:30] <scribe> There was a majority and loudness in favor of option two. NEW SPEAKER: Can
[09:05:34] <scribe> you ask another question, Jason fishl. What people that
[09:05:38] <scribe> voted for the first one, don't care. Or -- or you know,
[09:05:41] <scribe> who is okay with the second option. NEW SPEAKER: We've
[09:05:43] <scribe> already asked that. NEW SPEAKER: State did question awk NEW SPEAKER:
[09:05:47] <scribe> I think all of us that voted for the first option, are fine
[09:05:50] <scribe> with the second option. NEW SPEAKER: I'm not going to kill
[09:05:53] <scribe> myself because we picked the wrong option.
[09:05:53] --- alexis has left
[09:05:54] <scribe> (Several people talking.) NEW SPEAKER: Really, I'm
[09:05:58] <scribe> perfectly fine with the decision we just made. Is there
[09:06:01] <scribe> anyone that has a serious problem. NEW SPEAKER: Anyone
[09:06:06] <scribe> who picks option one, still sending to the mailing list
[09:06:09] <scribe> with option one. That's the question. NEW SPEAKER: I think, should
[09:06:11] <scribe> we call that. Two-thirds the, one-third. People in the
[09:06:13] <scribe> room. NEW SPEAKER: Yes. NEW SPEAKER: You said
[09:06:21] <scribe> very rough consensus. NEW SPEAKER: The question is,
[09:06:24] <scribe> do we declare this a consensus, I guess, that's what we
[09:06:27] <scribe> need to know. NEW SPEAKER: John wishes to address. NEW SPEAKER:
[09:06:27] <scribe> Yes.
[09:06:37] <scribe> NEW SPEAKER: Seriously. NEW SPEAKER: Our A Ds seem
[09:06:41] <scribe> to believe we have the least rough consensus in favor of option two.
[09:06:46] <scribe> And they out range me, so let's go with that. raink me.
[09:06:50] <scribe> NEW SPEAKER: I'm not an A D. With respect to this decision. NEW SPEAKER:
[09:06:53] <scribe> I wrote down John. Okay. NEW SPEAKER: Thank you. NEW SPEAKER:
[09:06:59] <scribe> We need to get through the rest of this very quickly. NEW SPEAKER: How
[09:07:02] <scribe> much time do I have here. NEW SPEAKER: Negative 7
[09:07:08] <scribe> minutes. NEW SPEAKER: Three minutes. NEW SPEAKER:
[09:07:12] <scribe> Okay. So, another topic that came up on the, and this
[09:07:16] <scribe> was primarily, came from Francois to a certain degree, was
[09:07:20] <scribe> to, there are times when the server wants to see
[09:07:24] <scribe> these keep a lives fairly frequently, because it's using
[09:07:28] <scribe> them to track when a client disappears. Okay. And
[09:07:30] <scribe> mostly, the clients want to track, the whole scheme was
[09:07:34] <scribe> designed tow clients can know when the keep a
[09:07:37] <scribe> lives die so if they're interested in that so they can re
[09:07:43] <scribe> register. So what they want to do, so that was the
[09:07:44] <scribe> original design.
[09:07:48] <scribe> There's a new requirement floating around that
[09:07:51] <scribe> hey, some servers track these keep a lives as they go
[09:07:54] <scribe> away. And we're putting a fair amount, we were sort of doing
[09:07:57] <scribe> a bunch of jumping around in the text to allow the
[09:08:01] <scribe> clients to have some control. We were putting in wig gel
[09:08:07] <scribe> room for clients with batteries by doing keep a
[09:08:11] <scribe> lives infrequently. You'd enable that by saying the keep a
[09:08:15] <scribe> lives were allowed, is the way it's in the draft now. The
[09:08:16] <scribe> text is weird and complicated.
[09:08:20] <scribe> Rohan suggested a cleaner way of writing this all down, which I
[09:08:24] <scribe> basically like. Which is to add this new keep a live timer
[09:08:28] <scribe> parameter, that basically says, if your URI is
[09:08:34] <scribe> configured with this it means you need to do keep a live
[09:08:40] <scribe> often, you can do it however you want on your battery
[09:08:41] <scribe> life management.
[09:08:46] <scribe> So, that's basically the proposal. It's to support this
[09:08:49] <scribe> feature of servers understanding what's going on. The
[09:08:53] <scribe> question I'd like to ask the group here, is, do we want to
[09:08:56] <scribe> add this or not? I don't think it's that much text change.
[09:09:00] <scribe> I mean, you know, Rohan, are you and I committed to have
[09:09:02] <scribe> this within two weeks, are you okay. NEW SPEAKER:
[09:09:04] --- ttfr has left
[09:09:06] <scribe> Rohan is giving a thumbs up on on that. Assuming I'm not
[09:09:08] <scribe> tossed off as editor.
[09:09:10] <scribe> Okay.
[09:09:15] <scribe> NEW SPEAKER: Kristen. I would support such a parameter.
[09:09:20] <scribe> And I think this is should also be one of the things which the edge
[09:09:24] <scribe> proxy can insert for example, because this can be something
[09:09:28] <scribe> which is depending on an effort or flow or whatever.
[09:09:32] <scribe> Something you can't have in a static
[09:09:33] <scribe> (Several people talking.) NEW SPEAKER: So this tag
[09:09:38] <scribe> could occur and that's the way we managed it, if it showed up
[09:09:40] <scribe> in the path header, anywhere the other tags happen. NEW SPEAKER:
[09:09:43] <scribe> Exactly. NEW SPEAKER: And fen if the U A does have
[09:09:47] <scribe> this parameter and you know, sends it in the
[09:09:49] <scribe> register, that the edge proxy can update the response. I
[09:09:52] <scribe> mean, similar to the registration expires parameter. Thank you. NEW SPEAKER:
[09:09:57] <scribe> So is there anybody who would not support adding this? There's
[09:10:00] <scribe> many I am profit ments taken to the list. Basically, yes
[09:10:04] <scribe> or no. NEW SPEAKER: It's a yes. NEW SPEAKER: It's
[09:10:09] <scribe> a yes. NEW SPEAKER: Next slide, please. Okay.
[09:10:12] <scribe> This draft, when you look at it, has grown through the usual
[09:10:16] <scribe> thing of trying to make everybody happy so it has all
[09:10:19] <scribe> kinds of whacky things in it at this point, sort of more
[09:10:23] <scribe> complicated. I notice many of our drafts have improved by having
[09:10:28] <scribe> a diet and cutting out stuff that added complex Dee that was not all that
[09:10:31] <scribe> important. I have no opinion on any one of these whether we
[09:10:34] <scribe> want to do them or not, other than I want a decision coming
[09:10:38] <scribe> out of here, a decision we don't make the draft will stay the
[09:10:40] <scribe> same as it is and publish it as soon as possible.
[09:10:44] <scribe> Right now, we -- I'm going to step through these one by one
[09:10:47] <scribe> and I'm interested in vague temperature of whether I should
[09:10:50] <scribe> pursue removing these things from the draft or not.
[09:10:55] <scribe> Right now, we support, there's talks about different types
[09:11:02] <scribe> of Mac instance I Ds and U U I Ds, basically the Mac are a
[09:11:08] <scribe> subset. The U. I D it was not an RFC, it was a draft.
[09:11:12] <scribe> And we were sure it would be published long before the U U I D
[09:11:16] <scribe> stuff was. And it of course is already an RFC at this point.
[09:11:20] <scribe> So the original argument is all gone. Do we want to just
[09:11:24] <scribe> use the U U I D. NEW SPEAKER: I think this question NEW SPEAKER:
[09:11:29] <scribe> We want the NEW SPEAKER: This is a question. Can you
[09:11:35] <scribe> generate a U U I did on other unique I'd if fires. For
[09:11:40] <scribe> phones that have Mac addresses, could that be used to
[09:11:42] <scribe> generate it? NEW SPEAKER: I can certainly check that.
[09:11:47] <scribe> I understand we want to be able to support M C. NEW SPEAKER:
[09:11:51] <scribe> As long as it can be generated, I think that's the key
[09:11:54] <scribe> thing. NEW SPEAKER: Yes. NEW SPEAKER: If it can be
[09:11:58] <scribe> generated off any other unique identifier. NEW SPEAKER:
[09:12:01] <scribe> NEW SPEAKER: It covers both of which we
[09:12:04] <scribe> know we need. It covers both of those. NEW SPEAKER:
[09:12:10] <scribe> So, are you proposing that U U I D is only thing you can use?
[09:12:15] <scribe> Because I think many something with you used for U U I D.
[09:12:18] <scribe> Sorry for instance header. NEW SPEAKER: That's the
[09:12:19] <scribe> proposal?
[09:12:23] <scribe> NEW SPEAKER: Yes. But I think that there's usage that you
[09:12:27] <scribe> can use other URLs for this. NEW SPEAKER: sos
[09:12:33] <scribe> what's the reason? I mean, to simply this? I certainly have
[09:12:38] <scribe> proposals where I think the instance I D could
[09:12:42] <scribe> use U RN for other devices. A U
[09:12:49] <scribe> NEW SPEAKER: U U I D is reasonably complicated to generate. (Several people
[09:12:53] <scribe> talking.) NEW SPEAKER: Which is the one I guarantee would
[09:12:56] <scribe> support it. That's the only other one that has come up. Do you
[09:12:59] <scribe> have some other use cases? Otherwise I'll just dash NEW SPEAKER: I have a
[09:13:02] <scribe> question. NEW SPEAKER: The M.D. Is actually a
[09:13:06] <scribe> possibility. But I think the I I is a better one, whereas the M.D.
[09:13:09] <scribe> Is a device, NEW SPEAKER: Yes. NEW SPEAKER:
[09:13:10] <scribe> The subscription
[09:13:13] <scribe> NEW SPEAKER: Identifiers on three GP P NEW SPEAKER:
[09:13:17] <scribe> So at least I would welcome this change. I don't see the
[09:13:22] <scribe> reasons. To make that change. NEW SPEAKER: I'll
[09:13:22] --- ttfr has joined
[09:13:27] <scribe> have to submit a two test question, two question test.
[09:13:32] <scribe> Namely, which of these items, if we decide to drop them, I'm always for
[09:13:37] <scribe> dropping things, cannot be added later, if it is somebody
[09:13:42] <scribe> truly creating a demand and going through the pain of doing it.
[09:13:45] <scribe> Which seems like the right trade off. Which of these, and I don't
[09:13:51] <scribe> know, just simply say one side needs to know what to do, or
[09:13:57] <scribe> is it everybody suffers for pain? It's a pain if you want it
[09:13:58] <scribe> but nobody else is botherd by it. That seems
[09:14:04] <scribe> much less harmless as opposed to causing pain and complexity
[09:14:06] <scribe> and everybody else. I don't understand these items well
[09:14:10] <scribe> enough to know which of these categories they fall into. NEW SPEAKER:
[09:14:16] <scribe> Well, I'll take a shot at answering. I believe all of these
[09:14:19] <scribe> could be added later if you didn't like them to start with. I
[09:14:22] <scribe> believe this one is pain on both sides. I believe the flow
[09:14:27] <scribe> tokens is only pain on your side. Flow token algorithms.
[09:14:31] <scribe> NEW SPEAKER: Option probing can be done. NEW SPEAKER:
[09:14:34] <scribe> The option probing can be done after. NEW SPEAKER: Too
[09:14:37] <scribe> late. NEW SPEAKER: No, no. It would say you just
[09:14:40] <scribe> didn't do the connection. The option probing is a way to get
[09:14:45] <scribe> a connection when you -- can we'll talk about option probing in
[09:14:49] <scribe> a second. And the flow fail hundred and 20 second thing
[09:14:53] <scribe> couldn't be done later it's only pain to client side. One
[09:14:57] <scribe> side. NEW SPEAKER: Question on the U U I D again.
[09:15:03] <scribe> When using other identifier besides Mac address can you extract back out that
[09:15:07] <scribe> identifier, even though it was represented as U U I D. NEW SPEAKER: No. NEW SPEAKER:
[09:15:10] <scribe> That's going to be a problem. Because I know a lot of
[09:15:14] <scribe> people with sell phones that use some kind of NEW SPEAKER:
[09:15:16] <scribe> So dash NEW SPEAKER:
[09:15:18] <scribe> (Several people talking.) NEW SPEAKER: Serves a bun of of
[09:15:23] <scribe> puvrps, only one of which is a unique token tore outboun.
[09:15:25] <scribe> Many people use it that way. NEW SPEAKER: I think I've
[09:15:28] <scribe> got enough feedback on this one to know that, the discussion
[09:15:31] <scribe> is going to be long, therefore, can it. I'm going to
[09:15:33] <scribe> leave it like it is in the draft. Is everybody cool with that.
[09:15:34] <scribe> Okay.
[09:15:38] <scribe> One algorithm for flow tokens. We've got two
[09:15:41] <scribe> algorithms. One requires you to do a bit of crypto. One
[09:15:46] <scribe> doesn't require you to do any crypto. But only works with
[09:15:49] <scribe> SIPs. Want them or not. NEW SPEAKER: I have a
[09:15:52] <scribe> question, Rohan, I have a question for the group. Is anyone
[09:15:59] <scribe> using the other algorithm right now? Anyone at all?
[09:16:02] <scribe> NEW SPEAKER: If you are, you have an unsecure system and I
[09:16:04] <scribe> can high Jack your calls, so I hope you're not. NEW SPEAKER:
[09:16:09] <scribe> I think that should answer our question.
[09:16:13] <scribe> NEW SPEAKER: Okay. These are, both these algorithms are
[09:16:17] <scribe> both non normative anyway. So we can add them later if we need
[09:16:20] <scribe> them. NEW SPEAKER: Can you clarify why it only works
[09:16:22] <scribe> with SIPs, I don't think I understand this. NEW SPEAKER:
[09:16:25] <scribe> Security. NEW SPEAKER: It's predictable. NEW SPEAKER:
[09:16:29] <scribe> Because it dash NEW SPEAKER: One less generator. NEW SPEAKER:
[09:16:33] <scribe> No. I tried to do that in the draft and I failed and I'm
[09:16:37] <scribe> going to fail even more miserably in the room here. We can
[09:16:40] <scribe> walk through it. It takes 5 minutes basically. If you can see somebody
[09:16:45] <scribe> else's at some point in time, you can use it to high Jack their
[09:16:48] <scribe> calls, as long as you have an account account on the same
[09:16:52] <scribe> system, but not their account. NEW SPEAKER: So it's
[09:16:56] <scribe> SIPs issue as opposed to TLS. NEW SPEAKER: It's an
[09:17:00] <scribe> issue that every single hop has to be non visible on the
[09:17:05] <scribe> registration. Or else if you observe any of the reg straix
[09:17:07] <scribe> anywhere, you can registration, you can get away with
[09:17:10] <scribe> hijacking the calls. NEW SPEAKER: The document actually
[09:17:11] <scribe> says that?
[09:17:14] <scribe> NEW SPEAKER: It definitely says you have to use SIP, so this
[09:17:17] <scribe> is insecure. The document says that. The explanation of
[09:17:21] <scribe> why that's true is clearly lacking. You're asking that
[09:17:24] <scribe> question, so it's lacking. NEW SPEAKER: Maybe I'll
[09:17:27] <scribe> look at it. Because I'm not sure it's necessarily a good
[09:17:30] <scribe> idea to say you have to use SIPs for that. NEW SPEAKER:
[09:17:34] <scribe> That's what I don't want to do. I would prefer, the
[09:17:37] <scribe> algorithm that everybody uses is the one that doesn't require SIPs.
[09:17:41] <scribe> So we can't have a an algorithm that requires SIP. NEW SPEAKER:
[09:17:47] <scribe> The difference is like crypto, the secure ones -- NEW SPEAKER:
[09:17:51] <scribe> dpour bytes or something. NEW SPEAKER: Yes. Four
[09:17:54] <scribe> bytes. NEW SPEAKER: No one more crypt particular than
[09:17:58] <scribe> me, let's say get run R rid. One that requires
[09:18:00] <scribe> SIPs. NEW SPEAKER: Okay. So I think, anybody want
[09:18:03] <scribe> to stand up to argue against that? Otherwise I'm going to do
[09:18:05] <scribe> it. Okay. NEW SPEAKER: Sorry, what was the
[09:18:08] <scribe> consensus then? NEW SPEAKER: One algorithm. NEW SPEAKER:
[09:18:14] <scribe> One algorithm. Okay. NEW SPEAKER: I want to talk
[09:18:18] <scribe> about this option probing here for a second. It lists two
[09:18:25] <scribe> points on the slide. It's one point. Right now, if you get a
[09:18:29] <scribe> -- okay. You get a URI that says, you know, this proxy
[09:18:33] <scribe> that you're about to connect to supports C R L
[09:18:36] <scribe> F. And so, you know, you go off and do it.
[09:18:42] <scribe> And if you find out that it doesn't do it, then you're sending
[09:18:45] <scribe> the stuff that's not wanted to a proxy that doesn't support it. And this
[09:18:47] <scribe> is a configuration error.
[09:18:52] <scribe> Now, I as an individual argued on the list that hey, you know
[09:18:57] <scribe> if you configure your SIP client to send SIP messages to the I
[09:19:02] <scribe> map server, it has to cope, right. We don't have to com Plaintiff's
[09:19:07] <scribe> to check it. If we can figure
[09:19:09] <scribe> out to send protocol up there. It doesn't.
[09:19:13] <scribe> That's some people's view on it. Other people think this is
[09:19:19] <scribe> crappy to sending junk to things that shouldn't going in a misconfiguration
[09:19:22] <scribe> error. That happens all the time. And what we want to do,
[09:19:26] <scribe> if you don't get a response back for the appropriate keep a live
[09:19:31] <scribe> thing, then you stop doing it and you optionally send an
[09:19:34] <scribe> options message up to the device that you're interested in and see
[09:19:38] <scribe> if it sends you back a supported header, in which
[09:19:40] <scribe> case you go xwak to just doing it.
[09:19:43] <scribe> And this stuff, it's clean and it does, you know, it
[09:19:47] <scribe> adds the stuff but it adds a couple more timers and a fair
[09:19:51] <scribe> amount of more complexity to the draft. In looking at things we can
[09:19:54] <scribe> possibly chop out, this is one of them. I note before there
[09:19:58] <scribe> was consensus to put this in. It didn't get in there random
[09:20:04] <scribe> plea. NEW SPEAKER: Caplan. So, I'm not going to
[09:20:09] <scribe> cut the draft. But I thought we weren't going to send stun
[09:20:11] <scribe> first, and then if there was no response, then send
[09:20:13] <scribe> options. I thought we were going to send some SIP message
[09:20:17] <scribe> first, whether options or registration itself. No reason
[09:20:20] <scribe> why just, you know, something in the registration. But that
[09:20:23] <scribe> tells you the response, the 200 okay or '07 or
[09:20:25] <scribe> whatever, for the registration.
[09:20:31] <scribe> Regardless, I don't know why we didn't do SIP to detect
[09:20:35] <scribe> whether it could do stun, which to me means there are no
[09:20:38] <scribe> extra timers. NEW SPEAKER: Let me answer that. NEW SPEAKER:
[09:20:42] <scribe> So the reason this argument went on, it's happened at least
[09:20:44] <scribe> three times. (Several people talking.) NEW SPEAKER:
[09:20:48] <scribe> With what happens if you have an edge proxy and the edge proxy
[09:20:50] <scribe> supports it but your registrar doesn't which
[09:20:54] <scribe> lots of people feel is a common configuration, when you send
[09:20:57] <scribe> the register as the first message. The 200 will (Several people
[09:20:57] <scribe> talking.)
[09:21:00] <scribe> NEW SPEAKER: Even though the edge proxy wants you to
[09:21:03] <scribe> do it. If you do the whole three G thing, you can in (Several people
[09:21:06] <scribe> talking.)
[09:21:09] <scribe> NEW SPEAKER: There is another option. Then what it all
[09:21:13] <scribe> migrates to, what you have to do before you send the register
[09:21:16] <scribe> message, you send an option, which will be challenged, and
[09:21:20] <scribe> then you send another option which is not
[09:21:23] <scribe> challenged and then you register. Peel thought it's not a
[09:21:27] <scribe> big deal. So your client has to do twice as many messages to start
[09:21:30] <scribe> out. That's not a big deal for the client. Who it is a
[09:21:33] <scribe> big deal for when the whole city powers up at the same
[09:21:38] <scribe> time and you have 20 million cable modems that all go
[09:21:41] <scribe> live. NEW SPEAKER: So, yes. We know that very
[09:21:44] <scribe> well. NEW SPEAKER: I'm sure you do, better than
[09:21:46] <scribe> anyone. NEW SPEAKER: But that's not the proposal that we
[09:21:50] <scribe> talked about. And I apologize with not keeping up with the
[09:21:53] <scribe> list. It seems to me we're circling around. NEW SPEAKER: It
[09:21:56] <scribe> was, yes. NEW SPEAKER: So the proposal was that we
[09:22:01] <scribe> could stick in, the UAC generate a require or supported header
[09:22:04] <scribe> when it first sends out the register and the proxy
[09:22:09] <scribe> would remove it. That, whatever parameter we decide it would
[09:22:13] <scribe> be, remove that parameter thing so that in fact when reg star
[09:22:16] <scribe> responded back it would be missing in the response. The same
[09:22:19] <scribe> type of thing that we do dpor one of the other RFCs, I
[09:22:24] <scribe> can't remember. Either second maybe privacy. NEW SPEAKER:
[09:22:28] <scribe> Secondary. NEW SPEAKER: It was one of the (Several people talking.) NEW SPEAKER:
[09:22:29] <scribe> Compression one. NEW SPEAKER: Exactly. NEW SPEAKER:
[09:22:33] <scribe> (Several people talking.) NEW SPEAKER: Exactly. So we have
[09:22:36] <scribe> precedence. NEW SPEAKER: That's how draft three was,
[09:22:39] <scribe> but that got killed. NEW SPEAKER: But again, my poyntd is, there
[09:22:43] <scribe> was no options stormd to be generated, it was
[09:22:46] <scribe> just inherited in the generation and the storm already
[09:22:50] <scribe> exists for that. Since we keep coming back to the same thing
[09:22:53] <scribe> again and again -- one other poyment. You cannot add this
[09:22:57] <scribe> thing in late, right? The whole idea of that was to do that text
[09:23:01] <scribe> first, in case the server you're talking to doesn't handle it
[09:23:05] <scribe> well. You can't have, say later, we found servers that
[09:23:09] <scribe> don't handle this well, because you've already deployed. So
[09:23:12] <scribe> don't generate the text. So it can't be NEW SPEAKER:
[09:23:14] <scribe> You and I are talking about (Several people talking.) NEW SPEAKER:
[09:23:18] <scribe> So do it now or don't. Having said you will all that I just
[09:23:21] <scribe> want this thing to be done. I think I'm one of the few
[09:23:25] <scribe> people who really thought dwas bad idea to send something to you
[09:23:31] <scribe> know, port 50 60 or 50 six one that's fundamentally different
[09:23:35] <scribe> encoding seem. It's bin re code, right. It's not as
[09:23:43] <scribe> key. Right ASCII. I'm cool with saying, forget that whole
[09:23:46] <scribe> thing, assume that configuration is correct. Be black
[09:23:51] <scribe> listed if the guy isn't supporting that header. Kristen is
[09:23:55] <scribe> probably going to say no. I think we need to move on. (Several people
[09:23:55] <scribe> talking.)
[09:23:59] <scribe> NEW SPEAKER: Everybody else at the mic, tell me leave the
[09:24:00] <scribe> document as it is. NEW SPEAKER:
[09:24:01] <scribe> (Several people talking.)
[09:24:08] <scribe> NEW SPEAKER: Kristen. I agree with that. I'm confused
[09:24:10] <scribe> as to one of the things you said. Because did first thing I was
[09:24:16] <scribe> going to say there, this is sold solved by
[09:24:18] <scribe> inserting this, it will inform the UAC
[09:24:21] <scribe> NEW SPEAKER: You're arguing to just leave the draft like it
[09:24:23] <scribe> is, right? NEW SPEAKER: Yes, with this addition. NEW SPEAKER:
[09:24:26] <scribe> Okay. NEW SPEAKER: What I'm confused about, is you
[09:24:31] <scribe> said this will only work for three G, as far as I understand, this part
[09:24:35] <scribe> is mandated by, I mean, in order to do outbound you must do
[09:24:37] <scribe> path. NEW SPEAKER: No. You can no. NEW SPEAKER:
[09:24:39] <scribe> The client must, not the proxy. NEW SPEAKER: (Several people
[09:24:46] <scribe> talking.) NEW SPEAKER: I shupt have said three G. That
[09:24:49] <scribe> was incorrect. It's just, we don't mandate that the
[09:24:53] <scribe> proxies do path headers. We just say approximately have to I
[09:24:56] <scribe> think you're voting for leave the document like it is. I suspect
[09:25:00] <scribe> the rest of the people at the mic are going inform say the same
[09:25:04] <scribe> thing. NEW SPEAKER: You have this case where the edge
[09:25:09] --- Alan Hawrylyshen has left
[09:25:11] <scribe> proxies register, but I do mandate the part, because it's home
[09:25:15] <scribe> proxy register port supports outbound. It's
[09:25:20] <scribe> only to indicate forward towards the registrar or home proxy. Thank you. NEW SPEAKER:
[09:25:26] <scribe> Let's wrap this up. NEW SPEAKER: I'm just a little bit
[09:25:29] <scribe> confused when you said the right thing. You send a stun
[09:25:33] <scribe> request and it doesn't happen at all, what exactly is that. NEW SPEAKER:
[09:25:34] <scribe> (Several people talking.)
[09:25:38] <scribe> NEW SPEAKER: Your host. If it for instance, if it just
[09:25:41] <scribe> can doesn't support it. It ignores it, I'm sure they have
[09:25:45] <scribe> some sort of nat traversal. Which means probably, the
[09:25:48] <scribe> expression is going to be set to 30 seconds. You're going to be keeping
[09:25:50] <scribe> up. NEW SPEAKER: Right. NEW SPEAKER: I'm not
[09:25:54] <scribe> seeing like a real deployment where this is going to be a problem.
[09:25:58] <scribe> I see it as a problem. It crashes. You know, it crashes. NEW SPEAKER:
[09:26:02] <scribe> Anybody who builds device owes the public internet,
[09:26:09] <scribe> when they receive a random bin re message mess binary.
[09:26:12] <scribe> Message that crashes. NEW SPEAKER: If it doesn't
[09:26:17] <scribe> crash, it ignores it. So there's got to be another
[09:26:20] <scribe> strategy for doing that. The options wonlt help you there
[09:26:23] <scribe> either. NEW SPEAKER: Yes.
[09:26:27] <scribe> NEW SPEAKER: Rohan may, so I think it was Dean who, I'm
[09:26:29] <scribe> trying to remember who asked for this. NEW SPEAKER:
[09:26:32] <scribe> Dean. NEW SPEAKER: Okay. NEW SPEAKER: I give
[09:26:35] <scribe> up. NEW SPEAKER: Is okay. NEW SPEAKER: I really
[09:26:38] <scribe> don't care. It's not a whole, it's like maybe two
[09:26:42] <scribe> paragraphs in the spec. It's not particularly difficult to implement.
[09:26:46] <scribe> I think it's even should. But you know, I'm fine with
[09:26:50] <scribe> deleting it.
[09:26:53] <scribe> NEW SPEAKER: Caplan again. Two things, one is, if we
[09:26:57] <scribe> decide it's not a must, I think it shouldn't be in there at
[09:27:01] <scribe> all. I don't want to have more optional things. It's too com
[09:27:06] <scribe> complicated. NEW SPEAKER: It's should. NEW SPEAKER:
[09:27:10] <scribe> The problem is not that the server is going to crash.
[09:27:14] <scribe> Anyway. The problem is, and I'll tell you the problem. Very
[09:27:19] <scribe> simple. The problem is that server may black list the phone.
[09:27:22] <scribe> And fundamentally, I think that's the right thing to do,
[09:27:25] <scribe> because it's something illegal. NEW SPEAKER: That's
[09:27:28] <scribe> misconfigured. NEW SPEAKER: So,
[09:27:29] <scribe> call for (Several people talking.) NEW SPEAKER:
[09:27:32] <scribe> Insanely hard to troubleshoot. Because you re boot the
[09:27:35] <scribe> phone and it successfully registers and you can even make a call
[09:27:39] <scribe> for a few seconds, all of a sudden it's dead. And then you re
[09:27:42] <scribe> boot it again. And it seems like a very fundamental
[09:27:46] <scribe> different problem than getting black listed because your phone is
[09:27:51] <scribe> sending some xwiz sar keep alive thing bizarre keep a leave.
[09:27:54] <scribe> And that's the where the things gets hot. Right. It's not
[09:27:58] <scribe> about crashes or whatever. But that was it. Okay. NEW SPEAKER:
[09:28:07] <scribe> Okay. The text at a should level I agree is useless, so
[09:28:09] <scribe> we either have the option of moving to must level or deleting
[09:28:10] <scribe> it.
[09:28:17] <scribe> So those in favor of moving that text to a must level, please
[09:28:19] <scribe> hum.
[09:28:21] <scribe> ( Silence. ) NEW SPEAKER: Those in favor of deleting
[09:28:22] <scribe> it, please hum.
[09:28:28] <scribe> ( Humming. ) NEW SPEAKER: The deletes have it.
[09:28:31] <scribe> NEW SPEAKER: All right. Last one. I hope this is
[09:28:33] <scribe> easier than the last one.
[09:28:40] <scribe> So the, imagine you had a proxy registrar system -- Rohan, do
[09:28:42] <scribe> you want to describe this? NEW SPEAKER: No. I
[09:28:46] <scribe> actually wanted to clarify for the notes so that I know what to
[09:28:50] <scribe> do, there are actually two places where options is mentioned.
[09:28:56] <scribe> One is the should send statement, about validating stun
[09:28:59] <scribe> support, and the other is where it says that you may send an
[09:29:03] <scribe> options. So, I'm assuming that we deleted, you know, the
[09:29:07] <scribe> should send an options, to verify support for stun. NEW SPEAKER:
[09:29:10] <scribe> The may accepteds an options is always true.
[09:29:14] <scribe> We can put that or remove it. NEW SPEAKER: Does anyone
[09:29:17] <scribe> object to removing it at both places? NEW SPEAKER: Thank you. NEW SPEAKER:
[09:29:20] <scribe> Okay.
[09:29:24] <scribe> NEW SPEAKER: So this last one, the deal is, there's
[09:29:27] <scribe> some stuff in there, imagine you have a proxy that's
[09:29:30] <scribe> continually re booting, going up, down,
[09:29:34] <scribe> whatever. What happens right now, is the draft says, you
[09:29:39] <scribe> register. And if your registration, you know, doesn't
[09:29:43] <scribe> work at all, you go through this expo negligence shall back
[09:29:43] --- thomas.stach has left
[09:29:46] <scribe> off of how long it is before you try and register again.
[09:29:52] <scribe> However, if you registration succeeds for more than a hundred and 20 seconds, then
[09:29:56] <scribe> you call it a good registration. And at any time after a
[09:30:00] <scribe> good registration, when you, if something fails, then quh
[09:30:02] <scribe> you re register again, you start, you know, you go back
[09:30:03] --- thomas.stach has joined
[09:30:09] <scribe> to the lowest time, 30 seconds, you try and re register after
[09:30:13] <scribe> 30 seconds and double and double and double. But if you fail
[09:30:20] <scribe> in if first one 20 seconds of the call, you -- let's say you register once
[09:30:24] <scribe> and it failed. 30 seconds, waited 60 seconds and try
[09:30:28] <scribe> again. It worked and then you failed in the first one hundred
[09:30:29] <scribe> 20 seconds of the call.
[09:30:34] <scribe> You woo wait for a doubling again, from your original 60
[09:30:37] <scribe> seconds. So you'd wait a hundred 20 seconds before you tried this
[09:30:43] <scribe> again. So, it adds this extra timer in sort of tracking what
[09:30:49] <scribe> happens in the one hundred 20 seconds and the doubling time.
[09:30:52] <scribe> It just adds one more timer and adds more complexity.
[09:30:57] <scribe> It's probably not that big of a deal for implementing. You
[09:31:00] <scribe> have to track it and combine that into your initial
[09:31:00] <scribe> registration algorithm.
[09:31:06] <scribe> So, it only really matters in the case where a proxy is
[09:31:09] <scribe> working to register and then promptly crashing again and
[09:31:13] <scribe> failing. So this was one of the other ones that we could
[09:31:16] <scribe> remove or leave in. I don't care one way or the other. NEW SPEAKER:
[09:31:20] <scribe> Get to a poll now. NEW SPEAKER: So, do you want to
[09:31:22] <scribe> take a poll on this, chairs? NEW SPEAKER: Those in favor of
[09:31:24] <scribe> keeping, please hum.
[09:31:28] <scribe> ( Humming. ) NEW SPEAKER: I heard
[09:31:32] <scribe> one. NEW SPEAKER: Could I just mention, one of the motivations
[09:31:37] <scribe> for this is not the proxy crashing, but NEW SPEAKER: If
[09:31:39] <scribe> what. NEW SPEAKER: If your nat is continuously re
[09:31:44] <scribe> bootinging it keeps you from hum beling the network. NEW SPEAKER: Thank you.
[09:31:48] <scribe> Those in favor of deleting, please hum.
[09:31:53] <scribe> ( Humming. ) NEW SPEAKER: The room is filled with
[09:31:56] <scribe> apathy. NEW SPEAKER: Could you do the people who want to
[09:31:58] <scribe> keep it again, please. NEW SPEAKER: What? NEW SPEAKER:
[09:32:02] <scribe> Could you do the poll again. NEW SPEAKER: We'll repeat the
[09:32:07] <scribe> poll. Those in favor of keeping the text, as is, please
[09:32:07] <scribe> hum.
[09:32:10] <scribe> ( Humming. ) NEW SPEAKER: Those in favor of deleting
[09:32:12] <scribe> this chunk of text, please hum.
[09:32:14] <scribe> ( Humming. ) NEW SPEAKER: Okay. There's consensus
[09:32:19] <scribe> in favor of deletion. NEW SPEAKER: Thank you very much
[09:32:23] <scribe> for getting through this. We will have a new document soon. NEW SPEAKER:
[09:32:29] <scribe> While we're changing speakers, I wanted to mention I will be
[09:32:32] <scribe> bringing an implementation of this stuff to SIP it that's
[09:32:36] <scribe> coming up next month in April. Registration for that thing,
[09:32:40] <scribe> cuts off next week. So if you want to be there, get
[09:32:44] <scribe> registered, if you got an outbound implementation, I'd
[09:32:47] <scribe> really like to have somebody to test against. NEW SPEAKER:
[09:32:52] <scribe> Is our next speaker this the room? Bob? Outbound fragmentation?
[09:33:02] <scribe> Next speaker after that in the room? That's Henning.
[09:33:05] <scribe> Henning, yes. NEW SPEAKER: While
[09:33:11] <scribe> Henninging is Mikeing up, I'll just say that
[09:33:15] <scribe> outbound is due for working group last call. So I propose
[09:33:18] <scribe> there's working group last call in the next version that it
[09:33:21] <scribe> is, so if you've got pre working group last call items you want
[09:33:24] <scribe> to do, get them on the list. NEW SPEAKER: You have
[09:33:26] <scribe> ten minutes. NEW SPEAKER: Okay. Hopefully this will
[09:33:27] <scribe> be quick.
[09:33:36] <scribe> Next please. The idea is that we have discussed quite awhile.
[09:33:39] <scribe> That it would be quite nice in certain scenarios to
[09:33:44] <scribe> have on a multi cast service discovery for particular local area
[09:33:48] <scribe> networks. Initially, there was some notion that type of
[09:33:51] <scribe> work would migrate to the SIP peer to peer group. It was
[09:33:56] <scribe> explicitly stated in the charter that that was out of scope.
[09:34:01] <scribe> But informal discussion, were hold, that indicated there
[09:34:04] <scribe> was a sufficiently minor change that this could find a possible home
[09:34:09] <scribe> elsewhere. So the idea is that you have a, in a small
[09:34:15] <scribe> environment, local area, the thing which used to be called
[09:34:21] <scribe> GRUU, and would be used to discover URIs on the local
[09:34:24] <scribe> network. Do you want to interject now? NEW SPEAKER:
[09:34:28] --- bhoeneis has left: dnsext@IETF-68@Praha
[09:34:29] <scribe> Yes. I'm just, are you really allowed to send, to have P T
[09:34:30] <scribe> R record in URI?
[09:34:41] <scribe> NEW SPEAKER: As far as I can tell, this is, there is a
[09:34:44] <scribe> question which I don't know and I haven't had a chance to
[09:34:47] <scribe> consult did DNS experts. NEW SPEAKER: I'll go get a
[09:34:52] <scribe> DNS expert right now and I'll be back in 5 or ten minutes. NEW SPEAKER:
[09:34:59] <scribe> We'll be finished if it's ten minutes. NEW SPEAKER:
[09:35:02] <scribe> So, I mean, this is O O draft and there's more questions
[09:35:05] <scribe> than answers at this point. But the idea is there would
[09:35:10] <scribe> be, it's a pre DNS, this is following just standard DNS S D
[09:35:17] <scribe> mechanisms. Module over ASCII even code. Namely, one mechanism which
[09:35:22] <scribe> has a P T R which is used in DNS D, which is not new.
[09:35:26] <scribe> For a look up function, as to which of the service, SIP
[09:35:32] <scribe> URI being the service. Bob and Joe in this case. One of
[09:35:35] <scribe> these entries, you have an S RV record which
[09:35:41] <scribe> points to particular host. And then DNS is the uses text records and this is
[09:35:45] <scribe> again, this is not specific to this particular proposal,
[09:35:47] <scribe> which provides further detail.
[09:35:52] <scribe> In this example, you see our current proposal would contain, namely the
[09:35:53] <scribe> name and the contact.
[09:36:02] <scribe> Next, please. It has been proposed that we should look at the
[09:36:06] <scribe> comparison to the SIP multi cast mechanism. We should note
[09:36:11] <scribe> that the SIP multi cast mechanism in 3261 is register multi cast
[09:36:15] <scribe> only. That has a different properties. In that
[09:36:18] <scribe> basically, allows you to only when you register to do that,
[09:36:23] <scribe> so that if a new U A joins a network, it won't discover those
[09:36:26] <scribe> other nodes until, let's say, an hour later. So that's not
[09:36:30] <scribe> terribly good. And because it's not reliable, means you may
[09:36:33] <scribe> miss what, you may miss a registration in that. So
[09:36:37] <scribe> essentially, you're distributing relocation
[09:36:39] <scribe> database across the U As.
[09:36:46] <scribe> The DNS S D mechanism has a query capability. So you send a
[09:36:51] <scribe> query who has this URI A O R and then you get it back. So that's
[09:36:53] <scribe> a bit more reliable on demand. Next.
[09:36:59] <scribe> The details, there's a service instance domain, encoding, I
[09:37:04] <scribe> won't go into that and there's a contact record. Next, please.
[09:37:09] <scribe> There's a set of behaviors to be specified, and I don't think we
[09:37:13] <scribe> can go through that in a great level of detail, what gets put
[09:37:17] <scribe> in the to header, or it gets stuck in the request URI. This is
[09:37:19] <scribe> roughly as far as the draft goes.
[09:37:25] <scribe> Since then, discussions among people who are irnt d
[09:37:29] <scribe> interested in that, among the authors, there's actually a
[09:37:34] <scribe> slightly big architectural issue, namely how this insects
[09:37:38] <scribe> with 3263. And there's at least three possibilities on where
[09:37:44] <scribe> these two things interweave, because DNS D is assuming that you
[09:37:46] <scribe> get the whole thing all the way to the IP address. You stop
[09:37:50] <scribe> at the service, you browse it, and at the end you end up
[09:37:52] <scribe> with an IP address on your local network somewhere.
[09:37:59] <scribe> And that doesn't quite mesh with the 3263 model. So you have at
[09:38:04] <scribe> least three mechanisms, namely, you essentially use DNS as
[09:38:08] <scribe> only for the text record, to get a contact U R and I then you
[09:38:13] <scribe> stuff that into your 3263 phone. The opposite is you ignore three 2 six
[09:38:15] --- dgtlsoul has left
[09:38:16] <scribe> three, just simply say, this this particular application,
[09:38:19] <scribe> that's an alternate way of getting that key addresses outside
[09:38:25] <scribe> the normal 3263 scope, in terms of nat, S RV and all that.
[09:38:30] <scribe> And you just do it from a D S D record and that's kind of in the
[09:38:35] <scribe> sperd of DNS S D, and the first one is more of a full SIP
[09:38:38] <scribe> spirit. And you can do combinations
[09:38:44] <scribe> and kind of skip a step, and that seems kind of a hack. I'm sure you've got
[09:38:48] <scribe> the answer in 5 minutes flat. NEW SPEAKER: Yes. So,
[09:38:52] <scribe> basically, the two people that I queried that were DNS
[09:38:56] <scribe> ops type folks, they had a strong suspicion ha the answer is no.
[09:39:00] <scribe> The spec says that the right hand side, the answer to P T R
[09:39:05] <scribe> record is a domain name. NEW SPEAKER:
[09:39:08] <scribe> NEW SPEAKER: So, is there anything about this proposal that we
[09:39:12] <scribe> can continue to talk about, given that that's not, that that part
[09:39:14] <scribe> isn't legal? NEW SPEAKER: TCP record. NEW SPEAKER:
[09:39:18] <scribe> I think that will probably go over like a fart in church,
[09:39:24] <scribe> DNS ops. Is tli anything else in here, I mean, NEW SPEAKER: (Several people
[09:39:24] <scribe> talking.)
[09:39:28] <scribe> NEW SPEAKER: Is it feasible to do, if we can't use either
[09:39:31] <scribe> of those two records. NEW SPEAKER: This isn't a coding
[09:39:34] <scribe> issue, clearly. A coding issue you can solve. I don't
[09:39:37] <scribe> see that as a big deal. NEW SPEAKER: There are
[09:39:42] <scribe> semantics defined, like most name servers do, in the
[09:39:47] <scribe> additional records section, they usually go and resolve the thing
[09:39:49] <scribe> on the right hand side (Several people talking.) NEW SPEAKER:
[09:39:53] <scribe> Take a look, and you have a right box in your hand, take a
[09:39:56] <scribe> look what's currently on P T R records being distributed right
[09:40:01] <scribe> now by DNS S D and maybe we can have a discussion off line on
[09:40:05] <scribe> that. I don't think there's NEW SPEAKER: You mean on
[09:40:07] <scribe> multi cast DNS. NEW SPEAKER: Yes. NEW SPEAKER:
[09:40:12] <scribe> Okay. But, I mean, I'm assuming we're not going to go
[09:40:16] <scribe> and specify something here in SIP, that DNS ops would can
[09:40:21] <scribe> clearly say, no, that violates, you know, that is
[09:40:23] <scribe> incompatibe with our --
[09:40:26] <scribe> (Several people talking.)
[09:40:28] <scribe> NEW SPEAKER: Yes. NEW SPEAKER: John. NEW SPEAKER: So
[09:40:32] <scribe> Jonathan. I'm going to sort of play a key for a moment and ask a
[09:40:34] <scribe> procedural question. This is interesting. I don't think anything
[09:40:38] <scribe> really about DNS guide. I don't understand the problem
[09:40:43] <scribe> that's being solved. Typically I thought what we did in the
[09:40:47] <scribe> working group is extensions or bug fixes or maybe something
[09:40:50] <scribe> that got a lot of discussion on the list. What I would have
[09:40:53] <scribe> thought we would have is a SIPPING document first, that
[09:40:56] <scribe> describes the problem that this is potentially solving,
[09:40:58] <scribe> because -- NEW SPEAKER: You're right. NEW SPEAKER:
[09:41:04] <scribe> It seemed to, my guess, yes, I can write a requirement
[09:41:08] <scribe> document and we can go through that. But it is
[09:41:08] --- vkg has joined
[09:41:12] <scribe> essentially, mult Dee cast discovery mechanism and one NEW SPEAKER:
[09:41:14] <scribe> I don't even know for what. (Several people talking.)
[09:41:18] <scribe> NEW SPEAKER: What problem we're solving. I'm not trying to
[09:41:22] <scribe> be malicious. I think it's good to do new work, I just
[09:41:26] <scribe> don't even understand. Is something broken? Is it -- what
[09:41:28] <scribe> is the problem we're solving?
[09:41:31] <scribe> NEW SPEAKER: The problem is, you were part of appear to peer
[09:41:35] <scribe> SIP discussions, is that if you -- and maybe that's the
[09:41:38] <scribe> requirements document. The use cases document for peer to
[09:41:42] <scribe> peer SIP, one of the use cases is the small domain case where you
[09:41:47] <scribe> don't want to set up a D H T or similar type of mechanism,
[09:41:50] <scribe> but you don't want servers either. NEW SPEAKER: So this is almost
[09:41:52] <scribe> an alternative of (Several people talking.) NEW SPEAKER:
[09:41:59] <scribe> During the discussion from the charter, which was exactly the
[09:42:03] <scribe> charter discussion we had was no, we don't want to do that,
[09:42:07] <scribe> because it's a distraction from a D H T based mechanism, but it is
[09:42:10] <scribe> valuable and we can find another home for it because it's small and
[09:42:14] <scribe> doesn't raise any big issues compared to peer to peer SIP stuff. NEW SPEAKER:
[09:42:18] <scribe> Okay. NEW SPEAKER: If I misunderstood that consensus I'm
[09:42:21] <scribe> sorry. I was part of the charter discussion. (Several people
[09:42:21] <scribe> talking.)
[09:42:25] <scribe> NEW SPEAKER: I'm asking, I don't, I don't know what
[09:42:28] <scribe> problem we're solving, NEW SPEAKER: This is not worth
[09:42:34] <scribe> beating to death this room. Let's close the line after
[09:42:36] <scribe> David. NEW SPEAKER: I actually think there are several of
[09:42:44] <scribe> the mechanisms people are proposing are fairly contrary to the
[09:42:49] <scribe> effect. I would be happy to provide an introduction to the N
[09:42:51] <scribe> D MS folks. And I believe that you would find that his view
[09:42:57] <scribe> of what zero was originally trying to solve, is sufficiently
[09:43:00] <scribe> different from this. That the, probably want to have a
[09:43:05] <scribe> fairly long conversation with him before he came to the
[09:43:07] <scribe> conclusion that this is all kinds of wrong.
[09:43:11] <scribe> But I have the suspicion that the end result of this is going to
[09:43:14] <scribe> be, this approach, we're using these records for this, is all
[09:43:18] <scribe> kinds of wrong. If you do need to do something in DNS, it's
[09:43:21] <scribe> sufficiently different from what's therein service discovery
[09:43:27] <scribe> that N DNS was designed to do, that re using it is more pain
[09:43:32] <scribe> and more breakage than it's worth. In particular, because of
[09:43:36] <scribe> the A.Com thing. Where you're going to be asserting an
[09:43:41] <scribe> identity to which you essentially have no way to provide any
[09:43:44] <scribe> assurance you have the rights to, as part of a different
[09:43:46] <scribe> domain. That's going to create things that they tried very,
[09:43:53] <scribe> very hard to avoid. The N DNS world and I think they might kind
[09:43:56] <scribe> of want you not to. NEW SPEAKER: e I will note, but I don't
[09:44:01] <scribe> know who is responsible what I chat does, which I suspect has some
[09:44:06] <scribe> institutional affiliation with N DNS crowd. NEW SPEAKER: I would be very,
[09:44:10] <scribe> very happy to introduce you to the N DNS crowd to make sure that
[09:44:13] <scribe> they dash NEW SPEAKER: This is essentially the same thing.
[09:44:18] <scribe> Again, you have a, you have a browser on your laptop,
[09:44:24] <scribe> just browse what I chat does. NEW SPEAKER: I think
[09:44:27] <scribe> this works is actually very interesting, and basically I have
[09:44:30] <scribe> a couple of comments. First comment is that
[09:44:34] <scribe> I really don't want us to sort of, you know, process is
[09:44:37] <scribe> more important than real work. It is sort of a no brain err.
[09:44:41] <scribe> We should have this. If you're in ad hoc network, you should be
[09:44:47] <scribe> able to, chat using simple. Without DNS servers, this is
[09:44:49] <scribe> what it's for. Basically, discovering the
[09:44:51] <scribe> peers in the ad hoc network.
[09:44:57] <scribe> And yes, so basically, you know, I think it's just silly to
[09:44:59] <scribe> go write requirements drafts. Let's not focus can on the
[09:45:02] <scribe> water fall model. Let's, you know, get some interesting work
[09:45:03] <scribe> done. I'm all for the work.
[09:45:09] <scribe> The other comment was, the comment about ted saying the
[09:45:14] <scribe> asserting the values A.Com. If we have other mechanisms like you
[09:45:21] <scribe> know, stuff done in the R T P sek, where basically you can do
[09:45:24] <scribe> this leap of faith type of thing when you're in the internet,
[09:45:29] <scribe> if you have some keys already, with this, you can verify
[09:45:34] <scribe> they're at A.Com. If you have already done this exchange
[09:45:38] <scribe> somewhere else, not in the ad hoc network, you can use that
[09:45:42] <scribe> search somewhere else. To also verify this the. But it
[09:45:45] <scribe> doesn't necessarily have to be, okay. I'm going too far,
[09:45:47] <scribe> probably. NEW SPEAKER: I'm out of time. NEW SPEAKER:
[09:45:49] --- Jabber-Wile has left: Replaced by new connection
[09:45:54] <scribe> Yes. NEW SPEAKER: You got feedback. Whatever he
[09:45:58] <scribe> says, I think it's clearly useful to find, even if it's in this
[09:46:01] <scribe> document, the problem we're trying to solve. And then try
[09:46:07] <scribe> and work from there to a solution, which I produce would be the
[09:46:10] <scribe> other way around. And you obviously have to go back to the
[09:46:13] <scribe> DNS crowd dash NEW SPEAKER: Obviously means I haven't
[09:46:17] <scribe> followed the DNS server stuff and there was a lot of
[09:46:21] <scribe> controversy in IETF. Somebody who does know about it, s there
[09:46:25] <scribe> has been individual submission on D S S D and
[09:46:28] <scribe> if somebody can tell me what the status of that is, I mean, this is
[09:46:32] <scribe> somewhat dependent on the status of that work. To at least in the
[09:46:36] <scribe> IETF. Maybe somebody here knows more about the status of the
[09:46:53] <scribe> DNS D work within the IETF. NEW SPEAKER: All right.
[09:46:55] <scribe> Clarification of privacy mechanism. Next, please.
[09:47:04] <scribe> We revised the draft based on the feedback we got at the previous
[09:47:13] <scribe> meeting. And now the purpose of the draft is, we define
[09:47:17] <scribe> and qualified the privacy mechanism so that means update or
[09:47:27] <scribe> obsolete RFC three 323. And the draft proposes to define new free
[09:47:28] <scribe> values. Next, please.
[09:47:36] <scribe> So, these are the basic concepts. User's privacy is based
[09:47:41] <scribe> on binary decisions, so privacy on or off. And privacy
[09:47:46] <scribe> functions are security at two points. That means
[09:47:53] <scribe> U A and privacy service. So, privacy proxies are, that U
[09:47:57] <scribe> and P privacy service or privacy service alone is based on the
[09:47:58] <scribe> scenario.
[09:48:05] <scribe> Next, please. These are the use cases for the new priv
[09:48:12] <scribe> values. So privacy on or off. And you A the message by
[09:48:12] <scribe> itself or not.
[09:48:21] <scribe> We are going to ask you here, is the direction of the draft right?
[09:48:27] <scribe> Or not? We got a comment yesterday that new privacy mechanism
[09:48:33] <scribe> should define privacy function executed solely on U A. And
[09:48:37] <scribe> we got another comment this morning that we should separate the
[09:48:44] <scribe> cases where the B to B U A is required, or end, where the B
[09:48:47] <scribe> to B U A is not required.
[09:48:49] <scribe> Next, please.
[09:48:57] <scribe> So, we would like to introduce you to, the two options, one
[09:49:01] <scribe> obsolete or update RFC and re define the privacy header with
[09:49:05] <scribe> new priv values. This is the direction of the current draft.
[09:49:10] <scribe> Option two, separate the draft into two drafts. So one
[09:49:16] <scribe> updating RFC with details on privacy treatment on pre-existing
[09:49:22] <scribe> priv values. And the other defining end point oriented
[09:49:28] <scribe> privacy mechanism that does not use B two B U A, that uses GRUU and
[09:49:33] <scribe> turn. So, I would like to hear people's opinion about
[09:49:39] <scribe> this. NEW SPEAKER: All right. John Peterson. A couple
[09:49:42] <scribe> of things here. First of all, I don't want to get into
[09:49:45] <scribe> another document organization question. So, what I want to
[09:49:47] <scribe> pull away from this slide is the question of whether we need
[09:49:51] <scribe> two mechanisms. One that is a mechanism for the user agent to supply
[09:49:54] <scribe> privacy for itself and another that's a mechanism for
[09:49:57] <scribe> describing how back to back you U As can provide the service
[09:49:59] <scribe> or be encouraged to provide the service.
[09:50:05] <scribe> And I guess my own feeling about this is, my preference, and
[09:50:10] <scribe> I'll fes up, I was probably the one that she was referring to
[09:50:13] <scribe> who said yesterday, there should be away to do this solely in the
[10:42:12] --- LOGGING STARTED
[11:14:53] --- marc.bailly has joined
[11:14:53] --- marc.bailly has left: Lost connection
[11:23:18] --- ttfr has joined
[11:24:52] --- ttfr has left
[19:34:12] --- philip_matthews has joined
[19:34:30] --- philip_matthews has left
[19:40:49] --- philip_matthews has joined
[19:40:56] --- philip_matthews has left