Last Modified: 2005-02-08
Done | Discuss initial geopriv scenarios and application requirements i-d's | |
Done | Discuss initial geographic location privacy and security requirements i-d. | |
Done | Initial i-d on geographic information protocol design, including privacy and security techniques. | |
Done | Review charter and initial i-ds with AD, and have IESG consider rechartering if necessary. | |
Done | Submit geopriv scenarios and application requirements to IESG for publicaiton as Informational RFCs | |
Done | Submit security/privacy requirements I-D to IESG for publication as Informational RFC. | |
Done | Submit PIDF-LO basic geopriv object draft as a PS | |
Done | Initial Common Rules base object draft | |
Done | Initial Common Ruels GEOPRIV object draft | |
Done | Submit DHCP Civil draft as a PS | |
Feb 05 | Initial bis-requirements document | |
Feb 05 | Confer with SIP WG on SIP using protocol draft as PS | |
Feb 05 | Submit draft-ietf-geopriv-policy as PS | |
Feb 05 | Submit draft-ietf-geopriv-common-policy as PS | |
Mar 05 | Close or re-charter for GEOPRIV-MAINT | |
Mar 05 | Submit draft-ietf-geopriv-radius as PS |
RFC | Status | Title |
---|---|---|
RFC3693 | I | Geopriv requirements |
RFC3694 | I | Threat Analysis of the geopriv Protocol |
RFC3825 | Standard | Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information |
Minutes of the GEOPRIV Working Group at the 62nd IETF
----------------------------------------------------- Co-Chairs: Allison Mankin Randall Gellens Andrew Newton Minutes: Medhavi Bhatia Edwom Aoki 1) Agenda Andrew presented an alternate agenda from the one circulated on the mailing list so that all the presentations could be reviewed with proper question and answers. His proposal was to eliminate any discussions specific to re-charter. There were no objections. 2) Status of PIDF-LO Andrew noted that this specification was pending IANA clarifications. Jon Peterson informed the group that he would meet with IANA to complete the clarifications. 3) GEOPRIV Common Policy Andrew noted that work on draft-ietf-geopriv-common-policy was holding on last call comments regarding the use of substitution groups vs. <any> elements in the XML Schemas. He also noted that discussion regarding unauthenticated vs. anonymous access had been moved to the SIMPLE working group. Regarding the direction of the XML Schemas for this draft, it was noted that one use case was offered showing the need for <any> elements and none offered for substitution groups. Andrew asked for any arguments for the use of substitution groups. None were offered so Andrew instructed the draft authors to make the necessary changes to this draft to use <any> elements. 4) NENA Requirements Brian Rosen presented draft-rosen-nena-geopriv-requirements. Brian noted the need for integrity of location information so that emergency calls cannot dispatch emergency responders to forged locations. Questions were asked regarding end-to-end security and integrity. It was noted that the requirement may be for the location generator to provide a signature that is carried from end-to-end. There was also discussion of providing a time-to-live for location information to reduce the amount of time location data is valid. Brian noted that multiple locations are confusing an unnecessary for emergency calls, and there is a need for a deterministic single, unique location. For this, it was noted that rules and guidelines were needed for an algorithm on resolution. Rohan Mahy questioned the need for placetypes. Brian suggested that emergency responders need information regarding the surroundings of the emergency and not just a legal/postal address or coordinates. Jonathan Rosenberg noted that many of the problems under discussion were already addressed by the PIDF specification. 5) PIDF-LO Profile James Winterbottom presented draft-winterbottom-geopriv-pidf-lo-profile. James noted that the GML specification used by PIDF-LO was very large and implementors needed guidance on how to use GML with PIDF-LO. A suggestion for the room was to limit the number of GML defined shapes used by PIDF-LO. Jon Peterson noted that this work was needed. 6) SAML Authorization Hannes Tschofenig presented draft-guenther-geopriv-saml-policy. There were no questions from the room regarding this work. Jonathan Rosenberg noted that is was good work. 7) GEOPRIV RADIUS Hannes Tschofenig gave a presentation on the latest changes in the GEOPRIV RADIUS draft. There were no questions or comments from the room. Andrew asked if the draft was ready for working group last call, and Hannes indicated it needed one more revision to address one known issue. 8) Domain Authorization for PIDF-LO James Winterbottom presented draft-thomson-domain-auth. Jon Peterson noted that original working group discussions around PIDF-LO came to the conclusion that security was only needed for the document as a whole and not in parts. Henning Schulzerinne commented regarding the multiple signing operations and called for a need of a single signing framework, and also noted that signed data in layer 2 network elements will require a location key in every layer 2 network element. Jon Peterson stated that the threat requirement for unsigned layer 2 location information was an unknown. James suggested that it would be necessary for intermediate nodes to add data to PIDF-LO, such as refinement of location information or additional information, and therefore the signature scheme needed to be able to accommodate PIDF-LO modification or additions. 9) HTTP Enabled Location Delivery James Winterbottom presented draft-winterbottom-http-location-delivery. Henning Schulzrinne asked how impersonations would be prevented without additional security measures. He also noted that the scope of DNS and access networks are not equivalent and therefore do not provide a proper match. Randall Gellens asked James to clarify the use case for this work. James pointed out this was about solely passing location objects and location information passed in the act of web browsing. Brian Rosen noted that this use of HTTP added to the overall architectural complexity of moving location information up the protocol stack. He noted that with more choices for transfer of location data, there is a higher likelihood of noninteroperability. Rohan Mahy pointed out that this was the case anyway given the number of layer 2 mechanism that provide location data. Jonathan Rosenberg noted that the use of source IP addresses would be problematic given the large number of NAT devices deployed on modern networks. 10) General Architecture Andrew opened up the floor to a general discussion regarding architecture of conveying location information through the protocol stack. This discussion touched on the trust associated with location generators, trust issues related to regulated service networks vs. adhoc networks, and the re-use of common network configuration mechanisms to provide location information to network nodes. To judge the sense of the discussion, Andrew asked the room to hum if they found work on this type of architecture was needed within the IETF. The hum carried. Andrew then asked if it was necessary to have one universal architecture or if competing architectures would be reasonable. The consensus of the room was that multiple architectures would be reality. Jon Peterson noted that multiple architectures would develop naturally and that the IETF needed to produce requirements and descriptions of properties for network elements at each layer in relation to moving location information from one layer of the protocol stack to another. Many participants in the room agreed that this was a better use of the groups time than to define competing architectures. Andrew asked for draft volunteers to raise their hands if they were willing to write Internet Drafts describing these properties. Many hands were raised. Andrew suggested that as many of them collaborate as possible and to submit drafts as soon as possible. 11) Any Other Business No other business was offered. Andrew closed the meeting. |