Topic - geopriv 68 - minutes - Thursday 3/22 9am - Notetaker: Robert Sparks - Summary - The group bashed the agenda to focus on l7-lcp. A series of hums confirmed that the group believed it was important to produce a single HTTP based l7-lcp solution. After hums did not produce a clear consensus choice between HELD and RELO, the group agreed to accept a plurality decision to move forward with the HELD document as the basis for continued work. - Steve Norreys volunteered to edit a document separating the On-Behalf-Of and Lis-to-Lis requirements from l7-lcp-ps - It was noted that elements in the Identity Extensions could be separated from the HELD documents - Raw Notes - Agenda Bashing - brian rosen - rearrange to focus on l7-lcp, don't talk about location signing (agenda so adjusted) - Document Status reported - jon points the group to the LC in SIP on location conveyance - pidf-lo-profile will be revved after meeting - Future Directions - Cullen Jennings - urges group to focus on making decisions around the analysis done so far. - LCP oriented polls: more than one lcp protocol? More than one l7-lcp? Will there be a SIP one? Will there be an HTTP one? - More than one lcp protocol - Brian Rosen - we made this decision - there is no one-size fits all - James Winterbottom - we have a WG requirements document for a new one - James Polk - There is already more than one, but there doesn't have to be more than one in the IETF - HUM: more than one ietf specified lcp protocol (in addition to LCP): - Strong Hum in favor. No hums opposed - jabber scribe reports strong support in the chatroom - SUBSCRIBE based approach using SIP - Brian Rosen: Each new option adds to the set of things each phone must implement - Rohan Mahy - I though this wasn't LCP, but was a general fetch mechanism for location information - Jon/Henning: (clarification that taking this discussion in the context of LCP doesn't constrain the general use of SUBSCRIBE mechanisms) - Jon/Henning: (can separate discussion into direct retrieval and mechanisms that include indirection) - Keith Drage: We had agreement that phones will have to implement all lcp protocols - earlier discussion that we're just creating options seems to go against that agreement. - HUM: Do we want to specify an event package that a target can use to subscribe to location (direct or indirect) - In favor: Strong - Opposed: None - No voices from jabber room - (non exclusive) Do we support a direct mechanism - Peter Blatherwick - are we talking about trying to change existing l2 mechanisms? (Room answers no) - HUM : Do we support a indirect mechanism - Favor : Strong - Opposed: None - HUM : Do we support an direct mechanism - Favor: Very faint - Opposed: Strong - Jabber room: some support reflected in favor on the jabber room - (Strong room consensus against, 13 in the jabber room for, but see note on delay) - Discussion: the delay on the jabber room may have confused the inputs on this hum from the jabber room. - HUM: Pursue extending existing l3 geopriv sponsored solutions w/ subscription (extending protocols like dhcp to support subscriptions) - Favor: Strong - Opposed: Some - Chairs: Consensus in Favor - HUM: Pursue solution for indirect lcp through layer 7 mechanisms - Favor: Strong - Opposed: None - HUM: Do we pursue an HTTP based approach - Favor: Strong - Opposed: none - (Long discussion on quality of reviewing requirements around dereferencing mechanism protocols ) - Kieth - urges us to make sure we're building towards the right things - Ted - confusion may stem from whether mechanisms are mandatory to implement - Henning - these hums are intended to prioritize work - HUM: Do we have more than one dereferencing mechanism (at least HTTP) - Favor: medium (clarified and repeated: strong) - Opposed: none - l7-lcp - discussion of document status - discussion of reorganization of document - discussion of obo and ltl requirements - Cullen: Privacy and Integrity need a viable story on these items before it could be brought in as a working group item. Its not clear that we can build a protocol meeting the OBO requirements - perhaps they should be pulled out and reintroduced when we're more convinced we can meet them. - Henning: Do we pull this document back for more editing and discussion? It's in WGLC now. - James: In constrained environments we feel we can meet the requirements. - Cullen: Difficult to pass documents that only work in specialized networks. - Henning: Delaying this document much will make it irrelevant - HUM: Do we keep obo and ltl requirements in this document - Favor: Strong - Opposed: Strong - chairs: That wasn't conclusive (15 in favor from jabber room) - Rohan: Could we put these in a separate document? - HUM: Would anyone be opposed to putting obo and lts requirements in a separate document - Result: no opposition - Steve Norreys volunteered to edit this separate document - Choosing an l7-lcp protocol - Presentations - HELD - Identity Extensions - Rohan: could be separated from held documents - Ted had a comment that I didn't capture (place holder for followup) - l7-lcp-requirements-compliance - RELO - Jon: Is it important to have exactly one answer to this question (other groups could chose one of many) - Ted: Between very similar solutions, we should go forward with one choice - Marc Linser : If we allow multiple solutions, we effectively require multiple must implements - Other comments in support of one: James Polk, Peter Blatherwick - HUM: Should this group produce a single HTTP based l7-lcp solution - Favor: Strong - Opposed: none - HUM : Are you informed enough to make this choice - Yes: Strong - No: Weak - jabber room is in favor - chair: result is yes - Rohan : when we pick one, the current contents of that will be subject to change - HUM: As a basis for the sole solution - Held: Strong (strong from jabber) - Relo: Strong - chairs: that was not conclusive - HUM: Is it important to solve that today - Yes: Strong - No: Few - Ted suggests we try to accept a plurality vote - HUM: Will the group accept a plurality for the decision? - Yes: Strong - No: none - Counts - Held: 22 (+15 in jabber) - Relo: 23 (+0 in jabber) (cullen cast the last vote in the room) - (ADs confer) : We appear to have a plurality. We agreed to accept a plurality - Ted: Your task now is how to bring this decision to the list. Stress the two above points. Give people who have not yet participated an opportunity to bring strong concerns with the process to the list. - Marc Linser: This decision was not on the agenda before the meeting - Henning: Would feel more comfortable if there were a representative design team on the new basis document - Andy: Can we hum on deferring the non lcp parts of held? - Otmar: We did not include the extensions in the process we just executed - geo URI scheme - Slides presented: Several members pointed to issues with the proposal.