[14:29:32] BERNARDA joins the room [14:29:44] BERNARDA has set the subject to: MARTINI Virtual Interim [14:30:18] Agenda [14:30:58] and other slides are now available here: [14:31:25] [14:32:17] BERNARDA leaves the room [14:50:16] brian1lindsay joins the room [14:50:32] brian1lindsay leaves the room [15:30:14] Adam Roach joins the room [15:42:18] alanjohnston joins the room [15:42:36] alanjohnston leaves the room [15:44:09] alan.b.johnston joins the room [16:11:52] brian1lindsay joins the room [16:12:58] brian1lindsay leaves the room [16:13:38] brian1lindsay joins the room [16:13:51] brian1lindsay leaves the room [16:14:56] brian1lindsay joins the room [16:15:46] brian1lindsay leaves the room [16:29:36] DRAGE-C1 joins the room [16:34:22] DRAGE-C1 leaves the room [17:25:13] dhancock joins the room [18:04:37] brian1lindsay joins the room [18:05:50] brian1lindsay leaves the room [18:22:56] brian1lindsay joins the room [18:26:49] bernarda joins the room [18:29:47] bernarda has set the subject to: MARTINI Virtual Interim: Slides at http://aboba.drizzlehosting.com/MARTINI/Jan-Interim/ [18:43:17] bernarda leaves the room [18:45:41] bernarda joins the room [18:45:45] AndyHutton joins the room [18:52:34] mary.h.barnes joins the room [18:53:32] DRAGE-C1 joins the room [18:56:48] michael_procter joins the room [18:56:54] JOHNSCOMPUTER joins the room [18:57:07] michael_procter leaves the room [18:57:10] mhp joins the room [18:58:04] jon-ietf joins the room [18:58:54] AdamUzelac joins the room [19:01:37] Dial in Audioconference and WebEx details: [19:02:57] ben joins the room [19:03:30] I'm getting lots of drop outs in the audio--is it just me? [19:03:50] I'm hearing dropouts from some folks... but not all. Can we figure out who is dropping? [19:04:00] I am experiencing a delay getting into webex [19:04:02] same here--was that keith? [19:04:28] I'm not hearing any drop outs right now [19:06:06] actually, what I'm hearing is an occasional cutting off of start and end of some people--maybe vox or silence suppression. It's worse when multiple people talk at once. [19:06:23] Can some webex wizard point out how to make the window with the user list in it larger? [19:06:46] What do I dial on webex for UK - it doesn't like +44 [19:08:17] John: usually, you can poke around a bit and get it to give you a dial-in number and bridge number [19:08:47] Usually, it's a toll-free number, but I don't know for sure what it does for the UK [19:09:15] Meeting # 961 982 327 [19:09:23] RjS joins the room [19:09:45] Ah, here we go. [19:10:07] UK Toll Free 08-000288339 [19:10:52] Thanks, I'm on the call now [19:11:04] I hear no "break-up" as well [19:11:15] for what it's worth [19:11:17] Audio is great for me [19:11:21] It's coming and going for me--but seems to get better. [19:12:42] there's a "break-up" sound possibly when the "call-in" users join the audio bridge [19:12:48] spencerdawkins joins the room [19:13:02] Willis Dean joins the room [19:13:10] mlepinski joins the room [19:13:49] pkyzivat joins the room [19:14:34] Spencer going over http://aboba.drizzlehosting.com/MARTINI/Jan-Interim/IETF%2077%20MARTIN_IJan10Interim_How_We_Got_Here.pdf [19:15:16] Agenda slides at http://aboba.drizzlehosting.com/MARTINI/Jan-Interim/IETF77_MARTINI_Jan10Interim_Agenda.pdf [19:16:05] should "short timeline" be considered in the Famous Last Word category? [19:16:36] I'm barely able to understand people. I'm going to drop and dial back end. [19:16:46] Hey, when we chartered XCON, we had a "short timeline" also, based on the incoming proposals and number of participants. :) [19:18:18] And we KNOW how quick XCON was. [19:18:52] ben: you can have webex call you; at least it offered to call me. [19:19:34] Dean: Was? Still is. Too many years for me to recall. [19:20:27] Should be noted that the some real deployments have a static/dynamic model: If I can reach proxy X, I know it can reach the following list of numbers/domains [19:21:14] Anyone know how to get webex to tell you your participant ID again if you need to reconnect? [19:22:01] or how to get it to call me _again_? [19:22:24] Just start with the webex URL in the calendar and work through [19:22:43] https://workgreen.webex.com/workgreen/j.php?ED=131012752&UID=1110677752&PW=NNjRjYjAzNDVj&RT=MiM3 [19:23:18] If you aren't speaking please mute [19:23:24] ah, it reoffered when I disconnected [19:23:58] getting echo on someone's line now - please mute if not speaking [19:24:18] Cullen Jennings joins the room [19:24:38] In my experience, Webex has bad echo on VOIP connections. The only unmuted VOIP participant is Richard, and he's not in the jabber chatroom. [19:25:19] Is there a way to mute in webex? I'm muting from my phone's mute button [19:26:01] Yes. Right click on your own name in the participant list, and click "mute" [19:26:16] ok. Where's the participant list? [19:26:28] Ah! found it! [19:27:08] apparently can't display the shared slides and the meeting list at the same time, even with multiple screens [19:27:22] Dean: Get a Mac! [19:27:24] ;) [19:27:26] I can--get a mac! [19:27:28] heh [19:27:38] I am on a mac! [19:27:43] Dean - you can. [19:28:00] use the "control panel" thingy - and hover over the buttons on the bottom [19:28:06] toggle back and forth [19:28:26] Ah, ok. Thanks, AU! [19:28:40] np [19:31:29] why would the IP-PBX (or associated UA) ever register with the sp.com? [19:32:11] because it doesn't have its own domain [19:32:19] sp.com [http://sp.com] is the domain of the sp that routes calls to the pbx [19:32:35] they want to have publicly routable aors, though [19:32:41] so they borrow the aor from their sp [19:32:51] The PBX DOES sort of have its own domain. But its RFC 3263 pointer does not resolve to the PBX. Rather, it resolves to the sp.com proxxy [19:33:18] should be enterpriseA.sp.com then [19:33:35] @jon - but I get the point [19:33:37] Subdomaining sortof works. [19:33:44] mind you, not an endorsement, just an explanation :P [19:34:12] domain names are basically free and inexhaustible, it's deeply unclear to me why someone wouldn't bother to get one [19:34:33] jon -- it's not getting one, it's setting one up correctly. [19:34:51] Hadriel's document asserts that PBX owners don't want to provision DNS for their PBX [19:35:04] his doc still asserts they might not have one (the prob statement) [19:35:16] Scneario: I have an intermittently-connected PBX, so I hire an SP to act as my always-on proxy. When my PBX comes on-line, how does it tell SP's proxy that it is, and that SP's proxy should route calls for my domain to my PBX? [19:35:47] In this scenario, the RFC 3262 pointer for my domain does not point at my PBX, but at SP's proxy. [19:35:58] not having one is so 2000, not 2010 - but seriously - it's an edge case [19:37:52] Paul's point about the value of e164 global uniqueness is spot on - it's crucial for routing [19:39:44] Adam: That's true, if we want to solve the problem only for E.164 numbers. And that would be within our charter. But it wouldn't even be correct for all IMS deployments. [19:39:46] so one would replace the request-URI with the PBX's alias for that phone number, AND route the request to the PBX [19:39:58] Dean: Correct. [19:40:30] Which means we need a translation table. Which is one of the (I think important) aspects of the solution I propose in my draft. [19:41:06] yep. The question is how to dynamically populate the translation table based on what's happening at the PBX(es). [19:42:16] Bullet one: If ot hurts, don't do it. [19:42:37] I don't like this discussion around "doesn't pertain to "peering", but does for the PBX<-> SSP interconnection - there should be a difference, functionally [19:42:53] PBX<->SSP IS PEERING! [19:43:01] egggggzactly [19:43:11] It's just constrained by a service provider contract. [19:44:11] but this registration method will be used (morphed) into something that the we SPs, will use for 'peering', as we have the same problems. [19:44:22] Afraid so. [19:45:15] it's trial/error routing now - shoot it out and hope, timer expires or negative response, go to the next routing option. [19:46:31] Keith is right. IMS is just wrong-headed, and only works because of back-end static configuration. [19:46:36] sub/not to populate the translation table, possibly? [19:47:11] Adam: or maybe PUBLISH? [19:47:18] So, SP would subscribe to routing updates at PBX, and PBX would send routing updates in NOTIFY? [19:47:22] I agree with Adam's comment. I'd say that but am conserving voice in the unlikely case I have something original to say [19:47:37] AU or AR you agree with? [19:47:41] AR [19:47:45] TRIP over SUB/NOT [19:47:47] sorry, the voice comment [19:49:07] PUBLISH would be a viable alternative to AU's sub/not. I proposed another request method that would basically have worked like PUBLISH. [19:49:50] Dean: It was somewhat tongue-in-cheek for a response -- because it's precisely what I propose in my document. [19:49:57] So we have to dynamically populate the identity bindings in the SBC as well as the SSP proxy? [19:50:01] who is speaking now with Hadriel now? [19:50:24] Hadriel is the loudest voice on the call [19:51:12] And I bitched about the 3GPP implicit reg thing back then, but . . . [19:52:08] i also don't believe that publishing a requirements document as an rfc is an endorsement of any mechanism [19:52:23] jon: take that to the mic? [19:52:24] but that's really not the issue here today [19:52:29] no, it's not salient [19:52:33] let's keep on topic [19:52:43] right. We have what we have, but we may not want to build more on that foundation. [19:53:09] i thought keith's argument ultimately would be that 1) isn't sufficient without 4) [19:53:24] that is, why have an explicit indicator without it explicitly designating some particulr mechanism [19:53:43] yeah, jon is exactly right. [19:54:13] just saying "it's implicit registration" doesn't help you interoperate if the market is divisive [19:57:14] AdamUzelac bows in shame for not having read AR's draft [19:57:32] yeah, let's get to the proposals, Best way to analyze somebody's requirements is to look at the solution tey propose. [19:57:39] Don't worry -- I hit the high points in my slides. It's actually very simple. Could almost be a BCP. [19:57:49] Ultimately I want to understand what the indicator does indicate and I am not getting there at the moment. [19:58:42] I think, Keith, that the problem is that the "indicator" indicates multiple things, depening on context. Therefore it still isn't quite a cooked concept. [19:58:47] Keith: It means "whatever protocol extensions the MARTINI working group ultimately defines are being applied to this request." [19:59:02] Yeah, same thing. [19:59:38] And that's why I wanted a different request method, to make the difference really freaking clear. [19:59:52] And ultimately we are not necessarily defining PROTOCOL extensions [20:00:48] Well, to the extent that SIP is an application rather than a protocol, yes we are. It depends on the "what is the extension model of SIP" debate that we never finished. [20:01:47] Yes, but reverse-outbound routing of wildcarded domain registrations is NOT well documentednow. [20:03:20] bernarda leaves the room [20:05:39] Big question: IS the domain "owned" by the SSP, which then extends it to the PBX, or is it "owned" by the PBX, which requests that calls to the PBX are routed throught the SSP? [20:06:12] Option 2!!!! [20:06:42] So, that settles the question of who mints GRUU. [20:07:19] Leaving the "do the middle boxes and SSP need to be informed of each minted GRUU". [20:07:28] as a question to be resolved. [20:09:26] barking dogs now, instead of hums - awesome! [20:09:43] Who let the dogs in? [20:10:04] bernarda joins the room [20:12:44] Actually, the heartburn is resulting not from the extensions to REGISTER, but from underlying design limitations in REGISTER itself. We can fix the whole thing by replacing REGISTER with a new-and-improved model. [20:14:40] hey, I'm all for entirely replacing REGISTER with a PUBLISH event package. [20:15:09] Oops, forgot the :-) [20:16:37] this is a much cleaner way to address this problem - but what about non-contiguous ranges? = monster PUBLISH? [20:16:50] I have aquestion. [20:19:49] Spencer: go forward two slides, please [20:19:50] See my mail on wildcarding - its is used on IMS and also handles non-contiguous ranges - its a problem we fixed for reg-event in SUBSCRIBE/NOTIFY [20:21:16] davidm joins the room [20:22:14] keith is a little muddled. But that's probably just Keith. He's English, and they talk that way ;-). [20:22:40] G.711/2400 [20:22:58] Actually, it sounds like he's on the edge of a W-CDMA cell and is getting AMR degradation. [20:24:02] I'm also hearing some anomalies that I think are related to volume normalization across different speakers. If Keith's trans-atlantic call is quieter than everyone else... [20:24:33] H.. Does Web-ex bridge try to nornalize sound levels? [20:26:52] Dean - I don't think there's normalizing sound levels, based on the decibel level of Hadriel's line [20:28:53] Good point, AU. Or maybe Webex uses an Acme SBC, which grants Hadriel superior voice rights... [20:30:27] Can I come in at some point [20:30:28] My attorney always says "The question is not CAN I legally do this thing, it is SHOULD I do this thing that is legal?" [20:36:18] they make dirty olive flavored vodka? [20:36:30] Yes. You want mine? [20:36:41] no. No, I don't. [20:36:41] I don't actually like it, but someone gave it to me as a gift. [20:38:15] - in case this is the Gong Show [20:39:00] The problem is that anything described as "implicit" is inherently DWIM, not DWIS. [20:39:27] I think this is more "urinal cake flavored vodka". It's dirtier than olives could account for. [20:39:51] Oddly enough said cake is the same color as the yellow that pops up when Spencer changes slides. [20:41:59] "Stiired" seems much cleaner than "Shaken" [20:43:26] or maybe I'm confused. I prefer the one with option tag "dreg" over "implicit". [20:44:47] CPL [20:44:53] call processing language [20:45:09] Actually, it was widely deployed: all of dynamicsoft's proxy servcies ran on CPL. [20:46:05] @AdamR - was the Publish internal to the Enterprise/IP-PBX domain? and then the SSP would SUB to that data? and therefore the NOT would be from the Ent to the SSP? - if in draft, just let me know. [20:47:17] AU: PUBLISH normally would go from PBX to SSP. [20:47:30] The PBX could then subscribe to the SSP to find out about changes. [20:47:56] that's how I initially understood, thanks. [20:48:10] didnt you have somehting to say which ones _would_ have worked? [20:48:14] AH, that [20:49:08] Because you get those delightful tiny chips of ice in the final drink. :) [20:50:15] Sorry -- I missed what Spencer said was a quick ride to nowhere? [20:50:51] I think he was referring to Domain Registration. [20:51:04] Alt-root DNS [20:51:06] And the issue of potential "alt root" abuses of it. [20:51:44] e.g. if the SP doesn't check authorization... an attacker can use it for hijacking. [20:52:24] Route authentication/authorization is always an issue in dynamic routing updates. [20:53:31] Yes... but in Domain Registration it is worse because unless the SP is authoritative for the enclosing zone, it wouldn't know whether the registrant is authorized or not. [20:54:17] For example, if the PBX is registering mydomain.sp.com then the provider can figure out if it is authorized.... but if it is registering example.com, how would it know? [20:54:22] Same problem in BGP route updates. When I was at MCI, we boobooed one day and advertised all sorts of routes for stuff we couldn't actually reach. MAde a problem. [20:54:35] Yup. [20:55:22] In the end, ISPs each manually configured a set of routes they would accept from a given peer. i.e., bult a manually-provisioned authorization database. [20:56:18] Which is pretty much what the SPP has to do to decide whether or not it will accept regs for "example.com" from "pbx@company.com" [20:56:28] if a pbx is registering 'example.com', then they should present a cert for it mebbe [20:56:29] Sure... but in this case it might even be hard for the SP to figure out who the "owner" of the domain really is, if the SP is not also a domain registrar. This might depend on whether the whois database is up to date [20:56:44] and the sp should authorize it if the pbx can do that or a comparble proof [20:57:42] Essentially this is requiring the SP to have expertise equivalent to cert issuance/domain registrar.... which is a big step. [20:57:43] when we discussed this over lunch in japan, i got the sense it was really the tel cases that people cared about here, though [20:58:09] i think bernard that really it only requires them to be a domain/cert consumer [20:58:29] which again it's tough for me to see how that is really a technical or financial impediment [20:58:32] Yes, tel cases are most important.... but issue here is really with the domains that can be used in domain reg... it is very hard if the domains cannot be delegated by the provider. [20:58:57] but, as i said above, if tel is the most important case then this domain discussion is largely a red herring [20:59:02] 3263 will never really work for tels [20:59:13] So there is that implicit restriction... or else it becomes questionable whether the SP can carry out the required authorization. [20:59:41] Bernard: Jon also suggested that if the PBX is registering a domain, it should be able to present a cert for the domain that can be verified by SSP. This solves the auth problem. [21:00:04] It stills pushes the problem to a cert provider somewhere, of course. [21:00:53] yeah, that part doesn't scare me dean [21:00:57] the tel's scare me [21:01:26] For tel's, it is down to the same thing telcos use -- configured tables based on contracts. [21:03:04] whoa [21:03:07] and now the bridge breaks [21:03:07] wow [21:03:16] More like echo-parody! [21:03:43] That does it/. My next protocol is going to include parody bits. [21:04:02] Like evil bits, byt snarkier. [21:07:01] Dean: in my draft, it does not arise because the PBX is acting as a huge barrel of individual AORs, instead of a monolithic domain. [21:07:28] But what if it publishes a route to a user at some other domain? [21:07:40] Then it should get a 403 [21:07:42] The SSP is still having to do authentication/authorization. [21:07:53] Yep. It is. [21:08:17] The martini-up document goes into authentication and how you compare these kinds of requests. [21:08:27] Whatever the SSP uses to do authentication on a published route, it could use to do authentication on apublished domain. [21:09:53] I have two things I believe we need to deal with: 1) somewhere we still need a document where we can finish th e requirements discussion; 2) we need to discuss whether IETF needs to document all of this, e.g. TISPAN has a document that describes what it expects the PBX to be able to do to the SSP. [21:10:01] Dean: I think we're using different antecedents for the phrase "this problem." [21:10:11] The first hum is "Should MARTINI discontinue consideration of Domain Registration as described in Hadriel's "stirred" draft?" [21:10:34] No, it's all the "should or should not the SSP route requests for a specific domain to a PBX, when that PBX has requested such routing." [21:10:42] no, don't drop Stirred [21:10:48] Yes drop [21:11:02] Abstain [21:11:22] Silence from me [21:11:27] Well, I prefer to drop dreg in favor of PUBLISH. Both are better than "implicit" [21:11:49] richard says kill stirred. [21:12:15] HUM to drop dreg [21:12:26] no, don't drop it yet [21:12:34] Yes, drop (my vote) [21:12:34] Perhaps we should keep until we determine that other options are better able to meet the requirements [21:12:51] keep dreg. [21:12:54] no [21:13:07] keep [21:13:38] keep [21:13:40] keep -- probably warrants more discusison [21:13:54] keep it for now [21:18:41] I get 10 "No", 5 "Yes", 3 "abstain" [21:19:40] months? [21:20:37] Next hum: "Do we need a requirements document?" [21:20:54] Yes. [21:20:57] AdamRoach: can you "publish" a naked domain route, or only one-per-user? [21:20:57] yes [21:21:05] Yes [21:21:09] Yes. [21:21:09] yes, we need requirements [21:21:09] Yes, at least to capture some discussion in a solution independent way [21:21:17] yes [21:21:21] Richard: No [21:21:24] Mary: Yes [21:22:02] agree a set of requirements should be captured - doesn't necessarily have to be a seperate doc [21:23:34] Modified hum: Do we need requirements to be written down? [21:23:37] yes [21:23:40] Yes [21:23:40] yes [21:23:44] yes [21:23:44] Yes [21:23:44] yes [21:23:45] yes [21:23:46] yes [21:23:49] yes [21:23:50] yes [21:23:51] HUM - yes we need requirements [21:23:52] yes, we need the requirements written down [21:23:54] yes [21:24:01] Yes, but my criteria is that they still need to be drafted in a solution independent manner] [21:24:18] requirement #1: use REGISTER [21:24:20] Hadriel: (from webex): Yes [21:24:22] (fell out of bridge - redialing) [21:24:25] is that solution independent? [21:24:53] Richard: no (in webex) [21:24:54] That's not a requirement. It's a bad solution. [21:25:04] well then i hate it :P [21:25:07] (ok, I'm being judgemental). [21:25:32] I get 15 "yes", 1 "no" [21:25:33] jon - you misspelled REG1STER [21:25:38] hoho [21:25:52] Confirmed. [21:25:58] John had a starting list on the mailing list [21:25:59] @jon - Requirement #2 - use Publish - ;) [21:26:52] Req #3: Must not need any existing code changes [21:26:57] now we're getting somewhere [21:27:16] I prefer PUBLISH. [21:27:34] i would suggest not taking that hum, but w/e [21:27:35] Hum: Which is your preferred mechanism: Publish, Domain Registration or Implicit? [21:27:42] publish [21:27:43] implicit reg [21:27:45] publish [21:27:48] publish [21:27:49] publish [21:27:51] implicit reg [21:27:51] publish [21:27:53] abstain [21:27:53] publish [21:28:05] I'm really undecided. abstain. [21:28:11] implicit reg [21:28:20] implicit reg [21:28:24] implicit reg [21:28:28] implicit [21:29:18] Hadriel (from webex): Implicit [21:29:19] @Shockey - "grouchy old man" alert? :p [21:29:23] either Implicit or Domain [21:29:25] Richard (from webex): Implicit [21:29:29] implicit [21:29:30] implicit reg [21:29:39] Brian: pick one [21:30:02] I'll say Implicit then for now [21:30:12] Cullen Jennings leaves the room [21:31:19] I get 6 for "publish", 11 for "implicit", 0 for "domain" and 1 implicit or domain (Brian). [21:31:56] Did you get Dean's pre-hum publish? I see 7 [21:32:05] Brian voted implicit in teh end [21:32:06] Ah yes... will recount. [21:32:32] I'll change from abstain to stirred/dreg [21:32:45] publish or perish, just like the university. [21:32:57] Can I vote perish? [21:33:05] i think the hum overall is premature if we all agree we'd actually need requirements [21:33:12] which we don't have [21:33:13] agree with jon [21:33:19] PERISH sip:route-server@example.com SIP/2.0 ... [21:33:32] EXPLODEMYPBX [21:33:54] The PERISH method purges a previous PUBLISH? [21:33:59] New count... 7 for "publish", 1 "abstain", 12 for implicit, 1 for dreg [21:35:19] I thought the bridge forcibly disappeared 5 minutes ago? [21:35:21] We have like 40 people on the webex; do we have a lot of sleepers? [21:35:26] Next steps: 1. Requirements. [21:35:44] 2. More detailed discussion on each proposal on the list. [21:36:02] @Dean: apparently... [21:36:12] Did Keith just volunteer to be Requirements Doc editor? [21:36:33] No - I thought John had the token [21:36:39] @Dean: some of us are on twice - webex session and unassociated phone call [21:36:40] Suggestion of Interim in another month.... [21:36:48] Ah. [21:37:40] Potential for week of Jan 25... [21:37:47] 25th itself is bad, shoot for midweek. [21:38:13] We could have a Valentine's Day Love Fest last call. [21:38:14] Will put out a Doodle Poll and see what turns up. [21:38:41] Richard: Another Interim the week of February 8..... [21:38:42] Yeah, do aggressive forward booking. [21:39:15] mlepinski leaves the room [21:39:18] Everyone who has been doing note taking... please send notes to me and spencer. [21:39:58] John Elwell will own requirements capturing.... [21:40:16] Sorry Keith - was meant as a joke [21:40:19] Ha! [21:40:27] but good deflect to Elwell [21:40:32] bernarda leaves the room [21:40:34] AndyHutton leaves the room [21:40:39] ben leaves the room [21:40:39] Keith dodges well. Excellent chair skills. [21:40:42] mhp leaves the room [21:40:45] Adam Roach leaves the room [21:40:50] alan.b.johnston leaves the room [21:41:02] Willis Dean leaves the room [21:41:54] RjS leaves the room [21:41:59] AdamUzelac leaves the room [21:42:11] dhancock leaves the room [21:42:22] mary.h.barnes leaves the room [21:42:22] JOHNSCOMPUTER leaves the room [21:42:33] davidm leaves the room [21:59:51] DRAGE-C1 leaves the room [22:00:41] brian1lindsay leaves the room [22:42:32] brian1lindsay joins the room [22:54:28] jon-ietf leaves the room [23:02:00] spencerdawkins leaves the room [23:18:07] brian1lindsay leaves the room