MINUTES - GEOPRIV - IETF69 Wednesday July 25, 2007 - 0900-1130 Summary: == pidf-lo-profile == * The group is not yet finished with pidf-lo-profile. * It is intended to clarify 4119 and address omissions. * We need to look at RFC4479 (the presence data model) and decide if this document needs to take it into account * The document applies to the use of PIDF-LO in general, including, but not limited to, the case where applications need to specify one location with minimal ambiguity. == HTTP Location Delivery == * Lisa Dusseault needs concrete use cases to help advise on the response time question which is still an open issue * The room hummed strongly indicating they were happy with the path this document is on == Location conveyance in SIP and its interaction with PIDF-LO == * The room confirmed the following two points by strong hum - The group wants a way to say to the network "If you need location to route this request, and you need this particular location object to do that, fail the request instead". - The group wants to leave providing the tool to the using protocols rather than change 4119. * The room hummed in support of having the SIP location conveyance document remain silent on the length of subscriptions associated with a location by reference. * When asked if geopriv should provide constraints about event packages used for location, the room expressed - dereferencing may be done with presence - dereferencing may be done with other event packages - geopriv's recommendations focus on using presence == lbyr requirements == * The room hummed in favor of adopting draft-marshall-geopriv-lbyr-requirements-02 as a working group item == lbyr dereferencing mechanism == * James and Hannes will merge their drafts and consider the using/transport question looking into the feedback Ted's original strawman attracted. There were several comments indicating using was more likely to be the correct path. == DHCP lbyr == * There is interest in this work (and the group still wants to address the problem), but the group is not ready to adopt this draft as the starting point for a mechanism at this time. - Lisa and Ted raise architectural concerns with the ability to carry arbitrary URIs == Location Security Requirements == * There is concern that the scope of the system has changed since the last threat model was published and that it is time for a new analysis - Several participants expressed interest. They will work with Richard to revise the draft and continue to pursue the topic on list. == Other points == * Attendees in the room expressed willingness to use conference calls or other more interactive tools to resolve some of the more contentions issues as they come up. ------ start of notes by Spencer Dawkins------ Notes by: Spencer Dawkins * 15m status/administrivia No agenda bashing happened. Hannes - policy document was revised while in queue, went back to the WG and back into the queue, saw this is pending a review by Tim Polk, included IANA comments, small update, hasn't moved since February. RADIUS Geopriv also confused me - what does "expert review" mean? I thought I addressed all the IETF Last Call Comments. Cullen - off the top of my head, wasn't policy in editor wait for a while? RADIUS draft had very negative comments from RADIUS chair, waiting for that to get resolved. Policy document is still waiting to look at most recent changes, RADIUS draft is waiting for RADIUS chair to confirm changes... Hannes - two options - version in February reflected WGLC comments, I added IANA comments so IESG wouldn't see them again. Robert - slow movement over last couple of months, is slow, won't stay that slow. WG document that fell out of the queue - does group think this is important and needs to be pursued? (binary lci) James - this document originated because of misunderstandings about RFC 3825, we made requested changes, chair left status in "waiting for new draft" and was unresponsive. Robert scanned for who read draft/was aware of it - small number of people, about 7, only 3 expressing an opinion about keeping it active. James - people are implementing, will chase their comments. Concern is that we are still talking about error - significant digits is fine. James Polk - did lots of work on PIDF-LO profile, Robert is looking for feedback on what this document was supposed to be. Hannes - not clear whether this draft covers data model or not. James - PIDF-LO looked useful, but there are about 6-7 places where you can insert different kinds of location, didn't seem helpful or obvious about what is going on. This got pushed off into IGC draft. Basic rules are two years old, didn't change during that period. Concern with post-LC comments is that we can put in users, devices, etc, really sweet but don't know how to choose between multiple locations in various places in the object. Could describe general case plus profile, could separate functions in separate documents. Open to suggestions, but this is getting in the way of being useful. Jon - some stuff in GML I totally didn't understand, we were just saying that there was other stuff we could also do. This doesn't replace anything in RFC 4119, isn't a 4119bis document. Robert - not just applications that talk about one location, right? Ted Hardie - two different questions - intended not to be 4119bis, it's omissions from 4119, is in no sense possible to read this and not 4119, may update but does not obsolete. Second question is "is there anything else editors need to do?" Does presence model require changes to this document, or a new document? Don't think we have had that conversation yet, and we haven't read this enough to decide today. Rohan - any reason to recommend that people DON'T follow the recommendations in this document? Think "no" - argues for "UPDATES 4119". Robert - takeaway is that we aren't quite done yet with this document. Do we need to say anything in addition? Please read 4119 and PIDF-LO document now, and check whether PIDF-LO is done. * 45m http-location-delivery - draft-ietf-geopriv-http-location-delivery-01 Mary Barnes presenting - 00 version taken from Winterbottom draft. 01 draft added terms and tried to make them consistent with other documents. (see Mary's presentation for details) Hannes - terminology stuff has been haunting us for a while, document has redefinitions of other terms, this is a problem. Mary agrees. Suggestion to remove duplicate definitions. Slide 7: Hannes - try to differentiate between IAP and ISP in other documents. Why use new terms? Should be explicitly. James - L2- LCP becomes our glossary of terms? Is this the right place to do it, or in separate terminology document? Slide 8: Brian Rosen - still don't think Response time is useful, but don't want to be an obstructionist. Richard - has a lot of impacts on timers and relationships. Mary thought these timers were independent. Cullen - would wireless technologies end up with really inaccurate location for emergency calls with default Response Time of 0? Robert - who understands this question? Who is paying attention? Ted - compromise is workable, won't fall on my sword, but discussion on list has shown disagreements and these are showing up in other arguments as well. Need to come to agreement in order to avoid continued fights. Lisa - as APP technical advisor to the group - this really isn't compatible with HTTP architecture, could make suggestions if you provided more information about the use cases I could be more helpful. (We will follow up with Barbara) - Wireless network could return a quick value plus a reference for a more accurate value later. James Polk - would there be a response delay in returning a URI? Why is there a response time issue? Rohan - some applications want to block on a socket and wait for accurate information, others don't want to wait. Return location type and response time = 0. Mary - don't have total consensus yet. Slide 9: James - a lot of discussion happened on list since we made these slides. We're thinking "just request civic" in case there are differences between postal and jurisdictional civic addresses. James - how do you know whether your response is postal or jurisdictional? Slide 11: Canada will use both jurisdictional and postal forms of civic. Slide 12: Hannes - refers to underlying question about what this reference refers to. Could ask for value AND reference. Clarify kind of location you want. Later document provides this information. If you always request both types, that could be useful. Richard - need to clarify which dereferencing protocol is being used? James - not necessarily restricted to one mechanism. Hope we can discuss this during dereferencing presentations. Slide 13: Robert - asked onlist whether people were happy with 00 as starting point, got no negative responsive. Still happy? Hums in the room indicate so. Rohan - looking at schema of revised civic, would be nice to add attribute that distinguishes between jurisdictional or civic. Brian - bad idea, can't know what to do based on one attribute. James - what about civic locations that are neither postal nor jurisdictional. LIS document has been around for a while, without much discussion. Document needs to move. Hannes - if someone thinks this is useful, they should just write a document and explain why. Brian - from list - if there is a country that uses A fields in a different way than the post office uses them, we would need to know that, but don't think there are any countries that use A fields in a different way. Miguel??? - currently trying to figure out where to put the number in PIDF-LO Hannes - larger problem - DHCP discovery isn't controversial, but DNS discovery is. If we don't get proper input from other WGs, this will not be good. * 30m location conveyance in SIP and its interaction with PIDF-LO - draft-ietf-sip-location-conveyance-08 Robert - questions from SIP community as background.... James Polk presenting... Robert checked (via humm) on whether he understood and correctly stated some background... Expires=0? Hannes - what does the reference actually point to? this is underspecified. Robert - non-zero Expires need to be defined - what does reference mean? Hannes - what is default type of location? Jon - confused - SIP presence has been specified pretty exhaustively, not ambiguous. Hannes - problem is that user isn't using this, often a proxy is. Brian Rosen - conveying URI, if it's a presence URI, you get to do what you do with presence URIs. Robert - Henning said the same thing (offline before the meeting) James Polk - you can track me as long as you have a presence URI, right? That was a big deal (required polling). Hannes - two ways to do this - we have seen use cases where access network adds the reference, haven't discussed how that works. James Polk - document is silent on this issue, we're talking about what's in 09 draft. James - don't think the document should say anything on this point. Ted - don't think this document should say anything about this, it's the wrong document and probably the wrong working group. Robert - after hum, this is not a geopriv-specific question and should be discussed for using protocols. Ted - question I asked for was "does this document remain silent?" Robert - is "silent" saying that the document says "not our problem"? Ted - levels of indirection are OK, I guess. Speaking for me personally, if you are silent you get the semantics of the type of URI you are using. If you want to say "not our problem", that's better than some alternatives. Rohan - premature to decide where something goes when we haven't decided what that "something" is. Lots of opinions, need to get motivations out in the open to make this decision. Robert - understand, still calling Ted's question for sense of the room. (Sense of the room is that "document shouldn't say anything") Does the Using Protocol only send the target's location? Rohan - is this in a SIP INVITE, or for any REQUEST? James Polk - goes back to "can't lie". Rohan - can set my city, etc. on my UAC. James Polk - can we have more than one location object with more than one identity? Rohan - but you can send any location you like, including "lies". Jon - never been a big fan of expressing multiple locations in a SIP message. Robert - do we want to rule out telling what we know about other entities? Jon - nothing is going to tell you what a URI actually represents. Robert - value versus reference is a separate question? James Polk - I have only one identity in each object, but I may have multiple objects. Hannes - location refers to entity and may have multiple PIDF-LOs Brian Rosen - generally in agreement, would like advice that sending multiple PIDF-LOs can be confusing. James Polk - document says that. Rohan - having problems with terminology, and problems are interfering with my ability to follow the discussion. Is location always about the request URI? Robert - "when you send a request, you're saying where something is from?" Can we talk about location of "something else" - is that the question? James Polk - people have been saying that PIDF-LO could only have request URI location, right? ERROR topic - Is granular error feedback a good idea? James - what about geodetic problem? Interested in a use case. James Polk - "didn't include city", UAC has some information about what the error actually was - need XML error body. James - this information is going to be big enough that an XML body makes sense. Robert (after hum) - will take this off the list * 20m dereferencing lbyr Robert - will enforce the 20 minute limit. Do we only pres? with what event package? Rohan - location is a first-class object, can be addressed directly. -------------------------- (scribe break) Hannes - don't need to say anything about this in the SIP conveyance document Ted - multiple LLs in SIP (was previous discussion) Ted - "may dereferencing be done with presence" - answer in room is probably "yes" - Does anyone object? No one jumped up... Ted - if there are multiple ways, is the current presence event package Rohan put forward one of the ways? Don't see any reason for this document to limit to pres. Brian Rosen - discussion we've had multiple times - something beside SIP-pres - just don't get Rohan's proposal and don't want to hold up this document - not MUST, but CAN Rohan - don't think "no other event package" is relevant Jon - working group should not provide mechanisms that are not conformant to the working group charter * lbyr requirements - draft-marshall-geopriv-lbyr-requirements-02 Roger Marshall presenting... Hannes has provided comments on 02, Roger agrees with all of those comments. James - question about what we call this depends on whether reference is anything BUT a URI - no? suggest we call this a "location URI". Brian - please look at requirements in conveyance draft for conflicts - don't think there are any but need to be sure. James - requirements are requirements. If some LCPs can't do a requirement, note that and move on. Richard Barnes (but I missed his comment) James - about status of this document - held has dependencies on this document and others are coming down the road. I'd like to see document move into WG. Robert - enough people have read the document to call the question (after show of hands) - any objections? none noted by hum/show of hands * held dereference BCP - draft-winterbottom-geopriv-held-deref-bcp-01 and draft-tschofenig-geopriv-http-using-protocol-00 James presenting Brian Rosen - think this is a using protocol, and don't think that's a problem. Hannes - philisophical argument - are we talking about security discussions in the document? Brian Rosen - privacy discussion, don't think anything else has to happen Hannes - we don't do location-based routing with this stuff. James proposal is to merge these drafts. Ted - think merger would be value, but when I put out a strawman proposal about this it went up in flames. Using protocol on top of HTTP caused serious heartburn - need HTTP as a using protocol. HTTP as transport punts too much important stuff to an unnamed using protocol. Keep as individual draft for one more round, consider whether we need to switch to HTTP as a using protocol. * 10m DHCP lbyr - draft-polk-geopriv-dhcp-lbyr-uri-option-01 James was brutally flamed 5 hours after submission - this was a humm in Prague? don't understand. Only issue was "must specify complete architecture before this can move forward" - but 3825 and 4776 didn't do this, either. James - discussion was on access network, this is an entirely different can of worms. "Need to have an architecture described" because I can't see the context. Hannes - do you plan to include text about validity duration? Something that tells both sides how long to store it. James Polk - in the message, or only in the specification? Lisa - please provide restrictions about types of URIs, so many types, could be useless or even harmful? Richard - could use same syntax to point someone to a HELD server. James Polk - but that's not what I'm trying to do. Marc Lisner - same mechanism has been used for other drafts, if we can figure out "unique", we can figure out "unique URIs". - why do we need a timer on this when we haven't had timers on previous mechanisms? This document should say the same thing as other documents - not a solution for mobile devices. Cullen as individual - this is an instantaneous thing, other mechanisms have implicit "zero lifetime", this mechanism could have a non-zero lifetime. James - if this is intended to be used in WiFi, need to say more about this. Robert - people are interested, but not enough interest (after a hum) to adopt as WG draft. James Polk will rev as individual. Ted - following Lisa' point - there are general URI mechanisms that aren't appropriate for every type of URI. As an architectural point, though, it might be useful to decide whether using a *single* option for every using protocol makes sense, rather than individual options. Radius and HELD are pretty different, and a client requesting this might request one over the other or only be able to use one. Architectural questions should be decided first. * 30m location security requirements - draft-barnes-geopriv-lo-sec-00 Richard Barnes presenting. Design team had concerns about security and how objects should be protected. We've been doing threats followed by countermeasures, this document just covers threats. Integrity and Authenticity: EKR - explicit assumption that this is a three-party system. Who doesn't trust who? Hannes - we've had a number of cases come up where people are concerned about information being manipulated in an emergency situation. Are existing mechanisms sufficient? EKR - hard to believe that 911 centers don't roll if they can't verify a signature. Hannes - this is the first step in coming to that conclusion. James - people haven't been exposed to the idea that if you can't trust location information, you can't even apply policy. Jon - what do you see as relationship between this document and 3693? Didn't have list concept at all when we did the work previously. EKR - would be nice to have text explaining why the usual situation (ignore what you don't trust) doesn't apply here. Robert - what's the goal? Adding to 3694? Richard - scope of working group has expanded since 3693, expansion of scope needs to be added. Robert - out of time, hearing that there is interest in the document, but additional work is appropriate. Please work with Richard and fill that in. James - problem is that it's not clear what the 3693 model extensions really are right now. Hannes - useful because it captures a contentious issue, don't want to replay 1000 e-mails again. Robert - in attempt to avoid threads of 1000 e-mails, would like to have more interactive forum between meetings? Teleconf? Text plus Audio? Please consider building your messages more carefully, not replying tit-for-tat. James - more agenda time? Or an interim meeting? ------ end of notes by Spencer Dawkins------ ------ start of notes by Marc Linsner ------ GeoPriv - IETF 69 - Notes No agenda bashing Hannes - question about the policy draft - why is it in and out of the queue. Hannes included IANA comments, why hasn't this moved since Feb.? Cullen - policy draft was in revised for a while, policy draft now waiting on ADs, radius has serious problem with radius wg. James W. - revised civic-lo has been in this state since April, is that normal? Cullen - policy draft status been since May, not Feb. Hannes - I updated the IANA comments.....???????? Robert - Drafts have been moving slowly, but going to better going forward. Spencer - Names please? Robert - What's up with binary-lci draft? It's expired.... John S. - this draft was originated due to confusion on 3825, chair asked for this draft, revisions were made, draft accepted as wg item, chair let the draft drop. Robert - 7 people read it, 3 want it to move forward James W. - people have done implementations and expressed there is still confusion....draft still talks about location error and we don't want location error in this draft. Robert - pidf-lo profile - questions on the slides Hannes - problems intrepreting 4119, this draft still causes confusion James W. - pidf-lo profile provides better intrepretation of understanding the pidf. Intent is to provide guidance as to how to a device will handle multiple locations within a pidf-lo. long discussion about how to intrepret pidf-lo using the profiles set out intially, against the concept of service, device, person Jon P. - Does this ask to stop doing what 4119 says? I hope not. What this draft states is these are additional things that can be done with pidf-lo Ted H. - this is intended to be a profile draft that supplements 4119, it doesn't replace 4119. Is there anything else we need to do with the recent presence data model changes? Rohan M. - this is not intended to obsolete 4119. Is there anything we should recommend people to do that is outside this profile? Ted H. - 4119 does not require the use of this profile Robert - suggests that the wg is not done with this draft.....please read 4479 and pidf-lo draft.... James W.- I want this ready to go for the Vancouver meeting Moving to the agenda presentations Mary Barnes - presenting HELD 00 (see slides) changes from Winterbottom draft Hannes - terminolgy changes required to maintain same across several drafts. Hannes - the terms Internet Access provider and Access Network provider needs defined to be the same across all drafts James W. - Should this L7-LCP be the main terminology document for all other docs? Or do we need a master terminology document. Brian R. - I still don't think the responsetime parameter is useful, but I won't stand in the way of this going forward. Richard B. - I see a problem with having these timers having a conflict with transport timers. Ted H. - If the underlying protocol timers won't wait for the upper layers Cullen - I want people to think about this, will the suggested default of zero be fast enough for an emerg. call in a wireless use case. Robert - Who understands the question Cullen just asked? Ted H. - The list discussion on the list has exposed serious disagreements and we need to resolve. Lisa - A technical advisor, this proposal does have http ramifications, so I need the understand the use cases. Barbara from the jabber - Wireless networks also return l by r Barbara from the jabber - clarification to her comment, wireless network provide both quick and accurate. James P. - Will there be a delay in returning a location uri? Why? Why is there a response time issue? Barbara from the jabber - clarified James question Rohan M. - there are use cases where someone will ask for the most accurate, I don't want a uri James P. - how do you request such? Rohan M. - use the request type and response timers.......... Mary - location type discussion..... James W. - there has been more recent discussion on list about removing the postal and jurisdictional types...my recommend is to eliminate the location types in the request Richard B. - this location type problem extends way further than just HELD Rohan - from the jabber room - Canada will use both jurisdictional and postal Hannes - there is a larger question about how the reference works....there is a question about requesting a reference for civic or request civic when requesting the reference James W. - are you happy that your use case can be addressed with the context mgmt style???? Richard B. - there will be a need to specify what type of uri is returned with the possible various de-ref protocols James W. - HELD returns a uri 'set' Richard B. - this need clear clarification Robert took a hum whether people are happy with this draft at this time... Rohan M. - I was looking the schema and we should add a tag distinguishing between jurisdicational and postal Brian R. - This is a bad idea, a single lo can handle both James W. - If you add this tag, it must be optional. James W. - a different topic....the lis discovery document has been around a while, held is dependant on this doc and this needs to move. Hannes - a comment, please don't add something to the revised civic, it's in a very late stage. Brian R. - If there is a country that represents a jurisdictional and/or postal using the existing tags different for each type, this needs to be known. Ted H. - per the jabber - an optional tag would be useful ??? - from Austria - (ed note, didn't understand this comment) Hannes - the lis discovery is a larger problem, dns discovery is bigger than this context, needs more discussion/review Moving to James P. preso on sip-location-conveyance Robert - the sip chairs launched questions into geopriv - 2 issues - do we want to reject a call that is routed based on the location object where retran. = no? Do we want a using protocol header to express the ability to route the call? Hannes - What does the uri point to? what is the object? (ed note....lost track of discussion) Jon P. - the presence info is totally unambigous....this mechanism will not change the semantics..... James P. - the target controls what is sent... Hannes - NO, this Jon P. - no, we must use the sematics of presence Brian R. - if we convey a presence uri, you use the sematics assoc. with presence, nothing more, nothing less Robert - Henning agrees with Brian James P. - this is not the understanding of the wg over the last several years. Hannes - take this example, there can be a presence uri where the rulemaker has control, but if the uri is inject by a proxy, how does this work? James W. - There is enough extensibility with the uri mechanism to allow semantics.. Ted H. - I suggest this document remain silent on this point. Robert asked for hum....consensus was that this document will remain silent on this document. Hannes - We need a document to address this.... (ed note....lots of discussion...not captured .... sorry) Robert asked for a hum - who thinks this doc should remain silent on this issue....rough consensus is to remain silent. James asked about which lo can this protocol retransmit Rohan - can I lie about my location? Jon P. - (ed note...distractions, don't understand) Jon P. - the rules are within the pidf-lo, no where else Brian - I agree Hannes - the doc should be silent Jon P. - the semantics for the pidf-lo are in the pidf document and does not need to be in outside that doc. Brian - I agree with Jon Rohan - I am difficulting with the terminology. Does sip only send location assoc. with the request uri? James P. - some believe that sip can only forward the location of the uac in the request uri James W. - how do you handle errors on the geo case? James P. - I don't know Hannes - We must figure out how to handle granular for geo James W. - maybe we need an xml solution? How about the LoST error Robert - next topic has a time limit......only 20 minutes James P. - what event package should this doc state ??? Rohan - location is a first class that we need to address appropriately....like other things, calendar, etc. location is a first class object Rohan - I purpose an event package that we use for location only....it's a first class data, it needs an event package of it's own Jon P. - my comments are pertained to the geopriv charter. this wg decided years ago, due to the desired attributes, that pidf-lo is the wg mechanism, we don't want to repeat these semantics in a new event package Ted - from the jabber room - Hannes - I agree, this has no bearing on this document.. (ed note....left room...) Roger Marshall presentation. James W. - do we believe a LbyR will be anything but a URI...we should call it a locationURI Brian R. - I would ask that you review the req. in conveyance for conflicts that they agree with this draft James W. - reqs. are reqs. - I don't think there are reqs. targeted at a particular conveyance type Richard B. - the req should be dereferencable by the client? this shouldn't be part of this draft (from the jabber) this draft should apply to all James W. - HELD has dependencies on this draft, I want this to move forward... Robert - who has read this document? Robert - who believes this document as a wg item.....consensus is that this doc is now a wg doc. James W. preso on a http dereference... Brian R. - the entity that is de-ref is the watcher.....the location server must take into account all the privacy rules.... this is a using protocol Hannes - I want to know what you have to write into the document to be declared a using protocol vs. a transport protocol Ted - I believe a valuable to merge the 2 proposals....my conclusion to my earlier strawman is that there are many in the wg is that http must be a using protocol James W. - location uri are much more complex than location bv value....this needs sematics Hannes - I think this needs synced with the semantics in the other location uri drafts... (ed note - discussion about dhcp being for the wireless use case) (notes missing) Robert - can this document be used for a wg item. consensus is to wait.... (from the jabber) g.caron hummed for pursuing this draft.... Richard Barnes preso..... Eric R. - this seems reasonable....there is an explicit assumption this is a 3 party system. Hannes - people believe that location data can be manipulated..... Eric R. - I don't believe that a psap will treat a location the same whether the location is signed or not Hannes - ? James W. - People don't understand the enormity of the problem Jon P. - we need a way to secure location information - how does this compare with 3694??? - this document should update that 3693/4 Eric - there is an explicit assumption there is an adversarial relationship between the target and watcher James P. - what is your goal with this draft??? are you adding to 3693/4??? Robert - we are out of time....there is interest in the doc, get with Rich. revise and bring it back to the list James W. - I have a concern that 3693 does not cover the use cases....the threat model has increased Hannes - this document is useful... Robert - as we are working forward, trying to avoid death by email, I would like to use conference call, text chats, etc. to help. James W. - we need more agenda time ------ end of notes by Marc Linsner ------