MINUTES - GEOPRIV - IETF 71 - March 11, 2008 Summary: Attention was called to the HELD prototype running at this IETF. Hannes will send slides to the list regarding a work in other venues that may result in regulatory recommendation. Roger called attention to the LOCSIP work in OMA. The http-location-conveyance draft is in WGLC. There are a small number of open issues still being closed. At this meeting, concern over the held: URI was discussed. Eric Rescorla suggests we use helds: instead. The room agreed to delete the section discussing VPN devices serving as a LIS. The -retransmission- draft was discussed inconclusively. The participants in the discussion agreed to meet later in the week and propose a way forward. Keith notes that the SIP WG needs a formal consensus opinion from GEOPRIV before the location-conveyance document being discussed there will change. Discussion of the use of binary-lci continues. Robert has taken the token to drive this discussion to conclusion. While discussing the -lo-sec- draft, the room felt it was time to ask to charter work to produce 3693bis probably based on this document. Richard will continue to work on it as an individual item while the chair pursues the milestone. Discussion of the open issues in -lbyr-requirements was deferred to the list. Discussion on the open issues in -dhcp-lbyr-uri-option was inconclusive and will continue on list. There was consensus in the room to approach the ADs for a milestone for dereferencing using HELD and to use the -deref-protocol- draft as a starting point. Cullen (as AD) notes we need discussion on sequencing this with other work. There was support in the room for working on problems discussed in the Identity Extensions and Context Management drafts before GEOPRIV is done. Very few people in the room had read these drafts before this meeting. There was consensus in the room to approach the ADs for a milestone on producing a draft discussing considerations in representing civic addresses and using the -civicaddresses-austria draft as a starting place for it. Raw notes from Dean Willis and Miguel Garcia follow. ------------------------------------- Raw notes by Dean Willis Chaired by Robert Sparks Note Well presented Topic: Agenda Bash and Announcements by Chair Slides presented Agenda accepted as presented Hannes reports that he attended an international privacy group and presented on geopriv. Slides have been posted to the list. The group will make a regulatory recommendation on geopriv. Roger Marshal reports that he received information on a new OMA contribution called LOCSIP that provides a 4th LCP protocol based on SIP. There needs to be further discussion on what to do about this. Richard Barnes reports that we are running a HELD prototype on the IETF server for location at IETF. Joint GEOPRIV/ECRIT meeting targeted for late June. Hannes suggests that we also have a face to face with 3GPP, and perhaps we could do this in one session. James notes that the April emergency workshop is Tuesday through Thursday, which would make adding 3GPP or GEOPRIV/ECRIT to that difficult. Topic: HTTP Enabled Location Delivery (HELD) Mary Barnes Slides presented Changes since last version reviewed. Issue: locationURI SHOULD not contain information that can identify device ir target. What are the conditions where violation of the SHOULD might be appropriate? Is there a "MUST except" condition? Issue: Editorial nit, to dash "by-reference" or not. Proposed that we bring this to RFC editor to insure consistency. Noted that for consistency we should use LbyR and LbyV in referencing documents. Issue: Where should HELD: URI be defined? Eric Rescorla (EKR) asks "Why do we have a HELD: URI?" This is a debatable topic with Applications Area. Lisa Dusseault reports that there is a problem with putting arbitrary URLs into a schema that just says "URL". Others like vcard are putting more specific URLs back into their schemas. For example, a generic HTTP URL might or might not point at a HELD resource. The alternative would be to spec that an HTTP URL is used, but that it MUST point at a HELD object. EKR responds that many URIs respond differently based on teh circumstances under which they are used. He is really concerned with referential integrity. Do HELD URIs get delivered in a context where they are clearly HELD targets, or are they handed around without context? Ted Hardie suggests that since "HELD:" is "almost free", it gives us a context free way of identifying the target content, and is therefore very useful. The real question is what is the cost at the other end for developing something that deduces the behavior from context. EKR counters that this works fine until to have to deal with the combinatorial explosion of having to have a single HTTP server address all of the types. Debate ensued . . . Jeff Hodges rephrases "minting" as the production of a URI scheme in an ad-hoc fashion. The tradeoff Ted is referring to is between having a specified URI scheme and an ad-hoc URI scheme. Ted continues that people DO mint ad-hoc schemes all the time, and we lowered the barrier to registering to reduce conflicts. If you have to have different handling for something that is referenced by an HTTP URI and it is referenced out of context -- for example, an RSS feed that reports location, then you will have a problem with data mismatch. further debate followed . . . Why is using a URI scheme to manage this a problem? counter: If we really registered a new scheme for every data type, we'd really have a lot of URI schemes. Question: Does this HELD: scheme require TLS? Ans: Yes. Then it needs to be a HELDS: scheme. TODO: Change to HELDS: Issue: VPN Device Serving as a LIS There are two different interpretations of the intent of this document session. Proposed that the discussion of DHCP and LLDP-MED be deleted. Brian Rosen noted that he wants to keep the "Beware" text around VPNs, which is in a different section. Concluded that text will be deleted as proposed. Topic: Location Retransmission Jon Peterson Slides presented Proposed that routing permission be moved to a binary flag in the Location header. Issue: Why have to dereference an object to find out of you have permission to do so? Henning Schulzrinne counter-argues that the same argument applies to ALL permissions, therefore it is questionable. JP counter-argues that LbyR gives a compelling case for the proposal. Also, geopriv-unaware logging servers also argue for selective witholding, and that the easiest way to do this is LbyR. James Polk argues that the proposal doesn't have the same security properties as the old "server vs recipient" encoding. The binary flag cannot encode the permission for the endpoint to redistribute the content but the servers to not route on it. Brian Rosen argued that there is a case where the ONLY thing you want is proxy routing and for the UA to NOT have access to the location. Ted noted that the "server only" or "recipient only" mechanism is provided by access policy on the LbyR. this is especially important, because there are really no security properties to either marking on LbyV. if you want the location to ever be private, LbyV is required. Further debate continued . . . Brian Rosen asks "why have a hint at all?": The proposed case is for avoiding overhead of a lookup while routing if there is no permission. Henning notes that the "don't bother" optimization on LbyR applies to recipients as well as routers. Therefore, we might as well included the more complex "server" and "recipient" flags as opposed to the binary value. Further debate ensued . . . JonP argues that the "server" and "recipient" semantics are wrong, from a user perspective. James Polk proposed that instead of a "routing allowed", what we need is a "handling" flag that controls routing and redistribution as distinct handling modes. Ted proposes that we could use differentiate by "routing" and "non-routing" roles. Keith Drage (SIP Chair) noted that SIP will not adjust draft-ietf-sip-location-conveyance until GEOPRIV comes to a conclusion in writing on the requirement. Ted wants to ask the room if we see value on providing the optimization of informing routing elements that there is "no need to ask for LbyR". Brian proposes a hallway conversation, rev of Jon's doc to reflect that conversation, and acceptance of Jon's doc as consensus to SIP. James wants to poll on the value of the hint for LbyV. Resolved: have a side conversation and come back with proposal. Meet at back of PEPPERMINT at conclusion thereof. Keith objects to scheduling an ad-hoc meeting on such short notice. Poll: Consensus on value of a hint on LbyR permission encoded functionally? General consensus that this has value. Topic: Using DHCP location in PIDF binary-lci Robert Sparks Slides presented Noted that there lots of issues with assumptions about boundary rectangles at varying laRez due to threshold effects and clipping. Question: What clarification does RFC 3825 mean to PIDF-LO. One approach is to say "this is a point" and assume nothing about bounding boxes. Hannes says we need to describe clearly how a PIDF-LO is created and what precision means. Rohan restated proposal as "We are indicating a point, not a shape." Henning noted that there does not seem to be a lot of practical experience with RFC 3825. So there's a good opportunity to either use something else, or help fix RFC 3825. James Winterbottom notes that we're going to be losing the precision every time we convert to a double anyhow, so we need to fix this somehow so that other things that use LCI encoding don't do something erroneous with the result. EKR notes there are two use cases. One is similar behavior to GPS, where we are reflecting real uncertainty about the location. The second is deliberate fuzzing or obfuscation of the location by reduction of precision. It's possible that no mechanism will simultaneously address both sets of requirements. Henning suggests we should talk to IEEE more -- we may be working on something irrelevant. Much discussion ensued about representation precision and decimal vs binary encoding. Noted that the spec says these numbers are to be interpreted as IEEE doubles, so this is a spec issue and not an implementation-only issue. Brian Rosen proposes that when converting from LCI to PIDF-LO that we apply the conversion precision, but be aware that this will not accurately cross further transformation cycles. The document also needs to talk about the limitations of the encoding. EKR argues that we do not have a consensus understanding of what an LCI means and how that converts to a GPS measurement and an error bound. James W notes that GML defines points and precisions thoroughly. Brian R notes that RFC 3825 simply doesn't communicate error, just significant digits, and that's OK. Henning proposed a set of alternatives for consideration that overflowed the listener's input buffers. There was a proposal from Brian Rosen to document the 3825 to PIDF-LO conversion. Poll: Would this be useful? Noted that this might be written by somebody not involved in this conversation. That was an indication of desire for a document that would encode precision in PIDF-LO. Chair notes that we do NOT have a consensus on the discussion of deprecating RFC 3825. Conclusion: Robert will attempt to do something. Topic: Security Requirements Richard Barnes Marc Linsner notes that 3693 and 3694 do not induce a dependence on presence. Jon P agrees, but notes that it has a similar logical architecture with compositional options. Jon asks if there is a difference between the applicability of presence and non-presence protocols that impacts the security model? The goal of this document is to simplify the writing of security considerations in geopriv documents. Ted notes that it is important to consider the role of a Location Generator as independent from that of a Rule Maker. The application of transport protections by an LG to limit access is not "making rules" about who can access the material. Discussion followed on whether a DHCP server is an LG or LS. Several argue that it is an LS that is configured with a location by an LG, and that it merely redistributes that location rather than generating it. Jon proposes that we have a new name for things that encompass LIS rather than trying to call them an LG. Noted that this document should use LCI or LI instead of LO terminology. Debate on security properties and their applicability to LI and LO continued for some time. Noted by James that a location recipient is not a target. Poll: Is this approach helpful? Most readers seem to have found it to be. Question: Should this document refer to architectural elements in other documents or define them itself? JonP suggests this document become 3693bis. Brian concurs. Noted by EKR that "x and y must have 129 bits of entropy" clauses don't have enough supporting information to be meaningful. Poll: should we start producing RFC 3693bis? Strong consensus observed. Chairs are to work with ADs to get this set up. Topic: LbyR Requirements Roger slides included Roger displays list of open issues and asks whether people want to talk about them here. The room seems to hold that list discussion will resolve the open issues so no further discussion here is needed. Topic: DHCP LbyR James Polk slides presented Changes since previous version reviewed. Open issue: "valid-for" field Proposed that field should indicate in epoch terms the end second at which the location will be valid. Topic: Referencing via HELD James Winterbottom Slides presented Poll: How many people have read the draft: Not as many as the chair wanted. Poll: Who thinks we should approach the ADs and charter this thing: General consensus to begin chartering. Poll: Who thinks this is a good baseline document: General consensus to use this as a baseline. Note from AD: needs discussion about how to sequence this with other work. Poll: Who has read identity extensions draft? Also a relatively small number. Poll: is it important that cover these items before we are "done"? General consensus yes. Several polls on civic locations draft taken quickly by chair. Details not captured in these notes. ---------- Raw notes by Miguel Garcia GEOPRIV - Tuesday 9:00-11:30 (150 minutes) 10m Administrivia Chairs Hannes informs about a meeting he was attending on regulatory aspects related to privacy. He will post the slides to the list. Roger Marshall: last week OMA accepted a contribution LOC-SIP to provide an interface to the SUPL service. It adds a 4th LCP protocol to those we have been talking here in the past. Hannes: we should talk to these OMA guys. Richard Barnes: there is a prototype HELD server running here at IETF 71. Status: see slides. HELD: Trying to get max one week beteween check points. Proposed joint GEOPRIV/ECRIT interim meeting around June. Hannes proposes to invite 3GPP folks. 15m HTTP Location Delivery Mary draft-ietf-geopriv-http-location-delivery-05.txt Mary goes through her slides. A.P. to Mary to check when SHOULD is used, there is text explaining the exceptions to the SHOULD, as requested by Brian Rosen. Topic: to use dashes or not: Location-vy-value versus Location by Value. There is no consistency across documents. Brian: bring it to the RFC Editor's attention. A.P. to Mary to contact the RFC Editor. Topic: HELD URI. Relaction to the location de-reference documnet. Eric Rescorla. Why do we have a HELD URI. Lisa D. There is a problem for not being specific and having any URL. Seen in vCard. What about an HTTP URL? It is the same: it can be CGI scripts, atom feeds, etc. There is no guarantee that you get the resource you are looking for. The solution is to be specific. Eric: if you see a HELD URI you know how to treat it? Ted Hardie: if there is a cheap way to indicate that this is a HELD URI, why not use it? People will mint one and use it, no matter whether the IETF specifies it or not. Eric: concerned with the explosion of URIs. Ted: There have been about 50/60 over the past 10 years. Jeff Hodges: when Ted says "minted" he means "ad-hoc non-specified minted". The trade off is to have it cleary open specified. Ted: People do mint ad-hoc URIs very easily. If you need to have a different handling of an HTTP URI due to the context, it should be a different URI. Ted: we are both trying to predict the future. The WG cannot resolve the question based on this predictions. Topic: HELD URI over TLS. EKR: if it uses TLS, then the HELD URI needs an 's' Mary: we will do it. Topic: VPN Device Service as a LIS: Mary proposes to delete the text. Henning: giving the complexity of VPNs, this needs some kind of BCPish document A.P: Mary to delete the relevant text. 20m Retransmission Issues Jon Peterson draft-peterson-geopriv-retransmission-00.txt Context: sending an INVITE with PIDF-LO. Intermediaries will inspect the PIDF-LO, potentially do not have trust relationship, etc. The is used to constraint the forwarding of PIDF-LO. The location conveyance has a parameter in the Location header. Problem: the creator of PIDF-LO cannot anticipate who can need the PIDF-LO. Not in PIDF-LO object. Privacy: geopriv-unaware logging proxy argues for selectively withholding location. Best way we know how to withhold to LbyR. Proposal: SIP location conveyance should reflect (and/or reference) these principles. Brian: missing case: you only want routing, you don't want the UAC/UAS to look at the location. Now you don't have the way to say: give it to the routing engine, not to the endpoint. Ted: there is a mechanism: the endpoint gets LbyR and will not have credentials to de-reference it. Brian: why don't we get rid of the hint? Henning: the same optimization should be presented to the endpoint "do not try to de-reference this because it is intended to the routing system". Henning: how far we should go? We essentially have two parties: intermediary and endpoint, giving four combinations of intended recipients. The discussion seems to go toward differentiating routing-element versus non-routing-element. Robert: is this something important? Small group of people, let's take it to a small group in a hallway discussion. Keith: Location conveyance is owned by SIP and the document is going to stay until we stay something from Geopriv with some different requirements. Ted: is it consensus in the room for optimize that endpoints do not need to de-reference a location by reference. Brian: propose to revise the document to reflect the hallway discussion and this will be the WG consensus. Hallway discussion deferred at the end of the Peppermint BoF. Robert: Will it be valuable towards providing a hint to de-reference at a functional element? Quite a few hands up. 20m Using DHCP location in PIDF (binary-lci) Robert draft-ietf-geopriv-binary-lci-01.txt Robert goes through the slides. What are we going to do with RFC 3825? do we need to change or clarify how to use information from 3825 in a PIDF-LO? The discussion seems to say that 3825 indicates a point. Some people (Henning, James W.) think that if we move this to a point the resolution bits become irrelevant. Henning: before worrying about backward compatibility we should know if this is a real issue. Henning: Two steps: we provide some text about the binary representation. A non expert can understand that. Brian: we need a document that ought to discuss the problem, how to convert to GML, and the associated problem. The document should talk about the limitations of the conversion. If you have a small number of significant digits, you should convert it the best you can and understand that the location might have lost accuracy. Robert: 3825 is not talking about areas. Hannes: we should not be academic. We should talk to people who implement things, figure out what they want, and fix it. Brian: a limitation of 3825 is that we cannot express error. We can only express significant digits, and when you convert it.... Henning: These are the options: 1- Deprecate 3825 and do something totally new 2- Keep 3825 and says this has limitations 3- Express how to convert to decimal Small set of people care about the conversation Hmmm about these options. 1- Document that says how to use 3825, keeping the res bits, and indicate the limitations when you convert to PIDF-LO (Brian's proposal). The editor of the document should not be biased on these discussions. 2- Document on how to John: We need to close the question. RFC 3825 does represent a point, not an arbitrary region. Henning: if we are going to deprecate 3825, let's do it and stop the discussions. If not, let's fix it. Robert: we are not at the point of taking a hum to deprecate 3825. Plan: getting a driver that is not one of the key participants, to continue conversations, wrapping the conversation. Deadline: interim meeting. 10m Security Requirements Richard draft-barnes-geopriv-lo-sec-02.txt Richard goes through the slides. There are concerns with respect the re-definition of new terms LO and LI. Hannes: we shouldn't care about the encoding on the wire because the security properties are the same. Jon supports the document. Robert: general feel for time for 3693bis. General consensus in the room. Robert to talk to the ADs for a new milestone to review 3693bis. This document is a potential candidate for this milestone. 10m LbyR requirements Roger draft-ietf-geopriv-lbyr-requirements-02.txt Due to lack of time, the presentation is deferred. 15m DHCP LbyR James P draft-ietf-geopriv-dhcp-lbyr-uri-option-00.txt James goes very fast through selective slides. 15m Dereferencing using HELD James W draft-winterbottom-geopriv-deref-protocol-00.txt James ask how many people has read the draft. There aren't so many. Robert ask for interest in the WG to get this document as a charter item. Hmm says YES Robert ask for a second hmmm to get idea of who believes this is a good document to fill that potential charter item. Hmmm says YES. 10m Identity extensions James W draft-winterbottom-geopriv-held-identity-extensions-04.txt 6 people hahow ve read the draft. 10m Context management James W draft-winterbottom-geopriv-held-context-02.txt 3 people have read the draft. Hmm reveals that people think this is important to be done before the WG is done. 15m Civic Addresses Alex draft-wolf-civicaddresses-austria-01.txt At the last meeting, the civic address considerations draft. People think that the draft has achieved what it intends. Hmm reveals that we should have a milestone, and this document should be the basis for it.