Transcript, SIP Session 1, IETF 67

Transcript recorded during SIP via "simultaneous translation" into a voice recognition program. It does fun things with names.

IETF, SIP session, November 9, 2006, 1 p.m, San Diego.

       NEW SPEAKER: So, good afternoon, everybody. This is the SIP working group. I'm circulating blue sheets. One down this side, one down that side. Please keep them moving. Get to the back of the room, bring them forward and start them over again, or bring them to the front and see if anybody needs to sign.
       A couple of very quick, before we start the meeting, announcements. At the end of the meeting session, there's only a ten minute window before the next meeting occurs in here, so, leave quickly.
       Don't pretend it's on fire, but leave in good order on. Also, I would like to thank the various victims, David Brian will be acting as our jabber scribe, and let's see, we've Jason fish she will and Philip Mathews will be taking some notes, to be sure that we have reasonably representative minutes.

       NEW SPEAKER: Okay. Now displayed is the note well statement, that applies to everything you say in this room, and this is a SIP working group meeting, so, please read it. This is identical to the yellow hand out you have in your envelope when you checked in. There are reference to a couple of RFC numbers there and you're assumed to have read those as well.

       NEW SPEAKER: One more request from our immediate why servicees people, and this is hard for me, so it's probably hard for you guys too. But, they've asked us to use the Mike phones very carefully when making all comments, speak slowly and clearly and distinctly into the microphone. Approximately three inches from the microphone, talking drebtly at it. Don't do like this and turnaround and talk the other direction. Well, turnaround and talk the other direction, because then it won't pick you up chl all right.
       Thank you.

       NEW SPEAKER: Please announce your name when you are speaking. Otherwise you will be interrupted by people saying, say your name. This is also for the benefit of the people listening. Okay. So this is the agenda for the session today.
       Chairs are always exceptions. A agenda for session one. Outbound, domain certs, quekt re use, since guide lines, grew, and then session two, a whole bunch of other documents. Does anybody have the need to play with the agenda?

       NEW SPEAKER: I don't know where anybody doing audio is, are but the folks in jabber on the remote are claiming it's extraordinary qui et audio.

       NEW SPEAKER: Could somebody go to the secretary desk and ask for the audio guy to take a look at that.
       I think his name is Joel. Do we have a volunteer?
       Thank you.

       NEW SPEAKER: Okay. So continuing, do we have any comments on the agenda slides at all?
       NEW SPEAKER: So, there's a little bit of an overlap of the agenda between session one item, in connection re connection re use, and the session two item of outbound discovery and mid dialogue requests.
       So, to the extent that there's overlap of that, even though we're not going to talk about st outbound discovery and mid dialogue until time, any overlap questions need to come up during today's discussion on connect re use, because due to family situation, vee Jay will not be with us on Friday. Got that Jonathan? Thanks.
       NEW SPEAKER: Okay. We did post to the list, a pointer to the status slides. Going to the status slides session directly, there are a couple of issues we need to bring up. Somewhere around certificates. Okay. Certificates is just recently be out to working group last call. We've had very little response to that. So, we just do a quick, do a quick pole in the pol into the room. brav paragraph how many people have read the current version of draft IETF SIP certificates. A fair number. Okay. So, of those people, we will do a quick look, do you think this document is ready to go to IESG as it stands? A, do you think this document is ready to proceed to IESG as it currently stands? And those that don't think it's ready and needs another review. Good. That's reasonable conclusion.
Okay.

       NEW SPEAKER: Note takers, please note that.
       NEW SPEAKER: Basically, the numbers I think, about 20 people, all of which seemed to be in favor of being ready.
       The next one is also consent framework, also on working group last call. More comments received on this one and it's going to be updated, but it was a fairly low level of comments. So again, same questions, how how many people have actually read this document? One. Two,
       NEW SPEAKER: I count 5.
       NEW SPEAKER: Okay. 5.
       NEW SPEAKER: That's not many.
       NEW SPEAKER: I think that means we need more review. Without even asking the other questions.
       Okay.
       NEW SPEAKER: And with regard to the consent framework, raise your hand if you care.
       NEW SPEAKER: What does that mean?
       NEW SPEAKER: If you actually have an interest in this work and have seen it and in seeing it proceed. Please raise your hand. There's like 30 people that care, are so that's significant.
       So, go read it.

       ( Laugh tea laughter.

       NEW SPEAKER: Rohan. Sorry. I should have got you ready to the Mike.

       NEW SPEAKER: Basically what we're looking for at the moment is that we try and get this document ready for working group last call somewhere before Christmas. We have identified a review team, but if anybody feels they ought to be on that review team, please come and give me your names at some point.
       NEW SPEAKER: Hi, I'm Rohan, I'm here again to talk about outbound. Next slide, please.
       So, there were a substantial number of changes that I made to this version of the draft based on the consensus that we had at the last IETF. And some additional useful suggestions on the mailing list that seemed to be uncontroversial.
       To summarize those real quick, we agreed to move stun to a separate section of the document so that it can be separately referenced later by some other document or white paper implementer, S D O, whatever. We added language clarifying that a user agent must not send stun without an explicit indication that the server supports it. And further clarified or added language that U A must stop sending stun if the server does not support stun. Stop stunning me please. Added a SIP stun option tag if you want to probe servers.
       A clarified that you should not put this in a proxy required, because that means that everybody in the path would have do support that, and that's not really particularly realistic situation.
       And explaind that the first hop must support the option tag. Let's see. Clarifiedd that SIP and stun over vair yus combinations of other framing and compression protocols, how that all works. So, for SIP, stun, inside of T L S, this is on the inside of the TLS record layer for stun used with SIP, it's outside the compression layer for U D P. But inside the shim header for something transports. If we leave the current language in here, it produces a new normative reference, on a document which is currently in working group last call. So just as a process note.
       NEW SPEAKER: Which one?
       NEW SPEAKER: Can draft IETF rock SIM something guide '08.
       NEW SPEAKER: And then, let's see, a must to a should, that, about U A C should measure a flow for each member of the out bound proxy set.
       Second page of changes. We had a lot of confusion in the draft and the draft was sloply written. Mea culpa, about the difference between a a proxy and registrar. And this was very unclear. So I used the term, introduced a term, authoritative proxy, to describe the proxy that is authoritative important the post part of the URI.
       And I separated the registrar activity from the section about what the authoritative proxy does. So, as a result, I think the language is much more crisp and easy to understand from an implementation perspective. Listen restrictions on storing a complete path vector, that to the reg star or authoritative proxy.
       So, basically, the way that, the way the draft is worded right now, if you go, each, any hop that is not route able, needs to go and put in a flow token. I have an open issue on this later which we'll discuss in a couple of slides.
       Let's see. And I think the rest of these are pretty reasonable, there was text here also about the OB parameter. I described this as a potential solution in a couple of slides. At the last meeting and they were, you know, available in the proceedings. But real briefly, there's, the first hop, is expected to add this OB parameter to a path, to the path header.
       And then, the registrar verifies that the OB parameter is present, and only if it's present, only if the first hop had this parameter present, does it then, it then pay attention to the reg I D parameter and support the out bound in the response.
       Okay. All right. We have a couple of late changes and additions that I made. Without a whole lot of discussion. One was the response code. So, this is our third try on response codes. We tried first with the four ten gone. Well, that didn't really quite work. The, Adam pointed out on the mailing list why it didn't work. Let's say Adam made a call to Collin and then wants to put him on hold and it goes over the mid dialogue request goes over a flow that fails. The proxy forwards the four ten response back to Adam, and Adam receives it, and according to the language in 3261, he is supposed to think, oh, Collin ceased to exist. I got it. I'll remove him from my address book. So, we changed it to 4 '80 temporarily unavailable.
       Well, 4 '80 temporarily unavailable is supposed to be used for do not disturb on telephones. So let's say I put my phone on on do not disturb mode. Let's say somebody calls me and they try two paths to my phone and sends the first one, and send a 4 '80 so it deletes that flow, hopefully. And then it goes to forward the other one and because, when this arrives at my U A it looked like a merged request so it hopefully re transmits the 4 '80 and well, it deletes all my flows. So that's not right either.
       So what I did is define a new response code, 4:30 flow failed, described what I meant and put it in IANA registration. No, we didn't make it 4 '89. 4:30 flow fail, does anybody have objections to this?
       Okay. Good. Next slide. I also added a new timer, because there was, I had some concern over the way the avalanche re start timers were described. It was really ambiguous what you were supposed to do, s if you sent a veg -- if you opened up a new flow, send a registration and got back a response and then the flow immediately becomes useless. Next time you try to do a people add, it doesn't work. Or if you get immediate TCP close after the 200 success, to the register.
       So I introduced this new timer called the stable flow timer, so, a flow has to be up for a short period of time. I set a default of two minutes. Before the flow is concerns table. So if you register successfully and the flow is still stable after this timer and then the flow fails, then you can re register immediately.
       If your flow wasn't stable then you have to go and use the timers, that were established in the rest of the draft for avalanche re start.
       NEW SPEAKER: Jonathan, I didn't follow the route use case. What is the use case for when this flow is not stable.
       NEW SPEAKER: You have a continuously re booting nat or an implementation where you send a TCP request and it closes the TCP connection after you send the response. There are a couple of different use cases for it.
       NEW SPEAKER: Infringe coverage.
       NEW SPEAKER: And also, when you're in poor coverage, this happens as well.
       NEW SPEAKER: Okay.
       NEW SPEAKER: Any other comments on this?
       Next, please. These are all new issues. Since the draft was, since the new version of the draft came out. So, right now, the draft says that every hop that inserts a path header, needs to add the OB token. And this, as it turns out, this is probably a little more than we actually need, many in many environments. It means that there are several other entities that would need to know about the outbound extension, than would otherwise need to, in order for connectivity to actually work.
       So, the, we probably only need the first hop to do this, and the registrar to support outbound. This assumption is a little brittle in that it means that if there's, any connectivity where we're not on globally route able, we're basically assuming that you can always, that just with whatever ordinarily, you would be put in the path header, that you can get back to the, you can get back to the first edge proxy.
       So, if folks are comfortable with that, we can change the draft, to only require the first hop and the registrar to support outbound and not have these intermediate devices and add the OB token.
       NEW SPEAKER: This touches on an area which we have not really explored very well at all.
       NEW SPEAKER: That's Jonathan. By the way.
       NEW SPEAKER: Sorry. Right.
       Is this the repeat the name every time you come to the Mike?
       NEW SPEAKER: Yes.
       NEW SPEAKER: We need to check and still know who you are.
       NEW SPEAKER: I think something about the discussion. You're not going to reject my statement that I'm Jonathan. Right?
       So, if you have for example, an enterprise that has a a proxy server using the enterprise and that's behind the nat to another service provider, you cannot bend these cases where you have, you might want to extend the outbound mechanism across multiple proxies.
       So if we did this, the implication would be those proxies saying enterprise need to be ways that they would have to strip path and appear as a U A towards the network. Which may be the right thing, actually. But we have not really explored that much.
       NEW SPEAKER: I have explored that little bit, I think what this means, the implication of this, and we did sort of come to consensus at one point that we weren't going to address, in this document, nats between the first edge proxy and the registrar.
       However, you could still implement this, it just wouldn't be part of the check. So, in other words, the first edge proxy, if the first edge proxy had a nat between it and the next E           intermediary, before the registrar, that the next E           intermediary could add a flow token and include the OB parameter.
       If it didn't, the U A would not detect that as failure. And revert to 3261.
       NEW SPEAKER: Probably doesn't work anyway.
       NEW SPEAKER: And there are several places where people do use path, where if we did do this, it would be a bit of a dam per on making this network, this mechanism deploy. So, I'm sort of leaning towards making this only work, only requiring this on the first hop and on the registrar go ahead.
       NEW SPEAKER: Kristen. I just like to say, I strongly support this, you know, this second option. I don't really see a need, with the current scope as I understand it, we only have a nat located in certain place. I don't see a need why every entity should have to support this. I mean, I think it's bad design also, because it's going to be can very difficult to get it deployed, or actually, you have to get it to load everywhere before you can actually start using it. So I would support this second option.
       Then if you want to extend the scope at some point, okay, fine, we need to think about that. But for now, I think the second.
       NEW SPEAKER: All right. So unless there's some objection now, I'm going to go ahead and make this change.
       NEW SPEAKER: So, if you have an objection, to making this change now. Speak now.

       NEW SPEAKER: Does that say issue A here?
       NEW SPEAKER: These are the old slides.
       NEW SPEAKER: Something is scrambled.
       NEW SPEAKER: Yes.
       NEW SPEAKER:
       (Several people talking.)
       NEW SPEAKER: In the new slides, this is issue B.
       Okay. So I'll describe bug A. If I can remember what it is.
       NEW SPEAKER: Hey, Rohan, for the Microsoft people, they call all the bugs issues.
       NEW SPEAKER: Use the Mike.
       (Several people talking.)
       NEW SPEAKER: Parameter.
       NEW SPEAKER:
       NEW SPEAKER: All right. Go onto issue C, which is --
       NEW SPEAKER: Objections
       (Several people talking.)
       NEW SPEAKER:
       NEW SPEAKER: Okay.
       NEW SPEAKER: Can you go to the previous slide please. Bug A, okay. So, the currently, there is no mention at all about the R port parameter in the draft. So, cons quently, someone who is going and implementing this and is using it in the typically envisioned, you know, charter Milestone intended use case, of outbound here, who is just trying to make a, for example, TCP connection or U D P flow, or or vee sorry. U D P flow work through a user agent or nat or fire wall and a proxy, the first edge proxy. They really need to put the R port parameter in. Otherwise, they will, will they need to put the R port parameter in and they need to send the request from the port that they will receive the traffic.
       These fundamental to the idea of this outbound initiated connection, is that it's a bidirectional flow. And you know, there can be other, things that use outbound, but for the ones that are trying to do this, I would like to add some text explaining that if you need to do that, you should put R port in the V I and set your ports appropriately.
       NEW SPEAKER: This is Jonathan. I obviously don't disagree with this. But the only thing is, I just remind you that we also have this document in SIPPING, the nat considerations document, whose purpose is to solve this problem. Like one document you can go to and give you all the guidance you need to solve the nat problem in SIP. But I would further add that your proxy vendor could do this too, but that says nothing about whether the media is going to work.
       So you really have to put all three of these things together with things like 36 O 5 and all that to get the complete picture and that's what that document says. I don't object to that, but I mean, just, I don't know. Should we not say this? It doesn't hurt.
       NEW SPEAKER: My thought is, it doesn't hurt anything, and it will make something, which is obvious to us, more, you know, obvious to readers of the document.
       NEW SPEAKER: I guess, you know, how about this, why don't you do that and then tell them to go read that scenario, have an informative reference.
       NEW SPEAKER: Whoever has got minutes, please record that.
       NEW SPEAKER: Restate it.
       NEW SPEAKER: Please record for the minutes that, in addition to adding text explaining that R port is needed in the usual case, that to also provide a pointer and informative reference to the nat scenarios document.
       Next slide, please.
       Okay. We talked about this one. Next slide.
       Okay. So this is an issue that Chris ter brought up before the previous meeting, and which I had programs wrongly thought it was closed and it was about this maximum number of flows.
       So I had assumed that max flows was out of scope, we don't really have, we don't have explicit requirements for this. And the maximum number of flows is already limited by the number of URIs in the out bound proxy set. However, there is a wrinkle, which is that this is provided by the, you know, the visiting network, probably. So if I've got a visiting network that specifies four or six U R Is or something like that, or a collection that works. In the outbound proxy set, this can be more than the home registrar and authoritative proxy are prepared to handle.
       So Chris ter made a suggestion to return some kind of a value or header or parameter, in a registration response, that would further limit the number of flows, and he also asked if I, if I'm a home proxy and I do get a request for registering more flows than I can handle, what should I do about that? Is there some error response code that I can issue and which one is it?
       So, you know, my feeling is that, my proposal is that we defer this, but I'd like to have had some discussion to see whether this is something we want to solve now.
       NEW SPEAKER: Do you want do to do that or close this?
       I've got three more slides.
       NEW SPEAKER: Jonathan, again.
       NEW SPEAKER: I'm still Jonathan. That's going to cease to be funny soon. It never was funny to begin with.
       Okay. I have two comments on this, one is a semi ramped, which is I am increase decreasingly convinced that this is an awful idea, for any number of reasons, not the left F least of which is security problem. And we need to talk about that. And that applies to I MS.
       NEW SPEAKER:
       (Several people talking.)
       NEW SPEAKER: That's a different conversation.
       NEW SPEAKER: We don't have a lot of time. Make it short.
       NEW SPEAKER: Okay. It's indicative of a problem. Secondly, I don't like the idea of having yet more things to negotiate. It's not just that you have a parameter to signal it. Now you need to have like behaviors and elements about what happens if it doesn't match and all that kind of stuff. If we have to do this, I would rather just have normative requirements about a minimum that you have to do or something like that. And be done with it. I don't really like adding parameters.
       NEW SPEAKER: Hang on on a second. I'm wondering whether people feel like they generally understand the problem, or the proposed requirement. And then maybe we can see if people find, you know, find well motivated with the requirements, whether we want to adopt the requirement or not, rather than have a long discussion. Okay. He's coming up.
       NEW SPEAKER: Caplan. I just want a clarification so I can understand it.
       NEW SPEAKER: Okay.
       NEW SPEAKER: If I'm configured with multiple outbound proxies, but as an operator, I want to limit it to one or two, would I have, is there, you know, a back up outbound? There used to be primary, secondary, both primaries and of course, I haven't caught up on the draft 5. But is there a way for me to say, use this one and only this one and if it fails, move to this one.
       NEW SPEAKER: Right now, the way that, the outbound proxy is set, is a list of URIs and each can have 3263 style S RV handling, so if you obl have a single URI and you drive one of the server that you got from S RV, you will try the other S RV entries in that fails.
       NEW SPEAKER: But there's still a way to limit them to one or two out bound flows.
       NEW SPEAKER: Yes. With one proxy.
       NEW SPEAKER: What about, Andrew somebody. What about scenarios where the edge proxies are in, different domains and dobt have knowledge about each other. Registering across, I mean, this max flow is just coming from one place and it might be a different problem.
       NEW SPEAKER: The issue is whether we think it's a requirement or not. A requirement we want to address in this dock: Go ahead.
       NEW SPEAKER: I just think that, I mean, Andrew just said, if they're all this home proxy or register, whatever you call it, if it's in the same network, yes, you can configure it. But this scenario is that the home proxy has no clue about what's happening in the visitor network. We may not like it but this is what's happening, in let's, you know, without mentioning where, in the deployments and architecture where this is happening. And have interest in this work.
       So, I mean, that's really where I'm coming from. That's why I think it would be useful, because in that case, the home proxy has no clue how many visiting URIs the network is providing. It has no way to even, you know, affect that, so that's --
       NEW SPEAKER: But let me ask a practical question. Please pretend everyone that I'm on at the microphone now. My question is.
       NEW SPEAKER: Who are you?
       NEW SPEAKER: I'm row I'm Rohan. Still. And is there, can we imagine a use skais, obviously, if there are two URIs, I don't consider this to be a significant brurd over the single URI for the home proxy. Do we imagine realistically, a situation where we're going to get, you know, a factor, a factor of two or three more than that, from, that we're going to establish in any reasonable time frame, an out bound proxy set from so many visiting proxies that we're going to get significantly more than that?
       NEW SPEAKER: I think six is maybe the max. You might register on three different networks and it's redone dant.
       NEW SPEAKER: I'm thinking three different networks with redundant proxy in each.
       NEW SPEAKER: And that was Andy.
       NEW SPEAKER:
       NEW SPEAKER: e hed can dral a further comment?
       NEW SPEAKER: I'm not a registrar vn dor, but I've seen they can actually have a problem. Which seems bizarre to me. Only because the challenge and everything is eating up their CPU. So they'd rather have one, if it fails they want the guy to move to another outbound proxy.s Long as that's con fig rabl, that's fine. I don't think if they have a problem with two, I guess it's actually the registrar vendors do have a problem with two. From what I've seen in the performance, one is almost a problem for them.
       NEW SPEAKER: Okay. I'll have a half a registration please.
       NEW SPEAKER: Okay. Collin.
       NEW SPEAKER: Another option is to defer this to the discovery mechanism. So what we'll talk about tomorrow, this is sort of easier done as part of that proper process as as another idea.
       NEW SPEAKER: Chris ter, give one more comment and let's try to get a sense of whether we have a consensus in the room
       (Several people talking.)
       NEW SPEAKER: What happens
       NEW SPEAKER: I think, we can discuss this more, but I don't think this is really part of the discovery issues, because again, your home network is not going to provide you with the addresses of the edge proxies in the visiting network. That's not going to happen so I don't think that's going to be, you know, solved.
       You know, when it comes to, you know, additional functions, you know, what happens, if this or that, this can be a recommended value, because I think that the second question there, what response code would be used, I think that is something that we need to solve anyway. Whether we have the max flows or not. If the reg strer gets gets too many registrations, there should be a way to refuse them.
       NEW SPEAKER: Actually
       (Several people talking.)
       NEW SPEAKER: I have a con ceet proposal for the second one, which is we can make, we could also use the 4:30 response code for that.
       NEW SPEAKER: Sure. I was actually going to po bos that earlier. But I thought I'd wait in this comes up.
       NEW SPEAKER: I think that's a air fairly non controversial point. I think the bigger issue is whether we want to address in requirement in this document now.
       NEW SPEAKER: I pirnly personally think it's an easy thing to do. And we can even call it a recommended value or whatever you want to call it. But that's my opinion. Of course.
       NEW SPEAKER: Okay. So, do you want me to ask for hands.
       NEW SPEAKER: Okay. All right. So those that feel that this is a requirement that the max flows limiting the number of flows from the registrar or authoritative proxy is something that we want to address in this document, please hum now.
       ( Humming. )
       NEW SPEAKER: Small but vocal number. But if you feel that we should not address this and we should defer this, or address it later, please hum now.
       ( Humming. )
       NEW SPEAKER: Okay.
       NEW SPEAKER: That's a larger number.
       NEW SPEAKER: Are you calling that?
       NEW SPEAKER: I call in favor of deferral.
       NEW SPEAKER: Okay. Next please.
       NEW SPEAKER:
       NEW SPEAKER: But if we defer -- we're going to get a response code.
       NEW SPEAKER: Mike.
       NEW SPEAKER: Sorry. Andrew. If we defer, we're going to get a response code that identifies why the registrations are rejected, right?
       NEW SPEAKER: Yes. I'll take that to the list, but I suspect that there are not going to be significant objections to doing that. I'm willing, certainly willing to do that.
       Let's skip through issue D. Let's skip this one. And let's skip this one. F. Okay. Right now, you can register an instance I D without a reg I D, and the problem when you do this, when you get back the response, you can't tell whether the registrar did 3261 binding rules or instead did the new, you know, based on the contact rules or whether they're doing it based on the instance I D. It used to be easy to tell what they were doing, because this used to be in the grew spec, and when they did do the instance I D style of rules, they send you a GRUU parameter.
       So the question is, does the U A really need to know, and if so, what can we do? We could add a new instance I D option tag in the response, to indicate that that's what the registrar did. And we could add some token in the contact header or we can just decide, we're not going to make any change, don't worry about it. Jonathan?
       NEW SPEAKER: I guess, what change in behavior you expect, if the registrar says, I didn't do this?
       NEW SPEAKER: From the UAC?
       NEW SPEAKER: Yes.
       NEW SPEAKER: I can't think of any, but I brought this up, so if somebody can think of something here or on the list, they should speak up. Because if not, we don't have any reason to make this change.
       NEW SPEAKER: I guess I could possibly think of one. It's similar to something na Derrick raced in the raised had the ice discussion. rav paragraph let's say there is S B C that fixes the problem. What the U A might do if it sees that the proxy, the registrar is not, the edge proxy is not helping, it could effectively go to a media relay, get an IP address support from that and re register using that address and port. You might try that. If you wanted to be able to do that --
       NEW SPEAKER: I'm not even able to understand the whole use case you're providing. So it would be productive to take this one to the list, I think. Maybe I should have even just skipped this slide. But,
       NEW SPEAKER: Okay.
       NEW SPEAKER: So,
       NEW SPEAKER: Name.
       NEW SPEAKER: Collin. Just individuals discussion on this draft and I sort of understand what Jonathan was saying and you need to think of that use case where you fall into the bizarre case where you have instant I D and not reg I D.
       NEW SPEAKER: For GRUU.
       NEW SPEAKER: I can't possibly imagine any case this would be useful. I don't want to take this to more list discussion. Unless there is some real requirement for needing this right now, I think we should decide it's out. And if we below it and make a mistake here. We can add another draft later that's fully backwards compatibe with this. I don't think we immediate to comment now.
       NEW SPEAKER: Jonathan again. So if there is a reg ID, how does it know and use 3261
       NEW SPEAKER: The supported, be
       (Several people talking.)
       NEW SPEAKER: In the support out bound spobs. That means that the registrar supported the mechanism, and that it verified that the first hop inserted the OB parameter.
       NEW SPEAKER: Then I apologize, because I misunderstood st use case.
       NEW SPEAKER: Okay.
       NEW SPEAKER: Next please.
       NEW SPEAKER: Is there a decision on this?
       NEW SPEAKER: So the decision on on on issue F, was, go back to F, please. The decision on issue F is that we're not going to make any change. If there is a concrete issue that comes up later, we will fix it in some other document.
       NEW SPEAKER: So the proposal on this line is accepted.
       NEW SPEAKER: That was issue F. Now we have issue three G. Come on, you guys are asleep or something.
       NEW SPEAKER: It's after lunch.
       NEW SPEAKER: Okay. This is binding bee haiv yor without flow tokens. So right now, three GP P wants to solve several requirements that happen to be solved by the out outbound draft. But they don't want to use the flow token behavior, sort of the reason that we originally went down this path, but the flow token behavior that's applicable to the generic U As on the public internet.
       NEW SPEAKER: Andrew. Don't want to be forced to use it on all paths, basically.
       NEW SPEAKER: Yes, yes. Okay. So, what is similar, about what they want is that they want to store multiple path vectors back to the same instance, each associated with its own reg I D and this could be for two for edge proxies on the same interface or different interfaces.
       The new registrations just like in the current document with the same reg ID would replace the old bibding with the same reg ID. But unrelated to the oud bound flow token processing.
       So, you know, they're looking for separation of binding behavior and flow token behavior. One of the reasons for this is that the current IP sec over U D P security mechanism uses several pairs of actual flows, instead of a single flow. Okay. Did I get this right?
       NEW SPEAKER: Yes.
       NEW SPEAKER: Next slide, please. Last slide. Okay.
       What can we do about this issue? I see three paths. One is, that we leave the current draft as is. And what this would mean for three G is that if you've got, if you are registering with this IP sec multiple flow, IP sec thing, you would register with an instance ID and no, and it replaces any cellular registration. And you would use reg ID when you register over wireless land interface, although it uses the four flows, it does it in a tunnel.
       NEW SPEAKER: Or possibly, or it may do it
       NEW SPEAKER: Use the microphone if you're going to speak.
       NEW SPEAKER: Andrew, again, sorry. So it may or may not use the nat traverse Sal mechanism on that particular flow, depending on what the security architecture is there.
       NEW SPEAKER: Hang on. Just let me get through the slide. So to clarify, there is, there does appear to be a way that solves a, you know, some subset of the requirements if we leave the current draft as is.
       Another way we can do this is to relax the flow token language slightly, and so instead of talking about the flow token staying in a specific U D P address for transport, over which the request arrived to make the language a little bit more generic, to say this is where ee we see a token to follow a logic flow to deliver data.
       Now, I'm personally not very comfortable that an ordinary implementer is going to get this right. But this definitely does appear to be a way forward and we can put language in that says, you know, for the ordinary U D P case how we do that.
       The third approach is to affect tiffly do a split of the two types of functionality inside of the outbound draft and replace the reg ID parameter with, you know, get rid of it and replace it with two new parameters. One would be a path ID parameter and this means I want this path to an instance to be stored and that's a binding part. And then this whole really take the existing OB parameter that's, that we put in the path, we can put that in the contact, indicate, that the U A wants outbound flow token behavior.
       NEW SPEAKER: Make this discussion very short.
       NEW SPEAKER: You need No. 2 for the outbound mid dialogue stuff to work. It actually has the whole construction algorithm that basically does No. 2.
       NEW SPEAKER: Oh.
       NEW SPEAKER: Think about the
       (Several people talking.)
       NEW SPEAKER: I think we have a fundamental problem here, which is if we don't have an enumeration of individual flows, a flow token that goes into the path header,
       NEW SPEAKER: Right.
       NEW SPEAKER: This is not referring to the flow tokens that go into record route. A flow token that goes into a path header, my impression is that in order for anything to really work, that you need one, you know, one token per path and if you have a token that refers to multiple paths then the 4:30 flow is dead mechanism does not work.
       NEW SPEAKER: Yes, it does.
       NEW SPEAKER: Okay. How?
       NEW SPEAKER: I mean, this is in the draft that I wrote.
       NEW SPEAKER: In a path, not in a record route.
       NEW SPEAKER: In my draft, the URI that goes in the path is no different than the one in the record route. It differs by on him another parameter, otherwise it's the same.
       NEW SPEAKER: It's becoming brutally clear to me that this is not going to conclude in the next two minutes. So would it be fair to ask all of you who have an interest here to have another time between now and tomorrow and have
       NEW SPEAKER: Do you want to cut into GRUU time?
       NEW SPEAKER: I want to finish this.
       NEW SPEAKER: Well, I mean, in terms of how much time we're going to need for GRUU. It's largely a question of you.
       (Several people talking.)
       NEW SPEAKER:
       NEW SPEAKER: I don't think there's anything new that I'm going to say about GRUU, that I haven't said on the mailing list.
       NEW SPEAKER: Okay.
       NEW SPEAKER: So you're willing to yield you know, 5 minutes or something more.
       NEW SPEAKER: We're already fifteen minutes into GRUU's 20 minutes or something like that.
       NEW SPEAKER: Okay.
       NEW SPEAKER: Chris ter. I was confused when I saw the previous slide, I guess it's clarified a little now. I think it's wrong to say, three G doesn't want to use the flow. I'm not aware of that. But now when I see this option two here, it gets more clear to me. It's not about removing, it's more about relaxing the text.
       I think, okay, you know, three G has this little different registration procedures. But when we talk functionality wise, I think the biggest request that comes from three G is that for this multiple registration usage, we don't necessarily want to use the nat keep alive because you know, we have scenarios where we don't have nats, I think functionally wise, that is the biggest issue.
       And then this is more, you know, detail so to say, but I do agree this has to be done in order for this to be useful, by three G, but the nat on a high level, it's really the nat keep alive.
       NEW SPEAKER: When you say this. Did you mean two or three or one?
       NEW SPEAKER: I will vote for two. I think this is really what really has been asking for. But when I saw the previous slide, it doesn't want to use this or that, I don't think that was true. But I think this clarifies it. It's about relaxing the text, not about really removing it.
       NEW SPEAKER: Yes. Is there anyone at the line who would like to speak in favor of something other than option two?
       Okay. Is there anyone here who is, would strongly object to doing something other than option would strongly object to doing option two?
       Okay. I believe that we have rough consensus
       NEW SPEAKER: Concur.
       NEW SPEAKER: Rough consensus on option two.
       NEW SPEAKER: In the meeting.
       NEW SPEAKER: So, let the record show that for issue three G we are going with approach two.

       NEW SPEAKER: Can I ask you to make sure these do go to the list this time. Within a short period after the meeting.
       NEW SPEAKER: Well, the minutes go to the list as well.
       NEW SPEAKER: But this needs to go to the list before that. Take fim to write the minutes.
       NEW SPEAKER: Right.
       NEW SPEAKER: Okay. vee Jay.

       NEW SPEAKER: Did you have more? Or are you finished.
       NEW SPEAKER: That was my last slide.
       NEW SPEAKER: There was a couple that he skipped.
       NEW SPEAKER: I did skip issue D and E.
       NEW SPEAKER: Can I ask a process question from the chairs. Do we have a review team --
       NEW SPEAKER: I'm going to go go back in the back and
       (Several people talking.)
       NEW SPEAKER: He has to revise the document and then we have the working group last call and the review team will be in parallel with that.
       NEW SPEAKER: Okay.
       NEW SPEAKER: That will take place hopefully before Christmas, assuming we get the revised document.

       NEW SPEAKER: Okay. Next slide.
       So st problem, I think we covered at least in did Dallas IETF and also in Montreal, is what sort of identities to store in the certificates,
       NEW SPEAKER: Speak lou louder.
       NEW SPEAKER: So, the basic idea is that the model is to use the example.Com, and that works when you're making an initial SIP request. But oftentimes many proxies or intermediaries pin their domain name, so when you go later onto that request, and if you do WWW Dot example.Com, and sort of the proxy, how do you authenticate that?
       That was one problem. The other one was that you have certain proxies that are authoritative to send requests out and they may not have D N S entries. When you make a connection, and the server wants authentication, you need to have some semblance that you're talking to an authorized entity.
       Next slide.
       So those two issues to be solved, one was to express the purpose of the certificate, and identify the host of the certificate. And the way the draft, the O three version does it uses two identities with different schemes, to indicate that you're responsible for this domain, it uses an identity with oo a SIP scheme and to indicate that you are indeed the host presenting a certificate, it using the D N S theme.
       There's been some discussion on the working list and the general consensus appears to be that having a couple identities and certificate is okay. And could actually propose three or four rules that are appropriate to use here.
       There was also some consensus that do not break these schemes down to SIPPING D N S. And instead of using a SIP scheme to identify that your response code authority for this domain, use some other things and one of the things suggested was D K U using N O I D. And so we talked to the security A D and we have a map, we have a way to move this forward and the next draft is going to reflect that.
       So basically, the questions now, are, in front of the working group, is you know, I think there's interest in pursuing this. What to do next?

       NEW SPEAKER: Jonathan. So, I still don't like this. And I now proposed a counter proposal mechanism that I don't know if people realize that it does that. But the outbound discovery mid dialogue document removes the need for this document completely.
       NEW SPEAKER: This is the connect re use document dash
       NEW SPEAKER: Both.
       NEW SPEAKER: Because it doesn't try to change the semantics of how it works for the wep. It allows for the case where proxies in a proxy form record route with an example.Com. They do not require an F D Q if the record route. What you expect to see is the record route behavior, and get that back to the right proxy and it does that by reducing something.
       And so, I, I'm sure, I mean, I have no doubt that people have not understood or on have not had a chance to see it has that effect. So most of us are sort of just, I had to mention this, but I'm raising the flag there is an alternative solution to this problem that allows us not to have to flood the D N S with names and all that stuff.
       NEW SPEAKER: But is there a solution tied in outbound. What if somebody doesn't come in outbound.
       NEW SPEAKER: It has nothing to do with outbound in the sense that kit would between proxies with nats. The semantics described in the document that use this caching mechanism, at a lower level to bind URI connections, that's how it does it.
       NEW SPEAKER: Restate vee Jay's question. Let's say you have two inter domain proxies that are going to try to re use connections. Does the thing that you're talking about complete canly eliminate the need for any of the text in this document, in order for those guys to re use connections?
       NEW SPEAKER: I believe so. I think it needs to be looked into to see if I'm wrong.
       NEW SPEAKER: Is that re using connections or certificates?
       NEW SPEAKER: Both.
       NEW SPEAKER: Okay. That's fine.
       NEW SPEAKER: And it works with a nat.
       NEW SPEAKER: John Peterson. As I think I've said a lot of times in the course of our discussions about certificates and security, you know, I really think it is in our best icht to keep the sort of certs stha you use for SIP similar to the traditional environment. That's because it's deployed, widely available, inexpensive, and very mature market in some respects. I think introducing new technologies into that market is very difficult.
       And people have tried to do this in e-mail space, in order to create custom certificates, if you do appropriate e-mail and so on, I don't think that the certificate authorities that do so have managed to exert much influence in the marketplace. So just as another data point on this, when I see the introduction with anything with a URI scheme or any requirements that don't seem to be satisfied by what you do when you order a C I for today, I get nervous about the deploy ability of the mechanism.
       NEW SPEAKER: Do you want me to explain, like do, plane how it works.
       NEW SPEAKER: No, no.
       NEW SPEAKER: Scott Lawrence. The, it's not just about the problem of routing things back. It's also about, if my proxy and your, my company and your company have a business relationship, that enables you to bill me for calls I make, all right. If I create a TLS connection to you and want to send bill able SIP requests over it, you need a way to insure that the connection you're getting from me is one that's authorized to create those bill able requests.
       Okay. Now, in the normal model for the web, you associate the domain with the certificate identity by doing a series of D N S look ups That say WWW Dot L OB goes to this address and then it presents me with a certificate that matches that name. But in the SIP case, as I'm creating that outbound connection, I may need to do it, for lots of providers already do this, from a connection which is not a a proxy that I want to be on the list of proxies that get resolved by my external name. I want a set of proxies that only does connections out wards to make high outbound requests run. And have a different set in the D N skchlt for connections that come into me. All right.
       So, but I still need you to be able to assure yourself that I'm a legitimate authorized caller from that domain.
       So you cannot use the normal web process of going, doing the forward look up to find the name and seeing that it matches it. You need the cert to be able to --
       NEW SPEAKER: I never said that
       (Several people talking.)
       NEW SPEAKER: You're describing a solution to the routing problem. I'm sciinging a solution to the authorization problem. They're different problems.
       That's why we need the name, the SIP name and the specific binding of that authority to the use of that name.
       NEW SPEAKER: Okay. We're missing each other completely, because, nothing you said doesn't work with the draft that I work. I'm totally confused about, I mean, if you don't want me to explain it, okay, I won't. But you know, it, it has the property you want.
       NEW SPEAKER: Collin?
       NEW SPEAKER: So we, there are certain times where proxies are going to insert something. A host name and a route or record route or something, and later somebody is going to need to make a TLS connection to them. And they might choose different things that they need to put there, based on how they do high availability and reliability in their domain. Okay. But whatever they put there, somebody is later going to try and form a TLS connection in there and they need to have a certificate to pov that's okay. Approve that it's okay.
       The certificates have this, therefore, that's why we put them this way. And that's why we put this in your record route. No. It's because you're putting this in your record route, that's why you put the cert there. It's consistent with everything, the fact that we do mutual TLS, tlaes nothing in the draft that says you can't do that. That's very normal.
       You know, the, there is nothing about the web model of looking up D N S to verify certificates of how you validate a trust chain. That's not how you do it. You look at, he can explain that in a second. But it doesn't have to do with D N S. So there's nothing the reverse direction that doesn't works. So I don't understand the problem there.
       I'm glad to, there's klee clearly some confusion on on this, and we want to clarify that. It does seem that we use certificates in two different waist, ways, one has to do with S MIME approach to it. That can all be dealt with separately. This stuff is really only about the usage of SIP with TLS and the SIP thing and it might be that this is, you know, I'm not quite sure how to organize these documents. I'm trying to get the text clear and right on this, and so we're all agreeing on this.
       But, you know, I don't think this is, it's not even clear that this shouldn't go in for example, Francois's SIP best advise draft. How to clarify it, I don't think we've gotten to quite the right text yet on what the solution is.
       NEW SPEAKER: So, yes, I'm confused too. So from a fundamental variant of TLS style indication, is you start with a name or URI and you have to all things in the front and backs, and then, through some magic procedure which we don't understand, you, and we don't describe, you make afford TLS connection or somebody forwards one to you, and you look at the name in the certificate and you do nim com. And this better be the same. And D N S is enter into any useful way something about connected.
       And if, you know, if, a if a stone tablet is dropped on your head and says, this is the IP address. Because the whole point is T L is to bypass the security issue.
       NEW SPEAKER: About what about clients authentication. You don't start with a name. You start with a connection.
       NEW SPEAKER: Well, you start with the certificate. And you extract the name and now you know who you're connected to. So that's the fundamental vair yanlt of reverse thing and again, D N S isn't relevant.
       NEW SPEAKER: That's not going to be a certificate in the client case.
       NEW SPEAKER: It better be the certificate
       (Several people talking.)
       NEW SPEAKER: That's what we're describing, that's the name you put in the certificate.
       NEW SPEAKER: I'm just talking about the variance of the system. So, I mean, so, I mean, the only thing you can usefully do with this authentication is extract the name on the certificate and compare it to something you know, or look up something. So, the, as I understand, as I understood the draft, there were two point being made. The first was the relatively uncontroversial point, con dpus ting certificates. And certificate that said, hey, this is like a SIP T L C certificate. And I really don't care about that. I think it's probably relevant, but I can live with you guys if you can get something off the extension.
       The second point, which part I have trouble with, is the assertion seems to be that you need to have multiplicity of names that are different context, and so, any given server might under some circumstances want to use the name, through that example.Com or example.Com. I'm not saying it actually happens, and I think that's where you're confused too. But it what does happen, I'm not sure it needs guidance because it's something we can't understand.
       NEW SPEAKER: Okay. Let me break in here. Two comments, one. I think that it's not just a multiplicity of names but Scott is talking about a directionality tea of names. You have some names that are used are for terminating connections and some originating. You don't want to get those rolls confused. And now I have one question are the jabber community, from Paul Waters. And he basically wanted me to mention that, well, somebody said you cannot trust the D N S, we do have this thing called D N S sec, you might have heard about it.
       NEW SPEAKER: That's funny.
       NEW SPEAKER: And we need to think about the role of D N S. And other records which might actually have some way of getting the same kind of information in the D N S.
       Okay.
       NEW SPEAKER: Okay. I'm not sure how to proceed here even. We probably need to get interested parties together and sit down. I think it's important that we be able to define what needs to be in a certificate that binds it to a SIP usage. For a domain name. The people who run the ee commerce site for L L been.Com will certainly not want it dob the same certificate that works for SIP. Okay. Those are entirely different domains run by entirely different people and entirely different parts of the organization. It's not going to be the e same thing.
       NEW SPEAKER: It will be WWW
       NEW SPEAKER: They have a choice.
       NEW SPEAKER: They can buy 50 of these things.
       NEW SPEAKER: Rant at the microphone, please.
       (Several people talking.)
       NEW SPEAKER: So, I'm with John, I mean, what I don't like is that we have to define a an entirely multi layer addressing technique and we're asking the certificate authorities to understand in order to get certificates from SIP. So I would rather have, yes, you get SIP
       (Several people talking.)
       NEW SPEAKER: You can't order certificates for SIP and this is part of why. No C A issues them, please.
       NEW SPEAKER: Hang on a second.
       NEW SPEAKER: Let's take a step back. Fund ment lie there are two ways that you can do certificates. I'm going to big a web farm and so I can do two things, one is, I can re name the things differently. I can name, you know, SIP, Dot L L been.Com. And that can be, and that provides separation but in an opaque way that people dobt have to guess at. But it's not really a problem. Because, you know, I mean, so the only proob lem there there is the some invert tant types that theoretically the web server could answer the SIP connection and I am persons Nate the SIP server. That's issue one.
       The other way to do it, I mean, the other way to do it is to stuff a, you know, is to stuff an extension certificate that means this is for only usable for web, and this is only usable for SIP S. That will work in some concrete sense. No C As, to determine that John Peterson is allowed to get a web certificate and not something ems. And I mean, the who you are, to e-mail at like.
       NEW SPEAKER: Send you an e-mail.
       NEW SPEAKER: Thank you.
       NEW SPEAKER: It's not worth it.
       NEW SPEAKER: So, you know, I mean, as I said earlier, I have no problem with the notion that you guys want to put an extension tert that says this is a SIP certificate. I don't understand why you want to do it in naming, however. This is what, you know, extend ted key usage is for.
       NEW SPEAKER: It will work. You'll have an M X record for SIP Dot example.Com.
       I'd like the property that we don't have to have something totally different. I mean, if we want to make something different, okay. That's why I didn't like certificates with two addresses, and that was an artifact of this record route name thing that we do in SIP, that people are putting F D N and that's why my draft suggests that if you use something use something to obtain mapping. Then you can avoid the need for that extra thing in the certificate and you can use existing web certificates.

       NEW SPEAKER: As I was saying, I think that's a good feature, if you can, because it's very difficult to change.
       In terms of what to do about this, I mean, I guess I agree with you that we probably do need to off line it at this point. I don't think we're going to resolve the issue here in this room. I'd be happy to try to fine some time to talk about this stuff. I'm sure that's true of all of us. So. Let's do that.
       NEW SPEAKER: Yes, in fact, we think we have a chair's proposal here. Everyone who has had heated and interesting arguments that they've presented here, try to write up your issue and put it on the mailing list. And we will try to get the interested participants together. It may not be possible here. But we'll try and schedule a working group kind of conferencing call, in the next two weeks and see if we can get everybody together. Is that okay? Thank you, all.
       vee Jay, the other slide.
       NEW SPEAKER: Okay.
       NEW SPEAKER: You have ten minutes.
       NEW SPEAKER: Next please.
       NEW SPEAKER: Okay. '07 is fairly complete. There is nothing more I can see adding to it. There was one open issue, that Collin had been asked about security type of stuff, if you have two virtual domains, and you connect to, so P has two virtual domains, and P connects to C as A.Com. Later on when C goes to re use that connection, it might inadvertently use that connection to B.Com.
       So the solution was basically saving the identity of these certificates, in your alias table and that mitigates the problem.
       Collin also pointed out one more issue to the mailing list, that the fact ta outboupd connect re use and connect re u use in this draft are orthagonal to each other. And that says, TCP connector use, use two connections in opposite directions, whereas outbound uses the same connection.
       And this particular thing is fairly easy to mitigate, because put some text around it saying, if you support outbound then you do your connection re use using outbound instead of this. So these are the basic changes. The draft is ready to go. I understand Jonathan's outbound discovery also has a mechanism here. Again, comments are the same, and I don't think you should be forced to implement outbound to get connect re use as a side effect. And furthermore, outbound between two
       NEW SPEAKER: I, sure
       (Several people talking.)
       NEW SPEAKER: I guess I screwed up in the draft name, that's clear. I need to pull out the top section that talks about client and server behavior that's generic for anything that's a client or server in the SIP transaction sense. If you just implement that piece of spec and never looked at SIP outbound it will work. And it will work through nat.
       NEW SPEAKER: To me, it seems that you always have to implement outbound to get this.
       NEW SPEAKER: No, no. You do not.
       NEW SPEAKER: So
       (Several people talking.)
       NEW SPEAKER: You can use it with UAC and proxy. You don't have to necessarily use the proxy.
       NEW SPEAKER: What?
       NEW SPEAKER: One additional property of this is that you can use connect re use between a U A and proxy as well. Not necessarily between proxy and proxy which is what your draft talks about, connection re use between proxies.
       NEW SPEAKER: My draft talks about connection re use between proxies.
       NEW SPEAKER: Yes.
       NEW SPEAKER: No. I mean, again, the problem is, it's a draft that was targeted at solving one specific problem which was the mid dialogue fail over. The solution that I found for that solved these other problems too. Eliminated the needs tore domain certificates and connect re use, in my opinion, again. We have to verify it. It's a complicated document. Because there's a mechanism in it that is not specific to SIP out bound that re defines client and server behavior so you don't have to use D N S as a re direction from URI to server that's a connection that you use.
       And that little thing, not the D N S, makes all these things go away. So it is not specifically it will work wherever on anything that has a client and server, which is every connection. So I don't know what to tell you.
       NEW SPEAKER: So I'll leave it to the chairs to what to do with the document per se. From my point of view, it's complete. There's no more cycles or nothing more I can do than move it forward.
       NEW SPEAKER: I suspect this means it has to be part of this workshop or conference call that I was proposing on the domain certs aspect of things. Once we get that piece naild down, this will also get naild down. Bring the two issues together.
       NEW SPEAKER: It's probably a subset of the people interested --
       NEW SPEAKER: Can I take 30 seconds to explain why it does this, if people want. Whatever. Do it tomorrow?
       NEW SPEAKER: We have three minutes left of this conversation. So it's up to vee Jay.
       NEW SPEAKER: Sure. If you want to come up, go ahead.
       NEW SPEAKER: So let me give an example. Okay. Two proxies. All right. First invite, no connection. Request goes to the first proxy. All right. It opens a connection to the second proxy. And let's ignore nat for a second. Goes to the second pros proxies and does mute yul TLS. Mutual TLS, so the left proxy presents a certificate for left.Com. And both proxies cache the connection and associate the connection with the connection. And if they ever see a URI that has that matching domain, they'll use that connection. Okay.
       So, when a request comes into the reverse direction, right.Com sees the request for left.Com, which is what left.Com record routed with and matches that to an existing connection that it has cached with that certificate. And then you get connect re use.
       NEW SPEAKER: That's essentially what this draft does too. You have proposed that solution in e-mail.
       NEW SPEAKER: Right.
       NEW SPEAKER: And that solution was then adopted by me and put in the draft.
       NEW SPEAKER: But it's still using the via related information and all that stuff. And that's not, I don't think -- and it doesn't work. And I'm not sure what's different at this point.
       The draft I have works through nat because it's not using IP addresses or anything in order to correlate these guys together and it has a load balancing property. I don't remember how I did it but I have to look at it again. Built it doesn't look at IP addresses.
       NEW SPEAKER: But this draft more specifically, I mean, when we first started this draft, outbound was not around and it didn't take into consideration nats. So this was a decision we made at some point, that for those of you who want to do nats, you do outbound and for the rest of the folks, we can provide guidance with TLS use.
       NEW SPEAKER: The reason we took the, that portion of it out, is because the draft didn't work at all for that portion. Of the issues. And we're still, at the question of you know, what we get out of this, and what, what is left in it, after all the things have been removed, is in one narrow case, the idea of matching a domain name in this connection table and then re using that connection, which is exactly the same as Jonathan's draft, except he has the multiple match thing that has a much higher reliability thing. And these ideas have evolved over time. I'm not saying what we should do, I'm just saying these are very similar things.
       NEW SPEAKER: Jason. I just, because of all this one does is, it allows you to half the number of TLS numbers that occur between proxies, to me, it does ment seem like it adds enough value to warrant standardizing it. And like, does that really, does, it, I wouldn't mind if the chairs could ask whether we think that's important. Does everybody even understand what the gain is here? Because I don't think the gain is substantial enough. I think the goals, when the document started were to do a lot more. Now what we've scaled back to is so limited and if it gets addressed in Jonathan's new work, then maybe we should just, you know, move on and take it up there.
       NEW SPEAKER: Jason. Do you think you could turn that into a question for the room?
       NEW SPEAKER: Okay. Do people think that halving the number of TLS connections, which is the only thing that I understand it, that that draft accomplishes, without nats between them, so just, you know, between big proxies in the middle of the network, does it warrant doing the work?

       NEW SPEAKER: Before we answer the question, vee Jay, is that your understanding of the benefit?
       NEW SPEAKER: For TLS, yes. For something else we use re direction anyway. The answer for me is yes, but I'll let the rest of the room decide.
       NEW SPEAKER: So Jason's question stands as, given that the effect of the draft here is to reduce by one half the number of connections between large proxies between which there are no nats, is it worth the complexity of dealing with this? So, those who believe that there is value in continuing with this process, and making that optimization at this complexity cost, first hum will be for and second hum will be against. So those for continuing with this, please hum.
       ( Humming. )
       NEW SPEAKER: Those opposed.
       ( Humming.)

       NEW SPEAKER: I'd say it's about 5 to one ratio opposed. Was there anybody who has a violent opinion or thinks they didn't understand the question I just asked. Please feel free to wave your arms and run to the microphone.
       NEW SPEAKER: All right. I think, Caplan. I have, there is value for hearing connections where you happen to have a lot of small hearing providers or service providers connected through your box. A lingt bit, whether it's worth this, I don't know. Half of us just have a configuration object to do this.
       So, the other side knows or will know to do it as well. So I don't, I can't really answer the question. But there is use case out there where you do have thousands of sockets. And connections, not TLS today very much. But you can just TCP for that matter, but hopefully in the future it will be.
       Did that say anything, sorry.
       NEW SPEAKER: Did you convince anybody. Does anybody want to change their hum as a result of what he just said?
       NEW SPEAKER: No.
       NEW SPEAKER: So clearly, we need to take that to the list for sort of a more final position on it. But I think the sense of the room is that the complexity out weighs the value.
       NEW SPEAKER: I think you should just table it for now and we'll find out later.
       NEW SPEAKER: The complexity won't disappear even if you go to some other route. The complex fee will be there.
       NEW SPEAKER: Right. But to me, the issue is can we solve a lot of other issues in one fell swoop. That's why I am harping on the other document. It solves a lot of problems with the same mechanism. So there and then it becomes worth it and it is more complicated. Al Collin pointed out, it's the same idea of associating properties with connections but it's got this multi layer matching stuff to get load balancing and solve other problems. But you get a lot bigger bang for that little buck.
       NEW SPEAKER: Let's move on to the next thing here. And I'd like Dan petri to come see me again.
       NEW SPEAKER: Dean, can you just say definitively the decision is to defer but --
       NEW SPEAKER: Yes. The position is that basically, it looks like, we're taking it to the list, but it looks like people are not interested in continuing the draft as it currently stands. If you want to go back to the issue, provide use cases and start from scratch again and work from there.
       NEW SPEAKER: Now we move onto SIP guidelines.
       NEW SPEAKER: Is this working?
       NEW SPEAKER: Louder.
       NEW SPEAKER:
       NEW SPEAKER: Is this working?
       NEW SPEAKER: Yes.
       NEW SPEAKER: Okay. So hopefully this is going to be a little bit faster.
       Let's move on, so before I go to the slides, just to give an idea of the people, of the sequence, what I'll start with is, the status, and, as an e-mail that was sent by the chair. I'll move after that to the summary of the changes m the document from last time. And finally, I'll tackle a little bit some of the discussions from the mailing list, and where do we go next. So let's move onto the next slide.
       So, basically, where we are at right now, this is fairly important. This came from Keith and it's an e-mail that he sent, I guess a week or two ago.
       What we're really looking at here, is something that will be an informational document. Okay. It isn't a Milestone for working group last call for March, 2007.
       ( It is a Milestone.)
       For submission to IESG in June 2 thousand 7.
       Another thing that's important that is not reflected now, it was agreed to be a working group document in Montreal. At IETF 6.7. That has not been done yet. It still says draft A D, SIP blah, blah, blah. It will be reissued as O O SIP working group document. Paragraph as soon as I get back hope home.
       The changes between that document and what we have right now is that it will be clear that it's informational. It will be made clear that it does not update RFC 3261 with. It will describe two things. Okay.
       First thing is, dp we use SIP security mechanisms, SIP S in this case, as defined now, you get, and this is what the document describes right now. Basically, the document describes what we have, our understanding of what wearyly trying to say in RFC 3261. Okay. So we're not trying, at this point to re in vent the wheel. And that is the source of most of the confusion that, and chaos that we've seen in the mailing list.
       Okay. So everything that I said so far is green. That's basically, we're not here to argue about this. This is decided.
       What we do after that is where we start to get into the more interesting questions here. So one, one thing that we have not done in this document so far, is examine the options for improvement, which, from which the working group can make informed decisions about changes necessary.
       So these protocol changes will not appear in the document, if we decide that we need these protocol changes. They will be subject of other documents. Okay. And we will need to re charter, if we need to do this.
       So as an example, if you look at all the things that were discussed, you know, deprecating this or that, and in venting a new mechanism, these type of things will not be mandatory changes in this document. We can discuss them to make a case for them or against them, in this document, but any technical changes will be done in other documents. Okay.
       Any proposed changes can be in the form of best current practice. The current rules in 3261 are best use, should only be used following manner, blah, blah, blah. And also did standard draft RFC if we need to change something. That's just procedural stuff.
       Okay. Let's move on -- well, do we want to take questions or maybe it's not a good idea.
       NEW SPEAKER: It's up to you.
       NEW SPEAKER: Keep going.
       NEW SPEAKER: Let's go. Let's continue.
       NEW SPEAKER: So let's go through the summary of technical changes. At the last meeting, we had a draft O two. Subsequently, very soon after Montreal, based on all the comments we got from Montreal, I did a draft O three and then based on all the comments on the mailing list, I did a draft O four. So the changes between O four and O two, in summary, are the following. And in the case of routing and rooming and registration, what we have done is clarify that the resourceing that are in SIP or SIP S URI, are really the same person.
       This is something that was very different from the previous version. I don't know if you remember, but in the previous, the first version of this, presented in Montreal, the assumption was that you would register all the different URIs, that you would register separately a SIP and S rSIP S as well as the transports that you may be using. So people really didn't like this.
       So we changed that.
       So we don't explicitly anymore list all the various possibilities. The rules that decide if you're going to use SIP or SIP S in registration are really mechanical rules. So it's a lot easier to implement, actually.
       What's really important, the really key point here is that it's the association of the contact and register, with the address of record that will determine if the user is reach able or not, with a SIP S URI. So if I register, so specifically, if I register with a contact that's a SIP contact. People that are trying to reach me with, requests that are sent to the proxy using a SIP S, will not be forwarded to me. Because it's not in two A. Notwithstanding the last exception rule. And we can talk about that later.
       That's the main change. Next slide.
       Other changes, clarified the menk of since. The whole thing about the padlock, blah, blah, blah, I think it's clear, obviously, it may not be to everybody. But, and dp there's something missing in there, we can obviously add that.
       ( Meaning of SIPs.)
       Another big change is the use of dual record route entries to deal with upgrading and downgrading between SIP and SIP S. This is really basically a copy of something that we did in the IP B six, and there's a couple of other drafts or RFCs that use the same mechanism. It's nothing new, we're just showing how to use the exact same mechanism for this.
       The call flows were completely re written and are a lot more expensive than they used to be.
       ( Extensive.)
       I invite people to look at them to see if there are mistakes miss takes, but they're a lot more descriptive than they were before. It's essentially a complete re write, really of most of the technical aspects.
       Let's move to the next slide.
       This slide, so, after all these discussions on the mailing list, we had a, an e-mail from Dean Willis, basically, proposing a way forward, where do we go beyond what's in there. I would say, right now, that the technical content of this seems to be fairly stable. I haven't had anybody complain really, anymore about any of the technical aspects of what's in the document. What we have is a lot of people that want to know what we're going to do now, after the basic stuff m did document.
       So Dean basically proceedsd four different ideas. That we would like to get some feedback on
       ( Proposed four ideas.)
       Interestingly enough, I think we are kind of seeing some sort of convergence on some of those. But not everything. So, the first one was some rules that are not really necessarily SIP S related but something for best practice, about using TLS for SIP transport, and explaining that you could still use IP sec if you want to, it's just that it's not SIP S. Okay. That's something that is, that's, that should be a little bit clearer. Okay. That was the first one.
       The second one was, essentially the deposition indication of the last hop exception rule. Okay. when you're using SIP S. So the proposal was to do that, to deprecate the last hop exception.
       The key point is, one and two are dwo different points. Point one has nothing to do with SIP S. Okay. It only has to do with the fact that if you're not using SIP S, you can use other security mechanisms.
       Point two is, if you're using SIP S, you want to deprecate the last hop. The third bullet is, if you really want to do best effort, we actually talk xw this in the draft and I think it would be a clarification of what's in there. But if you're not willing to have calls that fail, because the other end doesn't support SIP S, don't use SIP S, which to me is kind of obvious shs but I guess the proposal would be to make it even more obvious.
       And finally, the one I don't think we have consensus on right now, as far as I can tell, is, if you terminate on on P S D N Gateway specifically, can you use SIP S? Do you consider that your SIP S universe stops at the P S T N Gateway, or do you consider that your SIP S universe, that it, that you're essentially, you cannot use SIP S because you're going to a network that is not as secure as what we're using here? And we had opinions for arguing for both sides on the mailing list.
       Let's move to the next slide, and, which is the last slide. So what's left to be done is examine the slide we just did, the four proposals. Look at the to do list. There's a bunch of minor issues, which in the document I list. If anybody has comment s, comments, let me know. If we need a new mechanism, we need people to be advocates for them. And explain why and make their case for them.
       There's still the issue of deprecating SIP S entirely, which some people have been proposing. If that was to be the case, I think the chair made it very clear, we have to have a pretty good reason to do so.
       And that's about it. I think we can go to the questions.
       NEW SPEAKER: One question on the jabber chat line I'd like to bring in here. If you go back to the, so the question was, does that bullet two mean that all of the hops are going to be TLS? Yes. That's the intent all of the hops are TLS. That means SIP S is a commitment to use TLS end to end.
       The thing that makes the last point in red questionable, so if you can Gateway from SIP S to Gateway P S D N. You can Gateway to SIP, or SIP S to something else. If you believe it is a commitment, hard commitment to use SIP S all the way, then the point in red comes up as the question mark. Thanks.
       NEW SPEAKER: Okay. So, I just want to go back for a second. I think
       ( I don't know what he said.)

       NEW SPEAKER: There are really as far as this goes, two pieces of function nament R nalt that are being semi intertwined in SIP S. One is an instruction from the callly, to the cam ler that I would like you to call me, or you can at least call me. Or I'd like you to, whether you have SIP or SIP S URL. The second one is an instruction to every proxy along the path that it wants you to use TLS. These are coupled together. And the reason is because they're coupled together in something that everybody I am taits.
       I am Tates.
       So I think those are the functionalities that we have to be provided. I don't care. I people say deprecate, it's arguable that the URI scheme provides functionality. But my claim is, and my rationale for this, business card says, there should be some way to look at the business card and know that if he types the thing if in he's going to call me. And with regard to, you know, going way back to the log issue, it's absolutely true that TLS does not give -- it's a bad idea. No. 1. No. 2, you know, this is the key point here is the media, and to make signalling on merely having secure it doesn't give you a right to put a lock or something like that.
       But being able to have a commitment to have security all the way a us you to booth strap your way up to having secure media, that's why it's important to have the functionality.

       NEW SPEAKER: Can we just ask you to be brief, because we're already short of time. Try to be concise.
       NEW SPEAKER: Okay. Going back and forth, now I'm going to think about just take ting whole thing out, because since SIP S, that's bullet four, not take out the whole --
       NEW SPEAKER: Okay.
       NEW SPEAKER: But, unless it's really in a sense, end to end, you know, it's like a non solve able problem. And it being not just to P S T N Gateway but to another IP Gateway. And if it is to a P S T N Gateway, that does terminate to a P S T N phone, then the SIPs promise was kept. And if it's Gateway to another SIP thing, then it's not kept. It's just not solve able.
       NEW SPEAKER: So you're advocating which option.
       NEW SPEAKER: Take it all, just don't mention it at all.
       NEW SPEAKER: What is it?
       NEW SPEAKER: The, don't mention P S T N termination.
       NEW SPEAKER: Okay. What about other protocols that you might Gateway to?
       NEW SPEAKER: It's a non solve able problem.
       (Several people talking.)
       NEW SPEAKER: So you're suggesting delete bullet four?
       NEW SPEAKER: Right.
       NEW SPEAKER: Okay.
       NEW SPEAKER: All because of that, I said all I want to say about four. I'm not going to say anymore. I just wonder about one. Okay. I mean, it sounds great. But this is one of those cases where we keep saying, when we say should, we ought to say what we mean the exceptions are here. I mean, I don't see that we are at all clear what the exceptions might be. And I just don't believe that in most of the time it's going to get done. You know, if it isn't going to be done most of the time, then putting the should in is just holding out a false promise to people.
       NEW SPEAKER: You're suggesting mass something.
       NEW SPEAKER: May.
       NEW SPEAKER: I'm just saying take out one.
       NEW SPEAKER: I want to comment on one and four. I'm Collin jenks. On on one, I think we need to very clearly differentiate between what you need to implement and what you need to use as a general rule, we've tried to get people to implement security but not say how people necessarily use security in protocol s.
       But on four, I think that the commitment, I have a clear phrasing, of what the commitment is, which is, you know, you're going to use tail us all the way to the U A. That's what I think it should be. My U A happens to be a speaker phone and I'm sitting in this room right now and there's a hundred people. SIPs doesn't mean anything about what's going to happen on the other side of that speaker phone or the Gateway or the other side of protocol translator. Hopefully the protocol translator would do reasonable things, but it's impossible to specify beyond that point. It's as far as we can go. If Eckard wants to go and make a secure phone call on his phone, he should use a user interface mechanism. Not typing SIP's in. This is a tool to leverage and build other security mechanisms.
       NEW SPEAKER: Hold on. Don't leave. A question for clarification.
       NEW SPEAKER: Would you say it is a best current practice for an S B C determining the SIP S connection and generate a SIP connection on the other side?
       NEW SPEAKER: I think that one of the most useful features that an S B C vendor could offer today would be the one on edge of an enterprise that could take unsecure phone calls from vendors that hadn't managed to implement all this stuff inside the enterprise and secure it across the internet. I think that's a great thing for people to go build that.
       Now, needless to say, that same thing needs to happen on incoming calls. You know, that's just a pragmatic sort of approach to it. It doesn't matter what we say in the specifications though. I mean, you know, short of us breaking the P S T N, there's no way to solve this. We can't go beyond that, anything we say yobd that is just making ourselves feel great. It's totally meaningsless. So we should not pretend that it means anything beyond what it means to the U A.
       NEW SPEAKER: Hi, this is somebody. I'm a guy who was starting with SIP S. So first, my comment is like, in I N S, they have IP sec between two something. So the use over D L S and IP sec, we are going to provide twice encryption, is that good for us to do that? And on item four, we can know go beyond P S T N. You suggest SIP S can provide, like lock icon for the SIP signalling within the IP domain. Then if that is not the case, then it's just a CV P or some guideline which is not useful.
       NEW SPEAKER: I think that was,
       NEW SPEAKER: We need to cut the Mike after John.
       NEW SPEAKER: Okay. I just first of all, I want to remind everybody who is here, this is not Francois's draft. Anybody here is saying that Francois's draft is controversial.
       NEW SPEAKER: It's Dean at the top.
       NEW SPEAKER: It says Dean's SIP S trial balloon proposal. I just want to make sure we're clear on that before I say anything.
       NEW SPEAKER: But, I think I agree primarily with what everybody else has said and I'm hearth tend with the consensus in the room about one and four.
       The one thing I would say about four, for certain forms of protocol inter working where we're dealing with something going from IP to IP, basically from one to another one, I wouldn't see the harm in having something that was wa CV P have a should level thing to say if there was a comparable mechanism in the protocol, try again, or something like that.
       NEW SPEAKER: Would you fail the call if there's not? Into
       NEW SPEAKER: Yes.
       NEW SPEAKER: Well, okay.
       NEW SPEAKER: So this depends on the design of the Gateway, and the other protocol. But, I think you would certainly want to fail it if that capability was available in the protocol, but not invoked.
       NEW SPEAKER: Okay.
       NEW SPEAKER: Again, I have, I don't have the this massive proposal articulated. But I'm not e opposed to language like that. I don't think it's reasonable to expect the any of this to carry over.
       But yes, no No. 1, please and a softer four.
       NEW SPEAKER: Yes, that's exactly the same opinion I had for the P S T N and the similar network, I think, that's kind of important.
       NEW SPEAKER: Point out that Brian Rosen who is not here today was adamant about point four and P S T N termination.
       NEW SPEAKER: Head dral Caplan, yes, same thing about four, you can change should to might.
       No. 4, yes, there's no question SIP's is SIP's. It's not part of anything else. And you reach the U A S and you reach the U A S. Write a B C P. Go right ahead. But the people who don't want to use SIP's or whatever, ignore the B C P. For an S B C particular, you know, I don't like to talk about specific implementations, but I put it on the list, yes, S B C, as far as I know, most of the S B Cs that do support SIP's, will obviously try to keep it sips, and guess what, if the operator says, no, you can use euse SIP, they will do that. The operator decides, that's the concept.
       So they'll do that. They are a U.S. The UAC from the other side. So that's, again, they will do what they will do. If they're more Rons, they won't try to do that.
       But anyway, so, I don't know the point of a B C P. It's like telling me to write a B C P to show how people write local policy. Is there a B C P for local configuration, I don't understand that.
       For the other slide, to deprecate the whole thing, is that in another slide?
       NEW SPEAKER: I had that in the last slide.
       NEW SPEAKER: I don't think that's appropriate, not only because every RFC this group created has that term in it. I think you only need to deprecate something if it's dangerous and you don't want anybody to do it again. If it's just because nobody uses, it would we deprecate S MIME and a lot of other things too. Leave it and let the market deprecate it.
       NEW SPEAKER: Just one point. What's the point of a B C P?
       NEW SPEAKER: B C Ps actually document operational recommendations, how you, how we think an operator should operate their system. For example, there's a B C P around operating e-mail systems that says, don't be ab open e-mail relay. And what happens is, you have spam and no one will accept e-mail from you anymore.
       NEW SPEAKER: Agreed.
       NEW SPEAKER: One could envision this at the same level of recommendation. I doubt that spam houses set up yet to enforce people who are open SIP S relays, but one could think about that as a possibility. This is an operational recommendation, not a specification of the protocol.
       NEW SPEAKER: I didn't mean it that way. Sorry Dean. I guess, yes, I just seemed to be funny it's like saying, be good. It's like, well, it won't be good. There's no point in telling them to be good.
       (Several people talking.)
       NEW SPEAKER:
       NEW SPEAKER: It's more on the order, if you don't lock your doors, people can wander in through your open door.
       NEW SPEAKER: You think they just do it accidentally, e by misconfiguring.
       NEW SPEAKER: Yes.
       NEW SPEAKER: I'm with you. So S B C is a legitimate device.
       NEW SPEAKER: I can neither confirm or deny the legitimate existence of S B Cs.
       NEW SPEAKER: I just think we need to set a bid insignificant nationaling if we disregard this protocol.
       NEW SPEAKER: John. Wrap the conversation up. It's all yours.
       NEW SPEAKER: John el well. I'm going to speak to point four. And yes, I agree with the majority there. It has to stop at the U A S, if that's the a a SIP Gateway or speaker phone or whatever. I'm just a little bit concerned though, about the fact about user agent case. Particularly what you mentioned, Dean, about well, yes, if a user agent S B C upgrades a SIP request to SIP S, I guess no harm is done. The other way around though, is a bit worse. I send a message request with some pass and it gets back to the user agent and it down grades it to SIP, all the content in that message request now becomes vulnerable. So we don't normally legislate for user agents, and that's the problem.
       NEW SPEAKER: I think the wording that John Peterson had, actually applies here. it a similar network. It's kind of two back to back SIP networks. Seems like a B C P type issue.
       NEW SPEAKER: My assumption this conversation is now the time to close the conversation and
       (Several people talking.)
       NEW SPEAKER: Yes. I will, I think I have a good sense from the room what we heard, one, I think is some level of support. But not that much. Unless -- four I think we have a fairly good consensus, except for one person who is not here. And three is obvious, and two I think is the one that we implicitly, I think people like the idea of deprecating the last hop is kind of what I heard. But we didn't really have a vote or anything on that. What do we do with bullet two, the deposition indication of the last hop.
       NEW SPEAKER: I think we have consensus on pretty much everything, except for the fine print writing of four. And I think there's a fairly strong suggestions that No. 1 is completely out of place and just echoes what's already in 3261. So I think we can reduce No. 4 to a should level and explain the issues and do away with No. 1 and I think everybody except Brian Rosen will be happy.
       NEW SPEAKER: Okay.
       NEW SPEAKER:
       NEW SPEAKER: Fifteen minutes.
       NEW SPEAKER: I need 20.
       NEW SPEAKER: So let me talk about GRUU. For those of you, you know, this is the funny thing, go check out WWW Dot GRUU.Com. None of us know who runs this site. It just has a picture of this stone wall and says GRUU. We thought it was quite funny and it turns out, next slide, you can actually make some pretty good reasons why GRUU is like a whale. And it's, you know, okay. It's big and heavy, we know that one. It seems like it's been around for a long time. Looks friendly but it can swallow you whole. That's true, I know that well. Kind of cute, but not really. Widely misunderstood. Lives a really long time. Continues to consume resources to support its huge size. Blows hot air, everyone's in a while, every four months, approximately. Rumored to be Intel jenlt but cannot be confirmed and can get beached without moving very lingt.
It's scary how well that works.
       Anyway, what happened in a lot of changes. The view vee team was assembled and many significant comments were raised and almost a complete re write of the document. It lost some weight in the process. I've been on a weight loss binge with these things, re write them at the end to sort of clean them up from the accumulated garbage you've had over the years. I think it's hopefully clear. It is a hard document to follow.
       Next slide. So there's a bunch of high level changes. And that's the only thing I'll be able to cover. Temporary GRUU is the biggest thing. Okay. And the main issue is this. GRUU didn't address privacy at all. In fact, it made RFC 3261 even worse when used. So a comment got raised late in the process here, that there were European, the European can community as a general rule, which has tighter requirements around privacy, would pretty much make GRUU unusable for them by itself. That's nice, let me know when you finish it with the privacy neck miss many would be the conclusion. So when you have a draft that is undeploy able with without a feature, it tells you you have a problem.
       So the desire was to adjust enough privacy to meet RFC 3261 equivalence. We debated about that. But that was the approach.
       Next slide. The idea with this temporary GRUU is when you register, you get two GRUUs back. You a temporary grew and public GRUU. The public GRUU is the same GRUU that you know and love that we've had for the last 12 revisions of this document, whatever it is. And you've got this new temporary GRUU and they're both parameters in the contact header field.
       Every time you refresh your registration, your public GRUU is the same, but a in temporary GRUU is given to you. Now, this doesn't invalidate the previous one. It's sort of here, have another. Have another. You keep getting more and more of these things. Every one of them is different. They have all these nice, you know, Eckard text generated, I don't know, what, how do say it. Crypt graphically random, uncorrelate able with each other and to the A O R and they all remain valid.
       However, once your registration expires, so you turn off your phone, you time out, you forcefully Dee register, at this point the temporary ones ee evaporate and the only one that remains valid is the public one, as has always been the case.
       Next slide.
       So, the U A can do what it wants with these thing. It can remember none of them, it can remember one of them, so if only wants mild privacy. It can remember a whole bunch of them and then use oo different one in every column. So if you wanted uncorrelate able calls together, you use a different one in every call.
       There is no invalidation mechanism. There is no way to go to the server and say, turn off that GRUU, I don't want it anymore. Okay. The reasoning was, if the U A does not want, this is a spam issue, primarily. So if I call, you know, Dean, and he keeps calling me back and bugging me, because he's got my contact, I might want to, you know, reject his calls automatically. You can still do that in the user agent. And if the user agent uses a different temporary GRUU for I ever every call, I can put calls can on the black list and then reject them.
       We also have a mechanism that's in working group last call, the consent framework, that tells the server to reject the call. It will actually work with no change for this function to allow you to tell your proxy to reject incoming calls targeted to your anonymous group. We also have those solutions.
       Next slide. So, this is the big contentious topic. I should stop here and we should start debate on on this. Re name the parameters and removed SIPs and sd some other stuff and removed grid. And I'd like to entertain discussion or comments on the anonymous GRUU stuff or the other things too.
       NEW SPEAKER: So, I'm okay with the GRUU stuff, it makes a lot of sense to me, and reducees complexity. But for re naming it, we're almost done with GRUU in Montreal, and I don't know how many people have implemented GRUU right now, but I think people have. And the parameter re naming makes it a little harder. Quite a bit harder, depending on how you look at it, for making it backward compatibe with the previous draft.
       NEW SPEAKER: Right. IETF does not guarantee backwards compatibility of RFCs let alone drafts. My general rule of thumb is, I don't care about implementation. I care about deployment. Are you an active deployment with GRUU.
       NEW SPEAKER: We will be, but not now. We don't have cycles for this right now.
       NEW SPEAKER: I feel very strongly about the parameter re naming and we have a general practice that I think we have it documented in the SIP guideline stuff to document Ed stores, that we try not to have collisions between URI parameters and header parameters.
       You know, it just makes trouble for us in the long run.
       NEW SPEAKER: I guess, I'm curious to know what other people think.
       NEW SPEAKER: Okay.
       NEW SPEAKER: Does anyone else want to speak. I don't want to take a hum or anything, if you have any comments on liking or not liking that.
       NEW SPEAKER: I'm Jonathan. Yes, well, I like, yeshtion I probably instigated this and I do like this. My reasoning is somewhat like Robert's, I hate having things that have side effects that drive me nuts. I want everything to do one thing and this is a much better job of that.
       NEW SPEAKER: Scott Lawrence. I have one nit that I think temporary is the wrong name. And I think you had a side comment somewhere in the draft.
       NEW SPEAKER: It used to be called anonymous in the other GRUU circulated among the design team. Because it's not really anonymous. I mean, it's, you know, so what,
       (Several people talking.)
       NEW SPEAKER: I really don't care, to be honest.
       NEW SPEAKER: And I'll be glad to sort of sit down and brainstorm other names with you. But the particular thing that I don't like about the name temporary is that it's actually less temporary
       NEW SPEAKER: Right.
       NEW SPEAKER: Than the other thing, because it survives to the end of the expiration of dash
       NEW SPEAKER: No. It's less, it's definitely less permanent than the regular GRUU. The regular GRUU lasts like forever. This thing lasts until your registration expires.
       NEW SPEAKER: It lasts until all refreshes of the registration expire.
       NEW SPEAKER: Right. So I view there as having a registration inter val, which starts when I first register a contact. It persists while I refresh and dies when it it ir expires or I forcefully expire it with a zero registration. That window, which can be a very long time, but is always shorter than the public GRUU lifetime. Is a temporary GRUU lifetime.
       NEW SPEAKER: It's infinite.
       (Several people talking.)
       NEW SPEAKER: Public is near infinite as you can make it. Within the realm of possibility. Whereas temporary GRUU is just to turn the power off.
       NEW SPEAKER: You can make it infinite.
       NEW SPEAKER: Which one?
       NEW SPEAKER: The puck GRUU.
       (Several people talking.)
       NEW SPEAKER: If you even code it
       NEW SPEAKER: Can we keep the comments to the general re naming and rather than trying to find a name.
       NEW SPEAKER: I support the re naming but I think it might be nice to come up with names that are more appropriate.
       NEW SPEAKER: I'd be happy to put it back to a non GRUU, which is what I had it before.
       NEW SPEAKER: That's its purpose.
       NEW SPEAKER: I think there was something I have objections
       (Several people talking.)
       NEW SPEAKER: It did.
       NEW SPEAKER: Because some people didn't feel it was fully a anonymous.
       NEW SPEAKER: Right.
       NEW SPEAKER: Because you still have to call back.
       NEW SPEAKER: Why not private?
       NEW SPEAKER: I mean, I'm notd we hadd to temporary, but I think we're going to get push back the other way.
       NEW SPEAKER: Private GRUU or priv.
       NEW SPEAKER: There you go. That sounds better.
       NEW SPEAKER: Public private.
       NEW SPEAKER: So
       (Several people talking.)
       NEW SPEAKER: Before we run out of time, I would, there's the whole mechanism of doing this. There's been strong -- where is he anyway, has he been escorted out of the room. There have been objections on this mechanism, if no one is going to comment I'd like a hum at least, to see if people are comfortable with this mechanism or if you have any questions, please say so. I know Scott you had a lot of questions and I have not responded to your mail yet. Please go if it's fot clear.
       NEW SPEAKER: Actually, the most important one is
       NEW SPEAKER: Mike.
       NEW SPEAKER: Sorry.
       NEW SPEAKER: I was actually going back to my chair to look this up. But, is it required that I always provide both?
       NEW SPEAKER: Yes.
       NEW SPEAKER: No, no, sorry. The current draft is at should strength for the registrar to provide both and there was controversy on on this too. I tried to accommodate domain policies that said we're not providing that as part of our role and we don't want to deal with this. So it should for both of them. So you could omit one or the other. In the spec a must strength requires one or neither being present in the registry response.
       NEW SPEAKER: Okay. I guess, I would have preferred to see that written as the registrar must provide at least one or the other, and may provide both.
       NEW SPEAKER: We've never had that rule. It's always been should provide a GRUU for the same reason, even when we just had one, that, we don't want to make a mechanism that I'm forcing the server to do this stuff.
       NEW SPEAKER: Oh, I guess there's that. Right.
       NEW SPEAKER: One question about the previous slide where you have the flow, this one. So, the temporary GRUU is related until registration expires, enduring registration, even, during registration, I'm assuming from that, I believe that at some point in time, you can register, maybe, or one with a lot of temporary rules.
       NEW SPEAKER: So there's no, you would never store these. And the a appendix of the document gives an algorithm for stateless computation. There's an even better one that's not in the document that requires you to store one integer in the database per contact and that is all you need and you can generate and perform all the required functions for an infinite number of GRUU. The reason we wanted the long lifetime, we don't want the GRUU to expire m the middle of a call. And the easiest way to guarantee that, when your registration expires, we've always had the requirement that you had to registration active, you know, for, with GRUU to have a call. So we're not changing that with this mechanism and it's really not a new burden on the server.
       NEW SPEAKER: Okay. Yes, whatever algorithm you used it must be such that a third party, if it finds that one GRUU is no longer accepted, it can't itself calculate a later GRUU.
       NEW SPEAKER: Right. So the general algorithm is you basically take a bunch of stuff and encrypt it with a bunch of stuff of the key of the server.
       NEW SPEAKER: Do you wantd me to do the hum or you to do it?
       NEW SPEAKER: Let me just give a quick status of where this document is at. Basically, if people are positive with this version of the document, we are going to straight into working group last call, on on the current version. So, there is still time to comment on the document, if there are better things and basically, things like that. But is this document generally.
       NEW SPEAKER: All those who are happy with the current privacy anonymity mechanism in this GRUU document, please hum.
       ( huming. )
       NEW SPEAKER: All those who are not kovt able with it
       ( Silence. )
       NEW SPEAKER: I'd like to ask another question, just to be sure. I'm going to ask the same question, but there's three answers, I'm comfortable, I'm not comfortable or I don't know enough to have an opinion or I haven't studied it or not sure. All those who are comfortable with it.
       ( hum humming. )
       NEW SPEAKER: All those unkovt able with it. All those who aren't sure.
       ( Humming. )
       NEW SPEAKER: I had a feeling.
       I knew that was coming.
       All right. So I don't know what to do about that one.
       NEW SPEAKER: Can you call that, Keith?
       NEW SPEAKER: Well,
       NEW SPEAKER: What's the --
       NEW SPEAKER: First of all, people seem to be robl blee positive that the privacy action should be in the document. I think people still need more time to think about it, is the conclusion I got, from the second hum. Which presumably happened during that working group last call period, which will be in the next two weeks. So please
       NEW SPEAKER: I do wanltd one more minute on the U A user route stuff.
       NEW SPEAKER: I do have wunl question, like, regarding the previous answer from, the previous draft, so I want, can you get a hum on how many people are comfortable with the names?
       NEW SPEAKER: Sure. So, regarding the change in the parameter names, hum if you have a concern with changing the parameter names this this document.
       ( Humming. )
       NEW SPEAKER: Hum if you have no, you don't care that we change the parameter name in the document or you're fine with it.
       ( Humming. )
       NEW SPEAKER: Okay.
       NEW SPEAKER: Third hum.
       NEW SPEAKER: Do you want to do a third hum.
       NEW SPEAKER: That was ambiguous. So, are you proposing that we keep the names as RN GRUU 11.
       NEW SPEAKER: Restate the question.
       NEW SPEAKER: Okay.
       NEW SPEAKER: The question was, all those in favor of keep -- the question is, all those, dash who is in favor of keeping the parameters in GRUU 11 and there's three answers, yes I'm in favor, no, I'm opposed or three I have no opinion or don't understand. Okay.
       So, all those in favor of keeping the parameter names that are in GRUU 11, hum.
       ( Humming. )
       NEW SPEAKER: All those opposed.
       ( Humming. )
       NEW SPEAKER: Try that again.
       NEW SPEAKER: And all those who don't care or have no opinion.
       ( Humming. brav paragraph )
       NEW SPEAKER: I knew that was coming.
       NEW SPEAKER: How do you call that?
       NEW SPEAKER:
       NEW SPEAKER: Call it, chairs. What's your call, chairs?
       NEW SPEAKER:
       NEW SPEAKER: The general consensus was in favor of the GRUU 11. And there was a small minority in favor of GRUU ten and a lot of people don't care.
       NEW SPEAKER: It seems that way.
       NEW SPEAKER: Okay. Let me do the two minute grid. Next slide.
       Next slide.

       NEW SPEAKER: I removed grid. Why did I do that. After I heard a comment the general problem has nothing to do with GRUU at all, but A O R, the use case would be I create a cookie, put it in my A O R, give it out and get it back. So rather than solve this in GRUU, we created general mechanism for it. Next slide.
       Okay. So, that new mechanism is U A use route. I want to go to U A use route now, that's all my time. Right. So the general idea with U A use route is really easy, okay. When send an invite to my A O R and it arrives at my home authoritative proxy and look it up, gets my contact. Instead of rewriting the request URI, obliterating it, in any parameters it might have had, it just keeps it, and it takes that contact and it puts it in the route header. If there was a path, it puts it at the bottom of the route.
       So, next slide. So that's what this looks like. I register, here's my A O R, here's my contact. Invite shows up, I gave that guy a cookie as a parameter of my invite, this is the home proxy, it keeps the request URI and put the top most route in this case as -- I like this, it unifies the whole mechanism with loose writing with user agents. That's the name.
       Next slide. Almost done. It just also happens to solve like 5 other problems we've always had. It allows you to determine the alias by which you were reached. It allows you to have limited use addresses for anti spam. It provides sub addressing on I S D N style, multiple end points in a residence. It is also really helpful with all the service interaction drafts to prevent service parameters from being klob betterd and clobberd. And one of the free phone numbers it helps you know that you dialed it all the way through. There's all these nice things that come with the mechanism.
       Do you want to take a hum on this?
       NEW SPEAKER: No. We have two or three minutes to discuss this in conclusion. So any hums we'll take at Friday's session. I've been asked to point out to people that there is a previously unscheduled A TV section. So if you're tracking A V T session. You may be interested in that. Get out of here, because there's six minutes for the next group to come in.