[00:00:26] I'll be scribing the meeting this morning/evening/... [00:01:07] but there doesn't seem to be much point since we're both in the room... [00:02:08] shamus joins the room [00:02:16] brtech joins the room [00:03:21] HELIOPOLIS joins the room [00:03:41] we're on thedocument status slides [00:04:07] coopdanger joins the room [00:05:13] richard.barnes joins the room [00:05:52] suzukisn joins the room [00:06:46] kastaspella@gmail.com/Meebo joins the room [00:07:05] what is the question? [00:07:20] why does the initial INVITE have to have an offer? [00:07:51] please say: it's an error, it doesn't need to [00:08:12] milan0patel joins the room [00:08:25] sorry i'm late! [00:09:15] Shida Schubert joins the room [00:09:46] the regular feed is okay, the webex audio is very low [00:10:05] webex audio is being worked [00:10:42] RjS joins the room [00:10:42] suzukisn leaves the room [00:10:42] shamus leaves the room [00:10:42] brtech leaves the room [00:10:42] HELIOPOLIS leaves the room [00:10:42] coopdanger leaves the room [00:11:26] http://videolab.uoregon.edu/events/ietf/ietf764.m3u [00:11:31] What is the audio stream URL? [00:11:41] (I'm psychic :) ) [00:11:45] ta.. you prempted my question [00:11:48] lol [00:11:55] That is just scary Robert [00:13:06] ok i can hear you guys [00:13:31] The audio stream is working very well right now [00:13:34] hannes is bringing up the lost sync doc [00:13:42] http://tools.ietf.org/agenda/76/slides/ecrit-1.ppt [00:14:00] kpfleming has set the subject to: IETF 76 - Hiroshima, ECRIT WG == Audio Stream: http://videolab.uoregon.edu/events/ietf/ietf764.m3u [00:14:08] The webex works fine for the presentations [00:15:09] architecture slide [00:16:20] webex: http://www.ietf.org/mail-archive/web/ecrit/current/msg06840.html [00:17:19] massive chunk of xml on slide [00:17:25] lol [00:17:56] too many colons in his WGS84 URN [00:18:13] … [00:18:18] The problem with Germany form what I could understand was that "areas" of coverage were not defined beyond telephone prefix [00:18:30] perhaps we need to add that to the civic schema element [00:18:38] ;) [00:18:48] I suppose we could use addcode for it [00:19:25] i'm having a few issues with the audio stream...not sure if its my end or over there. [00:19:25] architecture slide, highlighting finland [00:19:41] finland FG slide: XML! [00:20:07] finland LoST slide [00:23:12] implications slide [00:24:14] presentation done [00:24:37] Randy joins the room [00:25:40] can we get someone to turn down the ceiling mounted infrared generators (lights) in this room? [00:28:04] Cullen Jennings joins the room [00:30:08] SOS parameter: milan [00:30:15] name? [00:30:31] name? [00:31:00] Milan, Hannes is calling you.. [00:31:02] am here on the jabber [00:31:09] RjS leaves the room [00:31:15] are you prepared to present on webex? [00:31:41] can you get on webex? [00:32:01] service URN update: looking at RFC 5031 [00:32:59] paul.erkkila joins the room [00:33:01] section 4.2, 4.3 [00:33:39] section 4.1 [00:34:38] looking at the draft - net effect: s/Standards Action/Expert Review/ [00:37:26] paul hoffman off-mic [00:40:12] could you hear me? [00:40:27] sort of... [00:40:28] http://tools.ietf.org/agenda/76/slides/ecrit-3.ppt [00:43:13] suzukisn joins the room [00:44:04] HELIOPOLIS joins the room [00:44:10] Question: How can we guarantee that legacy registrar will echo the URI parameter? Cullen only indicated that it might do so even if it didn't understand the tag. [00:44:16] audio really bad :( [00:44:46] i thought this is regular registrar behaviour [00:45:04] Cullen: If the registrator doesn't support the mechanism, how does the UA know? [00:45:22] cullen just asked the same question... [00:45:36] I was scribing for Cullen :) [00:45:53] sure [00:45:53] coopdanger joins the room [00:45:54] Cullen: It was previously discussed... what was the outcome? [00:46:06] Milan: I couldn't hear the question.... [00:46:14] Cullen: If the registrator doesn't support the mechanism, how does the UA know? [00:46:25] spencerdawkins joins the room [00:46:45] jjh31415927 joins the room [00:46:49] brtech joins the room [00:48:10] Barbara joins the room [00:48:19] Marc Linsner joins the room [00:49:15] was that Martin speaking? [00:49:22] Yes. [00:49:25] indeed :) [00:49:26] thanks :) [00:49:42] i didn't hear what you said, but i'm sure you were clarifying things :) [00:50:11] martin.thomson leaves the room [00:50:14] martin.thomson joins the room [00:50:51] is the WG still OK with the approach? [00:51:45] shamus joins the room [00:51:50] if this is a sticking point i can propose the use of option tags in systems where the UA needs to know of network support [00:51:57] would that be OK??? [00:52:06] Colman Ho joins the room [00:52:09] keiji joins the room [00:52:25] Why can't the REGISTRAR just return something in the 200 OK if the registration is understood? [00:52:54] That way if the REGISTRAR doesn't understand it, the UA knows that it may be hit and miss [00:52:55] sure....i guess its notharmful...I will ask the feedback here in 3GPP since we are in Beijing right now [00:53:03] sure OK! [00:53:24] Cullen: UA fully believes that emergency call will work... but registrar doesn't support it... when it gets used by a terminal connecting to a non-supporrting network, things are actually worse than without it. [00:53:29] i didn't hear cullen but I can throw this one to 3gpp and see what they say [00:53:36] Hannes: 3GPP won't have a flag day, so the problem could occur there too. [00:54:10] is the WG OK with the change to reg-type?? [00:56:30] Cullen: are we happy with the way the draft works, now that we understand it? We'll take it to the list... [00:56:42] RjS joins the room [00:56:57] IMHO, change to using reg-type is ok. [00:57:08] great, thank you :) [00:57:16] no objections [00:57:26] thank you to martin and Hannu for clarifications too [00:57:37] lost revision [00:57:50] http://tools.ietf.org/agenda/76/slides/ecrit-0.ppt [00:57:53] I think [00:58:42] HELIOPOLIS leaves the room [00:59:09] Jim joins the room [00:59:33] RjS leaves the room [00:59:52] RjS joins the room [01:01:12] possible changes slide [01:01:51] you can view the presentation realtime on webex... [01:02:04] In many places service bounaries for civic are based on telephone prefix [01:02:20] HELIOPOLIS joins the room [01:02:36] webex audio is a lesser quality, the ietf audio is better (but 10 second delayed) [01:04:15] put me in the queue to talk (on webex audio) [01:06:48] Who is we? [01:07:13] Who is the we that Brian is speaking for? [01:08:36] Is Brian representing a group larger than himself and Neustar? [01:09:06] sounds like NENA, possibly [01:09:15] Can we get confirmation please [01:09:28] will try to ask [01:09:49] There is no liasion between NENA and IETF... so probably no way to officially know.... [01:10:03] You could just ask him at the mic [01:10:21] i cannot get to the mic, i'm trapped in a sea of chairs and people :-) [01:10:25] Assuming you are in the room [01:10:39] lol [01:10:46] martin.thomson: can you ask him at the mic? [01:12:43] i heard: this is an extension, can you write an extension draft [01:12:48] and the answer is yes [01:12:55] :) [01:12:57] keiji leaves the room [01:12:57] thanks brian [01:13:05] hannes is suggesting that this go further [01:13:14] let's take this to the list [01:13:16] Audio has gone [01:13:22] Okay itis back now [01:13:35] did brian's NENA comment address the concern? [01:14:05] It did for the second set, but not for the first [01:14:12] martin.thomson: were brian's references to 'we' in references to NENA? [01:14:19] brian? [01:14:50] Brian clearly indicated that the civic validation issues were NENA issues, but he was not clear on the first set of issues [01:15:04] that were to do with Civic boundary mapping [01:15:05] ahh [01:15:17] well, there you go... [01:17:15] we'll have to assume that it was the royal "we" [01:20:11] yes of course, we are very pleased [01:20:18] suzukisn leaves the room [01:20:30] suzukisn joins the room [01:21:20] Ummm [01:21:32] If the UA can use it, and it will work, why do we care? [01:21:55] this sounds like an extension to me [01:21:57] This doesn't make sense to me [01:22:00] not a bug fix [01:22:10] If the UA can use it, why care? [01:22:37] Please ask the question [01:22:50] no more slides here, next presentation [01:23:01] yes, of course, but several of hannes suggestions are extensions and not bug fixes [01:23:12] contact info for error reporting for example [01:23:22] which I like a lot btw [01:23:29] @brtech: sure, it's a matter of degree [01:23:31] But if the route will still work, why is it an error? [01:23:51] because it's not the address used to dispatch responders [01:24:51] in current systems, it would be an error [01:25:06] in our newer systems designs, we can tolerate the alias [01:25:16] but we would rather have the "real" address' [01:25:20] Thanks for the clarification [01:26:17] i also live in an area where this is very common... roads that change names every mile or two, but have a 'proper' name used by the city and emergency responders (but not the post office) [01:26:30] yeah, many of us do [01:26:42] there is always an "official" name tho [01:26:45] right [01:26:57] and sometimes your GPS will announce the 'official' name and you have no idea what it's talking about :-) [01:27:05] haha [01:29:40] I think that is okay [01:37:15] That is false! [01:37:35] It makes the assumption that the main purpose of the deive is for making calls [01:37:39] PLEASE [01:37:43] POSt MY QUEDSTION [01:38:22] Thanks martin [01:39:26] Who says this? [01:39:57] This uses an emergency registration [01:40:25] marc? [01:40:38] marc, do you have a comment? [01:40:59] who is doing the jabber channeling for foks . I can take a question from to the Mic but tell me what to say [01:41:15] sorry that was really bad typing [01:41:35] If you tell me what question to take from the jabber room to the mic, I am happy to do that. [01:41:39] martin was the scribe, but he's standing up speaking and answering questions [01:41:42] Thanks [01:42:55] who is our? [01:43:19] Actually, some of the NENA folks I have just talked to about this are not anywhere near as concerned about this as Brian is [01:43:29] Specifically which group? [01:44:36] going to mic [01:45:08] But everybody has an access provider [01:45:32] And if you can block it at the access, then you reduce the problem [01:46:48] Thanks, I agree Marc [01:47:52] This is the normal call path for a device that doesn't normally make calls [01:48:10] keiji joins the room [01:48:35] suzukisn leaves the room [01:50:43] I think that the DoS issue is perhaps less of an issue than Marc is making out [01:51:38] If the Registrar only accepts regsitrations from domain with which it has relationships, that is local ISP networks, then I think the issue is somewhat mitigtaed [01:52:22] if the DoS is coming from a registered access network, then it is possible to get the location of the source [01:53:10] So you at least need to have some degree of local footprint to launch this attack [01:53:41] It isn't a we [01:53:46] there are way too many open access networks [01:53:48] I didn't find in the draft where it specifies for the UA to register as a user on the ISP??? [01:53:52] open WiFi for example [01:54:19] Marc, you can't access a network without someone providing access in the first place [01:54:21] In fact, I believe the draft implies the registration would be in the PS domain...?? [01:54:30] Yes it would [01:54:49] You mean ES domain i hope [01:54:50] but that access in no way implies what the registration would be…?? [01:54:57] yes, ES domain... [01:55:30] If you look at what is being proposed in Canada, for example, there is a VPN from the ISP to the stage-1 routing proxy [01:55:53] huh? [01:55:56] well, the VSP gets the identity of the LIS [01:55:58] At moment, this is only used for location, but it could easily be used SIP traffic also [01:56:01] and sends it to the PSAP [01:56:07] I missed such an architecture in the draft [01:56:08] the PSAP then queries the LIS for location [01:56:31] Not in the proposed Canadian solution it doesn't Brian [01:57:07] Nope [01:57:07] @marc: this isn't discussed in the direct draft [01:57:10] I'll go look at the drafts again, but I think it does [01:57:28] thanks Martin [01:57:44] In Ci2 brian, the VSP passes the call directly to a Stage-1 routing proxy, and the routing proxy gets the location form the LIS [01:58:16] the -direct draft bypasses all VSPs..... [01:58:27] yes [01:58:47] But it uses an ESRP-Proxy and Registrar [01:59:11] So channeling directly form the ISP network to the ESRP is a reasonable approch [01:59:22] Though it may not be the only approach [01:59:36] when the UA registers with the ESRP Proxy/Registrar, it's assign a contact-id with the domain of the ESRP [01:59:53] It gets a Public GRUU [02:00:13] slide: overview [02:00:14] Public does not equal access provider domain... [02:00:21] slide: L2 considerations [02:00:38] It equals the device on the ESRP [02:00:38] http://tools.ietf.org/agenda/76/slides/ecrit-4.ppt [02:02:21] slide: EAP considerations [02:03:59] slide: how to use EAP? [02:05:11] Just sent some review comments: http://www.ietf.org/mail-archive/web/ecrit/current/msg06847.html [02:05:29] thanks bernard [02:06:24] suzukisn joins the room [02:06:38] Question: Should the "Emergency NAI" use some of the concepts of the "SOS URI" (e.g. different types of emergencies?) [02:06:56] Question: Or does it not matter? [02:07:24] that's a question that would need to be asked if that was the solution selected [02:07:47] there were other methods, similar in many respects to the sos parameter solution for SIP [02:08:42] In general, emergency scenarios with web portals would be a nightmare.... hot lining or not. [02:09:49] It can take minutes to logon with some of the more obtuse web portals on a tiny handset screen... it's a nightmare in a normal situation, let alone an emergency. [02:09:57] indeed [02:10:09] I think that's where this is going [02:10:23] Into the nightmare zone? [02:10:27] how do you provide the service anyway - in some respects this is why the direct thing came about [02:10:59] Yes... unauthenticated hotspots aren't going to provide VSP services. [02:11:15] but they could open up the LIS, LoST server and ESRP [02:11:34] without requiring a portal and a credit card and so forth [02:11:42] Opening appropriate pinholes in the firewall, sure. [02:11:47] exactly [02:12:07] like 5060?, I don't think so [02:12:10] The question though is to how to only permit emergency calls via SIP.... [02:12:26] well... many of those also do their nastiness via DNS redirection, so they'd have to allow DNS queries for these various services to succeed, but continue to redirect other queries to their portal [02:12:35] not necessarily 5060 - IP addresses more like [02:13:03] The DNS redirectors are quite generic and often broken (see RFC 5625). [02:13:18] that being _another_ problem :| [02:13:25] and not dynamic, so they can't respond to the need to change their behavior for an emergency call, presumably [02:13:30] I'd be surprised if in general they would even support SRV RR queries. [02:13:39] right [02:13:45] those would probably be blackholed [02:14:07] Many SIP UAs will not react well to receiving bogus A/AAAA RRs corresponding to the web portal in response to their queries.... [02:14:22] likely most [02:14:31] so a set of requirements on these guys might help, but they would likely just ignore it...unless a regulator was breathing down their necks [02:14:41] I often get error messages about certificates failing to verify, registration failures, etc. [02:14:54] you don't just get crashes? wow. [02:15:40] Typically takes a few minutes to recover from all the errors, fill in the portal forms, restart the SIP UA, etc. And this is at coffee shops with nor pinholes at all. [02:16:06] it's not a friendly environment [02:16:26] On SIP UAs with no browser.... it won't work at all. [02:17:04] and the providers of such services have no intention of them being used for emergency calling at all [02:18:34] Bernie joins the room [02:18:35] and i wonder if they'd even be willing to deploy such a solution and take on the potential liability of their hotspot or uplink failing in some way during an emergency [02:18:38] Cullen Jennings leaves the room [02:18:41] Right. It's very unlikely any of those operators would support L2 "Emergency Services" facilities or anything like that (such as what is in IEEE 802.11u). Many are using APs that are several years old anyway. [02:19:15] And even if they happened to buy an AP that supported this, they'd turn it off to avoid the liability. Why take that on for a free service? [02:19:22] exactly [02:20:29] Even in enterprise, I don't see it happening. There are guest VLANs, but there is no claim of emergency services support and typically they're not unauthenticated (e.g. guests get a reg code at the front desk) [02:20:58] on our guest LAN it's open, but you are right, that's common as well [02:21:51] So in general, the fewer requirements on the network access provider, the better. No requirements is the ideal solution. [02:22:35] I wouldn't even have an expectation of finding a LIS in a guest scenario. [02:22:47] trying to follow 2 meetings simultaneously....did we handle the PSAP call back draft? [02:23:09] we're talkig about callback now [02:23:15] ok thanks [02:23:28] shamus leaves the room [02:23:36] Randy leaves the room [02:26:55] kpfleming leaves the room: Disconnected [02:26:56] for marking call back we would like the requirement removed from older 3GPP releases [02:28:38] hannu just suggested that this was the decision made in Beijing, I suppose that you would know better than us ;) [02:29:06] what were the choices cullen offered? [02:29:45] call back for the unauthenticated case? is there a regulatory requirement? [02:29:54] not usually [02:29:55] RjS leaves the room [02:30:04] Bernie leaves the room [02:30:06] but the PSAPs really want it [02:30:07] Hannu was relaying info from me [02:30:17] thanks [02:30:23] useful to kow this [02:31:24] richard.barnes leaves the room [02:31:32] actually this mechanism proposed by cullen was something we discussed here [02:31:50] I'll add more on the list probably next week [02:31:57] keiji leaves the room [02:32:01] discussed here = Beijing [02:32:19] coopdanger leaves the room [02:32:25] jjh31415927 leaves the room [02:32:47] suzukisn leaves the room [02:32:57] Jim leaves the room [02:33:03] martin.thomson leaves the room [02:33:07] martin.thomson joins the room [02:34:24] Paul Hoffman at the mike.... [02:34:52] Marc Linsner leaves the room [02:34:55] martin.thomson leaves the room [02:35:34] spencerdawkins leaves the room [02:38:10] richard.barnes joins the room [02:38:14] richard.barnes leaves the room [02:39:14] Barbara leaves the room [02:40:56] Cullen: GEOPRIV and ECRIT doing -bis documents before they are deployed is a problem... either stop sending drafts to ADs before they're done.... or stop "fixing" things that aren't broken! [02:41:56] paul.erkkila leaves the room [02:42:53] RjS joins the room [02:44:02] RjS leaves the room [02:46:50] Shida Schubert leaves the room [02:48:26] Colman Ho leaves the room [02:56:03] Question: What additional security is provided by using the Meruvengian VSP instead of direct? [02:57:54] Richard: What are the security goals? [02:59:32] Question: Instead of talking about what we don't want... can we articulate the security goals that we do want? [03:00:54] If there any assumption of a relationship between PSAPs and VSPs?? [03:01:25] How do you verify that a call comes from a service provider (e.g. http://matrix.wikia.com/wiki/The_Merovingian)? [03:20:28] milan0patel leaves the room [03:22:18] kastaspella@gmail.com/Meebo leaves the room [03:49:28] richard.barnes joins the room [03:54:30] richard.barnes leaves the room [03:55:50] richard.barnes joins the room [04:33:16] RjS joins the room [05:41:53] RjS leaves the room [05:43:14] RjS joins the room [05:45:54] RjS leaves the room [06:03:55] richard.barnes leaves the room [06:06:33] HELIOPOLIS leaves the room [17:08:01] brtech leaves the room: Replaced by new connection