Minutes - GEOPRIV - IETF72 Summary: The list feedback on the LC of draft-ietf-geopriv-sip-lo-retransmission-00.txt has all been positive to date. James Polk expressed significant discontent with the document during the meeting - his interpretation is that the document leads to a requirement that every INVITE request include a new header. After brief discussion, the consensus in the room was still in favor of progressing the document. Ted and James will follow up after the meeting. (Note that this WGLC ends August 1). While discussing draft-winterbottom-geopriv-deref-protocol-02.txt, there is a suggestion to have a single central document discussing authorization that all dereference documents reference. Hannes will look into what existing text we might have in various documents and send a proposal to the list. The people in the room were comfortable with continuing to pursue the plan of meeting as many of the requirements in the filter/event documents submitted for this meeting using the Presence event, the SIMPLE filter functions/formats (with any necessary extensions) and working with SIPPING to refine the throttle document there. We will revisit how to address any requirements that remain. The participants hummed to adopt draft-barnes-geopriv-lo-sec-03.txt as a working group item as a starting point for an update to 3693/4. During discussion the participants reconfirmed consensus that possession of a reference is equivalent to having the value and that consensus is documented properly in this document (with one dissenting voice). Richard and Hannes will work together to ensure we don't end up with two updates to 3963 in flight. Ted Hardie disclosed that he may be aware of IPR related to one or more of draft-polk-geopriv-pidf-lo-4-agps-00.txt, draft-polk-geopriv-pidf-lo-timezone-element-00.txt, and draft-polk-geopriv-pidf-lo-ext-4-triangulation-00.txt and will follow up with the appropriate statements and comments to the list. There was discussion that we are starting to talk about determination, which will have to be addressed in the charter, and that coordination with other organizations would be appropriate. Richard Barnes and Ileana Leuca are working to coordinate with OMA. There were several suggestions for a conference call in the September time frame including Geopriv, Sipping, and OMA participants. The consensus of the people in the room was that the proposed charter was mostly on track with the following comments/exceptions: * The third bullet in the immediate goals section (analysis of migration technologies) is too general. The suggestion is to replace it with actual milestones analyzing specific problems/technologies. * The lis-discovery mechanism goal should explicitly put pressure towards reusing existing discovery protocols rather than inventing yet another. * Maintenance of PIDF-LO should be made explicit * The wording on interacting with other working groups should be aligned with similar text in other recent RAI charters. There was discussion on how to structure the conversation around 3rd party access to location information about a target (in particular OBO), which will continue on list. Ted will send a message to the list focusing on the rulemakers role in these interactions to assist with framing the conversation. Raw notes from John Elwell, Bruce Lowekamp, and Christian Schmidt follow: ------------------------------------------------------------ Raw notes: GEOPRIV at IETF72 Notetaker: John Elwell 5m Administrivia/status updates Robert draft-ietf-geopriv-sip-lo-retransmission-00.txt draft-ietf-geopriv-lis-discovery-02.txt The chairs asked to defer charter-related dicussions to the final agenda item. Ted asked why we can't discuss chartered items first - consequently slight rearrangement. Mary sent proposal to list on draft???? Chair asked for explicit indications that people have read and are happy with review documents. Retransmission WGLC. Polk: Unsure whether this is a serious draft, and how this would be viewed by SIP community. Chair indicated that SIP had been asked but had given no feedback. Polk: Concern about impact on ALL INVITEs of having an extra header rather than a parameter. Peterson: is that your only substantive concern? Ted talked us through some additional slides available on this topic. Header rather than a parameter gives a way for someone downstream to add. If problem, could go back to previous mechanism, but need some method to handle other part of problem. Peterson: Two approaches: Design trade-off, depending on whether you consider rule-maker bound to UA. The recommendations (extract from draft) were walked through. In particular, a UA can insert the Location-Routing-Allowed header field even if it doesn't include a location. Keith: up to SIP WG to decide whether it is a header or not (although most likely it would be). Ted: This is meant to be a semantic expression of what is required. So wants to know if this is semanticly wrong. Chair: Asked who thinks semantics in draft are clear and who don't. James only one who did not think they are clear. Ted: How many agree with semantics in draft. About 12. How many object? Just James. Propose that that he, James, Jon etc. meet to work this one out. James: Prepared to go with parameter, but had a particular issue with previous draft, and resolving that issue should not have resulted from a change to use of a header rather than parameter. Doesn't address issue of UAS seeing this information. Ted: It is in the draft. Henning: Didn't see anything on B2BUAs. Ted: There is a section on this. Chair: Fairly widespread consensus to progress the draft, with exception of this one point. 10m Geopriv Policy Hannes draft-ietf-geopriv-policy-17.txt No slides. Went through all issues and posted updated last version, on which WGLC was started again. Hannes had raised one issue on time zone parameter, whether user cares about adding permissions to do with time zone. He had got no response. ???? Didn't want to spend further time on this. 10m lbyr-requirements Roger draft-ietf-geopriv-lbyr-requirements-03.txt 03 has been there a few weeks, and changes documented in appendix. Have been some comments from Martin. Plans to add various suggests in. Cullen: received a formal request to attend to absence of slides on web site. Chair explained that he didn't get slides until extremely close to the meeting start. The meeting paused to rectify the situation. 15m deref Hannes draft-winterbottom-geopriv-deref-protocol-02.txt Hannes described what had already been presented at interim meeting. Asked what next? ???? Questioned whether there was sufficient text on the two authorisation models. Hannes feels that sufficient is in there. Martin: Drafts talks about the different models, but it is not the job of the dereferencing protocol to describe this - described elsewhere. Marc Linser: Doesn't see a means to publish the rules. Hannes - that is in context document. Marc Linser: Shouldn't we mandate that the rulemaker uploads the rules. Hannes: What should I write? Marc: That MUST accept the rules of the rulemaker. Hannes: context document. ???? That is in a different document. Hannes: We talked about this at interim meeting. Rosen: Prefers the way we structure documents in this group on dereference is that we have a central document that all dereference documents can reference. This present document should not have the normative text that it does on authorisation. Polk: +1. Hannes: Who else think it is good idea. Martin does. Henning: Should not worry about whether there is room for another document - if we need it we should have it. Hannes: we have moved it around to different places, as our understanding changed. Henning: Perhaps just a matter of extracting text from existing documents and putting it in central place. ???? There is some starting text in draft???? Roger Marshall: There is a requirement that must support privacy rules, and interaction with rulemaker is out of scope. Summary, Hannes: Should investigate whether content is already covered in Richard's document, and if not will put proposal on list. 20m location events/filters Robert draft-ietf-geopriv-loc-filters-02.txt draft-winterbottom-sip-location-package-00.txt draft-polk-sip-location-get-00.txt Proposal for way forward - see if all requirements can be met by extending the existing presence filter framework. Several people expressed agreement with this. ???? Add what we can to presence event package, and then deal with what we can't. Rosenberg: It is more a question of whether the presence event package is the right thing if all you want is presence. Summary: continue down this path. 10m exploring 3963/3964 updates Richard draft-barnes-geopriv-lo-sec-03.txt Henning: Unsure about terminology - maybe better words could be found for some things, e.g., public/private. Polk: Thinks the possession model is broken. Can we find a way of coming to consensus on that topic? Rosen: We have talked about this lots of time, and thinks we have consensus that having the reference is equivalent to having the value, and that this is documented correctly in this document and reflects intentions of WG. Applause. Sparks: To answer James, group thinks we have had the discussion and have consensus. Nobody disagreed with this, apart from James. Ted: Gave an explanation of a scenario where somebody along the path can change the reference. Richard: Is this more limited approach still cover the major areas of uncertainty in the WG? What's missing. And is update to 3693/3694 sufficient? Henning: Keep it simple. Thompson: Thinks there is overlap between this and draft-????. Is there any benefit in taking stuff out of this and putting it into a separate document and referencing it. Rosen: Yes, but can't have two updates to 3693 at same time. Also need plans for how we are going to deal with some of the things discussed here. Chair: Thinks we can get a milestone for this. Hum for whether this would be a good platform. Unanimous in favour. 20m How to move forward with held extensions Martin (what's involved in making the adjustments discussed in the interim meeting) draft-winterbottom-geopriv-held-identity-extensions-06.txt draft-thomson-geopriv-held-measurements-02.txt draft-winterbottom-geopriv-held-context-02.txt Measurements. Martin: Focus first on additional information required, and then move onto identity afterwards. Richard: Measurements could be used for other purposes. Martin: But that is not purpose of present document. Ted: (I missed this point). Brian: Points us to notion that it is sometimes the endpoint, rather than the LIS, which does the calculation, and if there is some assisting entity providing information. Martin: Need to generalise measurements, regardless of how they might be moved around. But should not bite off more than we can chew in terms of scenarios we cover. Polk: Objects should be separate from transport protocol. Martin: They are. Henning: Location information, how it is represented, and how is it carried. Consistent representation in different protocols would be useful. Not convinced we need to have different drafts for each of the examples listed on slide. EKR from Jabber room: security question. Martin: Believes security section covered this - if not, take to list. Rosen: Would be reasonably easy to restructure document into generic structure and transport sections. Martin: Will look at doing it. Martin: Probably not ready for charter discussions. Context: Proposal to keep snapshot and limited use in draft. Henning: How closely does this follow policy document? Martin: Explained the problems with this. Henning: But what does it mean to restrict one of these, and how do we express these. Although permissions will clearly be specific to use cases, can we stick to existing means of expressing policy. Martin: Doesn't think policy can apply to this, so invites people to say how it can. Hannes: Already posted a proposal on this to a list, but it is a difficult problem. Henning: Concern that if we have difficulty expressing these, they run off the complexity scale. So it may be that the requirements are something we would like to do, but it may be too complex to provide a mechanism. Brian: Also suggests restructuring of this draft along lines discussed previously. Chair: Not in position to adopt the drafts yet - authors have been given feedback on how to improve these drafts. Identity: Not discussed. 20m pidf extentions James P draft-polk-geopriv-pidf-lo-4-agps-00.txt draft-polk-geopriv-pidf-lo-timezone-element-00.txt draft-polk-geopriv-pidf-lo-ext-4-triangulation-00.txt Hardie, had not previously read a-gps draft, but believes his company Qualcom may have IPR. Timezone: Already solved in RPID, so will let this document die. Discussion limited to the other two drafts. James described the similarities and differences. Biased towards SIP is a transport, since the server can create a subscription with the device and get the device to tell it when it has moved. Martin: Drafts define objects. James: Yes, but also define filters and transport protocols. Martin: Very hard to judge drafts on any of those three points, and thinks implementors will struggle. Also feels that expressing filters for satellite readings is not feasible, because satellites are always moving, even if device doesn't move. Also therefore has doubts on transports. Brian: Adding to what Martin says, expression should be in XML, SIP not a great idea for transport, similar concerns to those he had with Martin's draft. Roger Marshall: Seem to be crossing over from location delivery to location determination, which previously was out of scope. James: Yes, but doesn't know where else in IETF these documents can go. Cullen as AD: we are indeed moving outside scope of current charter, and this is in discussion with chairs. The problem space does seem relevant, but need to understand what we can do in the IETF and what has to come from outside. Marshall: OMA has been working in this area for some years, and has started to consideration use of SIP, so would like to see how the two organisations can work together. ???? In OMA there are solutions that have been accepted and deployed for some times. Would like to open the dialog, to understand what has been deployed in market, what are future plans, and what can be done to avoid conflicting specifications. Mary: Would appreciate more input from OMA on what they are doing, and feedback on what we are doing. ???? Dialog in progress to get people together to meeting in Chicago in August (believed to be Tuesday 19th pm). Rosen: Would like to organise a joint meeting, but 19th August too short notice. Mary: Should have more frequent conference calls. Need to include SIPPING too. ???? Conference call could perhaps be arranged for September. Martin: Think we are talking architectural differences, not just protocols. Chair: Will take to list how to get things moving. 10m civic location extensions Marc draft-linsner-geopriv-relativeloc-02.txt draft-linsner-geopriv-adminspecific-01.txt Admin-specific. Henning: At odds with general principles of XML, which already allows namespaces to address issues of extensibility. This would be fine for information items that are meaningful only within a given domain. Concerning removing when they cross a border, this isn't an issue unless there are privacy concerns. This latter is a much more generic problem, and need not be confined to information meaningful only within a domain. Martin: Agree. Second issue of Hennings can be dealt with through policy, and mechanisms already exist for that. So doesn't think draft is necessary. ????: Agrees with Henning, and also concern about changing PIDF-LO as it crosses a border, e.g., because it might be signed. Henning: May need to be sent as a different object. General concerns about removing data, e.g., making a mistake. Relative location. Martin: You are describing a new coordinate system, but I don't know if you want to put this in civic. Need proper consideration of whether to include in civic. Gabor: Don't have GPS inside building, and do agree that relative location is needed. Chair: Seems to be a community of interest in this. If interested, make comments. 30m Charter review Robert including "What kind of OBO-like work can we do?" (please review list discussion prior to meeting) draft-linsner-geopriv-obo-00.txt Chair: Charter available (as went to email list, with one slight change). Any major grief with main body of text (outside of the 3rd bullet). Ted: Would like text to say don't create an additional protocol unless really says so. Keith: May need to look at charters of BLISS etc. to see if wording can be improved. Brian: Add explicit item on maintenance of PIDF-LO. Hum on whether people are OK with charter with exception of 3rd bullet. Nobody against. On 3rd bullet. Ted: Terrible milestone - words are soon loose that almost anything could go there. Need a crisp milestone, e.g., analyse some specific technologies. Chair: This would not be a literal milestone, but we would build milestones based on these. Ted: But could craft almost any milestone to fit within this. Chair: So what can we do? Ted: There is a group of people in wG who want to do class of work X, and some people who think class X is contrary to goals of GEOPRIV. But the proposed words open a can of worms much bigger than just X. Henning: First sentence says one thing, and seems to imply we need to do second thing to make first thing happen, and I disagree with this. Don't know what migration means. Need something more on what we are trying to do and why it is useful. This should be in terms of third parties wanting to obtain location information, not the applications. Might need to express in terms of authorised third parties (e.g., authorised by subject or by authorities). Peterson: Henning pretty much on the mark. Is it the same say that rulemakers have in original GEOPRIV architecture. Laura: Different worlds between here and telephone companies and regulators. They don't care about what happens here, but have own concerns about privacy and regulation. In Germany, will not accept what end user says, for example. Chair. Need to figure out what we think the problem is. Do we want to schedule this question as a priority question. Ted: Really need to put it in terms of how rulemakers act when somebody else is making information available about a target. Focus on rulemaker. Will work with Jon to put together a message formulating this in rulemaker terms. ------------------------------------------------------------ geopriv meeting notes for 7/31/08 note taker: Bruce Lowekamp Robert presents note well and begins agenda bashing retransmission is in administrivia ted hardie: what parts of agenda is chartered work? rs: policy, lbyr, location events th: do chartered work first, then do unchartered work/discussion rs: accepted administrivia: hannes: working on revision james polk: retransmission is not ready if location is being transmitted or 4119 aware without location knowing that some element can insert location, header must always be inserted jon: don't care if it's a header or a parameter. is that a technical concern? james: that's a big deal if it has to be put into every invite message b/c a proxy may insert the location header th: can go back to it being a parameter, but need a way to indicate a desire for a location to not be inserted jon: do we want to imbue uac with rule-making power to describe whether location is permitted, or should that be separated? th: presenting recommendation slide from backup retransmission presentation james: even if uac does not include geolocation header, recommend that it be included th: slide says be allowed james says recommended keith drage: sip will evaluate where the semantics are conveyed in a sip message poll: who believes draft is clear on these points: about a dozen in favor, one opposed poll: who agrees with semantics: about a dozen in favor, one opposed james: #1 issue in email was to deal with how intermediary should see location. draft does not address whether uas should not see location. th: basic mechansim in draft is to include by reference and not allow the endpoint to dereference it henning s: how are b2buas in draft th: there is section hannes: policy update. one issue on timezone parameter. do people care about authorization decisions based on timezone? martin thomson: ship the doc lbyr update slides presented quickly, no coments cullen jennings: have gotten a request for the slides to be uploaded sparks: b/c slides were not given to chair until right before start hannes: deref presentation what's next? marc: is mechanism for rulemaker uploading rules defined? ht: deref is independent of uploading mechanism marc: how are authorizations enabled? ht: section rewritten. depends on policies and types, but uploading mechanism is not specified martin thomson: talks about different models but responsibiity for using and defining is responsibility of lcp, not deref ht: in sip presence, have mechanisms to upload and use, but could do others things marc: even in usage rules, don't see mechanism to publish rules to list and attach ht: that's in context, not this one marc: if we are allowing dereference this way, shouldn't we support this mechanism to upload the rules? martin: that's in the location by reference doc. it's part of the solution marc: want to see that machinery will accept rules and will adhere to rules of rulemaker martin: talking about relationship between location recipient and location server. interaction between location server and rulemaker is different interface in different document. brian rosen: should have sent comment to list. would prefer that way documents are structured in this group (dereference issue) is that there is a document that discusses posession models and access lists independent of actual implementing protocol. any dereference protocol should reference this permissions model draft. any future protocols should also have same properties or compare properties. can be requirements doc or something else, but would prefer that this draft (this part of solution) not have its own section describing this model. james: +1 henning: +1 seems to be rough consensus that a separate document describing these models should be created. first will evaluate whether richard's document might meet this criteria already. sparks: location events & filter presenting slides ask for comments on proposal for path forward +1, +1, +1 martin concerned about 4th pint, but happy otherwise jdr: does not thing that merely preserving prior decision justifies path, but general concept is good. martin: agree with jdr. presence filter package is going to be used for this, don't see way around this. need to add what we can to this. jdr: isn't either/or decision. presence takes state that exists and puts into single format. no doubt that location is piece of presence, is question whether there is a separate event package. consensus in favor of path draft-barnes-geopriv-lo-sec-03.txt presentation by Richard on prvacy scenaarios slide henning: public vs private is complicated for example by publishing previously unknown url context is word like session that should be used with great care james: thought general consensus was obo is bad chair: deferred to end of meeting james: concerned about possesion model. is concept that knowledge of uri can mean access is ok? brian: thought decision had been made that possesion model is ok as well as access model is ok. thought this draft is ok dealing with this model with wg consensus. end-to-end assurances slide martin: end scheme only can work if endpoint is somehow trusted question slide: is this enough henning: only appropriate to do a bis if 3693/4 become impossible to use w/o constantly referring to lo-sec martin: overlaps with hannes' document brian: can't have both if they both update 3693 poll: is this document good platform for adoption to update milestone? strong hum with no opposed martin thomson presenting held-extensions richard: measurements are not our concern? martin: yes, not our concern th: yes brian: another draft with same things but different transport. notion that we are moving is a useful thing. assist information can come from different elements. notion of measurements moving around should be generalized. james: as author of other draft, objects should be defined separate from transport protocol henning: it is not helpful if different protocols use different containers ekr: what if LIS lies martin: believe that is in security section held contexts slide henning: how closely does this follow policy document? henning: general concern that if it is difficult expressing policy, maybe requirements are not implementable. brian rosen: again, notion of policies is independent of the protocol. need to have common source ht: what is outcome? chair: feedback to authors is solid. no consensus on wg adopting these at this point James Polk presenting pidf updates th: ipr claimed on gps docs for qualcomm richard: request statement to be clarified with respect to held gps docs martin: drafts define objects. james: objects, filters to request, and transport protocol. martin: it's very hard to make comments because doesn't introduce own technical material, but duplicates material from measurements draft brian: also found it hard to understand these drafts. thought ideas should be expressed in xml, and sip isn't best transport. same comment that types should be extracted and transports should be separate. data is not location data, it is data that might be used to calculate those measurements roger marshall: crossing chasm into location determination cullen jennings as ad: intention is to look at this issue as part of charter updates roger: would like to work together with oma as they are starting to look at these issues and integration with sip iliana as oma liason: oma has deployed and tested enablers. would be extremely useful to open dialog and ensure understand what is deployed in market and not conflict brian rosen: happy to hear about this and would like joint meeting. discussion of possible joint meeting with oma at their august meeting, but very soon (8/19) mary: sip/sipping would like to know about and interact with on any potential sip event package etc, as early as possible marc presenting henning: xml is designed to allow extensibility. by defining specific extensions like this, you lose that easy ability without any advantage. really addressing two problems. 1) locally meaningful terms (like namespaces) 2) want to remove these elements as messages are traversed martin: agree with henning that the fields don't belong here. if 2nd requirement that fields need to be removed, can address in policy, and already mechanisms to do that roger: thought changes to pidf flow are constrained on relative location martin: this defines a new coordinate system. do we want this to be in civic? ?: need relative location, from front door james: can be well known point chair: let's get those interested on this together on list sparks: proposed re-charter discussion th: we discovered that there are currently 17 discovery protocols and would like to discourage creating an 18th. PICK NOT CREATE except under extraordinary duress keith: is standard coordination text in the charter? rosen: maintenance of pidf is not actually in list poll: is this charter prose (not third bullet) OK? strong in favor, none opposed third bullet discussion begins th: this is a terrible milestone. it doesn't constrain the problem. sparks: this is a goal, not a milestone th: doesn't offer any help on what milestones fit under goal th: is goal to specify how we are/aren't doing wrt OBO henning: first sentence says one thing, seems to imply that third bullet is required to do that, but this is not true. Unclear what migration means, since we're not migrating from anything. goal is really that 3rd parties are able to obtain location. sparks: which 3rd parties? do we want to constrain who can obtain it hs: this is an authorization problem, by target or LI sparks: are we getting into something which would be emergency services specific jon: henning is on target, this is about rulemaker. we've forgotten clarity we once had about rulemaker---it might not be the target. the original geopriv model allowed a very generic understanding about who the rulemaker was. we're trying to define a way to determine how the rulemaker gets their say. ?: ietf, corporate, and regulators are in different worlds. corporate and regulators have different requirements than ietf and don't care about ietf. regulators reject information provided by end device. need to build a bridge to have migration scenario to integrate new world with emergency calling, etc. sparks: based on number of conversations on this and having drafts on topic, people are devoting time to identifying this problem. poll: what is relative importance of addressing to other work talked about with exception of core held protocol. are we at a point where we want to manage and schedule this conversation? th: a lot of what's being described is not in terms of geopriv architecture as defined in past. how do rulemakers act when someone is revealing information about a target. Calling a 3rd party reveal OBO is a far easier way to grappel with this problem rather than simply saying this is... a focus on the rulemaker question... ------------------------------------------------------------ Geopriv at IETF72 Note taker: Christian Schmidt Agenda: A lot of side talks already started. Robert want to start with the charter review. Extensions No adaption of new WG items. Where is retransmission Administrative Session. Ted: Which of the argenda is WG item. Group the items, WG item first, then unchartered work. Robert accepted, changed the agenda accordingly. :Administrivia Hannes: We are working on an update (vtl location delivery) Retransmission; James Polk: Is this a joke? Robert: Yet no comments on the list. Night to implement header in every SIP INVITE message. Mandatory header part to be implemented. Ted: Doubt, that it is mandatory. Jon P: Is this all you care about. It is a reasonable approach. James Polk: This became a header, not a header parameter. Jon: Is this a problem. James: It is a big deal, because every INVITE would have to provide it. SIP will have to review Ted: If this a problem, we can go back to a header parameter. Jon P: 1) Rely on rule-maker to get this into the system. Where-ever location goes, policy goes with. 2) What this routing permitted flag is? 3) Design trade-off. 4) UA with rule-make power or within a separate entity. Recommendations in the draft: ( Ted Hardy presented and explained the recommendations in the current draft. This is a copy from the draft. James Polk have read something else. Keith Drage: How to interpret this. Requirement should not be specific about header or header parameter. It is just a container. Majority of the group was the opinion, the semantic in the draft is clear. James, Jon and Ted should clarify this in separate discussion. Feedback on the list. James: Another issue, concerning location / whether to see location. Ted: No it is covered and the reason, why we have not included it in the draft. James: Lets talk about later. Schulzrinne: Whats about B2BUA. Not mentioned in the draft. Ted: We hate them and we want them to go away. We can talk about a bit more text. Hannes: Update on location. Discussion on time-zone parameter. Authorization on time-zone basis. Perhaps for future release. Xx: Do not spent more time of this. LBYR requirements. Cullen James: Slides are not available online. Short break to upload the slides. Hannes: Held/Deref A: What about upload mechanism for the rules. Hannes: It's a different thing. A: In order to meet the architecture. Hannes: Architecture allows both models, depending on your deployment. I rewrote the session already. S Martin: This not issue of the deref document. A: Update the rules, where are this rules described. Hannes: Its part of the general rules. What do you want. It is part of the contents document. The interaction between rule maker and server is not part of this document. X: We need a separate document, to which this document refer, e.g. talking about access list - independent from the used protocol. Possession models and access list. Consistency is needed. Hannes: Do we have room for a further document on the charter. James Polk: That is a great idea. Schulzrinne: Concerned to reinvent things again and again. What is actually be referenced. Hannes: I personally thing, we do not need it. We wrote it down in different document. We moved it around. Schulzrinne: Just coping text and removing specifics. In adding other references could cause problems. Roger Marchall: Protocol must observe location privacy rules / vs. rules are outside of scope. Result: We should investigate, whether the content is already covered in james document and if something could be added or a separate document would be good. Robert Sparks: Filters Proposal for path forward. A: It is great. (4) JR: Fine. Presence state event package - Location is a part of this. More discussions on the list. Barnes-geopriv-lo-sec-03: Richard Barnes - A bunch of security considerations. Henning: Notion public vs. private is confusing. Dynamically changing. Not sure, if terminology is good. Better words would be good. James: Wasn't there a consensus, that OBO is something bad. Robert: We defer this discussion on the end of the meeting. James: Also concerned about possession model. It is broken. We have to provide a separate document. Brian: We have talked about several time. There was consensus, that this were good models. I thought it reflected the consensus of the WG. Robert: Room consensus, for this model confirmed. Ted: This works only for a certain endpoints. I have to assure, that I am talking to X. Richard: We have to have a trust model. Richard: Is this a useful / helpful approach? Henning: Only minor changes needed. X: Overlap to Hannes draft. Perhaps taking this parts out of this draft. It's a separate issue and should be referenced. X: How to use XML thing on this document. Robert: Should we adopt this as basis for a WG item: Accepted. Milestone list will be updated soon. Held Extension (Martin Thomson) - Location related Measurements - A: The measurements could be used also in other context / protocols? - Martin: This is not purpose of the protocol. - Ted: The usability for other protocols can be helpful. - Brian: There is another draft with the same issues, but different transport protocol. Sometimes it is not the list, it is the endpoint doing the calculation. We want to have a generalized notion for these elements. - Martin: We should not start talking about other things / use cases within this WG. - XX: Measurement data is needed in both directions. - James (Author of the other draft): Transport issues should be separated. - Martin: They are - Henning: Not convinced about the e.g. examples, mentioned in the presentation. - Henning: We should avoid to make it too complicated. - Adam: Are there not severe security considerations related. - Martin: Included in the document. - Brian: Restructure proposal: Generic description, Held definition for transport issues. - Martin: Not far away from, I will have a look if doing this. Held Contexts: Not happy with snapshot solution. Proposal: We keep snapshot and limited use in context draft. Henning: How closely does this follow the general policy document. Martin: Difficult, e.g. related to update policy and limited use. These 2 parameters are related to the generation, not the policy. Henning: How do this policy be expressed? Can we leverage common policy framework? Providing a set of composition rules, we do not want to re-invent for this specific things. Martin: I can not see, how policy can work for these things. I can not see, it works. Hannes: Feedback from WS and list: Its difficult and need more work. Henning: Concerned, if we have difficulties in describing - due to complexity. We have to re-thing. What is the minimum, we want to come out with? What are we willing to implement? Brian: Things like lifetime are independent. Independent issues should be separate - to be reference-able from other documents. Hannes: Did we make any decisions? Robert: Feedback of refining this drafts? Hints how to improve were made. James Polk-pidf-lo: Timezone-element: We will let expire. Tri&AGPS Ted Hardy: Ted Hardy has not read the related drafts, but assumes, that his company Qualcom may have IPR on this issue. An appropriate statement will be send to the list. Martin: Drafts defining objects. James: Objects, filters to request the objects, describe transport. Martin: Difficult to make technical comments on the contents. How to implement this? You imagination of filters are na?ve. Your measurements are changing all time. Brian: Struggle to understand this draft. XML should be described. SIP is not a good method for transport. Struggle, how to use PIF for the description of the measurements. James: I fully agree with this. Martin: Offer assistance. James: I know the challenge. Roger Marshall: Is this within the scope of GEOPRIV? James: Fully agree. Series of document moving to termination. Cullen Jennings as AD: We are on the edge of the charter. We have to figure out what are the limits of the charter. Roger Marshall: OMA was working in this area the last few years. OMA has received new requirements to include SIP. We should cooperate with OMA to have one common solution. XX: OMA we have enablers, tested since several years. It would be extremely useful to open cooperation. What has been deployed in the market. We do not want to have conflicting motivation. Mary Barnes: I would like to have more input from OMA. XX. We have a dialog with the OMA location group and will present on the next OMA meeting - Chicago in 19.August. Everybody in the room is invited to participate as representer of his company. Brian: Hard to organize for most people in the WG. Mary Barnes: We need quicker conference calls. We need more understanding of your requirements. XX: Maybe we can have dedicated conference calls in September, related to location. Robert: More information about ongoing conversation will be provided to the list. Expand pidf-lo (Marc Linsner) Henning: Slighly odd notification of XML. Level of indirection. For no particulary good reason. 2 different problem areas. Would like to separte this. Martin: Agreed. That certain things have to be removed is already there. We don't need it here. Hennig: From security, this is dangerous - if people can add / remove things. This do not look like a good approach. Marc: Signing of data would be in the same admin domain. Relative Location (Marc Linsner) Martin: You claim, that you are not describing a new coordination system, You do it. XX: We have already a lot of solutions for indoor positioning, all proprietary. Relative location can be used for this. James: Agreed, but we need semantic for. Robert: Make comments to the list. Robert: Proposed (re) Charter Anybody problems with the bulk of the proposals? Is this something we want to work with? Ted: Don't necessary create another (18. discovery protocol,) Keith: Check if all requ. Are included. Brian: Maintenance of PIF-LO is not mentioned. Robert: Send it to the list. Consensus on bullet 1 and 2. Provide an analysis of proposed migration: Ted: This is terrible, this is a transition. This is not in the milestones. Robert: What can we do to help build these platforms? Ted: This would be fundamental in contradiction to the work of GEOPRIV. Henning: What does migration means. What are we planning to do and why is this useful. Robert: Do we want to include 3rd party conversation? Henning: What is the alternative to the authorization part? Robert: We would focus on something like emergency services. Jon P: Its all about rule-maker. How to describe this rule-maker. Is this the same as chartered in the original GEOPRIV charter. Laura: The 3rd point is important work for us: IETF, PSUB, Regulater are living in different world. Different requirements. PSUBs don't like anything provided by the user, they just do not accept this. It would be important to provide a migration scenarios for this purpose. Robert: What is the problem, how much should be solved here? Is this an important issue. Ted: Rule Maker relationship have to be clarified. This is far easier way to approach to this problem. I will work together with John and provide something to the list.