Minutes - GEOPRIV - IETF 79 Summary (prepared by Richard Barnes): Chairs' Introduction The chairs briefly reviewed document status.  They announced an interim meeting on civic address formatting to be held November 29, 15:00 US EST.  The agenda was bashed to group all of Martin Thomson's drafts together, and to move the civic address discussion closer to the beginning of the meeting. draft-ietf-sipcore-location-conveyance (James Polk) Major open issues resolved at SIPCORE meeting.  Next version should address known issues. draft-ietf-geopriv-relative-location (Martin Thomson) Discussion ongoing within the author team, but reviews welcome.  Matt Lepinski agreed to provide a fresh review. draft-ietf-geopriv-deref-protocol (Martin Thomson) Current draft includes semantics for a GET request, in response to feedback on the list.  Martin Thomson will find an HTTP reviewer, but other reviews are welcome.   draft-ietf-geopriv-held-measurements (Martin Thomson) Current draft includes updates to WiFi schema.  Adding citations and seeking more expert review (beyond WiFi section).   Civic address extensibility (Richard Barnes) draft-ietf-geopriv-prefix draft-winterbottom-geoprif-local-civic Summary of problem of extending civic addresses and outline of solution space.  There was some debate about solution approaches, but fairly strong agreement on the problem statement in the slides.  Discussion will continue on the list, and at the virtual interim. draft-ietf-geopriv-policy (Hannes Tschofenig) Latest draft includes a new fuzzing algorithm.  Ongoing disagreement over whether "lying" should be allowed or required (in certain circumstances), and over whether this algorithm is the proper one for this specification (i.e., what the requirements are). draft-thomson-geopriv-location-obscuring (Martin Thomson) New draft describes an alternative fuzzing mechanism to that described in the current version of draft-ietf-geopriv-policy.  Discussion will continue on the list. draft-ietf-geopriv-held-identity-extensions (Martin Thomson) Feedback on registry of identifiers did not indicate a strong need for a registry; authors will add a note that any extensions should define a registry.  Authors plan to add fields to handle other transport protocols (DCCP, SCTP).    draft-barnes-geopriv-policy-uri (Richard Barnes) Current version incorporates clarifications to "default policy" concepts and adds some considerations related to deployability and NATs.  The authors believe the document is basically complete.  The chairs will issue a call for adoption soon, likely followed shortly by a WGLC.  Marc Linsner agreed to do a review. draft-thomson-geopriv-res-gw-lis-discovery (Ray Bellis) There were continuing concerns about the "3rd-party" use case, more from the utility perspective than the privacy perspective.  The chairs will have a consensus call on the list about the scope of this work item, followed by a call for adoption of this document. draft-hoene-geopriv-bli (Christian Hoene) Several attendees seemed to think that this draft was interesting, but needed more maturity before being considered for adoption.  The authors were encouraged to continue working on it. Raw minutes from Roger Marshall follow -------------------------------------- IETF79 – Beijing Minutes: Geopriv Meeting, 09:00-11:00 Agenda – Chairs, Richard Barnes, Alissa Cooper Note-taker: Roger Marshall Jabber scribe: Martin Thomson Interim meeting, Nov 29th 3:00pm Eastern US time zone Lightning Rounds – 4 presentations /next – Location conveyance – James Polk presenting Following the posted slides (2 min.) /next – Relative Location – Martin Thomson Talked through slide Alissa: is it being actively discussed on the author team? Martin: haven’t done.  Would welcome comments Richard: Would anyone be willing to do a fresh review? [ ? ] /next – HELD dereference – M. Thomson HTTP GET added, (author) thinks it’s ready for WGLC /next – Location Measurements – M. Thomson Alissa: [ ? ] /next – Prefix – Richard Barnes Talking through slides… People want to add elements, but we want to do it in a way that maintains backward-compatibility LoST validation tags – however we extend this, need to assure Ted Hardie: statement, “need to manage extensibility to maintain interop”, nothing that is used in a new namespace affects the stuff in the old namespace.  So, it doesn’t help (or hinder) in how you divide these namespace approaches. Andrew Newton: Brian, in his email, has mischaracterized the LoST approach as a hack.  Don’t see how what he’s proposing is going to help.  Registries won’t stop people from doing crud in there. Martin: (channeling Brian Rosen) – thinks the slide represents a good summary… Martin: I agree with Ted’s remarks Richard: Sketching out some process for how this stuff can work would be a good idea. Richard: sounds like we do have some agreement w/regard to the problem statement, so I’ll take this to the list. /next – Geolocation policy – Hannes Tschofenig Discuss background of what -21 contained, location obfuscation, tried to explain in text form So, version -22 shows location obfuscation Questions to vet – --/ Example uses the form of a circle.  Is this assumption appropriate? --/ We do not force the algorithm to lie.  Should the RM be able to control this aspect? Martin Thomson:  [ ? ] James Polk: Are you saying… what are you saying? Martin Thomson: suggesting that we not force the algorithm to lie.  We can sometime later address a case where this (lying) is the assumption. Peter St. Andre: last I checked, the IETF has nothing in writing to enforce ethical behavior (funny) Hannes: fictitious example of (Martin) visiting Berlin, and (James) could see his location reports, the smaller and smaller the blocks reported are, the easier it is for James to see (e.g., which company) Martin is visiting. Martin: it is probably a little more complicated to show – without pictures Alissa: [ ? ] Hannes: using various statistical techniques on the returned blocks, you learn more over time.  Especially so when block size is reduced. Martin: I think the point that Alissa is making, is that whatever we produce here, may not be able to guard against the information – of various types – showing a user’s location. James Polk: originally (~5 years ago), when started, making a fuzz radius of 1000km – turned out not so useful, since, for example Germany was largely covered. Hannes: [ ? ] James: if you shift at all, you expose some information.  Haven’t heard that that original, large scale approach wasn’t good enough. Alissa: running out of time, let’s move forward Hannes: explains “block” approach Hannes: Suggestions slide.  Use the example algorithm(s) in version -22, and see what people do. Randall Gellens: Is the intent that the actual algorithm would not produce a new reported location, if the device doesn’t move? Martin: 2 things… one, that if the device doesn’t move, then no different report is used, and if the device leaves, then comes back to the same location, then the reported location is the same so that interpolation can not be used. /next – Location obscuring – Martin Thomson Walked through visual slides Martin: introduce continuous randomized field – adjustments to the reported location are incremental Jonathan: Does this means that you have to keep state for every location? Martin: No, the draft talks about this. Marc: Did you try [ ? ] Robert: Short answer is yes, but it didn’t improve the problem. Interpolation [name? Sohel Khan]: Using this interpolation, is this because the length of miles changing when approaching the poles? Martin: suggest reading the draft Richard Barnes: I think we do, as a wg, want to arrive at some good proposal. Peter St. Andre: This document did include some of the most impressive ascii art seen in an Internet draft, but want to point out that you can provide links that could point to a .pdf, etc., and so I suggest that we may want to do that for this draft. /next – HELD Identity Extensions – Martin Thomson Question of whether we need a registry for these things? Alexey (as an individual): Richard: Do we anticipate extensions in the future that we’ll need to have an extensible registry? Richard: either way is ok. Martin: also agree. Richard: If we ever have a need to extend in the future, we could then create a registry. Martin: good idea. Alexey: Slightly on the opposite side of this, but don’t have a strong objection – either way. Martin: transport protocols James Polk: As the chair for that working group, I do think it makes sense to add SCTP and DDCP. Martin: perhaps you can help with [ ? ].  I will talk to you after the meeting. /next – geopriv-policies – Richard Barnes James Polk: Is this exclusively a HELD policy? Richard: Not at all. Default policy approach. It would be nice to have a review by a fresh set of eyes. Alissa: Is there anyone that could do a review? Alissa: Thank you – Marc Linsner. /next – res-gw-lis-discovery – Ray Bellis Read through slides – any comments? Martin: I think recently, this is called a “hard problem”.  I don’t think we can claim a solution yet. Ray:  [ ? ] Peter Koch: Come up over and over again – depends on what dnssec is delivering.  No assurance that the data put in is correct. Ray: summary – should it have wg adoption? Marc: I’m confused, and IETF78 the draft was talked about at the microphone.  Looking at the diff – a 3rd party (Jon Peterson) would have jumped all over this [ ? ]. Ray: Martin: the concerns were that a 3rd party could have taken this and exposed.  But there is no assurance that the [ ? ]. Ted: Some 3rd party has two problems, 1. Unaddressable space, and 2. Wrong context to query – which is impossible to know.  Not then whether the LIS is public or private, but that […], so the 3rd party seems to be foobar. Martin: I think that is a good point, since I don’t think it’s going to work for a 3rd party, I think we need some descriptive text wrt this 1918 stuff. Ted: You may find someone in the [miff?] wg, may have done work in this space. Marc: To characterize, then we’re talking about applicability to the 1st party. Hannes:  another document has some of this already, the other point is that there is a lot of hand waiving […] Hannes: running code, but running code for what? Peter Koch: What amount of deployment are you forseeing here? Ray: It is a backup mechanism, but it is […] Peter: ISPs really struggle deploying reverse lookup mechanisms for IPv6.  Wondering what your implementation time frames are… Peter: Also, ISPs consider providing reverse mapping, but then changing the data to the customer, wondering if that would work with this… Ray: In the former case, I don’t see a need to handle end user assignments. Peter:  […] Ray: my experience. Peter: Actually worked for an ISP with IPv6 deployment experience? - ! Ray: […] Peter: for this to work, you must have assumptions for up-tree reverse mechanisms… Ray: agree that we don’t have a lot of experience for … Marc: To agree with Hannes, this is an ugly mechanism.  A lot of dependencies, is fragile. Ray: It’s the best we’ve got – for now. Martin: in response to Marc,  I’ve spent a lot of cycles personally, and its pretty sad that this is the best we’ve got so far – many other ideas have fallen by the wayside, there were good reasons that those others were dropped, and good reasons that this one was labeled as superior to those other options. Hannes: I don’t know, maybe apathy is a reason – both in this room – and among ISPs that currently don’t provide information to others. Ray: UK solution as a reference implementation. Hannes: but the UK doesn’t even use this? Ray: It’s a part of the deployed solution in the UK for emergency svcs. Hannes:  […] Ray: This draft was indeed derived for a 3rd party case.  May not be well described in the text. Alissa: I think it’s obvious that there is more work needed, but I don’t think that this is a reason to not accept it as a work group item. Marc: To seek clarification, is this about 3rd party use – or not. Richard: (quoting the charter/milestone list) Ted: If this doesn’t work for a 3rd party case, why are we considering adoption? Richard: reading the milestone Martin: we need to correct that [ ? ] Ted: I think we need to drop the 3rd party description Richard: how do you, Martin, feel about losing that? Martin: [hard to hear] we need to look at that. [ ? ] Hannes: Are the other solutions so bad that they cannot be used? Richard: I think the direction is to have a consensus call on the list re: 1st party vs. 3rd party [ ? ] Ray: ok. /next – geopriv-bli – Christian Hoene Richard: Interesting work – speaks to a gap that we’ve have wrt to uncertainty [ ? ].  Don’t know if we’ve got the expertise here in the IETF, and am easily persuaded from those in the back, may suggest that you take this to the OGC – where they are highly interested in xml coupling with uncertainty descriptions. Martin: I’m not sure how this will be used by [ ? ] Ted: naming of the reference point – not sure how this was intended to be shared.  Understanding how those reference points would be shared or used by other systems, would indeed by very interesting. Richard: You may want to take a look at the “relative location” draft. Martin: referencing my email to you previously, how is this something that you need […]  Would be interested in discussion a little further. Richard: How many have read this draft? [ 4 check ] Richard: How many people are interested in reading this draft?  [count is 4 additional]. Richard: (asking) number of hands that this this is of interest to this work group [7 or 8 hands up] (a positive response) /next – mobility-and-privacy – Marc Linsner Marc: going to discuss this in https://www.ietf.org/mailman/listinfo/ietf-privacy Will spin another version soon. Has anyone read the draft? [4-5 hands up] No comments on the draft. Hannes: This is good that these authors put this together.  How does this relate to the other privacy in MIP. Scott Brim: We were more generally targeting Internet privacy. Hannes: Marc: Can you mention the upcoming conference? Hannes: IB-WC3, ISOC, IBT sponsored conference upcoming. /end.