[06:36:29] --- Barry Leiba has joined
[06:36:45] --- RandyG has joined
[06:36:53] --- raj has joined
[06:38:07] --- Ted_Hardie has joined
[06:38:23] <Ted_Hardie> Currently agenda bashing
[06:38:44] <Ted_Hardie> Sip Events package & saml-policy added
[06:39:24] --- raj has left: Replaced by new connection
[06:39:32] --- raj has joined
[06:41:04] <Ted_Hardie> Now presenting draft-winterbottom-location-uri-00 (winterbottom, peterson, thomson, eds)
[06:41:15] --- mstjohns has joined
[06:41:51] <Ted_Hardie> Location URI reference to LI; distinguishes between provisioning and use of location
[06:42:17] <mstjohns> http://tools.ietf.org/wg/geopriv/agenda?item=agenda63.txt has the agenda et al
[06:42:34] <Ted_Hardie> Privacy concerns
[06:43:14] <Ted_Hardie> Authors which to say that they believe it is within the privacy context, and reinforced them.
[06:43:15] --- dotis has joined
[06:43:42] <Ted_Hardie> (Authentication and authorization are required to retrieve L:I from the LS, Privacy Rules are applied each time)
[06:43:50] <dotis> Privacy
[06:44:09] <dotis> A Lr retrieves LI from the LS directly
[06:44:38] <Ted_Hardie> Next point: "A URI does not identify the Target" is challenged by Henning on the grounds that practical deployment may cause bleeding.
[06:44:51] <Ted_Hardie> of information from the URI.
[06:46:30] <dotis> Changes by reference by value versus location.
[06:47:03] <dotis> There are limitation with crypto. You may wish to limit exposure of information.
[06:47:37] <dotis> The same type of problems are seen with IM presents.
[06:49:10] --- faw has joined
[06:49:41] <dotis> Value and location information, without knowing who has access. How to you configure this access or authorization prolicies.
[06:50:35] <dotis> As with Presents, you establish default prolicies. Someone must do that work.
[06:51:01] <dotis> This must involve the use of crypto where you need to know who has which keys.
[06:51:19] <dotis> Cypto must know who holds keys.
[06:51:38] <dotis> That cost may too high for some applications.
[06:52:06] <dotis> These differences must be stated in the draft.
[06:52:35] <dotis> This draft was just to get the idea published.
[06:53:18] <RandyG> Hannes agrees with Jon's points (regarding fundamental differences between encrypting a value for a recipient and passing it on, versus sending a link and using access policy) but says the document does not say this and needs to.
[06:53:52] <dotis> It is diffcult to generalize a reference model. In the signaling channel, it would be difficult to know who is within this channel.
[06:54:18] <dotis> It would be difficult to know who is doing the forwarding.
[06:54:24] --- cnewman has joined
[06:54:42] <dotis> If you dont' care who gets to see the information by value. Then this works.
[06:54:57] <dotis> By reference also works when one does not care.
[06:55:20] <dotis> There are also costs related to bandwidth.
[06:56:49] <RandyG> Ted points out that the draft doesn't contain any mandatory-to-implement schemes
[06:57:19] --- klensin has joined
[06:57:26] <dotis> There is a different problem when things are done by reference. With my known set, one must know what the user has with respect to referencing ability to dereference
[06:57:30] <RandyG> Hence the sender needs to know the capability of the recipient to dereference
[06:58:03] <dotis> There must be manditory to implement.
[06:58:53] <dotis> This is not an fully defined draft. Adding the manditory aspects can be added.
[06:59:06] <RandyG> Ted and Jon agree that at some point the proposal must include a mandatory-to-implement scheme
[07:00:00] <dotis> There is a fundamental difference beween say I will allow specific by knowing the channel. This is different than saying anybody has access.
[07:00:10] <dotis> There is still the problem with forwarding.
[07:00:35] <RandyG> Brian points out that with by-reference, you could send location unsigned and unencrypted, but know that only entities within the signalling path will have access; this differers from a by-referemce model with access permitted by all
[07:01:14] --- prkj has joined
[07:01:44] <dotis> This would not work for routing.
[07:02:05] <dotis> There are options which do not involve crypto.
[07:02:21] <dotis> Passwords dont work...
[07:02:50] <dotis> The draft must be careful about discussing this issue with respect to access.
[07:03:34] <dotis> This draft is attacking by value.
[07:04:05] <dotis> The tone of document should change.
[07:04:50] <dotis> Geoprive DIDF-LO Usages.
[07:04:59] <RandyG> ---switching to draft-ietf-geopriv-pdif-lo-profile-01.txt --
[07:05:00] <dotis> PIDF-LO
[07:05:45] <dotis> Recommendations on subset of GML to express shapes, crs, precision.
[07:06:22] <dotis> Provide recommends on base seof of PIDF-LO civic fields for a nominal level of precision.
[07:06:50] --- tom_creighton has joined
[07:07:00] <dotis> Looking for help on completing the draft for routing and dispatch applications.
[07:07:44] <dotis> Routing would put you past boundaries.
[07:08:18] <dotis> In there are differences between regions that may this effort fruitless.
[07:08:55] <dotis> Geo or civic locations seems wrong to drop information.
[07:09:13] <dotis> Describe this as a hard problem without a solution.
[07:09:35] --- jfischl has joined
[07:10:51] <dotis> New, Clarified examples, cardinalaity issues, RFC 3825 data.
[07:11:27] <dotis> There was a mistake on the naming of the draft. The standard needs to be renamed to PIDF for than PDIF.
[07:11:40] <dotis> Get input on Civic Form.
[07:12:14] <dotis> Http Enabled Location Delivery.
[07:12:46] <dotis> Location Information, LI,
[07:13:04] <dotis> Li is an access network service.
[07:14:30] <RandyG> --- discussing draft-winterbottom-http-location-delivery-01.txt ---
[07:14:43] <dotis> Extensions to not affect the HELD payload. This transverses NATs, REliant only on the presences of IP. Comon location request protocl, type of netowrk has no affect.
[07:15:21] <dotis> An issue that affects both, is object lifetime.
[07:15:33] <dotis> Location information changes.
[07:16:19] <dotis> Sometimes you want the current location. You need to know which you are getting.
[07:16:19] <dotis> The location object will get deleted.
[07:16:51] <dotis> There should be more discussion on the what is return when a URL is querried.
[07:17:02] --- Ted_Hardie has left: Logged out
[07:18:25] --- mstjohns has left: Replaced by new connection
[07:19:35] --- raj has left: Disconnected
[07:19:50] --- Thomas Roessler has joined
[07:19:54] --- dotis has left: Disconnected
[07:20:10] --- RandyG has left: Logged out
[07:20:30] --- dotis has joined
[07:20:49] <dotis> Sorry, network difficulty.
[07:21:36] <dotis> When looking at the network from a sip prospective, there are problems with distictive names that change.
[07:22:07] --- prkj has left
[07:22:19] <dotis> The retention of location information, this information is retained for the duration and then an additional six months.
[07:22:56] <dotis> There is then the commercal use of location information. Saying there is a set time would be difficult.
[07:23:02] <dotis> This is a minimum.
[07:23:23] <dotis> The draft has provision for retension timers.
[07:23:48] <dotis> In an emergency context, this is not applicable.
[07:24:17] --- klensin has left: Disconnected
[07:24:18] <dotis> The retension timer is based upon the query.
[07:24:23] --- RandyG has joined
[07:24:44] --- cnewman has left: Disconnected
[07:24:53] <dotis> There is a need to know the policy, unless this is in the url, there is a problem.
[07:25:37] <dotis> Make a clear distinction whether this is a snapshot or current location.
[07:25:56] <dotis> Without this information, there could be routing loops created.
[07:26:21] <dotis> Get location from a URI,
[07:26:29] <dotis> Target publishing location update URI,
[07:26:48] <dotis> SL serves a request from LR.
[07:27:32] --- Thomas Roessler has left: Logged out
[07:27:45] <dotis> On behalf is problematic. Not all devices are capable of determining their own location.,
[07:28:29] <dotis> The routing information may request LI, but unaware of its location.
[07:28:42] <dotis> This is mandated by regulation for emergency services.
[07:29:58] <dotis> By reference needs a fair amount of work. Are there policy mechanism to handle this problem. Is this by private organization?
[07:30:23] <RandyG> Ted says on-behalf-of needs quite a lot of work; can't get away with just saying it is by private agreement or regulation
[07:30:54] <dotis> Split the requires to transport, from trusting the information as it is handled.
[07:31:05] <dotis> This need more work to express this problem.
[07:31:24] --- mstjohns has joined
[07:32:23] <dotis> Location based upon the access network is a mistake. It gets the location wrong based upon the ends of the tunnel.
[07:32:59] <dotis> The network that you are in "at the moment" knows, but this includes lifetime information.
[07:33:35] --- tom_creighton has left: Disconnected
[07:33:36] <dotis> Reliance upon the LS is a problem.
[07:33:38] --- Barry Leiba has left: Disconnected
[07:33:38] --- mstjohns has left
[07:33:48] --- faw has left: Disconnected
[07:35:02] <dotis> To use DHCP to find the server, and then going through DNS to do the same thing seems to be redoing this search. The concept of information in the host has a problem for discovery.
[07:35:42] <dotis> The discovery has limitations, including the DNS example. There are also issues with tunneling.
[07:36:27] <dotis> Building upon protocols with well-known problems will continue these issues.
[07:37:22] <dotis> Generating a location from an IP addess does clarify the mechanism.
[07:37:56] <dotis> Is there a relationship from other protocols from retrieving location information?
[07:38:16] <RandyG> Question on how this compares to OMA LIF
[07:38:37] <RandyG> Answer: LIF doesn't use PIDF-LO, plus other limitations
[07:38:49] <dotis> Yes, there are similar protocols, but there are problems with MLP. Such as the problems with fixed ports.
[07:39:43] <dotis> Please explain what is different such as header changes.
[07:41:06] <dotis> Geopriv ECRIT, prevention of DoS for Emergency Services.
[07:41:31] <dotis> This may be to fool emergency responders.
[07:41:53] <dotis> Example showing SIP proxy.
[07:43:00] <dotis> The location is retrieve from a distributed directory, whereas the end host holds the location information.
[07:43:40] <dotis> The first requires the proxy knows the end point locations.
[07:43:45] <dotis> This could be difficult.
[07:43:51] <RandyG> Slides distinguish between case where SIP proxy determines location of call originator versus where call originator provides its own location
[07:44:08] <dotis> End host may have access to location information that could be modified.
[07:45:06] <dotis> There is a risk having this information in the hands of the end-user, but why would the end-user spoof this information.
[07:46:08] <dotis> The main use of spoofing is to divert emergency responces.
[07:46:51] <dotis> This could be done to prevent police enforcement or to increase the damage caused.
[07:46:57] --- Thomas Roessler has joined
[07:47:29] <dotis> There is a problem today with people sending responses to the wrong location.
[07:47:42] <dotis> That was dealt with by including location information.
[07:48:32] <dotis> There is a implication that the SIP proxy must be trusted to handle location information, whereas spoofing the proxy is also possible.
[07:49:18] <Thomas Roessler> and how about spoofing by walking?
[07:49:39] <dotis> If the target spoofs, there is always a problem by this moves to the proxy as well.
[07:49:57] <dotis> There is two locations, the device and the user.
[07:50:31] <dotis> There may be real location information that is not transferred to the end user.
[07:50:50] <dotis> This would be real location information.
[07:52:23] --- Melinda has joined
[07:52:34] <dotis> What if a phone fetches location versus the location information, versus holds the information from the same source. There needs to be an identity that describes where the information is immediately derived.
[07:53:13] <dotis> The intent is not to have another discussion of references.
[07:53:29] <dotis> Assume this is independent of any reference information.
[07:53:32] --- faw has joined
[07:53:51] --- raj has joined
[07:54:24] <dotis> Determine the quality of the emergency call real-time to allow ranking of calls.
[07:54:47] <dotis> Catch adversary non-real-time.
[07:55:12] <dotis> Authenticate emergency call to the PSAP.
[07:55:48] <dotis> Might require public key, deployment and performance concerns.
[07:56:51] <dotis> It would be good to sign information provide to the PSAP to see that it has not been modified.
[07:57:04] <dotis> The signer is then held accountable.
[07:57:31] <dotis> This assumes the provider signs the information and not the end host.
[07:58:22] <dotis> With typical network access authentication, the user is not known to a visited network.
[07:58:32] <Thomas Roessler> ... and nobody ever steals a mobile phone?
[07:58:49] <dotis> There will also be providers that do not provide location signing.
[07:59:39] <dotis> There is then also a problem with replay attack. This could be handled by combining it with SIP signalling. Keeping this separate may be a problem.
[08:00:21] <dotis> Should this issue be handled... What is more important, location or identity?
[08:00:39] <dotis> Do you accept without identity?
[08:00:59] <dotis> Do you accept without asserted location?
[08:01:50] <dotis> Emergency specific authentication may be useful to handle when communication credits have lapsed.
[08:02:45] <dotis> The greatest concern from PSAP people is location information, but regardless, they will accept the call.
[08:03:26] <dotis> Improving priority may happen, but this could create problems. Location is more important.
[08:04:07] <dotis> If you can handle all the calls, then yes you take all the calls, but what happens when you can not.
[08:05:27] <dotis> The source of the date, versus the path. The source of the data is coming from a different path than what is used to place the call with different set of identities.
[08:07:07] <dotis> If data is not bound to the signaling session, and the data is coming outside this channel then replay remains a problem.
[08:07:53] <dotis> The problem that is being highlighted, the only entity that is within both channels is the end user.
[08:08:24] <dotis> The question is there a mechanism to allow the data to safely pass through these two channels.
[08:08:52] <dotis> Could Geopriv reduce these risks?
[08:09:44] <dotis> What is more important when under DoS? PSAP may not know that it is under DoS attack.
[08:10:04] <dotis> This knowledge happens after the fact.
[08:10:49] <dotis> There added information of no authentication may flag such an attach by seeing no authentication for a larger number.
[08:11:24] <dotis> There are two resources, the caller resources and the responder resources.
[08:12:05] <dotis> We are not closer to a solution, we need to define the problems.
[08:12:12] --- jfischl has left: Disconnected
[08:13:52] <dotis> Is it useful to bind location within routing information? Is there information that should be included to provide greater ability to resolve what is happening.
[08:14:35] <dotis> There may be an advantage to allow information added and signed by the provider.
[08:15:01] <dotis> This may improve the quality of the location information.
[08:15:26] <dotis> Location information may be one piece of information, but there may be many pieces.
[08:16:13] <dotis> There may be need to separate out the information related to the provider from that from the end device.
[08:17:50] <dotis> After conferring with co-chairs, there will be a decision with respect to the specific goals.
[08:18:58] <RandyG> --- draft being presented is draft-mahy-geopriv-sip-loc-pkg-01.txt ---
[08:19:10] <dotis> SIP defines Event Notification Framework. This includes filters for these events notifcation. SIP could be a "using protocol" for geopriv.
[08:21:16] <dotis> Asynchronous changes. A continous gradient into discrete events needs polling rate information to be meaningful. There can also be geometric parameters or percentage information added.
[08:22:10] <dotis> Civil location properties change (just named set/lists of polygons.)
[08:22:34] <dotis> A combination of all these parameters.
[08:23:20] <dotis> Not having domain information means this is easier to do this with SIMPLE.
[08:24:25] <dotis> Presences must include non-human objects, and location only signaling.
[08:25:43] <dotis> Filter symantics include polygons, or reference URIs. Use these in subscriptions.
[08:26:30] <dotis> Location disclosures regarding privacy policy. SIP notifiers may lie.
[08:27:10] <dotis> How does this fit with draft-ietf-sip-location-conveyance?
[08:27:19] --- Melinda has left
[08:28:01] <dotis> This draft does not include an event package, SIP intermediary handling of location.
[08:28:27] <dotis> Does this need to be done in SIP or SIPPING.
[08:29:38] <dotis> Define an event filter formation and relate that to SIP conveyance but these groups don't have the experience to handle this task.
[08:30:36] <dotis> There are binds that need to be improved for this to be useful.
[08:32:17] <dotis> About Privacy concerns. Privacy may be harder than first considered.
[08:33:04] <dotis> The privacy settings may cause problems when policy is not properly updated.
[08:33:26] <dotis> The example is a buddy list regarding location information.
[08:34:06] <dotis> The event filtering should be done here and then folded into XCAP.
[08:35:21] <RandyG> hum if geopriv should take on filter format
[08:35:26] <dotis> Should geopriv take on the task of filter formating, more for than against.
[08:35:28] <RandyG> stronger for than against
[08:36:06] <RandyG> re-hum
[08:36:33] <RandyG> no one against (last time people mis-heard 'against' as 'again')
[08:37:32] <dotis> When doing filter format in SIMPLE, unless this is strongly bound with SIMPLE, there may be a data model and event model that must be considered.
[08:37:56] <dotis> draft-guenther-geopriv-saml-policy-01
[08:38:23] <dotis> policy condition, actions, transformations.
[08:38:43] <dotis> support ofr SAML assertions and conditions.
[08:39:22] <dotis> extends comon-policy framework in the same way as geopriv-policy does.
[08:40:44] <dotis> Two have read the draft. Both shake their heads.
[08:40:52] <dotis> This would be useful.
[08:41:01] --- cyrus_daboo has joined
[08:41:11] --- cyrus_daboo has left
[08:41:26] <dotis> Taking the question to the mailing list.
[08:42:00] <dotis> There are issues with geopriv that still do not have solution to be considered.
[08:42:11] --- Thomas Roessler has left
[08:42:14] <dotis> That is the end of the meeting.
[08:42:22] --- RandyG has left
[08:42:47] --- raj has left
[09:03:56] --- faw has left: Disconnected
[09:04:35] --- dotis has left