Minutes - GEOPRIV - IETF75 Summary (prepared by Richard Barnes): 1. Chairs' Introduction The chairs reviewed the status of several WG documents. Hannes Tschofenig noted that the major outstanding technical issue with loc-filters is whether to add a "speed greater than" condition. Martin Thomson noted that lis-discovery is ready to go to the IESG 2. RFC 3825 Update draft-ietf-geopriv-rfc3825bis Bernard Aboba presented an update on this document. Several issues have been closed, leaving three remaining after the next, upcoming revision. 3. GEOPRIV Architecture draft-ietf-geopriv-arch Alissa Cooper presented an update on this document. The most recent edition added some clarifications and simplifications. Ms. Cooper proposed that the document be last-called. 4. HELD Identity Extensions draft-ietf-geopriv-held-identity-extensions Martin Thomson presented an update on this document. The primary open issues are around how authentication and authorization are applied. Cullen Jennings expressed concern that current text on authenticating ownership of identifiers is not implementable. The authors agreed to restrict usage to limited cases with pre-configured authorization relationships, except possibly for some cases the document can provide clear, implementable guidance. 5. Indoor Location draft-stanley-geopriv-int-ext draft-polk-geopriv-int-relative-in-tlv draft-rosen-geopriv-pidf-interior draft-thomson-geopriv-indoor-location Dorothy Stanley presented an overview of the first three documents. Martin Thomson and Brian Rosen expressed reservations about the syntax that these drafts employ, in particular the overloading of the civic address structure. Martin Thomson presented an overview of his document. The two teams agreed to work together to come up with a unified strategy. 6. Geocoding draft-george-geopriv-address-translation Robins George presented an overview of this document. Several participants had read the draft and agreed that the general topic is worth working on, but doubted whether HELD was the appropriate protocol. At least one more revision will be necessary before the draft can be considered for adoption. 7. Policy URIs draft-barnes-geopriv-policy-uri Richard Barnes presented an overview of this document. Hannes Tschofenig and Martin Thomson observed that indirect-publish mechanisms might be more suitable. Raw notes from John Elwell and Stephen McCann follow: ------------------------------------------------------------ Status update: On held-identity-extensions: Remote: Are we going to do a generalised mechanism? Martin: ???? Martin: lis-discovery - about ready. draft-ietf-geopriv-rfc3825bis (Bernard Aboba) Chair: Does issues list include discussion on list in last 24 hours Bernard: Indicated which issues were still open. Martin: Document in good shape apart from 3 issues listed on slide. draft-ietf-geopriv-arch (Alissa Cooper) In opinion of Alissa, about ready for last call. About 6 people had read the document. HELD Identity Extensions update and discussion of open issues draft-ietf-geopriv-held-identity-extensions (Martin Thompson) Issue#19: Martin also added that latest discussions lead to restrictions in which something can be considered LCP. No discussion. Issue#27: No discussion. Open issue on solution scope: Martin's proposal is that the questions raised on the list are valid questions but do not need to be addressed in this document, so out of scope. Richard: OK with first, but 2nd and 3rd should have something said to address privacy concerns. Cullen: On 2nd and 3rd, which document DOES address these? Richard: Can't have a general solution for these, but at least can give guidance. Cullen: Need proper normative references to get past IESG. Martin: We have such references, will make document a bit longer if we put them in. But problem is, that for one network they may work fine, but not for the next one. Jon: Sense is correct (not wrong), but unsure that it is complete or helpful (but that was a month ago). Doesn't understand how IMSI would work, for example. Martin: IMSI easier than MAC address from my perspective. Cullen: Others won't understand it - write it down. Jon: Different classes of problem, for IMSI, MAC address etc. Jabber: Gave reference. Martin: Don't see much value in an LCP request with identifier. Cullen: We need to say how privacy will work, although there won't be a single answer. From the present document I fail to see the answers. Same issue will come up from people who haven't previously read the document, as it progresses. Martin: Disallow request if you don't have policy for dealing with that request. Cullen: Not implementable. Richard: One case is MAC address look-up from IP address: Cullen: This doesn't make sense. Martin: That is correct, supplying MAC address as identifier is not required. Richard: So doesn't do any harm. Cullen: So it might be misused for something else. Martin: Explained one case. Jon: If that is the only case, I understand. Martin: Explained another case. Brian: Can give you a use case for LCP - involves a gateway. Could turn it into third party, but really it is first party. Jon: This should be treated as third party. Martin: No problem covering this in the document. Jon: Need text that says that for third party case must be some pre-association, and must express scope of what requests can be made. Cullen: Write down how it should work in practice. We have been complaining about W3C ignoring all privacy, so we should ourselves address the issue. Martin: When hosts can get their own location, this will gradually go away. Jon: This is a MUST use case, not just a MUST implement. Jabber: ???? Alissa: Make it clear in document which of these are third party cases. Jon: Fundamental distinction between these cases - different approach, different security. Martin: Want people to attach to network and get location information they need, and often IP address is sufficient. Jon: Don't' all become 3rd party, they are different. Alissa: They need to be explained. Martin: Will deal with non-LCP cases in more detail. Chair: If we can solve by reference, that would be fine. Open issue that we need examples: No agreement on list on what principles, but perhaps moot in view of previous discussion. Open issue on alphabet soup: Martin: Not a lot I can do about it, but we are in a lot better state than some other documents. Cullen: I agree with people complaining about this. No other issues raised from floor. Indoor location proposals draft-stanley-geopriv-int-ext draft-polk-geopriv-int-relative-in-tlv (Dorothy Stanley) Proposal also make use of draft-rosen-geopriv-pidf-interior. Jabber: Why just these shapes? Dorothy: Others can be added - just not in this draft. Roger Marshall: Good to have a discreet reference that is more precise than "front door". Dorothy: Looking to provide civic-only parameters. Brian: Like the draft. Generally the approach is correct, but two problems. "Front door" is a string that does not exist on the drawing. Would like to see something like "Door" with value "Front". Add another level or two of INT. Second issue is syntax for offset. Would prefer a more structured syntax. Dorothy: On first point, this was considered, but went this way to provide additional flexibility for deployment. Otherwise we would need to know all entity types (door, elevator, etc.) that one might want to use, and this is very difficult. Richard: Agree with Brian we should say what it is and what it is called. Dorothy: Yes, but issue of how to specify and what degree of flexibility we want to give. Marc: IEEE has adopted PIDF-LO and is using it in its protocols, so to say stop now and go in a different direction puts us in a bad light. Doesn't see problem with having a tag. Martin: I have already outlined my concerns, and whilst the use cases need to be solved, this is a bad way of doing it. A recipient could be mislead by this. Need to get the data model right first - then fix the other things. Roger: ???? Dorothy: In response to Jabber question, not trying to add complexity, just extending what already exists. Martin: The bunch of elements being introduced masks the complexity that is there. An entity not understanding the extension would get the wrong location. Dorothy: But would still have building address. Martin: Each element added to a civic address should make the location more specific. Adding these elements should make the location specific, but they are intentionally making it less specific (e.g., a circle) and shifting the location. Hannes: No way of negotiating what you understand. Dorothy: In the context of using this, would know the protocols being used. Hannes: Could use proprietary. Concerning comparison with draft-thomson-geopriv-indoor-location Martin: I don't think it is a good characterisation of my draft. draft-thomson-geopriv-indoor-location (Martin Thompson) Addresses same problem, but solution takes into account some things Martin considers important. Cullen: How to get from WGS84 is better attached as metadata to the map, but otherwise like the way this is going. Martin: Will need to discuss on list. Dorothy's final slide: Dorothy: Solutions have different characteristics, and different applications have different needs. So recommendation is to progress both. Martin: Would be willing to work on a merged proposal, if we get the data model right. Don't want to see two competing solutions. Dorothy: Happy to discuss this off-line, but there are some important considerations that need to be kept. Requirements don't appear to be quite the same. Martin: Let's discuss requirements and see which ones survive. Jabber (James): Any location must have significance outside the local environment. Martin: Either need a way of specifying both an outside location and an inside location, or need to know which the application needs. Marc: There is running code on some of this IEEE stuff. Richard: Should not have impact on XML - should be able to translate to/from binary. Brian: Would like to see one solution for this, if possible. draft-george-geopriv-address-translation (Robins George) 4 people have read the draft. Martin: Like the idea in general. Location requests in HELD is probably not the right way. Either use a different request in HELD, or better, another protocol. Perhaps need to work with James Polk. Also there are discussions on putting something similar into LoST. Roger: Good idea to have a standard for this. Seconds Martin's comments on use of HELD - perhaps a light LoST usage. Martin: Last discussion said don't geocode in LoST. Brian: Martin has said most I want to say. Would not accept the draft as is. Chair: More discussion on list. draft-barnes-geopriv-policy-uri (Richard Barnes) Open question: Does the general approach make sense Is the extension syntax correct (DHCP and HELD)? Do we need also to provide general policy (outside of LbyR) What is the right protocol for installing policy. Hannes: There was a previous proposal that people found too complicated. That was placed with something simpler in the HELD context document. Advocates a different model. How would server authenticate. Richard: Not all the things the policy server can provide require authentication. Hannes: ???? Martin: Not too against it, but don't see it as deployable. Jon: Needs to be some glue for some cases. Want to make sure all those cases are covered. Martin: Third bullet on open issues slide - thinks this is bad - sees no need to do. To Jon's questions, need to work on it. Other business: Martin: People should perhaps get involved with indirect publish, which seems to have relevance to these discussions, although it is only a straw man. Meeting closed. ------------------------------------------------------------ alissa and Richard Barnes chairing see slides (geopriv agenda) Draft status ------------ Brian Rosen's document is now in last call. There don't appear to be any mailing list comments on this. HELD on the RFC editors queue -loc-filters: Resolving WGLC issues Hannes: regarding the filter document, there was an issue about reachng a certain speed (e.g. 100km/h). You can currently say that the speed is above this limit. A custom filter is possibly required. Richard; Please can we take this discussion to the list Martin: I'm not sure why we want to use this. A: Tempreture changes, why not add greater than, less than. Martin: -lis-discovery, this has now finished last call and I've updated it with comments. I think its ready for IESG evaluation Cullen: Yes, I agree w3C liaison ----------- We sent some comments to w3C regarding their liaison. It looks as though no further action is required. RFC 3825bis - Bernard Aboba (remotely) --------------------------- Added some next sections as shown in the slides. Martin: Does these updates include the list discussion during the last 48 hrs? Bernard: Not entirely Martin: If we can close off the 3 issues as shown, then I think the document is good. Issue 4 is a bit of a concern. Bernard: Yes, ok. There are some more possible change to this. -arch-01 - Alissa Cooper ------------------------ Changes since 01. Alissa thinks the document is ready for WG last call (WGLC). Richard: How many people have read this document. About 9 HELD identity - Martin Thomson ------------------------------ Changes since 01 two primary issues have been raised: Issue #19 and Issue #27 There are some outstanding issues. Richard: OK, that's fine for the 1st point. For the 2nd and 3rd (about the security issues) I'm not sure. Cullen: But which document addresses the 2nd and 3rd points? Richard: Well, they would be use cases and have not been written down. We'll not have any universal solution to these issues. We can produce a set of requirements. Cullen: We need normative text so we can actually implement this. Alissa: There have been some ideas on the list, but are not in the draft. Jon Peterson: The text is ok, but I don't think it's complete. The IMSI cases are difficult. Martin: I don't think IMSI makes sense for LCP. Cullen: So perhaps we should split out IMSI. Martin: But IMSI is easier than using a MAC address. I can put in another paragraph about this. Jon: There are different classes of identifier, and perhaps these need to be dealt with seperately. You have different sets of security challenages for these classes. The IMSI does scare me (regarding the ease of attack), as opposed to MAC address. James Winterbottom (remotely). Something is already defined in a TS 31.xxx document (3GPP). Martin: I don't see any point in having a LCP request which contains an indentifier. Cullen: But this group is supposed to only create functionality where security is included. The document is missing this level of detail. Martin: So, if a 3rd request comes in, without a policy identifer, then we should ignore. Richard: Your trying to authenticate the identifier againsts an IP address, which is the LCP case. Martin: So we don't need any identifer. Cullen: But this draft will not be used for that type of functionality. You must be able to secure this system. Jon: Re: Emergency Service case: This is the only case where I can see this draft working. Brian (remotely): I agree that this is abig problem. You have a class 5 switch and need location for an ES. The identifier is a phone call. The gateway will query it's location using its own telephone number. The network will then assert the location against that number. The LIS should know the range of numbers and therefore allow location to be determined for that gateway. Therefore this is case where no IP address is used. Jon: I think this is still a 3rd party situation. It only works based on a security pre-association. Martin: ok, so I can put this in the document. Jon: So you add some text which describes the 3rd party case and the assumptoipn that there is a pre-SA between the individual and the LIS. Martin: So, that's your policy. Jon: Without a pre-SA, then this mechanism will not work. James (remotely): NAI is used in WiMAX. Typically there is no mapping of IP address to identifiers in a enterprise. Alissa: I think you need to describe the use cases for the 3rd party scenarios. Jon: I think there are almost all 3rd party cases, but there may be a couple of 1st party cases, where the security threat model is different. IMSI is a long term identifier. Alissa: Sure, but they all need to be explained. Martin: Ok, I'll address the cases where LCP make sense. Cullen: perhaps we could pull in the references to other SDOs which have addressed the IMSI case. Alphabet Soup comment Cullen: This draft is quite heavy on the acronyms. Martin: I agree but I'm not sure what I can do about it. -int-ext & -int-relative-in-tlv - Dorothy Stanley ------------------------------- There is also a draft rosen-pidf-interior, which has been covered in this pressentation. This work is partially in response to a liaison from IEEE 802.11, asking for support of WLAN relative locations. James Winterbottom: Why is ellipse not in the list? Dorothy: I'm sure that it can be added at a later point. It's not in the first draft. Cullen: The IP manager policy issue is quite unique. Richard: What is the difference between the private and the registered int syntax. Dorothy: It's just the way they are registerred. Roger Marshall: It appears to be a subjective reference. Perhaps you should use a wall. Dorothy: Yes, you could use a WG system, with a lat/long. Brian Rosen: This is very useful. But I have two problems: 1) the reference itself. Front door is a string which does not exist on the buliding drawing itself. I would like the reference point to be the civic address itself, then specify a "door" on the drawing itself. This adds another level of INT. 2) the syntax of the offset, is defined as INTs. Normally we would expect to see a normal piece of XML. This document tries to fit into the PIDF-LO syntax and to fit within a TLV. I think this is a poor way to define a new data strucuture. I think we should define a new element instead and have a new mapping to TLVs. Brian: With that I think it would be a really great draft. Dorothy: Regarding the enumeration of the door, we'd then have to enumerate all entities within the building, e.g. door, elevator, water cooler etc. I think our scheme gives more flexibility. Richard: But there needs to be a split syntax, say whay the entity is, then what it's name is. Dorothy: The problem is that the civic address is not enough to provide the referece point. Marc Lisner (remote): IEEE has adopted some of the PIDF-LO work and so we're trying to re-use that syntax. Regarding the explicit reference, I think this is a minor point. When it's mapped to the binary code. Martin: Civic address can identity a reference point for you. I think this is bad way to add a new item. The use cases are good. The binary format is not well designed. It allows mis-understanding. I think we need to get the data format correct, before we consider the binary format (RFC 4476). Roger: One different point would be to think of a virtual rectangle, and then to define anchor points at the corners. Then suite 400 centroid would make sense. The rectangle would then cover any civic location. James Winterbottom (remotely): Why not define a new location type, as opposed to Civic. Dorothy: We're not looking to add a lot of new functionaluty. We just want to extend what's there already. Martin: But you've already added new elements. The extra extensions can move the reference point and cause confusion. Dorothy: But the civic address is still ok. Martin: Every element you add to a civic address, just refines the location. Adding these element should refine the civic address, not move it somewhere else. Hannes: When we added speed and velocity, work in GML helped us. This is a similar problem. We then decided to not use the GML, as they were not backward compatible. Another approach is to go for a propriatery solution. Comparison table (between -stanley and -thomson) Martin: I was asked not to present, but I do have a presentation of my draft ready Alissa: Let's allow Dorothy to go through the comparison table, then you can present. Indoor Location - Martin Thomson -------------------------------- Cullen: The transformation from WGS84 to the map is better attached as meta-data to the map itself, as opposed to the location offset itself. Otherwise, I do like the direction that this is going. Recommendations slide - Dorothy Stanley --------------------------------------- The two solutions are different. recommendation is to progress both solutions Martin: I think the two solutions are not too different and I think it's a matter of getting the XML model right first. Then the binary part will come afterwards. I think two RFCs is a bad idea. Dorothy: Sure, but the binary representation is very important. We should be able to sort this out offline. James Winterbottom (remotely): How does a device obtain this location from a LIS, as it should be able to do that. Martin: Basically this is asking whether the location offset is spceific to the location. Well, yes it is. It would not be useful in another context. Perhaps we have to define an inner and an outer offset (perhaps for emergency service use). Alissa: But if you receive more detailed information, which you don't understand; I think you can ignore it. Marc (remotely): You wouldn't send all the offset information to a LIS server. There is product and running code based on the earlier work. Richard: But I don't think that will change the XML to binary conversion Brain (remotely): I think we need 1 solution on this. I don't think the compact biary requirement is not a bit issue. I think we should be able to compromise quite easily. Geodetic Datum to Civic address - Robins George ----------------------------------------------- Alissa: how many people have read the draft: about 5 Martin: I'm not sure that this is right place to put it. I like the concept. Geo-coding is quite useful, but location requests in HELD is not the best place. Perhaps a new request or even a new protocol should be created. Let's look at what people are using out there. Discovery of geo services would also be usful. It could also go into LoST. LoST needs an extension to provide this reverse look up mechanism. Therefore the draft needs some more thought. Roger: I like this document and its a good idea. In an emeregency context, PSAPs don't have a exchange protocol to communicate with each other. Something based on LoST is perhaps the way to go. Robins: But I thought the WG said, don't geo-code in LoST Martin: Yes, so perhaps another protocol needs to be found. Brian (remotely): Yes, I agree, but this should be a new protocol. it may have some good uses within NENA. Richard: Ok, so please can we have some more discussion on the list. -policy-url - Richard Barnes ---------------------------- LbyR (location by reference) Hannes: In the intiial HELD submissions, there was some text about policy. But how do you apply the policy. You need to authenticate and then use the LIS itself. Even today, it is not solved correctly. Within the DHCP document, James Polk wrote another mechanism to do this. The HELD approach is still rather heavyweight. Richard: You might want to upload some geographic information, which does not contain any identity information. Hannes: But many location service servers need some understanding of identity. Not everyone has certificates? In addition, these policies are quite complicated. There are some overlaps with the HELD policy document, but it's still not clear. Martin: I don't think this is deployable. I don't see why is it required. You establish a policy in one place and then you don't worry about the local access provider. Perhaps we just need the ability to invalidate the refernce. Jon Peterson: If I get a location and then give it to someone else, then this may be appropraite. Martin: You say, here's my policy. What happens when the IP address is re-allocated to someone else. This can be a real mess. Regarding JOn's question, can we fallback to location based authentication, but I'm not sure. === AoB --- Martin: Can I also have comments on the list about -immediate-publish, which may have some relevance here.