[00:02:36] Marc Linsner joins the room [00:03:52] suzukisn joins the room [00:05:36] Why doesn't this apply to things like light [00:05:44] For example if the light gets brighter than [00:06:28] yes, agree [00:06:35] Cullen Jennings joins the room [00:06:50] I think we want a filter like changed by that is greater than or less than [00:06:59] Martin T wrote a draft for Simple on requirements for continuous presence [00:07:13] In room seemed to be agremetn on general > and < filter [00:07:26] thank you [00:07:36] Jim joins the room [00:08:40] Shida Schubert joins the room [00:10:02] martin.thomson joins the room [00:10:52] Bernard presenting RFC3825bis remotely. [00:10:55] hehehe... he sounds like a jockey [00:11:09] Slide : 3825bis [00:11:22] coopdanger leaves the room [00:11:39] I wish that the slides on webex would stop skipping about [00:11:48] We really need a wideband codec for Bernard - he sounds like he is stuck inside a 1500 Hz can [00:11:52] Colman Ho joins the room [00:12:03] yeah... hehehe [00:12:33] It's amazing to me that a) webex won't do this (wideband codec, working voip) [00:12:54] and b) that we don't have a bunch of decent phone patches for IETF meetings [00:12:57] This is much better now [00:13:08] skype into webex bridge played out via another skype client into a microphone to the room audio... [00:13:20] He is on slide 4 talking about remaining issues. [00:13:23] although since this is only the 2nd meeting with webex i guess we forgive them and hope we do better next time [00:13:36] well you have to be able to download the webex client for free because a zillion people download and we can't pay royalties on every downlaod. So if only there was a royalty free wideband codec :-) [00:13:40] that may be better than what we are doing [00:14:06] there are now 3 wideband codecs that are RF [00:14:20] Seriously the problem we are having right now is probably 80% linking the VoIP with the in room audio [00:14:33] probably right [00:14:34] yep... [00:14:42] phone patch [00:14:47] Yah, was pretty exciting to see the G.719 announcement [00:14:56] yeah [00:15:07] arch slides [00:15:07] I was surprised [00:15:42] why is Alissa so good? [00:15:46] Rumor has it similar discussions have been happening around some other codecs [00:15:50] James Galvin joins the room [00:15:50] sounding [00:15:51] I was using Skype so I guess it went through a transcoder.... [00:16:01] Alissa presenting Geopriv-arch [00:16:04] Slide: geopriv-arch [00:16:08] she is sitting at the PC that is connected to the bridge [00:16:10] usually skype is better than most pstn [00:16:22] ah! [00:16:31] Right now she has a lapel mic and is standing at front of room [00:16:37] Might have been better calling Alissa over Skype.... would have avoided transcoding. [00:16:52] uhuh [00:16:53] But streaming audio is really excellent quality. [00:17:05] we could have all been on skype [00:17:09] yes, the mc audio is good….just delayed... [00:17:10] yes it is [00:17:25] I don't notice the delay Marc [00:17:35] It seems to fit with theslides quite well [00:17:52] jaggli claims the client is doing most of the buffering but I am suspicious [00:17:53] _/ [00:18:00] That was me raising my hand [00:18:07] call into the webex, you'll hear everything 10 seconds sooner….although lousy quality [00:18:18] Moving onto Held Identity presented by Martin Thomson [00:18:24] You said that yesterday and I didn't notice then either [00:18:27] Slide : held-identity-extensions [00:18:54] lol [00:18:59] Barbara joins the room [00:19:07] Webex if frozen [00:19:35] looks okay to me [00:19:41] not showing the slides on this end [00:20:05] working for me #19 [00:20:11] *8( [00:20:20] webex works for me [00:20:32] calvin joins the room [00:20:41] Slides are frozen at this end [00:21:15] Working now [00:22:07] shamus joins the room [00:24:15] Cullen on the mike. [00:24:15] shamus leaves the room [00:24:15] Colman Ho leaves the room [00:24:15] Marc Linsner leaves the room [00:24:15] brtech leaves the room [00:24:15] James Galvin leaves the room [00:24:15] Jim leaves the room [00:24:15] BAboba leaves the room [00:24:15] calvin leaves the room [00:24:15] Barbara leaves the room [00:24:15] suzukisn leaves the room [00:24:28] Mic. [00:24:35] Barbara joins the room [00:24:39] That was a big loss of people [00:24:45] Indeed. [00:24:53] I was unceremoniously dumped. [00:24:59] *8( [00:25:07] Welcome back then Barbara [00:26:08] Does Cullen want this for each idnetifier we include? [00:28:19] Meebo? What's your name.. Did you still want me to ask the question on the mic? [00:28:28] TS-29-061 [00:28:39] Meebo is James [00:28:48] It would be good to ask [00:28:56] IMSI can be checked [00:29:07] It is defined in TS-29.061 [00:29:21] Brian Rosen joins the room [00:29:25] James W to be more clear [00:30:33] Yeah, I think it's important to specify that last initial... [00:30:39] So you are saying that for each of the identifier, do you need to define an explicit security mechanism (authentication mechanism) is the question right? [00:30:56] yes [00:31:55] I think that that is a very bad idea [00:32:14] Yes [00:32:25] But in some networks you must be able to do that [00:32:42] WiMAX for example really requires the NAI [00:32:47] Randy joins the room [00:32:56] And you can definitely then map the NAI against the IP address [00:33:12] Dude, you are totally loosing me man.. [00:33:35] Identifiers in LCPs are necessary in some networks [00:33:47] Can you format the question in the form of a question when you want me to go to the mic.. Appreciated! [00:35:18] It is more of a statement, in some networks, the IP address is not enough to identify the Target [00:35:34] In WiMAX, the NAI is the key identifier [00:36:14] I can use the NAI, provided by the Target, and when I query the RADIUS server, I validate the IP address by getting it in a response form the RADIUS server [00:36:33] Marc Linsner joins the room [00:36:33] Marc Linsner leaves the room: Disconnected. [00:37:46] LCP with identity extensions is required, maybe not for all identifiers, but certainly for some [00:40:17] James Galvin joins the room [00:40:28] The WiMAX case is definitely LCP [00:40:37] I will try and get on the webex bridge [00:40:41] BAboba joins the room [00:41:00] MIC: I'd like to get in the queue to address the MAC address case... [00:41:05] Marc Linsner joins the room [00:41:11] I am not fine with that [00:41:14] NOT [00:41:14] suzukisn joins the room [00:41:22] rababy joins the room [00:41:37] i am on the line for mic. [00:41:44] In the WiMax case, isn't there a network entity that matches source IP against NAI to prevent spoofing? [00:41:47] ray joins the room [00:42:12] With a MAC address, requiring authentication may not be enough to authorize easily.... there is typically no mapping of userid to MAC address in an enterprise. [00:42:45] It is easier to prove authorization in the WiMAX case, since the device has a device cert containing the MAC address. [00:42:50] calvin joins the room [00:43:17] There also are LCP cases if the LIS is on the same LAN as the client making the reuqest (IEEE 802 Emergency Service Study Group has been looking at these scenarios). [00:43:57] There are also some "3rd party landmark" requests ... where the client requests the location of a landmark (*not* another user or device). Landmark = switch or AP port. [00:44:02] shamus joins the room [00:44:22] Can the webex bridge talk to the room?\ [00:44:32] yes [00:44:36] that is what I used [00:44:37] Jim joins the room [00:44:38] I just unmute everyone... [00:44:43] If the request isn't for a "landmark", it may be disallowed, even if there is authentication... if you can't map the authentication credential to a MAC address to enable authorizatino. [00:44:55] Adam Roach joins the room [00:44:58] please be quiet on the bridge, if you make noise I'll mute you... [00:44:59] why doesn [00:45:05] t IP address work [00:45:19] Did I miss something? [00:45:22] you can map from IP address to any other identifier can't you? [00:45:32] is LIS-to-LIS germaine for this? [00:45:33] Colman Ho joins the room [00:45:39] You could have an LCP-style request to the ISP that knows the L-3 identifier, but has to pass what's effectively a 3rd party request to a downstream L2 supplier to get the real location ? [00:45:48] albeit that's still a pre-established trust relationship [00:45:53] Wait, what? Did I hear "RADIUS"? I thought we were working with DIAMETER for WiMax/LTE/etc...? [00:45:54] Not if you you're not tracking IP addresses LOL [00:46:11] Yeap, you heard RADIUS. [00:46:51] RADIUS is being widely used for this.... both wireless (802.11i) and wired (Call-Check) cases are handled by many access devices. So RADIUS has the mapping between NAI, MAC address and location/port but NOT IP address. [00:46:58] Almost all WiMAX deplotments will be RADIUS Adam [00:47:04] Since the info is all in the db anyway, why bother with DHCP? [00:47:27] Virtually all enterprise access uses RADIUS... even unauthenticated Ethernet. [00:47:29] do you mean use LLDP? [00:47:46] No. LLDP is not widely implemented on clients. Neither is DHCP location. [00:47:56] Bernard, for the auth request in WiMAX the AAA must return the IP address of the Target if the NAI was used as the key [00:47:59] Neither is IEEE 802.11k/v/y, etc. [00:48:24] Yes, where the AAA handles IP address allocation it will have the IP address.... but not in IEEE 802.11 or Ethernet cases where it doesn't. [00:48:35] Okay [00:49:03] Are people happy with the outcome? [00:49:16] no…we'll take it to the list [00:49:21] BAboba -- or many CDMA cases, for that matter. [00:49:21] What is the outcome? [00:49:33] 3rd party only [00:49:37] Many commercial RADIUS servers now have the ability to build location databases.... FreeRADIUS has had this for a while, others do too. [00:49:45] imo…3rd party only... [00:49:46] LCp identifier sare okay providing a usecase if defined? [00:50:00] not what we just decided [00:50:07] 3rd party only [00:50:20] Then I object strongly [00:50:24] VERY STRONGLY [00:50:27] but…. asking the LIS to authenticate that a telephone number is owned by the requester is onerous [00:50:45] I can provide a use case for WiMAX [00:50:49] for my case? [00:50:56] gateway from Class 5? [00:51:09] it's easy [00:51:13] I can provide a use case for IEE 802 access. [00:51:27] because the LIS and the gateway are in the same domain and operated by the same entity [00:51:34] did you guys get it? [00:51:40] my point…you can't authenticate the identifier belongs to the requester, hence, you authenticate the requester [00:51:43] This doesn't answer the question being asked at all [00:51:55] Is it third-party only, or is it allowed to be used for LCP too? [00:51:56] Bran--your case there is a trust relationship between the class 5 switch and the LIS, so the switch can ask for any number for which it has access. [00:52:09] I agree... it *is* possible to authenticate the requester.... [00:52:31] Only if the outcome is not decided [00:52:34] Martin is answering the question in person.. [00:52:38] yes randy, I think what Jon said: treat it as 3rd party will work [00:52:42] Authenticating the requester makes more sense here [00:52:49] but you must handle each identifier separately wrt the identifier belonging to the requesting... [00:52:54] Brian--right, I'm agreeing [00:52:55] we can authenticate the requester [00:53:09] and limit its access to TNs that we know it is authoritative for [00:53:19] okay, sorrt [00:53:26] Better to handle some LCP as 3d party then to allow 3d party to appear as LCP [00:53:34] what's the problem? I'd like to pay attention to this presentation [00:54:05] I am not happy about idnetity extensions only applying to 3rd party requests [00:54:13] it wont [00:54:22] In that case I am okay [00:54:28] but we'll need to provide a lot more justification for those cases where LCP is used [00:54:30] What about my LIS-to-LIS example above? Is that a third party query even if the reason the first LIS initiated it is to satisfy LCP ? [00:54:50] we'll probably need to identify which identifiers are used [00:54:51] LIS to LIS is thrid-party [00:55:04] Okay thanks Martin, that clarifies enough for me [00:55:05] ok [00:55:06] Thanks [00:55:10] LIS-to-LIS is a 3rd party request - you need the pre-arranged, bi-lateral arrangemetn [00:55:17] Shida indicated third-party only, and I was concerned [00:55:28] Nope. I didn't. [00:55:37] @shida: :) [00:55:37] I did think that was the consensus, but we'll see [00:55:44] 3rd party only [00:56:09] For the 3rd party case you need to distinguish various forms of "pre-association".... [00:56:10] But I wasn't confident with the outcome so I asked the question whether the outcome meant 3rd party only.. [00:56:16] the consensus was that 3rd party has use cases, but 1st party needs better justification [00:56:41] My apologies Shida [00:56:44] we can do that for WiMAX, but I'm struggling to work with others [00:57:00] "Pre-association" shouldn't mean "anyone with a big enough gun can get the info". [00:57:16] @baboba: certainly [00:57:38] Bernard has some 802.11 cases too I think [00:57:53] at least to the extent that we can prevent the law from doing these sorts of things anyway [00:58:31] You should actually have concrete evidence of the mapping.... In IEEE 802.11 it's not very practical to map NAIs to MAC addresses to authorize on the LIS even if HELD is doing authenticattion... but some MAC addresses represent landmarks.... [00:59:43] Why don't they have ellipse in the shape list? [01:00:33] Alissa: Talk about it in the document! [01:00:46] Jon: MAC case can be LCP.... [01:01:38] James, that's a question to the current presentation right? [01:01:44] yup [01:02:12] Jon: IP address and MAC as a secret... [01:02:34] If you send *both* IP address and MAC that would be fine... LIS can decide which (or both) are relevant. [01:02:43] Alissa: They need to be explained! [01:02:57] James, it can be added it but it's just not in the first draft.. [01:03:05] ta Shida [01:03:19] Cullen: Can say more on IMSI is there is more to say... [01:03:24] kpfleming joins the room [01:03:47] I am not sure I understand that last comment Bernard [01:04:36] HELD can include both IP address and MAC address, then LIS can decide which to use based on what info it has. If it is tracking IP address, it can use that. If not, maybe it can use the MAC address. [01:04:57] If both are provided, then they need to match. [01:05:03] Sorry, it was the IMSI comments that had be baffled [01:05:18] @baboba: doesn't that introduce the potential for confusion/lying given that the MAC address could refer to another target? [01:05:25] I was just channeling Cullen :) [01:05:37] ;) [01:06:26] @martin: the LIS has to authorize somehow.... could be the LIS is on the same LAN, in which case it checks the source MAC against the HELD MAC... could be WiMAX in which case it can check the MAC in the device cert.... [01:07:26] that's what we said, apparently that's not enough [01:07:41] Also, LIS could check AAA db to see if it can map the MAC address to something else that it can use to authorize (e.g. NAS-Port-Type, IP addr, NAS-Identifier/NAS-IP-Addr, NAI (perhaps the same as the authenticated HELD identity)). [01:08:48] Come Martin T, I am waiting for your questions [01:09:02] I'm saving them [01:09:09] If it can't find anything to authorize, then it has to treat it as a 3rd party LCP.... though I would assert that authorization in that case can be based on *both* the authenticating identity *and* the request identity. [01:09:12] BTW Dorothy is presenting : indoor location [01:09:14] this is an awful solution [01:09:25] Yes, I agree it is not so wonderful :( [01:09:59] *8)... go get 'em Roger [01:10:39] How can you have an offset from something that doesn't have a clear starting point? [01:10:53] I loved Dorothy use cases - I found them very compelling [01:11:11] the use cases are good, the network policy one is a little scary, true [01:11:46] These are location in general usecases for an enterpie though, rather than compelling to this draft in particular [01:11:54] It's a great use case, IT departments will love it, (I will hate it :-) [01:12:22] you don't want anyone to know where you are... [01:12:27] RjS joins the room [01:12:43] which door of the mall is the front one? [01:12:48] So to say... but they already do :( [01:12:53] A door in Australia is 900mm wide though, so where in that am I talking about? [01:12:55] RjS: or the 'fifth' one [01:13:07] I want them to know where I am , but the fact that would use that to controll what SSID I could use had not occurred to me [01:13:17] And a sliding door to a main building is a lot wider [01:13:19] rjs: the reference is locally significant [01:13:21] yeah... interesting [01:13:33] the value inside the reference elements isn't dictated... [01:14:03] Most AAA servers don't yet support location-based authorization, but some do. So if you're setting in the courtyard in the sun, maybe they won't let you on the network, 'cause you could be an intruder :( [01:14:31] Sun hating IS guys [01:15:10] 'Elevator' '5A' [01:15:48] 'Stairwell' 'North-East' [01:16:31] Why are standard names needed? Just provide purely locally meaningful descriptive info. [01:16:34] I like our solution a lot more Martin [01:16:35] Far less ambiguous [01:16:37] Yea, what Richard said. [01:17:38] Why not build a compound location then, rather than mangle the civic location? [01:18:56] Shida, please ask my question> [01:19:17] This defines a new location type, rather than churning an existing location type? [01:20:15] sheda is in the mike queue [01:20:22] Thanks [01:20:52] This is also churning exsting geopriv specifications, something that we got chewed up about in ECRIT yesterday [01:21:25] This needs to be an extension not a redefinition [01:22:59] But this isn't extending it, it is redefining it [01:23:25] well, it is extending it. It doesn't redefine anything [01:23:27] Does it change the schema namespace? [01:23:56] The answer is yes [01:24:06] Therefore it redefines the schema [01:24:11] with their syntax, it doesn't [01:24:14] So it is a redefinition and not an extension [01:24:22] I would be inclined to change the schema [01:24:37] no, I added one CA type [01:24:40] I would be inclinded to make a compound location [01:24:44] they added zero CAtypes [01:24:56] To add a CA type to civic changes the shema [01:25:25] Yes, INT changes schema [01:25:37] it adds a CAtype [01:25:44] this doesn't add any [01:25:47] the way they defined [01:25:48] So it redefines, it doesn't extend [01:26:03] no, it doesn't [01:26:06] INT doesn't have this problem [01:26:22] these are new CAtypes, or they may as well be [01:26:24] Okay [01:26:26] I don't want to defend this syntax in general, but it doesn't change the schema [01:26:42] I'm not talking about schema, I'm talking about definitions [01:26:42] Yes, I want new CA types for this [01:26:43] I want this to be a compound location [01:26:47] semantics [01:27:22] Then I have serious plroblems with it [01:27:41] We know which protocols will be used to convey the PIDF-LO data? [01:28:54] James, the line got cut off.. I will ask your question at the end if it is unresolved. Please do remind me though. [01:29:30] Its okay, I think Martin T will probably address my point [01:31:16] Shapes should follow GAD [01:34:46] Location provides accurate location even outside of the local context. [01:35:13] mcharlesr joins the room [01:37:19] Martin presenting the slide.. Alissa is uploading the slide right now.. [01:37:25] Patient please :-) [01:37:43] Are you a Docotor Shida [01:40:16] I meant patience... Although I feel like a bad doctor trying to diagnose the problem (long thread of jabber), and unable to do so :-P [01:40:46] Here is the slide folks : thomson indoor location [01:41:04] mcharlesr leaves the room [01:44:03] lol [01:44:25] Comments guys? [01:44:33] I love this draft... *8) [01:45:29] Back to Dorothy presenting the last slide on her presentation >> indoor location [01:45:43] I have a question: [01:46:02] Since this location is to be obtained using an LCP [01:46:24] i am n line. [01:46:25] How does the device specify the application to the LIS [01:46:56] That is, any location provided by a LIS MUST have applicability outside of the local context as well as inside the local envirnment [01:47:29] ray leaves the room [01:50:12] Thanks Martin that is exactly what I was getting at [01:50:55] ;) [01:51:32] In answer to marc, today, if you sent that information to a LoST server, the route request would return an error [01:51:54] Brian? [01:52:31] the binary representation is OK [01:53:52] Next presentation on Geodetic-Civic Address Translation Protocol. [01:53:55] Slide : george-geopriv-address-translation [01:54:52] James, HUH? [01:55:10] If you don't understand xml elements, you ignore them [01:55:51] that's right, of course, the stanley proposal makes that no longer safe [01:56:45] yeah, because you can understand INT, but not relative offset [01:56:55] yes [01:56:59] you wouldn't be ignoring xml elements you didn't understand [01:56:59] martin: so, you are implying that if the offset is 15000000 meters away, the route would be wrong? [01:57:23] or you would not get a route at all [01:57:58] @marc: of course [01:58:32] that would be a large 'interior' location [01:58:37] @marc: the exact number varies on how much specificity you demand from the base civic address [01:58:59] I don't see this as confined to "indoors" [01:59:05] sure: "Front door" is maybe a meter uncertainty [01:59:10] it's more of a "local" reference thing [01:59:25] right. imagine something like the Pentagon building in Washington DC, which is enormous and has thousands of rooms, but likely a single civic location [01:59:31] @brian: precisely [01:59:39] yep, it's a local reference using a well-known crs.... [01:59:53] AA175 Seat 22A [02:00:46] How many people have read the draft? [02:00:58] Not me sorry [02:01:35] RjS leaves the room: Computer went to sleep [02:05:05] James Galvin leaves the room [02:07:05] Is someone prepared to help Robins offline? [02:07:18] ? [02:07:19] yeah i will [02:07:29] Thanks Brian [02:09:43] Richard is now presenting location policy extension. [02:09:51] Slide : barnes-geopriv-policy-uri [02:10:57] Adam Roach leaves the room: Computer went to sleep [02:17:27] kpfleming leaves the room: Disconnected [02:19:30] I want the ability to set location capabilities agains a URI [02:19:53] This is kind of policy [02:20:09] But it is more than just being able to invalidate a URI [02:21:37] rababy leaves the room [02:22:04] calvin leaves the room [02:22:23] Randy leaves the room [02:22:32] Cullen Jennings leaves the room [02:22:32] No way! [02:22:33] Jim leaves the room [02:22:39] A Georpiv meeting finishing early! [02:23:16] Can we get a view of remaining HELD draft priorities [02:23:31] suzukisn leaves the room [02:23:32] ? [02:23:34] What? [02:23:41] Too late I guess [02:24:01] Why don't you just ask the chairs on the list. [02:24:02] martin.thomson leaves the room [02:24:11] Colman Ho leaves the room [02:24:11] Sure [02:24:15] laters all [02:24:28] Barbara leaves the room [02:24:42] shamus leaves the room [02:24:51] kastaspella@gmail.com/Meebo leaves the room [02:26:17] Marc Linsner leaves the room [02:28:10] Brian Rosen leaves the room [02:31:05] Shida Schubert leaves the room [02:41:18] suzukisn joins the room [02:41:54] BAboba leaves the room [02:44:01] Shida Schubert joins the room [02:44:45] Shida Schubert leaves the room [02:46:19] suzukisn leaves the room [03:08:12] Adam Roach joins the room [03:59:52] calvin joins the room [04:01:33] calvin leaves the room [04:08:24] Adam Roach leaves the room [14:24:48] Marc Linsner joins the room [14:29:56] Marc Linsner leaves the room: Disconnected. [19:42:10] Marc Linsner joins the room [22:08:30] BERNARDA4 joins the room [22:36:02] Marc Linsner leaves the room