[05:10:06] --- bman has joined
[06:31:23] --- bman has left
[07:42:35] --- Bob has joined
[07:42:50] --- Bob has left
[08:57:59] --- bman has joined
[08:58:03] --- bman has left
[11:51:54] --- xmlscott has joined
[12:10:05] --- xmlscott has left
[12:36:08] --- richard.stastny has joined
[12:36:10] --- alexis has joined
[12:36:57] --- renee has joined
[12:37:43] --- richard.barnes has joined
[12:38:03] --- teemuk has joined
[12:38:51] --- scribe has joined
[12:39:30] --- isudo has joined
[12:39:41] <scribe> SIP session, IETF, March 20, 2007
[12:39:45] <scribe> NEW SPEAKER: This microphone works. All right. Anyone
[12:39:51] <scribe> in the room trying to talk faster than Eric will be summarily
[12:39:52] <scribe> asked to leave.
[12:39:57] <scribe> NEW SPEAKER: It's not possible. NEW SPEAKER: Not
[12:39:59] <scribe> succeeding in talking faster, just trying.
[12:40:03] --- jonlennox has joined
[12:40:06] <scribe> So I would like everybody,
[12:40:12] <scribe> especially present presenters, to be very attentive to the
[12:40:16] <scribe> timing of their speech and one of our wonderful volunteer note
[12:40:25] <scribe> takers is not an English speaker, and I do have
[12:40:30] <scribe> an unnamed power adapter, in case anyone thinks they lost it.
[12:40:32] <scribe> If you can identify it, I can give it back to you.
[12:40:36] <scribe> A couple of points, when you go to the microphone, please
[12:40:42] <scribe> state your name clearly and distinctly. NEW SPEAKER:
[12:40:45] <scribe> And just adding on that, NEW SPEAKER: Name. NEW SPEAKER:
[12:40:48] <scribe> Expense ser Roberts. That you
[12:40:54] <scribe> Spence ser. NEW SPEAKER: Is that Spence ser talking? NEW SPEAKER:
[12:40:58] <scribe> Yes. And the verbatim transcription has your name if you say
[12:41:01] --- kafka-j31415927 has joined
[12:41:01] <scribe> your name, you're just new speaker if you don't.
[12:41:09] --- frodek has joined
[12:41:17] --- Jabber-Wile has joined
[12:41:21] --- ttfr has joined
[12:42:21] --- marc.bailly has joined
[12:42:24] --- Alan H has joined
[12:43:16] --- marc.bailly has left: Lost connection
[12:43:35] <scribe> NEW SPEAKER: Okay. I draw your attention to the now
[12:43:38] <scribe> working projector. This is our
[12:43:42] <scribe> current a general agenda. We have three topics on today's
[12:43:45] --- richard.stastny has left: Replaced by new connection
[12:43:46] <scribe> discussion, ice option tag, changes to GRUU be the revision
[12:43:51] <scribe> process sfoor 3261 and other set specifications, anybody want
[12:43:51] <Alan H> Speaker is Dean Willis
[12:43:54] <scribe> to make changes to this agenda?
[12:43:58] --- richard.stastny has joined
[12:43:58] <scribe> Oh ki. Since nobody screamed, agenda
[12:44:01] <scribe> stands. This will be our second session agenda, of course
[12:44:04] <scribe> it may change by the time we get to the second session, but
[12:44:06] <scribe> it's a bit busy as you can see.
[12:44:15] --- worley has joined
[12:44:26] <scribe> NEW SPEAKER: The second session, the items on the agenda,
[12:44:30] <scribe> if time permits, the main priority is to get the
[12:44:34] <Alan H> Speaker is Keith Drague
[12:44:34] <scribe> SIPss guidelines and the outbound document discussed and the
[12:44:37] <scribe> other documents only get discussed if there's sufficient time
[12:44:37] <scribe> after that.
[12:44:42] <scribe> NEW SPEAKER: A couple of announce ments. We'd like to
[12:44:46] <scribe> point out basically two drafts that are kicking around, that may
[12:44:50] <scribe> actually turn out to be quite important, and at least we owe
[12:44:52] --- bhoeneis has joined
[12:44:53] <scribe> the respect of giving them a good reading. The first one is the certificate
[12:45:03] <scribe> based ought authentication draft. It, digest
[12:45:07] <scribe> authentication, has some weaknesses and it would be very
[12:45:11] <scribe> nice to have some although tern tivs, so please give this a
[12:45:12] <scribe> read.
[12:45:18] <scribe> it a lot stronger than digest and we hope we can make it
[12:45:21] <scribe> work. The other thing that's going on, or, people are
[12:45:27] <scribe> starting to worry about spam over internet telephony, and
[12:45:31] <scribe> there's a bunch of IP's out there, internet drafts on it right
[12:45:35] <scribe> now. There's now a mailing list for this discussion, so if
[12:45:40] <scribe> you're interested in spam over internet telephony, the list
[12:45:42] --- dp has joined
[12:45:43] <scribe> is, the address is at the bottom of the slide here. These
[12:45:47] <scribe> slides by the way are on the IETF meeting materials server,
[12:45:51] <scribe> and on the soft armor server if you want to download any of them.
[12:45:58] <scribe> Jonathan.
[12:46:23] --- marc.bailly has joined
[12:46:37] <scribe> NEW SPEAKER: Okay. We already decided to alter the
[12:46:41] <scribe> agenda, I changed the order of the GRUU and the ice option tag
[12:46:43] <scribe> discussion. NEW SPEAKER: Sorry, I didn't even
[12:46:43] <scribe> notice.
[12:46:51] <scribe> Okay. So, I'm here to talk about GRUU, again. For the
[12:46:52] <scribe> last time. Really this time.
[12:46:58] <scribe> NEW SPEAKER: Promise? NEW SPEAKER: Next slide.
[12:47:03] <scribe> So, there were some changes from dash 11, for the most part,
[12:47:08] <scribe> based on minor comments, so the minor change
[12:47:09] --- dwillis@jabber.org has joined
[12:47:12] <scribe> I made, it's just a little bug fix, there were some
[12:47:16] <scribe> references to include GRUU in dialogue forms and
[12:47:20] <scribe> requests and responses, including provisional response to
[12:47:27] <scribe> subscribe for example, and the nit fix draft says you're not supposed to do
[12:47:29] <scribe> that so I just removed that example reference.
[12:47:38] <scribe> I deeply went through Dale's GRUU implementing draft.
[12:47:41] <scribe> Which, and I tried to make sure there was nothing in there that
[12:47:45] <scribe> didn't need to belong in GRUU instead. And I found it
[12:47:49] <scribe> somewhat odd we have a draft on how to implement and clarify
[12:47:52] <scribe> GRUU while GRUU was still an internet draft. I mean, if we
[12:47:55] <scribe> need to clarify it, we should actually clarify it.
[12:48:01] <scribe> So I took out of there a couple of things, one of them which
[12:48:04] <scribe> had been an open issue for a while, was a recommendation that
[12:48:09] <scribe> if a URI has a grew GRUU and you need to reach it, you
[12:48:12] <scribe> don't need to play all of these games that have been discussed in
[12:48:14] --- richard.barnes has left
[12:48:17] <scribe> the cc transfer and other drafts to try to reach that end point.
[12:48:19] <scribe> It should just work. So just do that.
[12:48:23] <scribe> And then Dale had a draft about don't muk with the GRUU, it's
[12:48:27] <scribe> the URI you've been given, it's opaque and you should just
[12:48:30] <scribe> use it and not try to remove or add parameters and all
[12:48:33] <scribe> kinds of stuff. It's, you know, yes? NEW SPEAKER:
[12:48:38] <scribe> So, I actually have some issue with. I think there are
[12:48:41] <Alan H> speaker is Adam Roach
[12:48:43] <scribe> probably certain times when you want to have parameters.
[12:48:47] <scribe> Sorry. Adam roach. In particular, the first one that
[12:48:53] <scribe> comes to mind is in focus. If I am acting as a user agent.
[12:48:54] --- xmlscott has joined
[12:48:57] <scribe> I want to be able to add focus to it. And I should be able
[12:49:00] <scribe> to do that unilaterally. And there's a good chance that
[12:49:03] <scribe> future extensions will have similar parameters to do exactly
[12:49:04] <scribe> the same thing. NEW SPEAKER: Right. NEW SPEAKER:
[12:49:09] <scribe> So I, I think that probably needs to be revised. NEW SPEAKER:
[12:49:13] <scribe> Isn't is focus ahead err contact parameter, not a URI parameter?
[12:49:17] <scribe> NEW SPEAKER: No. It's a URI parameter. NEW SPEAKER:
[12:49:22] <scribe> Paul? Someone, can we verify it? I could have sworn
[12:49:23] --- marc.bailly has left: Replaced by new connection.
[12:49:25] <scribe> it's a call E cap. NEW SPEAKER: It's a
[12:49:26] <scribe> call E cap. (Several people talking.) NEW SPEAKER:
[12:49:33] <scribe> Reference? NEW SPEAKER: Yes, I'll have to double check
[12:49:33] <scribe> that.
[12:49:38] <scribe> However, it is the kind of thing you would --
[12:49:39] --- marc.bailly has joined
[12:49:42] <scribe> NEW SPEAKER: Hang on. So I mean, we don't have a lot
[12:49:45] <scribe> of other URI parameters. What other example would you give?
[12:49:48] <scribe> The thing I was worried about was people saying, oh, you
[12:49:52] <scribe> know, I've got a URI with transport equal U D P. I don't
[12:49:57] <scribe> like that, I think they should use TCP. You can't remove
[12:50:00] <scribe> that, because the URI terminates on the proxy server, not
[12:50:03] <scribe> you. You dpont get do do that. NEW SPEAKER: Right. NEW SPEAKER:
[12:50:06] <scribe> So that came up on the list, somebody wanted to be able to
[12:50:08] <scribe> do that and I said no no, you can't. NEW SPEAKER:
[12:50:11] <scribe> And I saw that e-mail and I figured that was the motivation for this.
[12:50:15] <scribe> So what I would say you probably want to specific sklee
[12:50:18] <scribe> disallow that. NEW SPEAKER: So, give an L R, you
[12:50:21] <scribe> shund muk with L R. NEW SPEAKER: So the other type of thing,
[12:50:25] <scribe> yes, so, it's the unoh known parameters I'm
[12:50:29] <scribe> concerned about here. If for example, we determine we need
[12:50:29] --- avwijk has joined
[12:50:32] <scribe> some sort of a cookie. There was previously the grid
[12:50:36] <scribe> functionality present here. And until the new text was added
[12:50:39] <scribe> you could actually unilaterally put in a parameter, that
[12:50:44] <scribe> came back to you, that you could use for the same purposes of
[12:50:48] <scribe> grid could originally be used. Now that type of usage is
[12:50:51] <scribe> normatively prohibited. Which means even if you decide you
[12:50:55] <scribe> want to do it in the standard way, the draft specifies how to
[12:50:57] <scribe> do this cookie behavior. Then you're going to run into
[12:51:01] <scribe> problems. NEW SPEAKER: That's a good point. U A use
[12:51:04] <scribe> route does dwpd on add being your own parameter. NEW SPEAKER:
[12:51:09] <scribe> I think the golt here was to disallow muking with known
[12:51:11] --- ben has joined
[12:51:12] <scribe> parameters that would be problematic to muk with. It might
[12:51:16] <scribe> be worth calling out what those are, by the behavior.
[12:51:20] <scribe> Because it's not terminating on U. Don't change parameters
[12:51:24] <scribe> that affect how the proxy has to behave. But things that
[12:51:27] <scribe> don't change how the proxy has to behave. That should be fair
[12:51:29] <scribe> game. NEW SPEAKER: Point taken. I agree, we'll
[12:51:34] <scribe> make that change. And I'll go through the existing URI
[12:51:36] <scribe> parameters and make sure that it's a coherent thing.
[12:51:44] <scribe> Okay. So, somewhat bigger change was Eckard wrote an
[12:51:47] <scribe> excellent draft on stateless tokens, that describes how to
[12:51:51] <scribe> the take a string, and create a token that you you can give to
[12:51:54] <scribe> somebody, and that they can give back to you, and you can make
[12:51:57] <scribe> sure they didn't muk with it and you can make sure they can
[12:51:57] --- christian has joined
[12:52:02] <scribe> understand it, and have all the security properties that we desire from the
[12:52:02] <scribe> tokens.
[12:52:03] <dwillis@jabber.org> Eckard == EKR, Eric Rescorla
[12:52:07] <scribe> So instead of every protocol having to do like what GRUU did and
[12:52:12] <scribe> define and ask Eckard to write the text, Eckard instead basically
[12:52:16] <scribe> wrote the draft that we can just reference. So, I went ahead and
[12:52:19] <scribe> referenced that. It's an informative reference. Because
[12:52:24] <scribe> the entire procedure is entirely informative in an appendix.
[12:52:28] <scribe> And I don't know, maybe one of the A Ds can comment on the status
[12:52:32] <scribe> of that document. Or Eckard himself, whether it's going to
[12:52:35] <scribe> go through as an individual, if it's just going to die, we
[12:52:40] <scribe> should definitely, you know, it's kind of silly, but --
[12:52:47] <scribe> NEW SPEAKER: Yes, are you the A D. NEW SPEAKER: Who
[12:52:47] <scribe> are you are sth
[12:52:50] <scribe> NEW SPEAKER: Eric. NEW SPEAKER: The stateless
[12:52:57] <scribe> guy. So I've, I sort of chatted with the A Ds and it
[12:53:02] <scribe> seemed like there was a fair amount of interest in moving the document
[12:53:05] <scribe> forward. I think we'll move forward somehow, the question
[12:53:08] <scribe> whether it gets into some working group, or in submission, I'm
[12:53:12] <scribe> not sure. I really thought this was going over preference
[12:53:16] <scribe> standards draft and you pointed out that it could be on on
[12:53:19] <scribe> another reference, and so it may, if we don't use the
[12:53:21] <scribe> standards track, it's easy to get through. NEW SPEAKER:
[12:53:25] <scribe> I think it could be an informative reference too. The spec
[12:53:28] --- hb47713 has joined
[12:53:28] <scribe> itself could be informative. NEW SPEAKER: The only
[12:53:31] <scribe> question is, are there other documents that have informative
[12:53:34] <scribe> reference. Maybe the A D can comment on that. NEW SPEAKER:
[12:53:38] <scribe> We need to go talk dash there's been some discussion on A Ds
[12:53:41] <scribe> on it and we want to move forward one way or another. We prefer
[12:53:45] <scribe> it to go as standards track, regardless of what this needs,
[12:53:48] <scribe> and we'll figure out a way to move that forward. Usually A
[12:53:53] <scribe> Ds answer, but we don't know yet. NEW SPEAKER: That
[12:53:55] --- ft has joined
[12:53:57] --- bpenfield has joined
[12:53:59] <scribe> was cull 11 jenks Collin jenks speaking. NEW SPEAKER:
[12:54:03] <scribe> I like the idea of referencing. Rather than
[12:54:06] <scribe> littering this document with this thing which other documents will have
[12:54:10] <scribe> to do. So, I put that in. And that had some, sort of a late
[12:54:14] <scribe> add, it was discussed on the list. But no one objected and
[12:54:16] <scribe> Eckard and I thought it was a a good idea.
[12:54:21] <scribe> Next slide. The biggest change and this has been an issue for a
[12:54:25] <scribe> while, that we've sort of only been zeroing in on the solution,
[12:54:29] <scribe> is this race condition. Folks will recall that we had this
[12:54:33] <scribe> temp GRUU that are sort of a anonymous dial GRUUs
[12:54:36] <scribe> that the server gives to you. And they accumulate. So
[12:54:41] <scribe> when you create a registration, you'll get temp GRUU and when
[12:54:45] <scribe> you refresh you'll get another one and all of the previous ones
[12:54:49] <scribe> remain valid until your registration lapses, so you turn off your
[12:54:53] <scribe> laptop, power down your cell phone, registration expires or
[12:54:56] <scribe> you forcefully expire it. All of those things go away.
[12:55:00] <scribe> So essentially, the client needs to know which temp GRUU are
[12:55:04] <scribe> currently valid to match the ones the server believes are
[12:55:09] <scribe> currently valid, it's a synchronization problem. In the
[12:55:12] <scribe> normal use case it's trivial. The client knows
[12:55:17] <scribe> when it's a active and when it lapses, as long as you don't
[12:55:22] <scribe> stup piddly wait until the very last second to renew the
[12:55:24] <scribe> registrations you'll be fine.
[12:55:29] <scribe> However, Paul duing a nice deep whole in this, and point tetd out that there
[12:55:32] <scribe> is a case where, there is a problem. A bunch of cases,
[12:55:35] <scribe> but one that was particularly problematic. And that's here.
[12:55:39] <scribe> So, the registrar basically changes the expiration, so we
[12:55:42] <scribe> have this capability, for registrars to
[12:55:46] <scribe> forcefully expire registrations. It's used for example, in instant
[12:55:52] <scribe> message, to for force a re authentication or boot a phone off the
[12:55:57] <scribe> network, so we have a rej ee venlt package the that allows the
[12:56:00] <scribe> client to find out about sich events.
[12:56:03] <scribe> So if the server wants to forsz a registration,
[12:56:08] <scribe> the client would be subscribed to rej event and saying it's registration
[12:56:11] <scribe> lapses in ten seconds, you have to re register right now.
[12:56:15] <scribe> And there's states and events in rej event that have been
[12:56:16] <scribe> thereto support that all along.
[12:56:19] <scribe> So what happens in this case, the client registers and gets a
[12:56:24] <scribe> 200 okay. At some point the registrar decides to change the
[12:56:30] <scribe> registration from 5 seconds from now to force a reroute. That comes in
[12:56:32] <scribe> a notify and we're okay with that. And then the client
[12:56:35] <scribe> quickly re registers. Hears the race.
[12:56:39] <scribe> The reg star, I need my pointer.
[12:56:57] <scribe> the registrar is going to over, here, expire the
[12:56:59] <scribe> registration, and the register will be refreshed when this
[12:57:04] <scribe> arrives. So it could either arrive before the expiration or after the
[12:57:08] <scribe> expiration. If it arrives before the expiration, that's
[12:57:09] --- worley has left: Replaced by new connection
[12:57:13] <scribe> great, there's no lapse in the registration. All previous
[12:57:18] <scribe> temp GRUU remain valid. If it arrives after the
[12:57:22] <scribe> expiration, there was a brief lapse, the registration
[12:57:25] <scribe> expired and this is not a refresh, this is a brand new
[12:57:27] <scribe> registration and all the temp GRUU will go away.
[12:57:31] <scribe> And so, the problem is, when the client gets a 200 okay to
[12:57:35] <scribe> this, how does it know which happened. Initially we thought,
[12:57:40] <scribe> oh, it will know when the notify shows up from the rej info.
[12:57:45] <scribe> The problem is this depends entirely on how the registrar
[12:57:49] <scribe> constructs it. fw it does the smart thing, and doesn't send
[12:57:53] <scribe> updates on every transient event, there's nothing that says
[12:57:58] <scribe> it has to send a notify during this brief lapse, it may only send
[12:58:01] <scribe> the notify on the final state which is your registration is active.
[12:58:05] <scribe> So, the notify comes, and it says you have an active
[12:58:08] <scribe> registration that expires in 3600 seconds. How does the
[12:58:13] <scribe> client know? Well, we could require that reg strars always
[12:58:17] <scribe> send a notify for every single event. But what happens if it
[12:58:21] <scribe> gets lost? Or what happens if somebody gets confuse dz? I
[12:58:25] <scribe> mean, this is a state synchronization problem. How do we
[12:58:30] <scribe> guarantee that rej info tnlt can give me confidence that my
[12:58:34] <scribe> view on the temp GRUU matches my server's view on the temp
[12:58:37] <scribe> GRUU and requiring every message to be dmrivrd from the
[12:58:39] <scribe> beginning of dime is not the right way to do that.
[12:58:40] --- worley has joined
[12:58:45] <scribe> I'd like for a way for the client to wake up at any moment and say,
[12:58:47] <scribe> I need to check. I'm not sure. So that's the problem.
[12:58:51] <scribe> Next slide. NEW SPEAKER: I know, this was going to
[12:58:55] <scribe> run over. And so we need to fix that, next slide. I
[12:58:55] <scribe> already said this.
[12:58:59] <scribe> So the solution that's in GRUU 12, much of which is actually in
[12:59:02] <scribe> rej ee venlt or will be when it gets put in there, that
[12:59:06] <scribe> didn't get done. If the server modifies the expiration times
[12:59:10] <scribe> it has to implement rej ee venlt and the GRUU extension. So
[12:59:14] <scribe> if you're a registrar that supports GRUU, you
[12:59:18] <scribe> also have to do GRUU Reggie vent. The same happens with the
[12:59:23] <scribe> client. If you support reg, event, you must also support
[12:59:24] --- dwillis@jabber.org has left
[12:59:29] <scribe> GRUU reg, event. Which makes sense. The rej ee venlts
[12:59:31] <scribe> contain the with a given call I D. Okay.
[12:59:37] <scribe> That's important. So, because these notifies contain the cc dha
[12:59:38] --- dwillis@jabber.org has joined
[12:59:41] <scribe> says, hey, I as the registrar when I
[12:59:46] <scribe> first created this with the caller I D. This is the C
[12:59:50] <scribe> seek, and that doesn't change as you re register, only when you create
[12:59:55] <scribe> a new one. And the C seek is provided by the client. So it
[12:59:57] <scribe> knows from its registers, all of the
[13:00:00] <scribe> registers it sent since that C seek, it knows what they
[13:00:04] <scribe> are, and it knows what temp grew it learned from them.
[13:00:07] <scribe> So at any point, this notification will tell the client
[13:00:11] <scribe> exactly which temp GRUU it currently has, are seen as valid by
[13:00:13] <scribe> the ver ver.
[13:00:19] <scribe> The caller I did D is in there is because C seek was from the
[13:00:23] <scribe> call I D. As a consequence of that, if the caller changes the
[13:00:27] <scribe> caller I D, the temp GRUU have to be expired. So that's
[13:00:29] <scribe> where things get interesting. Next slide.
[13:00:33] <scribe> So a side effect of the required solution to this problem is we
[13:00:36] <scribe> gained a sfeet feature. And people should be
[13:00:42] <scribe> aware of this. It was an actual feature and people asked ask for
[13:00:46] <scribe> it. And a client can now forcefully expire all of its
[13:00:53] <scribe> temporary GRUU with a new call I D and opposite obviously a new
[13:00:57] <scribe> C seek. And the benefit is it doesn't cost the expense of a
[13:01:01] <scribe> brand new registration. You don't have an outage. A
[13:01:05] <scribe> period of unreach ability. You can forcefully expire all of your
[13:01:10] <scribe> temp GRUU. It's crude because it's all of your temp grew
[13:01:15] <scribe> rGRUU. You can't pick the one I gave to Jonathan, because he keeps
[13:01:19] <scribe> bothering me. It's sort of acute feature and you
[13:01:20] <scribe> can get rid of all of them.
[13:01:21] --- dumdidum has joined
[13:01:24] <scribe> So there is one consequence of -- yes? NEW SPEAKER:
[13:01:27] <scribe> Seeing as I'm bothering you, NEW SPEAKER: Please do. NEW SPEAKER:
[13:01:32] <scribe> Why, Jonathan 11 knocks. Why can't the GRUU register list the
[13:01:37] <scribe> GRUU temp GRUUs, NEW SPEAKER: Because there could
[13:01:40] <scribe> be millions of them. NEW SPEAKER: Keep going? NEW SPEAKER:
[13:01:46] <scribe> So a consequence of this is, if an instance fails and
[13:01:49] <scribe> recovers and re registers, and it forgot
[13:01:55] <scribe> that it had previously re registered, it won't use the same call I D for
[13:01:59] <scribe> the same instance I D and the register will see a change in
[13:02:05] <scribe> call I D and expire all temp GRUU. This is a feature, but
[13:02:08] <scribe> I want to be clear this is also going to be a side effect of
[13:02:09] <scribe> this operation.
[13:02:15] <scribe> And the last consequence is that the stateless token algorithm
[13:02:19] <scribe> needs to change from using wall clock time, which was the sink|zinc
[13:02:23] <scribe> sink con saition event to call it N C seek. Which
[13:02:25] <scribe> is what I put in there. Next slide.
[13:02:31] <scribe> These are not worth going through. But anyway, did you want
[13:02:33] <scribe> to say something. NEW SPEAKER: Can I throw in a comment on that
[13:02:37] <scribe> topic? NEW SPEAKER: Yes. NEW SPEAKER: I like
[13:02:42] <scribe> having the gross invalidation mechanism enough to close my
[13:02:48] <scribe> eyes and ignore the yet another pressure on register as a
[13:02:54] <scribe> dialogue. So, if we go down this route, I'd like to see this
[13:02:57] <scribe> thing accepted, but you're not, you know, it's yet more
[13:03:01] <scribe> pressure to keep the call I sdchlt the same and update the C
[13:03:04] <scribe> seek and remember the C seek, so you've got half your
[13:03:06] <scribe> dialogue. NEW SPEAKER: I see. I see. NEW SPEAKER:
[13:03:10] <scribe> So if we can go down this path and I don't want to tie the faith
[13:03:14] <scribe> to this, I just want to throw in a suggestion while that
[13:03:19] <scribe> concept is fresh on people's mind, to cut bait and make
[13:03:22] <scribe> register did you lively create a dialogue. NEW SPEAKER:
[13:03:27] --- JeffH has joined
[13:03:29] <scribe> No, I would say. NEW SPEAKER: Why leave it as half state NEW SPEAKER:
[13:03:32] <scribe> Because -- NEW SPEAKER: We're now relying, you have something
[13:03:37] <scribe> normative, weary lying on the bee we're, relying. NEW SPEAKER:
[13:03:43] <scribe> It's like I need to remove a mole from your face, why not
[13:03:47] <scribe> give a face lift about it. NEW SPEAKER: That sounds
[13:03:48] <scribe> like an excellent discussion for the list. NEW SPEAKER:
[13:03:54] <scribe> I want to close GRUU. This would be a major re write to -- NEW SPEAKER:
[13:03:58] <scribe> Close GRUU, go ahead with this, you can have that other
[13:04:02] <scribe> conversation separate. NEW SPEAKER: Just a question,
[13:04:06] <scribe> I kind of got lost in the first, very first slide, where
[13:04:10] <scribe> basically is the problem. Why won't the registrar like,
[13:04:15] <scribe> say, okay, expires ten seconds and then 5 seconds later go,
[13:04:18] <scribe> oh, I really want it to be 5 seconds? NEW SPEAKER: I'm
[13:04:22] <scribe> sorry. I was, I just switched between examples.
[13:04:24] <scribe> Whatever, it's all 5 seconds.
[13:04:28] <scribe> It says to the notify, go back to the flow, I'm sorry if I
[13:04:35] <scribe> confused you. It says it changes it in 5 seconds and in 5 seconds
[13:04:40] <scribe> later it will expire it ment. And there's a race from the client. NEW SPEAKER:
[13:04:44] <scribe> There's a way to lower the expiration, in the 200 okay. Right?
[13:04:47] <scribe> Why did you do it there? What's this notify? NEW SPEAKER:
[13:04:47] --- richard.stastny has left
[13:04:52] <scribe> You guys asked for this for three GP P. NEW SPEAKER: I
[13:04:55] <scribe> never asked for it NEW SPEAKER: The reg star has the
[13:04:59] <scribe> ability outside of a reg star transaction at any time force a
[13:05:03] <scribe> re registration. I'm assuming that that capability is
[13:05:06] <scribe> there, and desired, if it is there and desired and it is in
[13:05:12] <scribe> 36 '80, this is a consequence. You're suggesting a an alternative to
[13:05:17] <scribe> deprecate that functionality from 36 '80. But we put it in
[13:05:19] <scribe> in first place for some reason. NEW SPEAKER: So, the
[13:05:23] <scribe> GRUU, I mean, that, you know, whatever really is
[13:05:27] <scribe> specified, that's not going to be used in GRUU anyway. It
[13:05:31] <scribe> seems like a whole lot of new complexity, just because of, I
[13:05:35] <scribe> mean, this looks really weird case. There is a sdart and all
[13:05:40] <scribe> of a sudden, things, okay, okay. I'm going to, you
[13:05:43] <scribe> know, expire this contact. NEW SPEAKER:
[13:05:45] <dwillis@jabber.org> Aki Niemi speaking
[13:05:48] <scribe> Apparently, it's, I understand it's a common feature from mobile
[13:05:51] <scribe> networks when you suspect credential suspect. NEW SPEAKER:
[13:05:52] <scribe> (Several people talking.)
[13:05:53] <scribe> NEW SPEAKER: Right. NEW SPEAKER: NEW SPEAKER:
[13:05:56] <scribe> That's why it was added to the spec. NEW SPEAKER: And
[13:05:58] <scribe> it was your colleagues who added it. NEW SPEAKER:
[13:06:05] <scribe> Yes. This is why I'm totally -- sdmoo and it only
[13:06:07] <dwillis@jabber.org> Cullen Jennings speaking
[13:06:08] <scribe> happens, this problem only happens if the network registration
[13:06:11] <scribe> doesn't give you enough time to actually, it doesn't set it
[13:06:15] <scribe> to zero. If it put it to zero, the client would know it
[13:06:20] <scribe> wasn't going to work. And if it takes the client 5 seconds to re
[13:06:24] <scribe> register, this would have worked fine too. It put it in the
[13:06:27] <scribe> exactly the right can time. It's about the amount of time it
[13:06:32] <scribe> took the client to reg register if this
[13:06:33] <scribe> occurs. (Several people talking.) NEW SPEAKER: Doctor
[13:06:40] <scribe> Doctor, it hurts. NEW SPEAKER: Right. Caplan. I was
[13:06:41] --- alexis has left
[13:06:43] <scribe> going to say exactly the same thing, that you can have
[13:06:46] <scribe> minimal value, especially with these trans ACKss,
[13:06:50] <scribe> longer than that. The other thing was, so, the change, not the
[13:06:54] <scribe> change, you're saying one of the hidden features of this is if you change the
[13:06:59] <scribe> call I D only on re registration, it's effectively not a re
[13:07:01] <scribe> registration, it's a new registration. NEW SPEAKER:
[13:07:03] <scribe> A 3261 always allowed you to (Several people talking.) NEW SPEAKER:
[13:07:07] <scribe> Absolutely. I was going to say, there are plenty of U
[13:07:10] <scribe> As that do that right now. They unfortunately change their
[13:07:12] <scribe> caller I D every registration. NEW SPEAKER: Right. NEW SPEAKER:
[13:07:16] <scribe> I think you're saying, that's okay, because they wonlt
[13:07:19] <scribe> create this problem, because if they want to implement
[13:07:21] <scribe> this, this GRUU, they would stop doing dash NEW SPEAKER:
[13:07:25] <scribe> GRUU rej ee vent. NEW SPEAKER: Yes. NEW SPEAKER:
[13:07:30] <scribe> If the group wants to not worry about this problem
[13:07:34] <scribe> and simply mandate that rej ee venlt go to one minute or
[13:07:40] <scribe> something like that minimum, we'll lose this forced bulk registration
[13:07:44] <scribe> feature and I'm okay with that. It wonlt require us to make
[13:07:48] <scribe> a change to rej ee venlt. I can back it out of GRUU 12 and all
[13:07:52] <scribe> that. That's not a big deal. I'm happy to do that. So we need
[13:07:55] <scribe> a decision. NEW SPEAKER: Regardless of this, I
[13:07:59] <scribe> just think it should be explicit, not just apparent, like if the
[13:08:00] <scribe> caller I D changes --
[13:08:02] <scribe> NEW SPEAKER: We have to when we use (Several people
[13:08:04] <scribe> talking.) NEW SPEAKER: Yes, yes. NEW SPEAKER: So
[13:08:08] <scribe> again, an argument can be made, why don't we define a separate
[13:08:11] <scribe> expiration mechanism that's more NEW SPEAKER: For this
[13:08:16] <scribe> particular problem, I, obviously, whenever it happens,
[13:08:19] <scribe> it's going to be zero or longer, 60 seconds or something like
[13:08:22] <scribe> that. NEW SPEAKER: Yes, okay.
[13:08:27] <scribe> NEW SPEAKER: So in this particular example, if the registration
[13:08:32] <scribe> expires, you wouldn't get a 200 okay. You would get a 4 01
[13:08:35] <scribe> challenge. NEW SPEAKER: No. This one happened like a half
[13:08:39] <scribe> hour ago. sdmoo no, the second one. Like the expiration
[13:08:43] <scribe> happened here. The registration came later, at this point, the
[13:08:46] <scribe> registrar is going to challenge you with a 4 01. NEW SPEAKER:
[13:08:48] <scribe> If it was for re authentication, yes. NEW SPEAKER:
[13:08:50] <scribe> It would do that even if it wasn't expired. NEW SPEAKER:
[13:08:55] <scribe> Right. What's the point? NEW SPEAKER: Is there --
[13:08:57] <scribe> is there a point, yes it would challenge and that means?
[13:09:01] <scribe> NEW SPEAKER: All the GRUUs are gone, because --
[13:09:05] <scribe> NEW SPEAKER: Why is that rejected registration does not
[13:09:11] <scribe> invam date invalidate GRUU. NEW SPEAKER:
[13:09:14] <scribe> Adam roach, I realized just now, when I
[13:09:20] <scribe> went to see the responses to bs it, that mail is stuck in my
[13:09:26] <scribe> outbound box and it did not go. Either don't do this, or
[13:09:29] <scribe> add more specification around exactly what the client is
[13:09:32] <scribe> supposed to do when he receives these notifications, because right
[13:09:35] <scribe> now, by my reading, it's a little under specified. NEW SPEAKER:
[13:09:39] <scribe> It's not specified at all in GRUU. NEW SPEAKER: No, you
[13:09:41] <scribe> have some text saying the client must implement this. The
[13:09:47] <scribe> server must implement this. But you don't satisfy what they
[13:09:48] --- Alan Hawrylyshen has joined
[13:09:50] <scribe> do say what they do with the information. NEW SPEAKER:
[13:09:55] <scribe> In GRUU rej ee venlt. It didn't get update today to reflect
[13:09:58] <scribe> all that. NEW SPEAKER: Okay. It needs to be in one of
[13:10:01] <scribe> the two documents. NEW SPEAKER: It's only if implement
[13:10:06] <scribe> GRUU reg, event. If you don't implement that, you don't have
[13:10:10] <scribe> the problem dawl. So I want to put the burden on this, only
[13:10:16] <scribe> if it goes in GRUU reg, ee venlt. And, if you're doing
[13:10:20] <scribe> GRUU and reg, ee venlt. You better. NEW SPEAKER: I
[13:10:22] <scribe> doment do that then.
[13:10:26] <scribe> NEW SPEAKER: I'm personally to same page. I wish that had been
[13:10:29] <scribe> said on the mailing list. NEW SPEAKER: Is there a
[13:10:34] <scribe> conclusion to change something in the GRUU Reggie venlt
[13:10:35] <scribe> there. NEW SPEAKER:
[13:10:38] <scribe> NEW SPEAKER: It depends on the outcome of this conversation. NEW SPEAKER:
[13:10:41] <scribe> If people don't like this the, we can come up with another
[13:10:46] <scribe> one. I mean, you could have registered and your registration is
[13:10:48] <scribe> supposed to expire in an hour, and you know, between now and
[13:10:54] <scribe> the hour you get out of connectivity. And then you get your
[13:10:58] <scribe> connectivity back before your reg straying is expired and you're
[13:11:01] <scribe> trying to refresh it. NEW SPEAKER: Right. NEW SPEAKER:
[13:11:06] <scribe> So you're still with the ambiguity. And it has nothing to
[13:11:08] <scribe> do with rej ee venlt. NEW SPEAKER: Right. NEW SPEAKER:
[13:11:13] <scribe> I tend to like the synchronous approach, and I think that's
[13:11:15] <scribe> right. There's probably all kinds of conditions
[13:11:18] <scribe> where you could get to weird race conditions or whatever.
[13:11:21] <scribe> Plus I like the side effect of being able to get rid of your
[13:11:26] <scribe> temporary GRUUs becauses you know,
[13:11:29] <scribe> before I was worried about that. And that's going to be
[13:11:31] <scribe> heading back to the list, on a system. NEW SPEAKER:
[13:11:34] <scribe> Yes. NEW SPEAKER: A refresh has much less impact.
[13:11:37] <scribe> And so if people want to get rid of their temporary
[13:11:41] <scribe> GRUUs which they may well do, if somebody starts bugging
[13:11:45] <scribe> them, this will be back on the mailing list, so I like this
[13:11:47] <scribe> approach.
[13:11:52] <scribe> NEW SPEAKER: Mohammed. Two questions, even if we don't
[13:11:56] <scribe> have rej ee venlt, doesn't this problem exist when
[13:11:57] <dwillis@jabber.org> Mohammed Vakil speaking
[13:11:59] <scribe> registration is refreshed by the time at the edge of --
[13:12:03] <scribe> NEW SPEAKER: The current spec, this one, the spec says,
[13:12:08] --- marc.bailly has left: Disconnected.
[13:12:09] <scribe> don't do that. And, you know, so, NEW SPEAKER: Second
[13:12:14] <scribe> question is like, the expression to server, weren't the
[13:12:20] <scribe> configure something rej ee vebt that registration expires. NEW SPEAKER:
[13:12:26] <scribe> As I said, the alternative would be to always send a notify
[13:12:32] <scribe> for every event. But if we're running into troubts
[13:12:35] <scribe> troubles where we have sequences, you don't
[13:12:43] <scribe> want to rely on the, and eventually you'll run out. So if you
[13:12:47] <scribe> want a reliable fix to the synchronization problem. This is
[13:12:52] <scribe> reliable. tnlt, even a synchronously, the client can
[13:12:58] <scribe> do a rej, refresh, subscribe. See what the C seek is and
[13:12:59] --- xmlscott has left: Replaced by new connection
[13:13:02] <scribe> verify its current temp GRUU at any time. And it will always work.
[13:13:04] <scribe> And I think this is Paul's point.
[13:13:07] <scribe> So, it really, the right decision here is is depending on how
[13:13:10] <scribe> worried we are about, in all these different cases,
[13:13:16] <scribe> eventually getting out of zinc on temp GRUU. If we think we
[13:13:20] <scribe> want a solution to a klou for synchronization, this works
[13:13:25] <scribe> relatively well. If we think we can punt it, you can
[13:13:28] <scribe> say, you'll always know, you don't need to verify. Trying
[13:13:33] <scribe> to get away from race conditions, by saying if you lose your
[13:13:38] <scribe> TCP connection, you invalidate them anyway. I mean, you
[13:13:43] <scribe> could do those kind of things that cover 97, 98 percent. NEW SPEAKER:
[13:13:49] <scribe> Okay. Sorry if I was sort of sounding ignorant of the but how would a
[13:13:51] <dwillis@jabber.org> Aki Nieme speaking
[13:13:52] <scribe> dmoyt fi get lost? This is -- NEW SPEAKER: You know,
[13:13:57] <scribe> TCP, there's a temporary failure for 30 seconds in the notify
[13:13:59] <scribe> times you out as a transaction. NEW SPEAKER: So
[13:14:01] <scribe> basically the subscription is invalid as well? NEW SPEAKER:
[13:14:08] <scribe> Do invalidate a subscription on (Several people talking.)
[13:14:12] <dwillis@jabber.org> err, Aki Niemi.
[13:14:15] <scribe> NEW SPEAKER: So a lot of these details, dab -- that NEW SPEAKER:
[13:14:18] <scribe> That only makes the situation worse. NEW SPEAKER: Societies
[13:14:21] <scribe> going to help in that case. NEW SPEAKER: No.
[13:14:25] <scribe> It, we still need this if that happens. I never get the
[13:14:28] <scribe> notify. In fact, I don't know I lost the subscription.
[13:14:33] <scribe> It will get rejected on the re subscribe. I'll subscribe a
[13:14:39] <scribe> fresh and now which temp GRUUs are valid. The notify con
[13:14:41] <scribe> tanks the original C seek will tell me. NEW SPEAKER:
[13:14:47] <scribe> Okay. NEW SPEAKER: Wow, okay. So, I'm actually split
[13:14:48] --- xmlscott has joined
[13:14:51] <scribe> on this personally. We need to make a consensus call on this thing. Do
[13:14:54] <scribe> you want to take a hum or raise hands. NEW SPEAKER:
[13:15:05] <scribe> Was it cull 11 who Collin jenks
[13:15:13] <scribe> generalings again. I jenings. If the
[13:15:18] <scribe> only, I think I would do it by returning the time in the
[13:15:19] <scribe> previous registration. NEW SPEAKER: I, we used to
[13:15:22] <scribe> have stuff like that. I went through that with dash NEW SPEAKER:
[13:15:24] <scribe> Okay. (Several people talking.) NEW SPEAKER: So I'm not
[13:15:28] <scribe> against this. I think I would be in favor of this. But I, so don't
[13:15:31] <scribe> take me as against this. NEW SPEAKER: I'd like to still
[13:15:32] --- enrico has joined
[13:15:34] <scribe> just take a show of hands so we know what to do with
[13:15:36] <scribe> this document. Is that all right?
[13:15:39] <scribe> NEW SPEAKER: Go ahead. NEW SPEAKER: All in favor of
[13:15:43] <scribe> adding this rej ee venlt synchronization technique, which is
[13:15:48] <scribe> already in GRUU 12, raise your hand. NEW SPEAKER: All
[13:15:50] --- worley has left: Replaced by new connection
[13:15:52] <scribe> who prefer the technique of simply mandating that the server
[13:15:56] <scribe> don't use such small expiration intervals and
[13:16:00] <scribe> hope we don't run into this race, two of many other ways
[13:16:04] <scribe> ways, raise your hand. NEW SPEAKER: Wow. NEW SPEAKER: NEW SPEAKER:
[13:16:07] <scribe> Just kill me now. NEW SPEAKER: Raise your hand if
[13:16:10] <scribe> you'd like to be the new editor of the GRUU specification. NEW SPEAKER:
[13:16:13] <scribe> Could you call NEW SPEAKER: What --
[13:16:15] <scribe> (Several people talking.) NEW SPEAKER: Equal hands each
[13:16:17] <scribe> way. NEW SPEAKER: Okay. Thank you.
[13:16:21] <scribe> NEW SPEAKER: Change my vote if it makes a consensus out of
[13:16:24] <scribe> it. NEW SPEAKER: Perhaps we can take one on the people
[13:16:27] <scribe> who believe it's critical for us to make a decision right
[13:16:30] <scribe> now, even if that involves Keith flipping a coin.
[13:16:40] <scribe> NEW SPEAKER: Not that many people. NEW SPEAKER: This is
[13:16:43] <scribe> why you guys get paid the big bucks, you tell me what to do.
[13:16:46] <scribe> I want this to be done more than anything else. NEW SPEAKER:
[13:16:50] <scribe> Do both. NEW SPEAKER: Do both. NEW SPEAKER:
[13:16:55] <scribe> Don't do that, but if you do, NEW SPEAKER: I think
[13:16:58] --- worley has joined
[13:16:58] <scribe> what we need is a call, how many people in the room, is
[13:17:04] <scribe> this a major issue to? But you know, whichever way we go,
[13:17:09] <scribe> basically, is does anybody have a major problem with not just
[13:17:12] <scribe> resolving this one way or the other. NEW SPEAKER: I
[13:17:14] <scribe> think part of the reason that you're not getting many
[13:17:18] <scribe> hands is that people are getting lost in the pronounce, we're
[13:17:22] <scribe> not talking about removing the ability to validate
[13:17:24] <dwillis@jabber.org> Robert Sparks speaking
[13:17:25] <scribe> GRUUs by Paul. We're talking about learning about can
[13:17:28] <scribe> changes here. NEW SPEAKER: No, we are. NEW SPEAKER:
[13:17:29] <scribe> Entirely. (Several people talking.) NEW SPEAKER:
[13:17:34] <scribe> I would back out the whole change, with the call I D,
[13:17:36] <scribe> invalidating, all that. NEW SPEAKER: Okay. I
[13:17:40] <scribe> doubt seriously that more than a fifth of the people that
[13:17:44] <scribe> raisedd their hands a minute ago,
[13:17:46] <scribe> understood that point. So call it again. NEW SPEAKER:
[13:17:48] <scribe> All in favor of me backing out --
[13:17:53] <scribe> NEW SPEAKER: Explain fully the implications, and then ask
[13:17:58] <scribe> for a call again. NEW SPEAKER: Is there a slide you
[13:18:00] <scribe> can point to. NEW SPEAKER: Approach one is I back out the
[13:18:05] <scribe> changes that were put into grut are GRUU and I don't put them
[13:18:07] <scribe> in rej ee venlt, which means we have this race condition
[13:18:10] <scribe> that's possible, we have to recommend the timers to deal with
[13:18:13] <scribe> it, as freev yus GRUU specs had, there would be no
[13:18:19] <scribe> way to do a forceful bulk, expiration of your temp GRUU,
[13:18:22] <scribe> the stateless token algorithm would revert to wall clock
[13:18:25] <scribe> time. One of the minor issues with that is that, you know,
[13:18:30] <scribe> I don't like time stamps so much as synchronization as a clock
[13:18:33] <scribe> skew. I thought the C seek was nicer. NEW SPEAKER:
[13:18:36] <scribe> Would that make these tokens much smaller?
[13:18:39] <scribe> NEW SPEAKER: I think it has a trivial impact. NEW SPEAKER:
[13:18:43] <scribe> Okay.
[13:18:47] <scribe> NEW SPEAKER: Sorry. That's option one.
[13:18:55] <scribe> Option two is, we have this technique, if you implement rej
[13:18:59] <scribe> event and GRUU, you'll need GRUU rej event and also, you will
[13:19:04] <scribe> be able to invalidate all of your temp GRUU in bulk, that does
[13:19:09] <scribe> not require rej event or GRUU rej event to do that. You can
[13:19:12] <scribe> register refresh but if you're worried about sink
[13:19:17] <scribe> problems, you want rej ee venlt and that capability would
[13:19:26] <scribe> still be there. That's the big issue. All in favor of the
[13:19:30] <scribe> first one, raise your hand. NEW SPEAKER: Keeping
[13:19:35] <scribe> bulk invalidation and adding these parameters to rej event to support the
[13:19:38] <scribe> that. Raise your hand. NEW SPEAKER:
[13:19:47] <scribe> (Several people talking.) Oh, God, please kill me now. NEW SPEAKER:
[13:19:52] <scribe> It was a long description, you wanted me to describe the whole
[13:19:53] <scribe> thing. I forgot.
[13:20:00] <scribe> Okay. Option one is -- can we just write this on a slide. NEW SPEAKER:
[13:20:18] <scribe> Type it on a slide and then do it. I NEW SPEAKER: I
[13:20:21] <scribe> think I can do this chl e I think I can do this this fast. NEW SPEAKER:
[13:20:23] <scribe> We're in your time slot now. NEW SPEAKER: All right.
[13:20:26] <scribe> Let me try. NEW SPEAKER: Please. NEW SPEAKER: All
[13:20:30] <scribe> right. What I would like to know, Jonathan has made a
[13:20:33] <scribe> change. He's got a proposal, there are ramifications to
[13:20:38] <scribe> that change if he needs to make it. If we pursue this path
[13:20:42] <scribe> so we have bulk invalidation, we have to do extra work to tie
[13:20:47] <scribe> these other packages together. Would you be
[13:20:50] <scribe> happy, raise your hand now. You like the idea of being able
[13:20:53] <scribe> to bulk invalidate, even if it means a little bit of extra
[13:20:54] <scribe> work.
[13:20:57] <scribe> All right. If you want to revert the changes he made in this
[13:21:01] <scribe> area, since the last draft and go back to where there is no
[13:21:04] <scribe> ability to do bulk invalidation of GRUUs and take all
[13:21:06] <scribe> this stuff out, raise your hand now.
[13:21:10] <scribe> All right. NEW SPEAKER: And if you you don't care. NEW SPEAKER:
[13:21:15] <scribe> Can I call it? NEW SPEAKER: It was a small number of
[13:21:18] <scribe> hands for both votes but it was significantly in favor of
[13:21:20] <scribe> pursuing this path. NEW SPEAKER: It was like ten versus
[13:21:22] <scribe> three or something. NEW SPEAKER:
[13:21:22] <scribe> (Several people talking.)
[13:21:25] <scribe> NEW SPEAKER: Some people don't care. NEW SPEAKER: The
[13:21:28] <scribe> chairs would like to know who does not know and who doesn't
[13:21:28] <scribe> care.
[13:21:31] <scribe> NEW SPEAKER: Two separate things.
[13:21:37] <scribe> NEW SPEAKER: It's okay. We'll let it go. NEW SPEAKER:
[13:21:42] <scribe> Okay.
[13:21:45] <scribe> NEW SPEAKER: So the resolution of that is that Jonathan
[13:21:51] <scribe> will keep the changes in. And we need to talk to the SIPPING
[13:21:56] <scribe> chairs about GRUU rej event. NEW SPEAKER: All right.
[13:21:59] <scribe> Ice option tag. This is basically an option tag and media
[13:22:02] <scribe> feature tag for ice. Please read the draft. It's two use
[13:22:10] <scribe> cases. Registration, U A forms its registrar so proxy can
[13:22:14] <scribe> insert a Gateway. If you get an incoming ice call and you want size
[13:22:19] <scribe> to work. Option usage case two, is to require it to
[13:22:20] <scribe> support ice. Next slide.
[13:22:24] <scribe> The three important things I want to group to note, the initial note
[13:22:30] <scribe> vaition was offerless invite. Wouldn't it be cool if I
[13:22:34] <scribe> could construct it in one X X or two X X if the offer, if the
[13:22:37] <scribe> invite err supported ice without the them if they don't.
[13:22:40] <scribe> That does not work. Because of third party call control that
[13:22:44] <scribe> use case is not supported in this dock: It's not even
[13:22:48] <scribe> mentioned. Thing two to note, option tag is not
[13:22:52] <scribe> used with supported just require. The way you indicate that
[13:22:56] <scribe> you could do ice, is with the media feature tag. And the
[13:23:00] <scribe> offerers themselves, it's the ice attributes.
[13:23:03] <scribe> The only thing do you with the ice option tag is force the
[13:23:08] <scribe> other side to support it and I just want to point out this sort
[13:23:11] <scribe> of weird double thing. I did this because I didn't want two
[13:23:15] <scribe> tags with exactly the same meaning. I tried to segment the use
[13:23:19] <scribe> cases for them. So the media feature tag refers to doing ice.
[13:23:24] <scribe> And the option tag refers to an empty specification if you
[13:23:28] <scribe> also do ice, that's a weird way to think about it. That's it. I just want
[13:23:31] <scribe> to make sure the group was aware of these things. There are
[13:23:33] <scribe> somewhat to note, if you have no questions or
[13:23:37] <scribe> comments, that's fine. But just note there are a couple of
[13:23:39] <scribe> interesting things about this draft.
[13:23:41] <scribe> NEW SPEAKER: Could you back up one slide? NEW SPEAKER:
[13:23:44] <scribe> Thank you.
[13:23:49] <scribe> NEW SPEAKER: Okay.
[13:23:54] <scribe> NEW SPEAKER: Isn't this a little inconsistent with the 3261
[13:23:57] <scribe> option tag, where you pit it in every request you send? NEW SPEAKER:
[13:24:01] <scribe> You could put it in and support it but it won't be looked at for this
[13:24:06] <scribe> purpose. It means dash NEW SPEAKER: Put it in support it NEW SPEAKER:
[13:24:10] <scribe> Right, but no one will look for it; or if somebody has a
[13:24:14] <scribe> better idea. it the same problem with registrations, you
[13:24:18] <scribe> can't support registers, you have to use media feature
[13:24:20] <scribe> tags and there you go. NEW SPEAKER: Okay. NEW SPEAKER:
[13:24:25] <scribe> We're ready to go to working group last call with this draft. NEW SPEAKER:
[13:24:29] <scribe> This is last call ice, which is imminent, so this will
[13:24:32] <scribe> also be going to working group last call. So issues, raise
[13:24:35] <scribe> it before last call. As I've said previously on the list,
[13:24:40] <scribe> now would be a very good time to do it. Also, just
[13:24:45] <scribe> backtracking while Robert is picking the Mike up to GRUU, that
[13:24:51] <scribe> is, Jonathan updates, we're going to submit that as a
[13:24:54] <scribe> publication request, if there's anything further you need to do,
[13:24:57] <scribe> God help us if there is, then make it pretty damn quick. NEW SPEAKER:
[13:25:00] <scribe> I've already made every other change to the GRUU spec on
[13:25:04] <scribe> the, posted on the list since this draft was last issued. So
[13:25:09] <scribe> I have a draft in my machine that as soon as the black
[13:25:13] <scribe> out is done, it's going. I will now incorporate the
[13:25:15] <scribe> suggestions from Adam on this change, like today or
[13:25:19] <scribe> something. So, you know, speak, really speak like
[13:25:23] <scribe> today, or hold your piece. We're going to go on this. NEW SPEAKER:
[13:25:25] <scribe> But obviously, speak on the list. NEW SPEAKER:
[13:25:31] <scribe> Just, at this point it becomes even more imperative that we're
[13:25:35] <scribe> rej event at the same time, right? NEW SPEAKER: Yes. NEW SPEAKER:
[13:25:38] <scribe> We'll have that discussion in siping chairs. NEW SPEAKER: All
[13:25:41] <scribe> right. Let's go ahead and go to the first slide.
[13:25:47] <scribe> So, Keith put a draft in, about a cycle ago
[13:25:50] <scribe> about an essential correction process. Basically, the idea of
[13:25:56] <scribe> the process was to be able to make corrections to the core
[13:26:01] <scribe> specs, three 3261 in particular, that had time pressure
[13:26:02] <dwillis@jabber.org> Robert Sparks presenting
[13:26:05] <scribe> really needed to be made, in a way that didn't cause people
[13:26:11] <scribe> to implement core 3261 and get the basics down, had to go
[13:26:14] <scribe> hunting through a whole handful of documents to figure out what
[13:26:15] <scribe> was going on with exactly the core.
[13:26:19] <scribe> If you read the draft that he put together, and there's a revision
[13:26:24] <scribe> coming out that's got some clarifications in it, it's pretty
[13:26:30] <scribe> explicit that the non goal is to open the door to 3261 BIS,
[13:26:33] <scribe> not what we're talking about. We're talking about making the
[13:26:36] <scribe> small changes we have to make now. We're not talking about going
[13:26:40] <scribe> back in and clarifying, revising and making huge
[13:26:43] <scribe> architectural changes. So let's go move forward.
[13:26:48] <scribe> The basic mechanics is, we would have a repeating cycle that
[13:26:51] <scribe> we did. It might be driven by the heartbeat at the IETF meetings.
[13:26:55] <scribe> We might go to another phase that's going to depend on what we
[13:26:59] <scribe> discover on how fast content for these things can be generated.
[13:27:06] <scribe> We would, for a give convenient essential change think fork loop fix for
[13:27:12] <scribe> a proceed tow typical example. Taking draft that motivated
[13:27:15] <scribe> the change, specified the change, through working group
[13:27:19] <scribe> last call. And as we went through this cycle, we collect
[13:27:22] <scribe> these drafts up. When we got to the end of the cycle
[13:27:25] <scribe> point, we would take all of those, merge them into one document.
[13:27:29] <scribe> Merge that into the BIS from any previous versions ever this document and
[13:27:33] <scribe> obsolete it with the new ones so anybody who was attempting to implement
[13:27:38] <scribe> 3261, essentially had 3261 and a draft that was the essential
[13:27:41] <scribe> changes. To go look at it.
[13:27:41] <scribe> Move forward.
[13:27:46] <scribe> So, we need to have some discussion and I think it will
[13:27:50] <scribe> probably be chewing on this on the list for a little wilt,
[13:27:53] <scribe> about what is an essential correction. I want to propose that
[13:27:59] <scribe> it's a normative change, that has to be made quickly in order
[13:28:03] <scribe> to be real problems. So, fork loop fix is good. I think
[13:28:07] <scribe> we would have all agreed that 4 three20 was, maybe not.
[13:28:08] <scribe> Let's move forward again.
[13:28:13] <scribe> Things that aren't likely to be droptd into this process are
[13:28:18] <scribe> things that are just normal extension, like creating a new
[13:28:21] <scribe> extension for the use of SIP, that's the way it's gone before.
[13:28:24] <scribe> Clarification to the spec, we found a bug in the example
[13:28:27] <scribe> kind of stuff, are not going to be going here. And things that are
[13:28:32] <scribe> really corrections but they're not perhaps addressing a real
[13:28:38] <scribe> pressing problem and I threw up here an example. I got
[13:28:41] <scribe> feedback and I chose a bad example, and if people think we
[13:28:46] <scribe> should dlo it in in the essential correction pace space.
[13:28:47] --- enrico has left
[13:28:50] <scribe> Before we start taking questions, let me run through those and
[13:28:51] <scribe> then we'll run through the discussion.
[13:28:55] <scribe> Some near term candidates to get some more of an idea of what
[13:29:00] <scribe> I've got in mind. There's a bug bugzilla database on having
[13:29:04] <scribe> the invite transaction state machine delete itself when you
[13:29:07] <scribe> send a 200, that we discovered we need to create a stim err for
[13:29:09] <scribe> instead.
[13:29:10] <scribe> ( Timer for.)
[13:29:19] <scribe> There's some normative changes in 3261. There's a draft that
[13:29:23] <scribe> thom has out, that probably is not, but I wanted to show it
[13:29:26] <scribe> up here, the talk about the boundary. Move forward.
[13:29:31] <scribe> So the current plan is to just pilot this approach with 3261 and
[13:29:35] <scribe> if it makes sense to go ahead and apply it to some of the other
[13:29:37] <scribe> core drafts as they come along.
[13:29:42] <scribe> An example of a normative change that wouldn't fall into
[13:29:45] <scribe> considering core specs, and this is also something that
[13:29:51] <scribe> causes folks to jump up on the line. My U V has a draft with
[13:29:55] <scribe> normative clarifications to the privacy header extension. I don't
[13:29:58] <scribe> think this is, that that would go into this process. That
[13:30:01] <scribe> would just update or obsolete the privacy draft.
[13:30:05] <scribe> All right. So let's go ahead and go to the line. NEW SPEAKER:
[13:30:10] <scribe> Yes, Chris ter somebody, I think you answered my
[13:30:14] <scribe> question, you said we're not going to define new ex stenk, that's
[13:30:16] <scribe> fine. But we could have either
[13:30:20] <scribe> extensions, where similar changes would be needed. One
[13:30:23] <dwillis@jabber.org> Christer Holmberg
[13:30:24] <scribe> thing I have in mind is for example, the route, with Jonathan
[13:30:30] <scribe> has been working on, which would classify that, maybe the loose
[13:30:33] <scribe> routing. NEW SPEAKER: They're extensions, what he's doing right
[13:30:38] <scribe> now are things that don't actually normatively change 3261. If you're
[13:30:41] <scribe> just doing a 3261 thing dash NEW SPEAKER: That's what I
[13:30:46] <scribe> menlt, this is only things which apply to 3261. If we want
[13:30:50] <scribe> to do something similar to other specifications we need a
[13:30:53] <scribe> separate work item or separate -- NEW SPEAKER: Yes. NEW SPEAKER:
[13:30:58] <scribe> So, can two comments. One of the things I
[13:30:59] <dwillis@jabber.org> Jonathan Rosenberg
[13:31:00] <scribe> thought we were going to do with this. This is Jonathan. We
[13:31:04] <scribe> have this long list of things in the bugzilla database, the vast
[13:31:07] <scribe> majority of which are not I think essential corrections,
[13:31:11] <scribe> because all the essential corrections you point to are drafts.
[13:31:14] <scribe> Big big stuff. There's a bunch of stuff in there that's
[13:31:18] <scribe> probably still useful but is all small. So are we excluding
[13:31:22] <scribe> that, are we not going to comb through that
[13:31:24] <scribe> database and pull those out. NEW SPEAKER: I have
[13:31:27] <scribe> combd through the database already and anticipate in the next
[13:31:31] <scribe> couple of weeks going through and making annotations saying
[13:31:34] <scribe> which things are essential and which are not. A higher level overview of
[13:31:39] <scribe> what I found, for the things affecting 3261 at
[13:31:43] <scribe> least, the vart yort vast yort majority of them,
[13:31:47] <scribe> are bug or text clarifying. There's a block that's maybe ten
[13:31:50] <scribe> percent, in the B N F is wrong. NEW SPEAKER: I think
[13:31:52] <scribe> that's where the fixing dash (Several people talking.)
[13:31:54] <scribe> NEW SPEAKER: Two things I put up pt here. NEW SPEAKER:
[13:31:58] <scribe> I think the B N F work is worth fixing.
[13:32:02] <scribe> The other comment I would make is that, to me, the litmus test
[13:32:06] <scribe> is, if you can do this as an extension, it doesn't go in
[13:32:13] <scribe> this document. NEW SPEAKER: I think that's sane. NEW SPEAKER:
[13:32:19] <scribe> So, are you mostly, so at places where the spec has a vacuum, because it's
[13:32:19] <dwillis@jabber.org> Miguel Garcia
[13:32:24] <scribe> missing to do, to indicate some normative actions, are those
[13:32:29] <scribe> considered a normative state essentially, a correction? NEW SPEAKER:
[13:32:34] <scribe> Yes. And what will happen, in that case, is that we will have
[13:32:37] --- xmlscott has left: Replaced by new connection
[13:32:38] <scribe> to put a group consensus that this is something that we
[13:32:40] <scribe> consider an essential correction in the spec. NEW SPEAKER:
[13:32:44] <scribe> Right. Right. The other thing, you know, I was
[13:32:49] <scribe> thinking that perhaps rather than essential correction, when you are
[13:32:53] <scribe> looking for is more like a normative correction or correction to
[13:32:56] --- xmlscott has joined
[13:32:57] <scribe> normative statements, in 3261. NEW SPEAKER: Well, (Several people
[13:32:58] <scribe> talking.)
[13:33:00] <scribe> NEW SPEAKER: The essential corrections are normative
[13:33:03] <scribe> corrections, I think there are normative corrections that are not
[13:33:07] <scribe> essential. NEW SPEAKER: It's basically a judgment,
[13:33:13] <scribe> each case is a judgment call. But part of the judgment call
[13:33:17] <scribe> is, is it unimplement able or does it cause something to break
[13:33:20] <scribe> when you try to run it as it's currently written. NEW SPEAKER:
[13:33:23] <scribe> Right. NEW SPEAKER: So we may have other normative
[13:33:26] <scribe> changes that are corrections that we want to make, that we'll
[13:33:32] <scribe> go ahead and put in the bugzilla database and safe for that
[13:33:35] <scribe> faithful day when we do a big text revision. NEW SPEAKER: Can
[13:33:39] <scribe> you give an example. NEW SPEAKER: I don't have any in my head right
[13:33:43] <scribe> now. NEW SPEAKER: This could cause the conversation to
[13:33:46] <scribe> roll into infinite depth. NEW SPEAKER: I have to think
[13:33:50] <scribe> at some point in time, the discussion is going to be where this is
[13:33:53] <scribe> essential or not. And I would like to be there. That's
[13:33:57] <scribe> why I would like to identify now, and having a clear definition of
[13:34:00] <scribe> what it is. NEW SPEAKER: All of this has to happen as
[13:34:03] <scribe> consensus. It will all happen on the list. Everybody will
[13:34:07] <scribe> have a chance to say no, that goes in this bucket or that
[13:34:11] <scribe> other bucket. NEW SPEAKER: Right.
[13:34:16] <scribe> NEW SPEAKER: Philip math shoes. I was Mathews.
[13:34:19] <scribe> I was just going to suggest, rather than publishing the
[13:34:24] <scribe> essential corrections as RFC, point somebody to go and make the
[13:34:28] <scribe> changes to the text of 3261 and working group last call, and only
[13:34:32] <scribe> those changes and not the rest of the dock. So there's only
[13:34:34] <scribe> one document to look at. I see Jonathan -- NEW SPEAKER:
[13:34:39] <scribe> That runs us deeply into an IETF process violation. NEW SPEAKER:
[13:34:42] <scribe> It's also just an awful idea for other reasons. NEW SPEAKER:
[13:34:47] <scribe> Let me rephrase it. There's a great advantage, I understand
[13:34:50] <scribe> the desire, it's hard to understand the changes out of
[13:34:54] <scribe> context. One problem we can run into at the I S G, if
[13:34:57] <scribe> nothing else, the security considerations would have to be reviewed
[13:35:01] <scribe> based on what the IETF considers appropriate security today,
[13:35:04] <scribe> not 3261. And that's a significant change. NEW SPEAKER:
[13:35:10] <scribe> Oh, man. NEW SPEAKER: So, you know, what we really
[13:35:16] <scribe> don't want to have is some document out there that is being
[13:35:21] <scribe> reap SIP specification, as long as 3261 is ostensibly not
[13:35:26] <scribe> obsolete ted. NEW SPEAKER: I am just curious how the I
[13:35:32] <scribe> S G is going to handle this issue. Somebody is going to point that
[13:35:34] <scribe> they're still missing security considerations. It
[13:35:39] <scribe> sounds like a lot of haing geling to me, and
[13:35:43] <scribe> really haggling, and do you expect that the
[13:35:47] <scribe> security experts are going to be fooled by this? NEW SPEAKER:
[13:35:53] <scribe> Who is something. NEW SPEAKER: Caplan. I have two
[13:35:58] <scribe> questions. One comment. The B N F, the examples you
[13:35:58] <dwillis@jabber.org> Hdriel Kaplan at mic
[13:36:01] <scribe> change, which I agree with, the B N F has to change,
[13:36:02] <dwillis@jabber.org> Hadriel, that is
[13:36:06] <scribe> because that's where the disconnect usually is. The B N F does not
[13:36:10] <scribe> agree with the example. So the B N F has to change. I didn't
[13:36:14] <scribe> fully follow how the change is going to be documented. Is it
[13:36:17] <scribe> going to be a published RFC every couple years, or are you
[13:36:20] <scribe> suggesting the same number? NEW SPEAKER: No, no.
[13:36:23] <scribe> There will only be be one RFC. The RFCs are
[13:36:26] <scribe> permanent. We'll publish a new one and obsolete that one. NEW SPEAKER:
[13:36:32] <scribe> Yes, right. NEW SPEAKER: Andrew, yes, I agree
[13:36:37] <scribe> with the B N F, I think obviously, that could cause serious
[13:36:43] <scribe> misoperation. That's what we deem essential corrections, is a
[13:36:47] <scribe> frequent and serious misoperation in the system. So the
[13:36:50] <dwillis@jabber.org> Andrew Allen at mic
[13:36:51] <scribe> problem with 3261 if you implement it the way it's written and
[13:36:55] <scribe> that's going to cause an inter operability problem or some
[13:36:58] <scribe> serious problem in the system, like up loading the messages
[13:37:02] <scribe> or security issue, big security whole, that's something we
[13:37:05] <scribe> should fix. If it's nice to have, then it's some extension
[13:37:10] <scribe> that makes things prettier, that's nice. But if it's something
[13:37:13] <scribe> that's going to break and cause significant inter operability
[13:37:16] <scribe> problems, then thais the basis of doing essential correction. NEW SPEAKER:
[13:37:22] <scribe> Okay. So, before we get to the next speaker, in interest
[13:37:27] <scribe> of moving faster, I think we heard that we'll do the B N F
[13:37:32] <scribe> fixes, unless you're going to say, don't do the B N F fixes
[13:37:34] <scribe> and then don't talk about it anymore. NEW SPEAKER:
[13:37:37] <scribe> Just clarification to avoid unnecessary discussion on the
[13:37:42] <scribe> list, since this this is not going to be based on new RFC and stuff like
[13:37:45] <scribe> that. I assume things we're not going to do, as part of
[13:37:49] <scribe> this is for example, deprecate the U D P from SIP and things like
[13:37:52] <scribe> that. NEW SPEAKER: Something that is that large of a
[13:37:55] <scribe> scale of change is not likely to be done with this mechanism. NEW SPEAKER:
[13:38:00] <scribe> Unless you can prove that the U D P is totally wrong. NEW SPEAKER:
[13:38:04] <scribe> Well, we seem to -- no. No. (Several people talking.) NEW SPEAKER:
[13:38:07] <scribe> Don't answer that unambiguously. No. NEW SPEAKER:
[13:38:15] <scribe> Yes, I think Keith just addressed a key point here. This kind of
[13:38:20] <scribe> issues, these are always somehow a matter of judgment. And
[13:38:24] <scribe> to get your proposal, you really need to prove what is broken
[13:38:27] <scribe> in real life. Otherwise it's no go. That's very clear.
[13:38:32] <scribe> I would like to ask people to think about one more aspect, if
[13:38:35] <scribe> going ahead with this new scheme, which looks rather
[13:38:39] <scribe> promising, it just takes some getting used to to get it right
[13:38:41] <scribe> properly. Namely, if there is decision and agreement to
[13:38:45] <dwillis@jabber.org> hannu at mic
[13:38:47] <scribe> go forward with a change, which is considered essential, do
[13:38:53] <scribe> we restrict the mandate to just that or do we allow smr
[13:38:55] <scribe> further, nice corrections, but not so critical ones at the same time?
[13:38:59] <scribe> That's something to think about. We don't need to answer
[13:39:08] <scribe> that now. NEW SPEAKER: The line is drained. No one
[13:39:12] <scribe> came to the Mike and said this is a terrible idea. If anybody
[13:39:15] <scribe> thinks it's a terrible idea, go ahead and throw a note to the
[13:39:19] <scribe> mailing list or privately to the chairs. Otherwise we're
[13:39:24] <scribe> going to move forward, with this. NEW SPEAKER: So,
[13:39:29] <scribe> with my A D hat on here, if the group wants to move
[13:39:32] <scribe> forward in this direction, I just want to say that I think we
[13:39:35] <scribe> really do want, one thing I've noticed over time
[13:39:41] <scribe> is everybody thinks that their draft is particularly more,
[13:39:46] <scribe> whatever word we're using, critical. Than others. We're
[13:39:49] <scribe> going to have to be really careful about that. And anything
[13:39:52] <scribe> that can be done as update or extension or something else like
[13:39:56] <scribe> that, I think we're going to really push that to be that way. And
[13:40:01] <scribe> even with things that aren't clearly, if somebody find a bug
[13:40:04] <scribe> with S MIME, I'm just not, you know, it's going to be
[13:40:07] <scribe> hard to view that as critical. That's going to have to be something
[13:40:10] <scribe> that's impacting people in the field. And I know some of the
[13:40:13] <dwillis@jabber.org> Cullen at mic
[13:40:15] <scribe> things in the bug database, you've seen lots of SIP it is and big
[13:40:16] <scribe> problems. I know we have issues like that.
[13:40:20] <scribe> The other question is, a lot of the concerns about this have
[13:40:24] <scribe> to do with how big it, how complicated they are, I think
[13:40:27] <scribe> that once we see the document and see what the draft starts
[13:40:30] <scribe> looking like when it forms together, we're going to get a
[13:40:33] <scribe> slightly better idea of how do deal with it. NEW SPEAKER:
[13:40:36] <scribe> Exactly. NEW SPEAKER: If this draft is as long as
[13:40:40] <scribe> 3261, this is a 400 page draft (Several people talking.) NEW SPEAKER:
[13:40:42] <scribe> It's not the right path. NEW SPEAKER: Right. NEW SPEAKER:
[13:40:49] <scribe> If this contains three paragraphs of normative change text and 5
[13:40:51] <scribe> pages of text that explain why we did that around it or
[13:40:55] <scribe> something, then it's very helpful. So I think we have to
[13:40:57] <scribe> see what this looks like before we really
[13:40:59] <scribe> completely know what to do. NEW SPEAKER: It would
[13:41:07] <scribe> already be that size, because it 42 60 constitutes more than that.
[13:41:10] <scribe> So the correction RFC z is already 20 pages. NEW SPEAKER:
[13:41:14] <scribe> Okay. NEW SPEAKER: And it may be that we discover, you know,
[13:41:17] <scribe> thinking through what we would have done if we had been doing 4
[13:41:20] <scribe> three20 at this time, I suspect that I would have come
[13:41:23] <scribe> to this group with the, here are the essential normative
[13:41:27] <scribe> changes and a very, very small body of text. And we might have
[13:41:31] <scribe> an additional informational document that comes along and
[13:41:34] <scribe> provides the details and motivation. NEW SPEAKER: My
[13:41:38] <scribe> suggestions for this would be to do what we did in ice, the
[13:41:42] <scribe> normative text up front and the dependencies and motivation
[13:41:49] <scribe> described and why. NEW SPEAKER: Yes. All right.
[13:41:52] <scribe> I think we're done. NEW SPEAKER: Well, there's a couple more words.
[13:41:56] <scribe> Robert is basically, he's the consolidation editor at the
[13:42:00] <scribe> end of this process. So basically, the responsibility for
[13:42:05] <scribe> progressing errors is if we find them, progressing. And
[13:42:10] <scribe> Robert has them in his mind, his own individual input and process.
[13:42:13] <scribe> NEW SPEAKER: Yes, I'm not volunteering to be the only
[13:42:16] <scribe> editor that creates the bits that go into this. NEW SPEAKER:
[13:42:20] <scribe> So if you do think you've got changes and obviously consider
[13:42:23] <scribe> what you think they're extensions or bug fixes, come and discuss
[13:42:27] <scribe> them with Robert and the chairs or on the list and we'll
[13:42:31] <scribe> basically be working together in sort of promoting some of
[13:42:35] <scribe> these forward to try to get these fixes into the marketplace. NEW SPEAKER:
[13:42:39] <scribe> Andrew again, just a question, will it be an easy way for
[13:42:43] <scribe> development people to find out what the latest RFC number is for
[13:42:46] <scribe> this, rather than using the old one, knowing when a new one
[13:42:51] <scribe> is coming out. NEW SPEAKER: RFC index Dot text, soft
[13:42:52] <scribe> armor. ab (Several people talking.)
[13:42:55] <scribe> NEW SPEAKER: No. No. NEW SPEAKER: When you go to the IETF
[13:43:00] <scribe> RFC z repository and look at 3261 it will show updated the dash NEW SPEAKER:
[13:43:01] <scribe> Okay. (Several people talking.)
[13:43:06] <scribe> NEW SPEAKER: It will be tracked. NEW SPEAKER: The
[13:43:06] --- xmlscott has left
[13:43:10] <scribe> thoughts are, you ought to probably put p a special page on soft
[13:43:15] <scribe> armor those in progress or approved so we have complete
[13:43:18] <scribe> coverage on them. NEW SPEAKER: Chris, just one thing
[13:43:23] <scribe> before we get out; you know, large draft that we start
[13:43:27] <scribe> working on, I think it would be grood good to
[13:43:32] <scribe> agree on some kind of template so we don't spend a lot of time
[13:43:35] <scribe> saying I want it documented this way or that way. NEW SPEAKER:
[13:43:40] <scribe> Keith's draft. NEW SPEAKER: My draft contains a ver
[13:43:46] <scribe> writ able template. So send comments.
[13:43:49] <scribe> It's draft dredge SIP essential corrections. NEW SPEAKER:
[13:43:56] <scribe> Okay. Done for the day? NEW SPEAKER: lrtd. NEW SPEAKER:
[13:44:02] <scribe> Has anyone got the blue sheets? No one is leaving the room until
[13:44:04] <scribe> we get the blue sheets back. NEW SPEAKER: We'll be
[13:44:07] <scribe> meeting in a closet. NEW SPEAKER: I'd also like to ask
[13:44:11] <scribe> those volunteer who are taking notes to please send them to me as soon
[13:44:16] <scribe> as possible, and especially before they dpor get
[13:44:21] --- ben has left
[13:44:31] <scribe> forget them. NEW SPEAKER: Okay.
[13:44:31] --- scribe has left
[13:44:36] --- ttfr has left
[13:44:43] --- Jabber-Wile has left
[13:44:56] --- renee has left
[13:44:59] --- avwijk has left
[13:45:07] --- ft has left
[13:45:13] --- dwillis@jabber.org has left
[13:45:18] --- Alan Hawrylyshen has left
[13:45:19] --- jonlennox has left
[13:45:22] --- dp has left
[13:45:26] --- teemuk has left
[13:45:28] --- isudo has left
[13:46:03] --- bpenfield has left
[13:46:12] --- bhoeneis has left
[13:47:04] --- hb47713 has left
[13:47:07] --- JeffH has left
[13:48:11] --- dumdidum has left
[13:49:53] --- chadolabba has joined
[13:51:02] --- chadolabba has left
[13:51:13] --- worley has left
[13:51:58] --- chadolabba has joined
[13:53:58] --- chadolabba has left
[13:58:35] --- jbcranshaw has joined
[13:58:52] --- Alan H has left
[14:00:45] --- frodek has left: Replaced by new connection
[14:01:09] --- jbcranshaw has left
[14:05:06] --- kafka-j31415927 has left
[14:21:36] --- christian has left
[20:15:14] --- chadolabba has joined