---------- Minutes - GEOPRIV - IETF80 Summary (prepared by Richard Barnes): 1. Chairs' Introduction The chairs noted that since the last IETF, one GEOPRIV RFC has been issued (RFC 6155) and three more documents are in the RFC Editor queue. They noted their intention to issue WGLC on draft-ietf-geopriv-deref-protocol and draft-ietf-geopriv-policy-uri and to submit a publication request for draft-ietf-geopriv-dhcp-lbyr-uri-option. 2. GEOPRIV Policy draft-ietf-geopriv-policy Jorge Cuellar gave a presentation on the GEOPRIV Policy document, providing a detailed description of grid-based fuzzing algorithm. Several participants noted that there is still some ambiguity in the algorithm, and that its privacy properties are not completely understood. There was consensus to restructure the fuzzing section in the following form: -- A registry for fuzzing algorithms -- Privacy goals for fuzzing algorithms -- Performance of the "simple" and "grid" algorithms relative to the goals The authors will work to have a new draft ready by 15 May 2011. 3. Civic Address Extensibility draft-ietf-geopriv-local-civic Brian Rosen discussed the current status of the document. The major remaining disagreement is whether all extension elements should have the same level of RFC 2119 requirement, or whether some should be SHOULD and some MAY. Discussion will continue on the mailing list. 4. LIS Discovery through Local Gateways draft-ietf-geopriv-res-gw-lis-discovery Ray Bellis gave a status update on this draft. There have been some minor changes in -01, and the major remaining issue is how to address concerns about what domain name to validate in TLS. Brian Rosen and Martin Thomson agreed to review the document. 5. HELD Measurement Extensions draft-ietf-geopriv-held-measurements Martin Thomson gave an update on this document, and said that he believes that it is basically ready to ship. A show of hands indicated that only around three participants had read the document, so the chairs requested some additional review before moving to LC. Geoff Thompson agreed to review the document, and Martin Thomson said that he will recruit a few more reviewers. 6. Location Transformations draft-marshall-geopriv-location-transform Roger Marshall presented this new document, which would create a "location transformation" service that could translate, for example, between geo and civic, or between coordinate reference systems. Given the fairly rough state of the document, the authors will release at least one more version before requesting WG adoption. 7. HTTP Geolocation Header draft-thomson-geopriv-http-geolocation Martin Thomson presented this proposal to add a Geolocation header to HTTP. The header would use basically the same syntax and semantics as the SIP geolocation header, but use HTTPbis ABNF. There was general interest, but the authors will revise the draft to have better privacy considerations and more discussion of use cases before requesting WG adoption. Raw notes from Terry Manderson and Roger Marshall follow. -------- Monday 28th 0900-1130 Morning Session I: Grand Ballroom RAI geopriv ***10m Chairs intro & administrivia Minute taker: Terry Manderson ***DISCUSSION OF DRAFTS IN IESG PROCESSING: =-=-=-=-=-=-=- 20m draft-ietf-geopriv-policy (J. Cuellar/H. Tschofenig) Jorge: Up to rev 23, really want to complete it. Location Obscuring - give an area I am in. Interesting thing is worrying about movement assume we do not force the user to lie Shall each run of the protocol render a different output with same input? or Shall each run of the protocol render a different output with same input? What happens when you present the same location? Question: Paul Are you talking about privacy between individulas or servers Jorge: no I am talking about different scales of accuracy and leaking information to ietf members for example. Am I leaking to you more info than what I wanted? Problems about state. I prefer stateless algorithm. Intersection of circles can be small, providing accuracy. Can we prove one algorithm is better than the other? PII concerns, naming. Indistinguishability. Solution: Cannot present random 'circles'. Create big "indistinguishable regions" as big as possible. Idea of regions allows presentation of certain circle. Circles will naturally overlap Algorithm then allows to measure exact amount of leakage. Calculations are easy. Simple. Gives a lot of privacy protection. Would like to move forward Martin Thompson: like to disagree, algorithm doesn't define a number of things. It doesn't define what to do with reported locations. Doesn't describe what to do with uncertainly, and doesn't describe grid transition. Also concern about amount of privacy gained. A fairly complication. I disagree with "simple". More iterations required. Like to see the 'other stuff' published, don't want to be held up on this work. Interested in what it takes to get this document published. I don't think pursuing this algorithm is worthwhile. Jorge: martin: those a secondary points, the bigger issue is should we include the algorithm in this document. Jorge: the purpose is to provide some privacy, yes it doesn't specify many things. Martin: my point is I can't implement this yet Q from floor (missed name):. Initially we said will define a registry to list algorithms. and that is fine and works. Richard mentioned providing support for static location. Previous algorithm required state to be kept. With a grid state storage goes away. And description more clear. Dealing with uncertainty has always been an issue and has to be dealt with. Complexity: this is not a trivial piece of work Martin: uncertainty, fine to defer- but still needs addressing. Need to think about accuracy v's precision. Getting this right will take a long time, not happy with this as a baseline Brian Rosen: want us to publish. If we can't define this. then get it out of the document and publish. Richard Barnes: Make a proposal about how to go forward. Propose three things: 1) document requirements/criteria. 2) have a way for the client to know about different algorithms. 3) some sort of initial example for registry ie one that we know its properties. Admittedly it would be a crappy algorithm Jorge: I haven't heard that people don't agree with algorithm, Richard: not arguing on the merits of the algorithm. About moving the document forward Jorge: Algorithm provides precise notion privacy. Need a good solution soon. Need a baseline algorithm. Speaker: you are making an argument for 1 algorithm not baseline. Jorge: no. Speaker v Jorge: discussion about limitations and number of algorithms. Somewhat heated discussion. Alissa (as chair): under proposal that we use registry and simple algorithm it means that we can move the draft forward. Jorge: I don't see we need to put a simple and wrong algorithm in the document Speaker from floor: I would like to have a hum, I am tired of this argument. James: Multiple algorithms will get intersection problems, I understand that. Why not put in initial algorithm with a list of caveats. and put this algorithm into a new draft that addresses the caveats. People can then judge the algorithms. Or put BOTH algorithms in the documents. Richard (chair): lets have some Hums. Hum 1 result: in favour of privacy in document Kieth: I'm not sure where you are going with this. Martin: I think what richard is getting at do we have 1 or more, and how we prime the registry. Keith: if there is no consensus on any algorithms where do we go. Speaker: concern over repeated location updates. Richard: Keith if we don't have consensus we will cross that if we come to that. james: do we take out the registry? Not sure how many questions you have so not sure what to hum for. back to hums (richard clarifies hum) Martin: I don't think we have discussed all the issues about multiple algorithms. Speaker: but we had consensus on that for many years. Alissa: if we have multiple algorithmss, then we assume that we have to deal with them. Hums: (again) Multiple algorithm in favour from hum. what should document define: Simple algorithm be included: no result. martin: want to see something in the document, but ambivilinet Speaker: people don't remember what the algorithm is. Keith: does this mean the document go forth no algorithms in a registry. Richard: we have to have some algorithm Howard: I think that needs to be clarified. no algorithm == no move forward Martin: please hum again. Hack to hum: support for simple algorithm by hum. support for grid algorithm by hum. Will confirm those hums on the list. Speaker: I want next steps plan. How do we make progress on overall problem. It will take time to describe consequences of grid algorithm. Don't stop discussions. Martin: there are other options on the table. Richard: recaps. and describe 4 things to go into the document James: like to add two things for each algorithm, describe what it good at and what it is not good at. Speaker: add Martin to geolocation policy due to his lengthy involvement. Keith: worried about putting algorithms in doc with no consensus. Raised concerns about author status. Some discussions on authors.. Speaker: I think need to set a milestone for the changes. Alissa: september. ***WG DRAFT UPDATES: =-=-=-=-=-=-=-=- 20m draft-ietf-local-civic (B. Rosen) Brian: How to extend PIDF problem: how to pass via DHCP Problem how to avoid explosion of incompatible types. Change registry, no more numeric types. Add a mechanism for passing things to DHCP, add a CAtype. Martin: wondering if common requests would be accommodated by this draft, ie concourse, gate etc Brian: can we take that to the list. Martin: sure. Brian: back to preso Add column to registry, values A and B. A under "should implement" by standards track. Martin: I don't see benefit to additional fields. Brian: people need to know what PIDFs they will receive. Martin: any reasonable implementation will be able to handle any extension. Richard: Type B elements a general client might not be able to handle it. Martin: perhaps take this to the list as I don't agree. =-=-=-=-=-=-=-=-=-=-=- 20m draft-ietf-geopriv-res-gw-lis-discovery (R. Bellis) Ray: became WG draft after ietf 79 rev'd to -01 (third party usage expunged, IPv4 private address changes, /56 IPv6) Outstanding issue: HELD rules for validation of SSL impossible to apply. Please review. Hoping to get to last call for summer. Alissa: can we get a couple volunteers to review? Brian? Thanks we will hunt more people down. =-=-=-=-=-=-=-=-=-=- 10m draft-ietf-geopriv-held-measurements (M. Thomson) Martin: Minor update References fixed, cellular, GPS and Galileo. Ready to ship. Richard: would be good to have a few more people to review this before shipping. ***NON-WG DRAFT PRESENTATIONS AND DISCUSSION: =-=-=-=-=-=-=-==-=-=- 20m draft-marshall-geopriv-location-transform-00 (R. Marshall) Translation of address/location types. eg take civic and return geodetic (lat/lon) Many types of transformations. -Between civic location types -Between datums PIDF-lLO Not meant to be unit conversion tool next steps: Protocol framework missing. Speaker: notion is you use LOST service and provides a hint to the service to do the transform. Marshall: correct Speaker: mention two drafts, why is this draft targeted as informational? Marshall: no reason, should be standards? Any objection to being standards track? =-=-=-=-=-=-=-=-=-=-=- 10m draft-thomson-geopriv-http-geolocation (M. Thomson) Martin: Modelled on sipcore-location-conveyance. -header based on httpbis -no geolocation routing header -427 error defined -relies in sip draft for content == short document. are there privacy concerns? Richard: Privacy needs to be addressed. will be need for permission framework. Leverage W3C api. Alissa: clarify, that isn't in the draft? Martin: no. Geoff Thomson: Need use cases to allow thoughts on privacy cases, eg emergency services. Martin: I can't see any uses there. Alissa: Any thoughts on usefulness of this? Speakers: think its good to look at it. Like better understand interoperation. support exploring the work area. Martin: more support needed for W3C api. But not sure where this work lives. Richard: I think we have a fair number of people that understand that API in this group. Alissa: fin. -------- Geopriv Meeting Notes IETF80 Prague, CZ 3/28/2011 09:00-11:30AM --- Notetakers: Roger Marshall, Terry Manderson Chairs: Richard Barnes, Alissa Cooper --- Posted agenda: INTRO: 10m Chairs intro & administrivia DISCUSSION OF DRAFTS IN IESG PROCESSING: 20m draft-ietf-geopriv-policy (J. Cuellar/H. Tschofenig) WG DRAFT UPDATES: 20m draft-ietf-local-civic (B. Rosen) 20m draft-ietf-geopriv-res-gw-lis-discovery (R. Bellis) 10m draft-ietf-geopriv-held-measurements (M. Thomson) NON-WG DRAFT PRESENTATIONS AND DISCUSSION: 20m draft-marshall-geopriv-location-transform-00 (R. Marshall) 10m draft-thomson-geopriv-http-geolocation (M. Thomson) --- 10m Chairs intro & administrivia --- Have to decide on Geopriv policy... --- DISCUSSION OF DRAFTS IN IESG PROCESSING: 20m draft-ietf-geopriv-policy (J. Cuellar/H. Tschofenig) --- Jorge Cuellar: Location obscuring Model (static) to protect privacy is okay, as long as you don’t move! We assume that we don’t force the user to lie. Paul Oftus?: Are you talking about privacy between two individuals, or privacy in some other sense? Jorge: clarifies – am I leaking to you – much more information than I intended? Would prefer to have a stateless algorithm Not only one device, but many devices, many sources of location information, and difficult to keep them in sync. Can we prove that one algorithm is any better than another? Example: PII (personal information) why? Because not too many people have same name. Notion is indistinguishability. Solution: this version -23 contains a simple algorithm that solves this. Pseudocode algorithm shown 2 types: from meters to degrees, and if I’m in one of those regions, what choices do I have? I think this is a simple algorithms Martin Thomson: disagree with a few things that you’ve said. Doesn’t cover some things. Doesn’t describe what to do in areas where overlap occurs, uncertainty, transition between areas. Also, concerned with amount of privacy that is claimed to be gained, e.g., 1.3? This is a fairly complex process, a complex problem to understand, and think that we need to go through it more closely. I do agree that there are other portions of this draft that are necessary, and want to get this published for these. Jorge: are you saying, doesn’t deal with Martin: doesn’t say under what circumstances do you generate an updated report. I do think we need to leave off with this algorithm, and get the other parts published. Jorge: we need an algorithm that provides some location privacy, yes the 3 points you’ve mentioned – are not specified – I don’t care. Martin: a long path before I would agree with this. Hannes: from beginning, we thought we would come up with a registry that would contain various algorithms – one size doesn’t fit all. I don’t see a problem with having a two-stage approach, having a baseline algorithm, and having a mechanism so others could come up with their own algorithm. Richard sent email, need to come up with a civic location algorithm. Before, we had an algorithm that required the keeping of state (remembering prior circles). Hannes: on complexity, Jorge has provided a pseudocode, Robert has shown a different way – I don’t have a preference. My overall fear for location based services, is that there is some resistance to providing too fancy of features that will likely keep implementers from providing, and users from using these things. There is research going on – Carnegie-mellon – not a trivial piece of work. Martin: really only got up to call you out on the uncertainty problem. Accuracy vs. Precision, when start dealing with uncertainty by essentially ignoring it, results in degradation of accuracy. I’m not happy with it. Brian Rosen: This document has a lot of stuff that needs to get published. The promoters/distracters need to get together and work out how we can go forward. Richard Barnes: three proposals to move forward: 1.) write down criteria for use of which algorithm, 2.) a registry, maybe we have that, 3.) need an example in the registry – and that the example algorithm needs to meet the properties listed, and can talk in detail about what is/isn’t met. Admittedly crappy algorithm in the document, but provide a clean path forward into the future. Jorge: haven’t heard anything about this algorithm… Robert: you haven’t been listening then. Richard: I’m not arguing that this algorithm is good, or bad, only that it is not yet well understood. Jorge: this algorithm offers a very precise description of privacy. The other point to make is that we need a good solution soon. Robert: you’re not making an argument for a baseline, but for _one_. Jorge: okay – so let’s take the word “privacy” out of the group. Robert: we can’t say what the limitation are Jorge: yes, I can. Robert: The group will not decide within _days_ for that. Jorge: you’re deciding for the group. Robert: we’ve been around in circles for so long, especially that we don’t have a strong showing in favor, yes – this is the one, then I’m saying this is not a clear path. Robert: Jorge: you’re jumping to conclusions – yours, not mine. Jorge: if you let anybody do whatever they want then we get into privacy problems – this algorithm assures indistinguishability. Robert: you’re not saying what < > Jorge: I admit that there will be a registry of other algorithms, but I do think that we need a good algorithm to go forward. Alissa: Given Richard’s proposal, a simple starter algorithm, a registry affords a path forward for your algorithm. Jorge: the problem will be that readers will see the included “crappy” algorithm, thinking it will offer privacy – they will be lead wrong. Brian Rosen: I’d like to have a hum. James Polk: I understand jorge’s point about multiple algorithms giving away location. Two ideas: 1.) Why don’t we leave the original baseline, simple, algorithm in, with all of the proper caveats, then pull this out – into a new draft. People then can look at both and choose, 2.) another idea, leave both in the original document. Richard: Let’s have some hums. 1.) Whether this document should meet privacy goals Results 5 in favor 0? Not in favor 2.) Should we have a registry, with initial contents – i.e., one or multiple per registry Keith Drage: I don’t think the wg has agreed on any of the algorithms Martin: Keith: If there is no consensus on any algorithms, where do we go? Hannes: We did have an agreement for an algorithm, 20-something revs., then came across multiple updates. As an alternative to qualifying it, Jorge has brought in a different algorithm. Richard: James: Not sure how many hums you’re planning? Richard: (above) + 3.) which should be the baseline algorithm? Martin: would like to have a usability discussion around which algorithm to use, not sure we can hum on that right away. Hannes: but we did have consensus for several years. Alissa: if we have multiple algorithms, then we’ll hum in favor of multiple. Richard: hum: if in favor of only one Results: Clear favor of multiples Randall Gellens: multiples now, or one now and multiples later Richard: first question: Should the “simple” algorithm be in the document? Results: 1 in favor, 1 opposed (editor’s judgement) Martin: and, if you don’t care, come to the mic. Hannes: the problem is that many may not remember what that algorithm of two years ago – looks like. Keith: are you humming for the inclusion of a registry, but with no algorithm included. Richard: we have to have some algorithm. James: I think it needs to be clearly stated. Richard: yes. Martin: please ask for the hum again. Richard: if in favor of that “simple” algorithm In favor (light), none opposed Richard: if in favor of the algorithm with “privacy” implications In favor (slightly more in favor, a very few against) James: said out here it sounded like a 60/40 in favor. Robert Sparks: I can’t say that this (Jorge) algorithm is bad, but can say that I don’t understand the implications of the algorithm. Don’t stop having the discussion of whether this works. Martin: a reminder that there are other options on the table. Reluctant to put forward another option – I don’t want to do that. Richard: add to the document the privacy constraints, work on analysis of the two algorithms that are there. James: would like to add two things, describe what it’s good at, what it’s not good at, in order for more informed choices. Hannes: Would like to see Martin’s(?) name on the draft, Richard: we may have reached the technical limit of authors, may have to remove an author. Keith: Not okay with what Hannes was proposing, Jorge: I said, that I would be disappointed if my name were on it, if it had no privacy constraints. Alissa: we can sort out the authorship among contributors Robert: when do you think we’ll be done? Alissa: September Martin: It depends on what we’re trying to do. /next --- WG DRAFT UPDATES: 20m draft-ietf-local-civic (B. Rosen) --- Brian Rosen: James Winterbottom and Martin Thomson started this. Goal to add a CAtype in the PIDF-LO. Problem how to pass in DHCP – what this draft does is fix that. And it discusses how to avoid explosion of types. No new numeric CAtypes – we’re going to add one, “Extension CAtype” Martin Thomson: wondering if some of the common requests, airport related. Also, tower example (ref. two towers in Bejing problem) Brian: can we take that to the list? Martin: sure Brian: I (Brian) would like to distinguish between general and specialized CAtypes. Two columns in registry, A (should), and B (may) for clients, and added to the registry per stds track and expert review, respectively. Martin: I don’t think this adds any value. People will make their own decision. Brian: And, my view is that IETF support is < > Martin: Any reasonable implementation would be able to handle _any_ extension. Brian: I think Prefix is an example of why that isn’t right. I don’t agree. Richard: The type B ones might be the ones that a general client can’t do anything with. Martin: let’s take it to the list, since I don’t agree with what you just said. Richard: what remains Brian Brian: need to take it to the list as to what else needs to be in there, that’s all. --- 20m draft-ietf-geopriv-res-gw-lis-discovery (R. Bellis) --- Ray Bellis: -04 (individual) became -00 after IETF79 Alissa: Asking for a couple of volunteers to review this, Brian, Martin, and Roger --- 10m draft-ietf-geopriv-held-measurements (M. Thomson) --- Martin Thomson: Minor updates, GPS/Galileo ICD specs, have asked for expert review internally. Richard: how many have reviewed this? (3)? I’d like to have a few more reviews, Geoff Thompson? Geoff: yes, sure. Richard: < > Martin: sure. --- NON-WG DRAFT PRESENTATIONS AND DISCUSSION: --- --- 20m draft-marshall-geopriv-location-transform-00 (R. Marshall) --- Brian: Just to clarify, this proposes to use LoST as a discovery process, and have a brand new protocol. : Is there a reason why this is “information” rather than “standards” draft tract? Roger: none – editing oversight. --- 10m draft-thomson-geopriv-http-geolocation (M. Thomson) --- Martin Thomson: Location conveyance for HTTP Modeled on –sipcore-location-conveyance Examples shown. Goal today is to ask whether there are any privacy concerns, before I take this elsewhere to do most of this work, since this is probably not where this work should be done. Richard: (disclosure as an author) Probably should have some privacy constraints. I think there is an example within WG3 that can be used. Alissa: but that discussion isn’t in the draft now Martin: No, not it for now. Geoff: I guess I’d like to hear a few more use cases – where applicable. Martin: Emergency – none. Geoff: I can get with you offline. Alissa: Can I get a sense of whether anyone thinks this belongs here – or not. Hannes: We had a discussion around this several years ago, It’s good that we’re exploring this. Martin: Agree that between this and the W3C’s API. Richard: I think we’ve got here enough people to be able to analyze how the two would work. /end